Деперсонификация как первый шаг разрешения проектного конфликта.

Я же предлагаю начать прежде всего с деперсонификации конфликта.

Шаг первый.
Нет, это не Стивен - говнюк, срывающий мне-Джону своим упрямством проект. Это - руководитель разработки, который не может обеспечить результат своими ресурсами в желаемый срок.
Поэтому, я бы для начала побеседовал со Стивеном, на предмет того, правильно ли он понял свою часть задачи, на чем базируется его оценка, есть ли условия, при которых он все же успел бы в срок (например, снять самую тяжелую часть работ или добавить ресурсов).
Предположим - нет, но у вас зато есть понимание позиции Стивена и ваше мнение насчет ее объективности.

Шаг второй.
И Уолтер - тоже не говнюк. Он (например) отстаивает интересы клиентов, которым без этого внедрения тяжело пользоваться продуктом. Или интересы Банка, который не зарабатывает или теряет много денег. И вы по итогам беседы с Уолтером более менее понимаете, чем важна дата именно конца следующего квартала и чем она отличается от следующего за ней дня.

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

Уже на этом этапе может родиться компромисс и выясниться, что желаемая задача может реализоваться Стивеном чуть по-другому, что для него будет намного проще, и Уолтер вполне будет счастлив. Вариация: кому-то из смежников Стивена надо будет тоже свою часть работ сделать по-другому.

Шаг четвертый (можно совместить с третьим, по ситуации)

Собрать всех пятерых лидеров разработки ИТ-систем, объяснить ситуацию, варианты.

Тут, о чудо, может оказаться, что кто-то из четырех руководителей разработки недооценил задачу. Или у него не хватило смелости высказаться, и в результате окажется, что не только Стивен не успевает, но и еще два-три его смежника.

По итогам встречи все обсудили развилки и к чему-то пришли. Например:

- Да, все вместе можем успеть в заданный срок но с сокращением объема работ (список предложений по сокращению)

- Нет, большинство считает, что результат - недостижим и эта позиция подверглась челленджу (это обязательно ! )

Челлендж, как описано выше, это:

- а если я ресурсов добавлю?

- а если приоритет этой задачи подвину?

- а если воооот такой бонус команде?

- а если вот это с тебя снять и ему добавить?

Причем, если все понимают важность и ценность результата, то эти вопросы будете задавать не только вы, но и коллеги Стивена.

После челленджа, позиция аггрегируется и доносится Уолтеру.

И теперь в глазах Уолтера не Джон - плохой РП, который не смог выполнить задачу, а объективная реальность, подтвержденная экспертизой со стороны некоторых руководителей разработки.

И Уолтер теперь понимает свою развилку:

 - соглашаться на один из вариантов уложиться в срок;

- соглашаться на более качественный результат чуть позже;

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

Подытожим.

- Джон не говнюк в глазах Стивена и его коллег, сохранил отношения на будущее

- Джон - не лох в глазах Уолтера, т.к. выполнил задачу и принес проект управленческого решения Уолтеру

- Стивен - тоже не говнюк, а - молодец, т.к. подсветил риски не успеть, предложил альтернативу, да еще и мотивирован сделать проект качественно

- Уолтер тоже чист перед своим руководством, т.к. он теперь тоже может донести объективную реальность, если финальное решение не за ним.

Вот так работает деперсонификация.

А вернуться к сценарию лобовой эскалации можно всегда.

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

Типа без него это был третий квартал, а вот благодаря ему - второй.

Представьте, что только ради этого вы бы перессорились с ключевым разработчиком.