50 Золотых Правил Управления Проектами
Шрифт:
Пример проекта из реальной жизни: в одной лидирующей компании – “голубой фишке” выполнялся ИТ-проект обновления программного обеспечения, продвигающийся в никуда. Несколько Проектных Менеджеров, которые на бумаге ранее выполняли подобные проекты, сменяли друг друга из-за того, что сроки пропускались, а проблемы неизменно накапливались. Роб, успешный проектный менеджер без опыта работы с проектами в сфере программного обеспечения, был нанят для того, чтобы вернуть проект в свое русло. В течение нескольких дней он идентифицировал корневые причины проблем: слабый сбор требований, границы проекта не определены, роли и ответственности не ясны, большая нагрузка на исполнителей, и т.д.
ПРАВИЛО #02 – БУДЬ ПРОАКТИВНЫМ И ПРЕДВОСХИЩАЙ
Как Проектный Менеджер, никогда не принимай ничего как данность. Ты обязан представлять себя в будущем, в разное время будущего, всегда думать о том, что может пойти не так, что может быть улучшено, и как это сделать. Это как игра в шахматы – всегда быть на шаг впереди и предугадывать. Будь проактивным, не застывай на месте! Планируй худшее заранее. Где необходимо, делай запас на непредвиденные обстоятельства. Вся эта дополнительная работа, особенно на старте проекта, воздастся сторицей. Постоянно оценивая всю информацию, все ограничения, зависимости и требования, ты сможешь предотвратить многое. Не стесняйся делать предположения. Настрой команду проекта и сам проект на успех.
Этот подход, вдобавок к прошлому опыту Проектного Менеджера, должен также исходить из постоянного взаимодействия с проектной командой. Бросай вызовы, задавай вопросы, ищи ясности и доказательства. Всегда имей запасной план для наиболее критических пунктов проекта. Зная заранее, что делать в случае кризиса, ты будешь иметь больше шансов вернуть проект обратно на рельсы и минимизировать последствия удара. Что касается дополнительного запаса, на случай если он не понадобиться – что же, ты будешь лучше смотреться, если за счет него ты сможешь сделать проект быстрее или дешевле. Это выигрышная ситуация для всех.
Пример проекта из реальной жизни: Желая быстро сорвать куш от использования новой технологии, благотворительная компания давила на своего Проектного Менеджера и требовала внедрить её как можно скорее, как советовал разработчик. Однако, рассмотрев все переменные, Проектный Менеджер Сэм потребовала у руководства два месяца для тестирования и первоначального планирования, чтобы потом эффективно интегрировать эту технологию в существующую среду. Основываясь на фактах и предвосхищая, что их ждет, она смогла проактивно убедить Спонсоров Проекта, что спешка не в их интересах. Разработчик не знал всех особенностей их рабочих мест. Эта задержка оказалась полезной и проект стал успешным.
ПРАВИЛО #03 – БУДЬ ПАРАНОИКОМ В ОТНОШЕНИИ РАСЧЁТА ВРЕМЕНИ И СОСТАВЛЕНИЯ РАСПИСАНИЯ
В проектах “расчёт времени” является всеобъемлющим: говорим ли мы о проектных вехах, встречах или просим об услуге людей. От первоначального планирования и до конца проекта Проектный Менеджер должен иметь параноидальное отношение к таймингу. Эта вещь имеет склонность всё подвергать опасности и выводить из синхронности. Поэтому добавление запаса по времени и непрерывная оценка того, как решения и события влияют на расписание, являются ключом к успеху. Проектные Менеджеры
Сколько встреч запланировать и какой длительности, или как часто бегать за кем-то, – все зависит от возможностей и инстинкта Проектного Менеджера. Сделаешь встречи слишком частыми или слишком долгими – и ты приведешь людей в уныние. Будешь бомбардировать кого-либо звонками и письмами, – и ты добьешься успеха только в натяжении нервов. Поэтому Проектный Менеджер должен постоянно думать, что лучше подходит для данной ситуации, основываясь на особенностях каждого проекта и участвующих в нем людях. Этому нельзя научить, это невозможно стандартизировать. Всё, что нужно – использовать здравый смысл, личные навыки и опыт.
Пример проекта из реальной жизни: Поскольку проект выглядел простым и имел высокий приоритет, Дэйв, Проектный Менеджер хеджевого фонда, получил один месяц на его выполнение. Однако в течение первых дней планирования стало ясно, что для его правильного внедрения потребуется колоссальный объем тестирования. Также оказалось, что ключевые члены команды проекта были уже задействованы на других проектах и перегружены текущей работой. Рекомендации Дейва были очевидны: проекту необходимо три месяца. Обладая этими фактами, Дэйв убедил Заказчика Проекта изменить свои ожидания. Проект был успешно завершен через три месяца, и все снова вернулись к прежнему рабочему балансу. Уделив дополнительное внимание тому, что действительно могло вызвать крушение проекта, Дэйв обеспечил успех и своему проекту, и своей команде.
ПРАВИЛО #04 – ПРОЕКТЫ ОБЯЗАНЫ ИМЕТЬ ДАТУ НАЧАЛА И ДАТУ ОКОНЧАНИЯ
Правило может звучать очевидным, но множество людей всё еще забывают, что проект – это временное мероприятие. Оно должно иметь начало и окончание. Иначе как же понять, когда можно отпустить проектную команду для других работ, был ли проект успешным, и какова его реальная стоимость? Шокирует то, что множество организаций всё еще не следуют этому базовому принципу, находя себя с низко мотивированными Проектными Менеджерами, “больными” проектами и несчастными клиентами.
Чтобы не делать такую же ошибку, оценивай и планируй дату окончания проекта с самого первого дня. Убедись, что все приняли и согласились с этой датой. Установи процесс и чек-лист для подтверждения и обоснования всех первоначальных проектных требований и чек-лист для закрытия проекта в регулируемом виде. Если проект длится вечность, это значит, что управление изменениями отсутствует, спонсоры проекта не вовлечены, и что там нет правильного Проектного Менеджера. Всегда проверяй эти признаки неприятностей.
Пример проекта из реальной жизни: Свен, один из менеджеров логистической компании из Швеции, назначенный Проектным Менеджером нового проекта, быстро обнаружил, что является жертвой своего успеха. Первые результаты тестирования нового программного обеспечения были такими успешными, что топ менеджмент компании решил увеличить скорость внедрения этого ПО в подразделениях по всему миру. К сожалению, тестовый проект еще не был закончен и вскоре начали накапливаться проблемы. Несмотря на это, ожидания руководства остались теми же. К началу глобального проекта остался ворох накопленных проблем, и вместо того, чтобы правильно закрыть проект и назвать его успешным, Свен помножил эти проблемы на количество глобальных подразделений компании. В целом это стало стоить серьезных денег и вызывать разочарование в людях. В конце концов, был выделен специальный Проектный Менеджер для спасения проекта. Он сумел правильно расставить приоритеты и вернуть проект на свои рельсы.