Корпоративные преимущества процесса управления проектом

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

Были изучены и рассмотрены многие процессы управления проектами - от процессов Министерства обороны до процессов государственного и местного правительств. Кроме того, изучались и рассматривались процессы управления проектами в коммерческих предприятиях, банковской сфере, здравоохранении и ядерной энергетике. Здесь описывается концепция процесса управления проектом, и почему его внедрение выгодно для вашей организации.

В большинстве случаев процессы управления проектами (PM) действительно служат определенной цели в организационной схеме, предоставляя методологию процесса управления проектом в среде, в которой ее официально не существует. Хотя компания может иметь описанный в документации SDLC (жизненный цикл разработки системы), он характерен для разработки систем и приложений, а не для управления проектами. Следует указать, что проекты не относятся исключительно к Отделу информационных систем. Также следует указать, что не все SDLC надлежащим образом отражают процессы управления проектами.

Согласно PMBOK (Совокупность знаний по управлению проектами), "Проект – это временное предприятие, выполняемое для создания уникального продукта, услуги или результата. Эти временные и уникальные характеристики определяют, является ли конкретное предприятие проектом". С учетом этого проекты могут существовать во многих областях организаций, и нередко так и бывает, с оговоркой, что они могут не рассматриваться как проекты в соответствии с основными принципами процесса управления проектами. Даже если проекты существует без ссылки на процесс управления проектом, тем не менее, они могут быть успешными, хотя они нередко управляются беспорядочно.

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

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

1. Устав проекта
2. Цели проекта
3. Краткое изложение обстоятельств
4. Анализ заинтересованных лиц
5. Документация по масштабу проекта
6. Документация по требованиям проекта
7. Матрица ответственности
8. План проекта
9. План коммуникации
10. План рисков
11. Протоколы совещаний
12. Отчёты о состоянии

Это далеко не исчерпывающий список, но он дает представление о некоторых типах документов, необходимых для формального проекта.

Рассмотрим ситуацию, когда управление проектами не используется. Каковы некоторые из трудностей? Отделинформационных систем характерен для многих организаций, поэтому для данного примера будет использоватьсяприложение. При этом без использования процессов управления проектами стоит ожидать, что проект будет плохо документирован или же вообще не документирован, и, вероятнее всего, будет находиться в состоянии постоянных изменений. Другими словами, вы начинаете собрание коммерческих потребителей и руководителя и/или разработчика приложений с «мы хотим, чтобы приложение делало это»… и заказчик описывает свои требования к функциям приложения. Рано или поздно заказчик возвращается и просит реализовать дополнительную функциональность. Этипожелания записываются, и начинаются действия согласно им. Данный цикл продолжается, пока заказчик не будет удовлетворен, и пока приложение не будет одобрено и переведено в стадию производства.

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

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

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

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

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

Если организация внедряет процесс или методологию управления проектами, то с этим связано реальное сокращение расходов. Например, средняя стоимость проекта может быть уменьшена до 75% относительно недокументированного процесса. График проекта может быть сокращен примерно до 40%. Время ресурсов проекта может быть сокращено75%. Если рассматривать качество, то число дефектов может быть сокращено на 80%. Подобная экономия расходов и времени, а также повышение качества происходит, когда организация старательно внедряет надежный процесс управления проектами. По мере того как организация достигает зрелости в использовании управления проектами, появляется дополнительная экономия расходов и времени, и рост качества.

Давайте переведем вышеназванную экономию в реальные числа. Исследования показывают, что если вы используете процесс управления проектами, то ваше приложение стоимостью $100.000 может быть разработано за $25.000. Это весьма существенная экономия только по бюджету, и у вас останется $75.000, чтобы потратить их на другие инициативы. Если график проекта может быть сокращен до 40%, то это значит, что 20- недельный график проекта можно сократить до 12 недель. С учетом этого, у вас появятся деньги и время для работы над другими инициативами. Следующее: использование ресурсов проекта с экономией до 75% - то есть то, что отнимало у ваших ресурсов 800 часов на выполнение, теперь отнимает 200 часов на выполнение. Теперь у вас есть дополнительное время, деньги и ресурсы для других инициатив. Помимо этого, число дефектов сокращается до 80%. Вместо 20 дефектов продукта в итоге появятся лишь 4 дефекта. В конечном счете, вы получаете дополнительное время, деньги и ресурсы с уменьшением числа дефектов продукта. А что происходит в вашей компании?

Сейчас компании определенно стремятся повысить эффективность коммерческой деятельности путем оптимизации процессов. Руководителей ИТ просят увеличить до максимума прибыльность системы на инвестицию и привести информационные системы в соответствие с целями коммерческой деятельности. Чтобы эффективно выполнить это, руководители высшего звена вплоть до руководителей ИТ должны понять, как такие процессы, как управление проектами и иные, влияют на общую стоимость систем и приложений.