Войти в систему
Войти с помощью соц. сетей:
У каждого проекта должен быть устав, в котором прописаны характер и масштаб работ, а также ожидаемые менеджером результаты. Устав — это краткий документ, содержащий некоторые или все нижеперечисленные позиции:
Составление устава заставляет руководство четко сформулировать то, чего должен достичь проект. Давайте рассмотрим пример.
Фил был куратором деятельности компании по перестройке системы выполнения заказов и обслуживания клиентов. Он всегда открыто критиковал то, как исполняются эти функции, поэтому лучше всех подходил для этой работы. Ему не нравилось, что заказы выполняются слишком долго, что клиенты обслуживаются на посредственном уровне, а затраты на эти операции он считал завышенными. Ответственной за проект по усовершенствованию данной деятельности он назначил Лайлу.
Какого рода издержки рассчитывал сократить Фил? В чем именно он видел недостатки существующей системы? Каким, по его мнению, должен был быть успех? Лайла хотела получить от Фила ответы на эти вопросы, но у нее ничего не вышло. Он был слишком занят, чтобы тщательно обдумать это, и слишком сильно стремился делегировать ответственность за результаты проекта. Другие топ-менеджеры компании также хотели видеть улучшения, но, подобно Филу, не имели четкого представления о том, какими конкретно должны быть результаты проекта. Поэтому, когда Лайла стала задавать вопросы им, они тоже не смогли сформулировать точные цели. В отсутствие указаний Лайла и ее команда сами выработали цели и критерии успешности проекта.
Команда работала, и в течение 10 месяцев Лайла докладывала Филу о ходе работы. Вечной проблемой были ресурсы, в первую очередь из-за того, что Лайла никогда не знала точно, сколько денег она может потратить и сколько людей может принять в команду на ключевых стадиях. На каждом этапе ей приходилось отдельно обсуждать вопрос ресурсов с Филом.
В конце концов команда осуществила поставленные задачи, достигнув всех самостоятельно сформулированных целей. Ей удалось сократить время выполнения заказов на треть, а общие издержки на выполнение и обслуживание клиентов — на 12%. К тому же теперь клиенты, как правило, могли разрешить все возникшие у них вопросы с помощью одного телефонного звонка. Команда отметила завершение проекта роскошным обедом, и ее члены вернулись к своим стандартным обязанностям.
Однако высшее руководство оказалось не вполне удовлетворено результатом. «Вы хорошо поработали, — сказал Фил Лайле. — Вы добились значительных улучшений, но мы стремились к более масштабной реорганизации и большему сокращению издержек». Лайла была поражена и рассержена. «Если он этого хотел, — думала она, — то почему не сказал?»
Подобные ситуации случаются нередко, но их можно избежать, если у проекта существует устав, в котором четко прописаны его цели, сроки исполнения и масштаб.
Как показывает случай Лайлы, менеджерам проектов нужно нечто большее, чем примерное описание целей, за достижение которых они несут ответственность. Недостаточно конкретная формулировка целей ведет к недопониманию, разочарованию и дорогостоящим исправлениям.
Возьмем, к примеру, такое требование: «Разработать веб-сайт, который быстро и точно предоставлял бы информацию о продуктах и обеспечивал выполнение заказов наших клиентов эффективным и экономичным образом». Что конкретно это означает? Что такое «быстро»? Как определить точность? Допустима ли одна ошибка на 1000 случаев? Одна на 10 000? В какой степени сайт должен быть эффективен и экономичен? Ответы на все эти вопросы должны быть получены во время консультации с куратором и основными заинтересованными лицами проекта.
Правильный устав должен определять цели, а способы их достижения остаются на усмотрение менеджера проекта и членов команды. Если высшее руководство указывает команде, что и как она должна делать, сам смысл набора компетентной группы людей оказывается под вопросом. Ричард Хэкман в книге «Управление командами» (Leading Teams) пишет: «Когда определены цели, но не средства, члены команды могут — скорее, даже стремятся — использовать все свои знания, умения и опыт для разработки и применения таких способов деятельности, которые лучше всего подходят именно для целей и обстоятельств данной команды».
Помимо установления конкретных, измеримых целей необходимо определить сроки их достижения. Проект не может быть бессрочным. Бывают случаи, когда срок завершения устанавливается жестко, но при этом возможны изменения масштаба. К примеру, поставщик программного обеспечения обещает делать новые релизы каждые три месяца. Проектная команда должна корректировать масштаб этих новых релизов — добавлять или исключать какие-то характеристики продукта, — чтобы выполнять все обязательства по срокам.
И наоборот, при фиксированном масштабе проекта логичный дедлайн может быть установлен только после того, как менеджер проекта и команда разобьют цели на набор задач и оценят продолжительность выполнения каждой. Тем не менее в уставе должны быть отражены разумные примерные сроки, которые могут быть скорректированы, когда проектная команда начнет лучше понимать, что она должна сделать.
Объем возможных работ — куда более вариабельная величина, чем время и ресурсы. Чтобы сделать правильный выбор, полезно устроить общий мозговой штурм с заинтересованными лицами и участниками проекта и определить, что должен включать в себя проект и что должно остаться за его рамками.
Первой частью устава можно считать ожидания куратора (цели, которых нужно достичь), а второй — план проекта (средства их достижения). Обычно план составляет менеджер проекта, но очень важно, чтобы его одобрил куратор, иначе можно столкнуться с теми же проблемами, что Лайла и Фил. В идеале в плане должны быть отражены лучшие идеи многих или всех членов команды. Подробный план особенно ценен для крупных, сложных проектов, так как в нем фиксируются все детали задач, результатов, рисков и временных графиков. Он служит команде дорожной картой.
Войти с помощью соц. сетей: