Методологии проектов: непростое решение проблемы

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

Например, заинтересованные лица проекта не удивятся, если увидят, что у руководителя проекта есть набор документов, включающий:

• Экономическое обоснование
• Документ начала проекта
• Схема производственного процесса продукта
• Описание изделия
• Отчет о ключевых показателях
• Журнал рисков

Разработка стандартных процессов явно полезна здесь, вместе со стандартными шаблонами для используемых документов она поможет предвидеть и обойти многие проблемы проекта. Чтобы быть эффективными, методологии должны справляться с самыми сложными ситуациями, например, с постройкой места  для проведения олимпиады для Лондона 2012.

Размер и масштаб некоторых методов может быть причиной серьезных проблем, если руководитель проекта стремится решить, какие элементы из методологии можно рассматривать как необязательные, и пытается уменьшить масштаб подхода для маленьких проектов. Уровень детализации или число этапов в плане – это все вопрос оценки, как и соответствующее членство наблюдательного совета в рамках подхода PRINCE2. Иногда такое сокращение может быть вызвано внешними соображениями коммерческой необходимости и дефицитом времени, а также людьми, спрашивающими, почему вы не прекратите создавать документы и не заставите команду сосредоточиться на реальном производстве чего-либо; но это также могут решить сотрудники, свободные для выполнения надзорных функций и рассмотрения структур.

Руководитель проекта и группа

Задача руководителя проекта и группы - убедиться, что документы и средства управления имеют надлежащее качество, но иногда этому уделяется недостаточно внимания.

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

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

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

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

Примеры нескольких ненадежных допущений, которые мы выявили в прошлых проектах, таковы:

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

Обзор проекта

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

Заключение

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