Избегание синдрома "темного, извилистого, заполненного поворотами туннеля"

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

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

Устанавливайте осмысленные контрольные точки

Контрольные точки – это базовая часть каждого хорошо сконструированного графика выполнения проекта. Они устанавливают моменты времени, в которые выполняются значительные события, выпускаются предоставляемые результаты, или достигаются контрольные пункты завершения стадии. Часто эти контрольные точки вставляются в график руководителями проектов без применения перспективного подхода к управлению представлениями заинтересованных лиц. Безусловно, существуют "естественные" контрольные точки, например, достижение контрольных пунктов завершения стадии, являющиеся уместными. Но если устанавливать и применять контрольные точки, обращая внимание на демонстрацию значительного коммерческого прогресса, большая польза исходит от этих указателей прогресса проекта. Ключ к тому, чтобы заставить это работать, - привязывание контрольных точек к событиям, вытекающим из деловой цели для выполнения проекта. Контрольные точки могут (и должны!) быть установлены до завершения детального графика.

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

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

Разбивайте проект на фазы - 9 месяцев или меньше

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

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

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

Управление и понимание длины пути

Тройные ограничения проекта устанавливаются в начале проекта. Они должны изменяться по мере того, как обнаруживается все больше деталей о проекте и требуемом решении. Несмотря на это, основные параметры для проекта устанавливаются в начале. Удовлетворительные сроки для сдачи – с учетом величины изменений и сложности проекта, устанавливаются в начале как часть тройных ограничений. Часто забывают, что по мере обработки запросов на изменения, коммерческие изменения вызывают корректировки приоритетов, и проектная группа сталкивается с неожиданными событиями. Люди склонны сосредотачиваться на микроуровне изменения и забывать о сроках макропроекта – что они изначально использовали для обоснования выполнения проекта! Управление сроками макроуровня проекта требует следующего:

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

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