Думаю многим читателям знакома следующая ситуация. Вы завершили работы по проекту или ключевому этапу (например, разработали систему, написали технический проект, подготовили дизайн-концепцию и т.д.) На ваш взгляд, все круто! Результат — супер, да и замечаний у заказчика нет. Деньги в студию!

Однако если копнуть дальше, то ряд согласующих еще не смотрели результаты вашего труда. Другие не будут согласовывать без одобрения результатов владельцем смежной системы, с которой нужно интегрироваться. И эта песня может тянуться очень долго. Поэтому сегодня будем говорить о согласовании результатов работ.

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

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

Обычно процесс согласования выглядит так:

В одном из комментариев к посту автора, многоуважаемого пользователями Habr, я ответил, что основной причиной неудач проекта является не использование методологий «через %опу» или «как получится», а наличие только операционного управления в рамках проекта. Проектный подход у таких менеджеров заканчивается уже после составления сметы проекта.
В этом посте проведу более детальное сравнение операционного подхода с проектным.

Уровни управления проектом

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

Процедура управления изменениями

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

План – это не идеальная картина, а навигация по проекту

Почему когда вы едете на машине и попадаете в только что возникшую пробку, то ваш навигатор пересчитывает маршрут и время движения по нему, а управляя проектом, вы отказываетесь от такого полезного инструмента?
Когда реальная картина на проекте складывается не так, как было запланировано, то его руководитель начинает выстраивать в голове другие маршруты и перестает ориентироваться на первоначальный план.
Уверен также, что вам знакомо следующее мнение. План – это идеальный сценарий, в действительности все бывает по-другому, поэтому ориентироваться на план невозможно. Авторы подобных тезисов под словосочетанием «план проекта» подразумевают только первоначальный план (Базовый план). Но замечу, что проект должен также иметь другой план — Рабочий план, который будет учитывать все изменения в проекте и являться вашим навигатором по проекту. Такой инструмент будет показывать вам:

• Ак туальное расписание всех задач
• Узкие места
• Прогноз завершения проекта (этапа)

Используя рекомендации, приведенные в статье, вы научитесь легко оживлять ваши рабочие план-графики, находить проблемные места, прогнозировать достижение конечной цели. Тем самым вы качественно улучшите навыки планирования и контроля, что повысит вашу эффективность минимум на 20%!

Настройка статусов задач

Вам один раз нужно настроить программу (MS Project), используя формулы, приведенные в конце статьи, и графические индикаторы.
После чего вы сможете регулярно использовать простой и эффективный инструмент.
Итак, рассмотрим статусы задач, которые нам предстоит настроить.