Кому покажется глупым топик, прошу просто не читать и не писать коменты
Опишу ситуацию: Банк, отдел сис.анализа: Гл.аналитик , стажер и Начальник. 
Бизнес решил расширяться и берет еще одного главного СА.
Новый гл.аналитик имеет очень слабые знания в области анализа, предментной обл. и самой системы. Раньше работал начальником программистов и решил переквалифицироваться.
Т.к. пришел новый специалист, то заказчик увеличил кол-во требований и сократил сроки исполнения.
Старый аналитик и стажер как работали так и работают с той же производительностью и с тем же качеством. Но задачи нового аналитика не выполняются: долго формируются ТЗ, а затем разработкой отправляются на доработку и т.д. Итог - ни одной выполненой задачи за 2 мес.
Приближается час Х  должны сдать функционал заказчику, но выясняются что он не выполнен. Тогда все задачи перекидываются на старого аналитика и стажера. И сокращаются сроки выполнения.
Аргумент заказчика: вы просили, я оплатил, сроки согласовал - жду отдачу.
Аргумент начальника - нового надо обучать и его должен обучать старый аналитик. Должностные обязанности любого спеца, за это идет ЗП. Найти профессионала на рынке нереально за такую ЗП.
Аргумен старого - я и так обучаю стажера и никто за это не платит. Тем более мне обещали помощь - гл.аналитика. Работать в авральном режиме не могу. Это не мой стиль, делаю много ошибок.
Аргумент стажера - я не хочу работать с новым аналитиком, потому что хочу сам учиться, а приходиться учить его.
Аргумент нового аналитика - работаю медленно, но профессионально. Никто меня пока еще не понял. Я говорил что ничего не знаю, но мне на собеседовании обещали что обучат всему анализу за пару недель, я жду.

Вопрос: как решить конфликт за теже деньги и в срок? Кто виноват уже не волнует. Главное тушить пожар.

Как мне видится:
1. Признать свои ошибки. Если новый аналиттик вменяемы, то см. дальше, если нет, то его выгнать.
2. Договориться с заказчиком о переносе сроков, поставить реальные сроки с учетом п. 1
3. Договориться с новым аналитиком о его обучении

В статье прочел, что "Основная причина «торможения» проектов — это разница между скрытыми интересами ключевых участников и целью проекта".

Что значит "Приближается час Х, должны сдать функционал заказчику ... "? В чем должен выражаться результат - код или  документ?
Если это код, то где программисты ?
Если документ, то я так понимаю надо подготовить функциональные спецификации? Если так , то на Вас вся ответственность, тушите пожар. И к понедельнику хоть что-то.

Сразу скажу, что в теже деньги и срок данная задача не решается, необходим пересмотр бюджета и сроков.

Предложение решить данную проблему в теже сроки и деньги, равносильно задаче собрать из четырех кубиков с буквами А,О,Ж,П, слово "счастье".

Но два месяца скажу это фигня, у нас как-то один аналитик женского пола работал два года и за это время ни сделалала ни одной задачи более менее качественно, а вы говорите жалкие два месяца...

равносильно задаче собрать из четырех кубиков с буквами А,О,Ж,П, слово "счастье".

А на это есть ответ: в задаче же не запрещено найти кубики с другими буквами и собрать слово.

Вы же говорите тушить пожар. Кто сможет только Вы. И проблему можно в теже деньги и срок решить если уменьшить качество. Ну сделайте верхнеуровневые требования.
Или все-таки результат - это код?

А на это есть ответ: в задаче же не запрещено найти кубики с другими буквами и собрать слово.

Вы же говорите тушить пожар. Кто сможет только Вы. И проблему можно в теже деньги и срок решить если уменьшить качество. Ну сделайте верхнеуровневые требования.
Или все-таки результат - это код?

Коллега, я не ТС, посмотрите внимательнее. На мой взгляд, запрет на изменение сроков и бюджета равносилен запрету поиска новых кубиков, такая вот аллегория.

Если очень нужно, и если хорошие отношения с разработкой - тогда можно сократить до минимума документы и работать по этой задаче в непосредственном контакте с теми, кто код пишет, решая неясные вопросы по мере их возникновения у разработчика. Спецификации (или иные документы, предусматриваемые корпоративным стандартом) оформить уже ПОСЛЕ того, как код написан, поручив это упомянутому новому аналитику.
Как-то так... 

Чуть поясню: у нас банк, заказчику интересен функционал (спецификации, код, настройки - никого не волнует). Т.е. есть какая-то проданная клиенту услуга и эта услуга должна заработать в дату оговоренную договором.
Не заработает - потери дохода и лояльности клиента. Потеря клиентов для карманного банка - смерти подобно самого банка.

Но два месяца скажу это фигня, у нас как-то один аналитик женского пола работал два года и за это время ни сделалала ни одной задачи более менее качественно, а вы говорите жалкие два месяца...

Два месяца для главного аналитика  - это мало? Два года ждать. В таком случае нам дешевле к вендору обратиться.
Не, если меня компания нанимает на гл.аналитика, то я в первый день решаю 2-3 задачи. У меня стажер в первую неделю уже решил 2 задачи.

Как мне видится:
1. Признать свои ошибки. Если новый аналиттик вменяемы, то см. дальше, если нет, то его выгнать.
2. Договориться с заказчиком о переносе сроков, поставить реальные сроки с учетом п. 1
3. Договориться с новым аналитиком о его обучении

Ошибки некто не признает. Выгнать из банка человека - сложно. Все по КЗОТ. Судебные тяжбы не выгодны, афишировать не хочеться. Мир банков сильно общается между собой.
И человек добровольно не уйдет - опять же все друг друга знают, найти работу ему будет тяжело, будет бороться. Тем более ему дали высокую зп и без испытательного срока.
Обучать его невозможно, 10 лет стажа как разработчика, Хотели в разработку перевести - начальник разработки его не берет, он  уже 2 р систему подвесил.
 

Кому покажется глупым топик, прошу просто не читать и не писать коменты
Опишу ситуацию: Банк, отдел сис.анализа: Гл.аналитик , стажер и Начальник. 
Бизнес решил расширяться и берет еще одного главного СА.
Новый гл.аналитик имеет очень слабые знания в области анализа, предментной обл. и самой системы. Раньше работал начальником программистов и решил переквалифицироваться.
Т.к. пришел новый специалист, то заказчик увеличил кол-во требований и сократил сроки исполнения.
Старый аналитик и стажер как работали так и работают с той же производительностью и с тем же качеством. Но задачи нового аналитика не выполняются: долго формируются ТЗ, а затем разработкой отправляются на доработку и т.д. Итог - ни одной выполненой задачи за 2 мес.
Приближается час Х  должны сдать функционал заказчику, но выясняются что он не выполнен. Тогда все задачи перекидываются на старого аналитика и стажера. И сокращаются сроки выполнения.
Аргумент заказчика: вы просили, я оплатил, сроки согласовал - жду отдачу.
Аргумент начальника - нового надо обучать и его должен обучать старый аналитик. Должностные обязанности любого спеца, за это идет ЗП. Найти профессионала на рынке нереально за такую ЗП.
Аргумен старого - я и так обучаю стажера и никто за это не платит. Тем более мне обещали помощь - гл.аналитика. Работать в авральном режиме не могу. Это не мой стиль, делаю много ошибок.
Аргумент стажера - я не хочу работать с новым аналитиком, потому что хочу сам учиться, а приходиться учить его.
Аргумент нового аналитика - работаю медленно, но профессионально. Никто меня пока еще не понял. Я говорил что ничего не знаю, но мне на собеседовании обещали что обучат всему анализу за пару недель, я жду.

Вопрос: как решить конфликт за теже деньги и в срок? Кто виноват уже не волнует. Главное тушить пожар.

Кто владелец проблемы? С какой позиции смотрим и чью проблему решаем?

Начальнику надо запустить функционал, новому СА надо удержаться на работе, старому СА не хочеться работать за двоих на тех же условиях что и раньше.

Автору вопроса хочется получить ответ на вопрос о том, какова позиция топикстартера по отношению к описанной проблемной ситуации.

Также автор вопроса считает, что конфликты должны решаться в следующем порядке:
1. Силами руководителя, создавшего проблемную ситуацию и несущего ответственность за этих людей, их работу и отношения с клиентом;
2. Силами всех участников ситуации, за счёт сбора в одном месте, обсуждения проблемы и совместного поиска решения. Важно начать обсуждение с признания заслуг каждого;
3. С привлечением стороннего медиатора.

NB: Предлагаю истории дать кодовое имя «Сколько аналитиков нужно, чтобы вкрутить лампочку решить проблему 4-х аналитиков».

Чуть поясню: у нас банк, заказчику интересен функционал (спецификации, код, настройки - никого не волнует). Т.е. есть какая-то проданная клиенту услуга и эта услуга должна заработать в дату оговоренную договором.
Не заработает - потери дохода и лояльности клиента. Потеря клиентов для карманного банка - смерти подобно самого банка.

Вот это на мой взгляд самый главный комментарий в теме. А раз так значит нужно решать проблему любыми путями, есть такие проекты на которые тратят любые деньги, чтоб обеспечить лояльность закачзика на будущее, потому он потом перекроет затраты этого проекта в других проектах с лихвой и обеспечит новыми задачи, так сказать работа на репутацию.
На мой взгляд виноват в сложившейся ситуации руководитель аналитического отдела, он должен отвечать за провал проекта, но исправлять ситуацию все равно надо, надо договориться с заказчиком о новом минимальном сроке, когда будет готов функционал, а с текущими специалистами, кроме нового гл. аналитика, договориться о сверхурочной работе, если им прделожить хорошие деньги, думаю они не откажуться поработать за четверых.
Куда девать некомпетентного специалиста, пусть опять же будет задачей некомпетентного руководителя, он должен ее решать.

Я в Вашем случае виже управленческие ошибки, а не конфликт:

Новый гл.аналитик имеет очень слабые знания в области анализа

Такой работник должен называться "младший", "стажёр", "ученик мастера", "падаван", но никак не "главный". Независимо от количества лет опыта работы в других ветвях ИТ.

Т.к. пришел новый специалист, то заказчик увеличил кол-во требований и сократил сроки исполнения.

Этого нельзя было допустить. Если это не проект с чистого листа, то интервал, на котором новый сотрудник обучается и работает в минус - 1-3 месяца в зависимости от обучаемости сотрудника.
Любой адекватный заказчик должен это понимать. Больше и быстрее - значит удар по качеству, значит потери на исправление ошибок в будущем, а ошибки аналитиков - самые дорогие ошибки в ИТ-проектах.

Я предложил бы в этой ситуации:
измерить время, которое уходит у опытных коллег на обучение нового, с этими фактами прийти к начальству/заказчику и договориться о переносе сроков, либо уменьшении состава работ. В Вашем случае, возможно, второй вариант более приемлем.

Попробуйте оптимизировать работу всех троих:
1) если ухордит время на консультирование, сделайте регламент(но только краткий, в 3 строчки) процесса обращения за консультацией. У меня это срабатывало в случае когда инженеры дёргали аналитиков, не читая спецификаций. Внутри аналитической команды тоже вполне может сработать.

2) распределите задачи по глубине проникновения в домен. Для эффективного решения некоторых задач нужно вариться в предметной области годами, для некоторых других задач это не обязательно.

3) приоретизируйте задачи по важности для заказчика и тяжести возможных последствий.
Исхожу из предположения о том, что заказанный объём работ выполнить невозможно: лучше работать таким образом, чтобы максимальное количество критических задач было выполнено как можно раньше.

Максимально откажитесь от любых видов деятельности, не ведущих напрямую к выполнению работы. Отчёты, чтение второстепенной почты, совещания... Если у вас дейсчтвительно аврал, то вас поймут.

Все участники должны признать свои ошибки и проблемы, но разбор полётов будет потом, когда ситуация будет решена.