Управление проектами - это философия управления, а не инструмент или техника
Управление проектамиГлоссарийФорумКонтакты

Как снизить уровень документации по управлению проектом

Управление проектом - это необходимый сервис, который должен быть предоставлен всем, кроме малых проектов. А в чем заключается данный сервис? Это сервис для клиентов или упражнение в создании документации?

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

Но управление проектом вовсе не в  этом должно заключаться.  Управлению проектом можно научиться в команде по выполнению заявок клиентов. Более того, во время проекта никто не подходит так близко к клиенту и его бизнесу, как эта команда. Если ваш руководитель проекта решит отступиться, то они смогут стать каналом связи с вашими клиентами. То есть руководитель проекта может общаться с клиентами как можно чаще, а с разработчиками -- по необходимости, тем самым позволяя последним создавать продукт, при этом держать контакт с клиентами.

Конечно, управление проектом требует создания документов, включая документы с информацией, которая сможет помочь в случае, если вы встретите проблему. Мы не должны забывать о том, что всегда существует риск краха и даже вероятность  оказаться в суде. Так какие ключевые документы необходимы руководителю проекта, фокусирующемуся  на сервисах?

План проекта

Это наиболее важный документ, который руководитель проекта должен создать и поддерживать на протяжении всего проекта. Он содержит даты всех встреч, консультаций, работы по разработке. Он должен быть использован для того, чтобы руководитель проекта мог проследить, когда проект на правильном пути, а когда съехал с рельсов. Также стоит иметь план предоставления ресурсов для проекта.

Журнал целей

Как ни странно, но многие проекты не имеют определения целей. Цель "разработка новой системы обработки продаж."  может быть конечным результатом проекта, но команде разработчиков это не приносит никакой полезной информации. А вот цель в виде "иметь возможность автоматически обрабатывать заказы, осуществленные через интернет" или, что еще лучше, "позволить автоматическую обработку 20,000 заказов за день" содержит больше полезной информации. Конкретный вид данных целей помогает в планировании и в принятии решений, а также помогает команде понять те проблемы, которые они пытаются решить. Такие формулировки целей предоставляют большее понимание бизнеса клиентов и  наглядность достигаемых на протяжении проекта целей. Таким образом, они жизненно важны.

Журнал рисков

Очень важно помнить о том, что все должны быть в курсе вероятных рисков проекта. Это может быть простым "клиент может не обладать соответствующим аппаратным обеспечением" или же "проект может продлиться и не быть выполненным в сроки." Журнал рисков должен быть создан в виде одного единственного документа с риском, оговоренными действиями и эффектом в случае возникновения проблемы. Все должны быть в курсе содержимого данного документа, и он должен быть постоянно пересмотрен и обновлен. Одной строки для риска будет достаточно, а вот больше по документу на каждый риск - это уже чересчур.

Журнал проблем

Так же, как и журнал рисков, журнал проблем должен быть поддержан руководителем проекта. Опять-таки, это простой список проблем, возникших во время проекта, а также решения к ним. Данные проблемы должны быть доступны всем, и каждый должен иметь возможность добавлять в их список новые.

Журнал действий/соглашений

Многие руководители проекта любят сокращать встречи, как внутренние, так и с клиентом, при этом долго повторяя одно и то же по теме, не относящейся к проекту (кофе и пончики, к примеру). В какой-то степени это можно понять, но иногда это превращается в кошмар. Члены команды и клиенты или не будут слушать, или же потратят ценное время на перечитывание каждой детали, зная о том, что если они упустят какую-то деталь или неверно сформулированное предложение, то они потом могут за это поплатиться. Все становится сложнее, если проект имеет длительные сроки, поскольку тратится немало времени на ссылки на прошлые разговоры для того, чтобы исключить конфликты между соглашениями, что может вылиться в спор в будущем.

Создав журнал действий и соглашений, вместо того, чтобы каждый раз тратить время на их повторное обсуждение и напоминание, руководитель проекта может хранить их все в одном месте. Во время собраний данный документ может быть пересмотрен, и конфликты могут быть определены  раньше. Журнал действий также хорош для определения того, кто выполнил свои задачи, что еще необходимо сделать и как это влияет на состояние рисков проекта.

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

David Carr

 

Предложения

Copyright ©2014, PMToday.ru. При копировании материалов наличие прямой индексируемой ссылки на сайт обязательно.