Немного теории. В любом проекте разработки и внедрении программного продукта существуют два ключевых понятия: управляющий комитет (steering committee) и интегральные характеристики хода проекта (наиболее популярный метод освоенного объёма, входит во все стандарты, прост для заучивания).
Приведу пример, что если данные понятия не на словах, не на бумаге в уставе проекта или в project definition, то в данном проекте не может быть кризиса.
Выдержка из IFS ERP Implementation Methodology, которую я переводил в косматом 2005(6) году для знакомых, которые неплохо знали английский, но ничего не понимали, ни в ERP, ни во внедрении тяжёлых «тиражных» продуктов.
Процедуры эскалации
Нижеследующие критерии описывают, когда процедуры эскалации должны быть запущены:
♫ SPI < 0,8 в текущей фазе для всего проекта
♫ CPI < 0,8 в текущей фазе для всего проекта
Нижеследующие процедуры применяются в случае, когда пороговые значения для критериев были достигнуты:
► Отчёт всех участников Проекта к определенной дате.
► Измерение текущего Статуса Проекта.
► Оценка будущих последствий текущего Статуса в терминах времени и стоимости для случая, если ничего не будет сделано.
► Составление списка альтернативных смягчающих действий, которые могут быть применены, в том числе, в терминах времени и стоимости.
► Составление отчёта о Статусе Проекта; извещение Управляющего Комитета с предоставлением полного списка альтернатив и рекомендуемого плана действий; созыв внеочередного совещания Управляющего Комитета.
► Внесение изменений, согласованных с Управляющим Комитетом в план и бюджет Проекта.
► Уведомление участников Проекта.
Уверен, что и для Navision (OnTarget Methodology), и для Accelerated SAP, и для O(racle)M(ethod), и даже для няшной в то время Axapta – всё было идентично в этом плане.
Поэтому в проектах, которые «прозрачны» по исполнению кризиса быть не может по определению. Но кризис есть! И его надо признать. А в этом проекте эскалация (информация о кризисе) выглядела просто. Так как мы были одним из соисполнителей по проекту, другой соисполнитель появился в офисе с заявлением "Если вы ничего не предпримите, то мы все попадём в список ненадёжных поставщиков данного холдинга. И это скажется не просто на репутации (сработает репутационный риск проекта), а приведёт к цепочке негативных последствий". Так в данном проекте должен появиться новый РП – кризисный РП. И им был я...
Отмечу, что кризис ещё не признан, пока только признано плохим состояние управления проектом. А далее сбор информации. Информации. И понимание того "дна океана", где оказались все соисполнители. Отмечу, что пока и ещё общение в проектных группах корректно, уважительно и без мата. Глубина возможных потерь не осознана. Инициированный проект как лёгкая прогулка в начале, остаётся в таком статусе для всех и сейчас. И это невзирая на существенную потерю времени.
Важный факт, и отчётность была, и работы велись. Но когда «с ногами» влезаешь в ситуацию выясняется следующая картина:
Требования не обработаны.
Регламенты БП не согласованы.
Разработка идёт, но по принципу Обломова, «который любил Ольгу как-то вяло, лёжа».
Готовых наработок нет, а без них сроки превращаются в сыр Хохланд или немецкое кино про любовь.
Более того, ещё нет паники, но уже есть недоверие простых исполнителей к менеджменту.
И первая задача РП сказать всем «СТОП». Не надо далее двигаться. Проект таков, что надо резать, рубить, жечь и расчищать поляну, на которой надо строить с нуля. В том числе и команду. И тут вместо ау в лесу раздаётся тихий вой: "крииизииииииссссс…."
Интересно, что при этом топ-менеджмент никогда (проверено на всех кризисных проектах, в которых я участвовал) не даёт карт-бланш РП. А строго наоборот, начинает его «пасти» и «учить». Это всегда происходит при любом уровне опыта РП, и обычно это во благо и самому РП, и проекту ????