Интересно мнение, поскольку в этом форуме большинство связны с управлением и координацией проектов.
При жестоко регламентированных сроках релиза, стоит ли увольнять Менеджера Проекта, если проект не сдан в срок.
Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать.
Прежде чем увольнять, надо разобраться в причинах. Если человек просто ничего не делал -- это одно, а если какие-либо
обстоятельства, то это другое. Плюс, надо смотреть на сколько сроки поплыли.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, hpux100, Вы писали:
S>Прежде чем увольнять, надо разобраться в причинах. Если человек просто ничего не делал -- это одно, а если какие-либо S>обстоятельства, то это другое. Плюс, надо смотреть на сколько сроки поплыли.
Хороший ПМ всегда сможет придумать обстоятельства непреодолимой силы, которые помешали сдать проект вовремя.
Здравствуйте, hpux100, Вы писали:
H>При жестоко регламентированных сроках релиза, стоит ли увольнять Менеджера Проекта, если проект не сдан в срок.
Вопрос, а кто поставленные сроки соглашался? Этот же ПМ или его начальство? H>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать.
Зависит от степени вины. Можено срезать бонусы, можно уволить.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, hpux100, Вы писали:
S>Прежде чем увольнять, надо разобраться в причинах. Если человек просто ничего не делал -- это одно, а если какие-либо S>обстоятельства, то это другое. Плюс, надо смотреть на сколько сроки поплыли.
Сроки плывут не сильно но уменьшают сроки выполнения задач для других команд, в частности тестирования.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, hpux100, Вы писали:
H>>При жестоко регламентированных сроках релиза, стоит ли увольнять Менеджера Проекта, если проект не сдан в срок. K>Вопрос, а кто поставленные сроки соглашался? Этот же ПМ или его начальство?
Да именно ПМ H>>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать. K>Зависит от степени вины. Можено срезать бонусы, можно уволить.
Здравствуйте, hpux100, Вы писали:
H>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать.
Не сталкивался и не разумно.
Не, если ПМ просто балду пинал, то его конечно надо попросить,
но такие вещи видны еще до окончания проекта.
А в целом, на не совсем простых проектах не может один человек быть ответственным за прокол.
Реальность всегда сложнее и интереснее.
Ну а негативная мотивация — это почти самая худшая из мотиваций.
Хуже только подневольный труд.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, hpux100, Вы писали:
H>>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать.
B>Не сталкивался и не разумно. B>Не, если ПМ просто балду пинал, то его конечно надо попросить, B>но такие вещи видны еще до окончания проекта.
B>А в целом, на не совсем простых проектах не может один человек быть ответственным за прокол. B>Реальность всегда сложнее и интереснее. B>Ну а негативная мотивация — это почти самая худшая из мотиваций. B>Хуже только подневольный труд.
За сроки отвечает именно ПМ с его строны нужна как минимум аргументация почему это происходит.
А какая кстати для ПМа может быть мотивация в случае срыва сроков?
Здравствуйте, playnext, Вы писали:
P>За сроки отвечает именно ПМ с его строны нужна как минимум аргументация почему это происходит.
С этим согласен. ПМ отвечает за планирование, контроль
и своевременную коррекцию если что-то идет не туда.
Но это не означает, что он все сможет сделать.
Он "всего лишь" координирует и является таким же винтиком, со своей зоной ответственности,
как и другие участники проекта.
P>А какая кстати для ПМа может быть мотивация в случае срыва сроков?
Такая же как и у других. Не вижу смысла ПМа обсуждать особо.
Но если ПМов после каждого косяка увольнять, то придется их менять как перчатки.
Менее половины проектов укладываются в сроки и запланированный изначально бюджет.
Не уложиться в план на одном проекте — это еще пол беды.
Намного хуже, если косяки не анализируются и не вносятся коррективы в процесс в целом.
On 13.12.2012 19:26, hpux100 wrote:
> Сроки плывут не сильно но уменьшают сроки выполнения задач для других > команд, в частности тестирования.
Ну так в чем проблема выяснить причины такого уплывания. Может кто-то
планирует слишком оптимистично?
Здравствуйте, bkat, Вы писали:
B>Менее половины проектов укладываются в сроки и запланированный изначально бюджет.
Это сильно оптимистично... Думаю, что процентов 30...
B>Намного хуже, если косяки не анализируются и не вносятся коррективы в процесс в целом.
Обычно за процесс в целом отвечают уже другие люди, типа руководителя проектного офиса...
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, bkat, Вы писали:
B>>Менее половины проектов укладываются в сроки и запланированный изначально бюджет. N_C>Это сильно оптимистично... Думаю, что процентов 30...
Ну 30% тоже меньше 50%
Какова реальность фиг его знает.
Вот здесь говорят о 40%
Но в целом я скорей с тобой соглашусь.
B>>Намного хуже, если косяки не анализируются и не вносятся коррективы в процесс в целом. N_C>Обычно за процесс в целом отвечают уже другие люди, типа руководителя проектного офиса...
В целом да, но это опять же совместная работа.
Процессы, которые тупо навязываются без учета мнения завалившего проект ПМ, абсолютно ничего не стоят...
Здравствуйте, Vzhyk, Вы писали:
V>On 13.12.2012 19:26, hpux100 wrote:
>> Сроки плывут не сильно но уменьшают сроки выполнения задач для других >> команд, в частности тестирования. V>Ну так в чем проблема выяснить причины такого уплывания. Может кто-то V>планирует слишком оптимистично?
Причин несколько, в частности не учли влияние разработки новых компонент на систему в целом, в результате доведение системы до приемлемого качества заняло больше времени. Но сроки сильно сдвигаться не могут, об этом было сказано, тем не менее ПМ утвердил план работ по объему и срокам.
Здравствуйте, hpux100, Вы писали:
H>Здравствуйте, Vzhyk, Вы писали:
V>>On 13.12.2012 19:26, hpux100 wrote:
>>> Сроки плывут не сильно но уменьшают сроки выполнения задач для других >>> команд, в частности тестирования. V>>Ну так в чем проблема выяснить причины такого уплывания. Может кто-то V>>планирует слишком оптимистично?
H>Причин несколько, в частности не учли влияние разработки новых компонент на систему в целом, в результате доведение системы до приемлемого качества заняло больше времени. Но сроки сильно сдвигаться не могут, об этом было сказано, тем не менее ПМ утвердил план работ по объему и срокам.
И в чем косяк ПМ? В том что сроки сдвигаться не могут и он был вынужден утвердить сроки?
Не понятная ситуация...
Здравствуйте, hpux100, Вы писали:
H>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать.
Мне как то один ПМ в аутсорсе говорил одну вещь. Самый страшный провал в ПМстве — это не срыв сроков. К срыву сроков даже в несколько раз все привыкли, и считают это само собой разумеющимся. Ибо всегда будут изменения требований, потери на коммуникации и согласования, и на это вполне можно списать лишнее время. Самое страшное для ПМа, это сделать проект досрочно. Вот в этом случае ПМа нужно увольнять, ибо здесь он расписался в том, что не умеет оценивать время — здесь у него отмазок быть не может.
Здравствуйте, elmal, Вы писали:
H>>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать. E>Мне как то один ПМ в аутсорсе говорил одну вещь. Самый страшный провал в ПМстве — это не срыв сроков. К срыву сроков даже в несколько раз все привыкли, и считают это само собой разумеющимся. Ибо всегда будут изменения требований, потери на коммуникации и согласования, и на это вполне можно списать лишнее время. Самое страшное для ПМа, это сделать проект досрочно. Вот в этом случае ПМа нужно увольнять, ибо здесь он расписался в том, что не умеет оценивать время — здесь у него отмазок быть не может.
ИМХО ерунда... Каждый ПМ всегда закладывает резерв времени на непредвиденные или предвиденные ситуации. Выстрелят они — еще неизвестно, но даже если не выстрелили, ругать ПМа за резерв как-то странно. Всегда можно сказать заказчику, что в качестве бонуса ему сделаем еще несколько задач, или просто перекинем команду временно на обучение/другие задачи/отправим в отпуск...
Вот как раз срыв сроков, о которых ПМ не предупреждал заказчика — вот действительно провал ПМа. Ведь, по сути, срыв сроков на три месяца когда-то начинается сдвигом сроков на неделю. И утаивать эту информацию с тем, чтобы вывалить на заказчика сразу срыв в три месяца — вот самая большая ошибка ПМа...
Здравствуйте, elmal, Вы писали:
H>>Кто нибудь сталкивался с такой практикой насколько это разумно, или наоборот не желательно делать. E>Мне как то один ПМ в аутсорсе говорил одну вещь. Самый страшный провал в ПМстве — это не срыв сроков. К срыву сроков даже в несколько раз все привыкли, и считают это само собой разумеющимся. Ибо всегда будут изменения требований, потери на коммуникации и согласования, и на это вполне можно списать лишнее время. Самое страшное для ПМа, это сделать проект досрочно. Вот в этом случае ПМа нужно увольнять, ибо здесь он расписался в том, что не умеет оценивать время — здесь у него отмазок быть не может.
А что, если затянул сроки — то умеет оценивать?
Я думаю, этот ваш знакомый ПМ просто лапшу на уши вешал.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, hpux100, Вы писали:
H>>Здравствуйте, Vzhyk, Вы писали:
V>>>On 13.12.2012 19:26, hpux100 wrote:
>>>> Сроки плывут не сильно но уменьшают сроки выполнения задач для других >>>> команд, в частности тестирования. V>>>Ну так в чем проблема выяснить причины такого уплывания. Может кто-то V>>>планирует слишком оптимистично?
H>>Причин несколько, в частности не учли влияние разработки новых компонент на систему в целом, в результате доведение системы до приемлемого качества заняло больше времени. Но сроки сильно сдвигаться не могут, об этом было сказано, тем не менее ПМ утвердил план работ по объему и срокам.
B>И в чем косяк ПМ? В том что сроки сдвигаться не могут и он был вынужден утвердить сроки? B>Не понятная ситуация...
Риски он не учел, по критичным изменениям в системе и как они повлияют на качество. Сроки сдвинуть нельзя, объем можно скоректировать. Бюджет можно было увеличить. Неизменны только сроки.
Здравствуйте, hpux100, Вы писали:
H>Риски он не учел, по критичным изменениям в системе и как они повлияют на качество. Сроки сдвинуть нельзя, объем можно скоректировать. Бюджет можно было увеличить. Неизменны только сроки.
А Вы уверены, что ПМу давались именно такие "руководства к действию" — сроки жестко закреплены, при этом можно уменьшить объем или увеличить бюджет? Может все было сказано в довольно обтекаемой манере, как обычно руководство описывает ситуацию, не желая взять ответственность на себя, а свалить на других?
