Войти в систему
Войти с помощью соц. сетей:
Лорен Гэри
Допустите ненужные изменения в вашем проекте, и вы рискуете сбиться с курса, превысить бюджет и сорвать сроки. Откажетесь от полезных изменений — и вы рискуете упустить отличную возможность. Итак, возникает дилемма: как сохранять открытость для совершенствования и при этом не поддаваться «расползанию», при котором вроде бы незначительные изменения в конечном итоге выливаются в огромный перерасход бюджета и времени? Ответ: строго определив границы проекта и обеспечив возможность быстрого подсчета эффектов потенциальных изменений или отклонений от курса.
Просто удивительно, сколько проектов запускается без должных стараний определить их параметры. Спешка — ваш главный враг, говорит Дэйв Моффатт, имеющий 40-летний опыт в промышленном управлении проектами и занимающий должность старшего консультанта по операциям в Гарвардской школе бизнеса. Планируя проект, проясните следующие важные аспекты.
«Цель проекта — это общая выгода, которую он даст организации, — говорит Алекс Уолтон, консультант по проектам из Флориды. — А его масштаб — это все частные элементы (или характеристики продукта), которые проектная команда способна контролировать и договорилась создать».
Например, целью проекта может быть создание новой электронной игры, которая увеличит предпраздничные продажи компании-производителя на 40%. Но команда, разрабатывающая продукт, должна знать, какие характеристики должны быть у этой игры и каким будет бюджет ее производства. Такого рода информация фиксируется в описании содержания проекта; в нем в нескольких предложениях должно быть прописано, как команда намерена достичь успеха и по каким критериям он будет оцениваться. Обсудите содержание и масштаб проекта с ключевыми заинтересованными лицами, чтобы их ожидания соответствовали реальному пути его развития.
Чтобы обеспечить наличие у проекта четких границ, недостаточно определить масштаб. «Организации нуждаются также в агрегированном проектном планировании, — говорит профессор Гарвардской школы бизнеса Стивен Уилрайт, — которое отражает стратегию, задающую схемы и ритм для последующих, связанных с этим проектов». Это особенно важно в сфере разработки продуктов. При отсутствии графика будущих проектов инженер-разработчик, придумавший новую идею, может обеспокоиться, что она никогда не будет воплощена в жизнь, и пытаться внедрить ее в продукт, разрабатываемый в данный момент, — уже не думая о затратах и графике.
Ценным дополнением к агрегированному планированию может служить анализ предшествующих проектов. Рассмотрите последние несколько внутренних ИТ-проектов, осуществленных в вашей компании. Какие общие закономерности вы видите? Ваши открытия помогут вам определить потенциальные трудности в подобных проектах в будущем и подготовиться к ним.
Еще один способ минимизировать расползание масштаба — требовать вдумчивого обсуждения и одобрения любых серьезных изменений. Например:
В ИТ-проекте, влияющем на отделы продаж, маркетинга и логистики, такой совет должен состоять из старших менеджеров этих отделов. Менее крупные проекты — с бюджетом менее $1 млн и продолжительностью не больше года — могут эффективно функционировать без формального совета, говорит Тарн. Менеджер проекта может просто обращаться за советом к ключевым заинтересованным сторонам по мере необходимости.
Когда наступает время осуществления проекта, разбейте его на небольшие составные части с непродолжительными сроками исполнения и в первую очередь сосредоточьтесь на задачах с наименьшей неопределенностью и вариабельностью.
Например, команда разработчиков ПО, работающая над продуктом с четырьмя новыми характеристиками и при этом пока точно не знающая, насколько востребована на рынке будет одна из них, должна сначала создать остальные три. Дата запуска четвертой характеристики должна быть установлена позже, после того, как команда соберет достаточно данных от потребителя, чтобы убедиться в ее необходимости.
Но не ждите, пока все подпроекты будут завершены, чтобы проверить, будет ли успешен весь проект (или продукт), говорит Уилрайт. Он рекомендует подход так называемого периодического системного прототипирования: «В фазе исполнения регулярно объединяйте все подпроекты и проводите системный тест. Это поможет убедиться в том, что подпроекты, которые вы осуществляете, сочетаются друг с другом так, как это было запланировано».
В процессе строительства Макартур-Холла, жилого корпуса Гарвардской школы бизнеса для слушателей образовательных программ для топ-менеджеров (некоторые программы длятся восемь недель), было принято решение изменить масштаб проекта — построить десять дополнительных комнат, так чтобы гости, приезжающие к слушателям, могли оставаться в кампусе на несколько дней.
Если бы эти десять помещений были оборудованы за счет уменьшения числа комнат для студентов, потенциальный доход школы снизился бы, так как на программы принималось бы меньше слушателей. Куратор проекта счел, что лучше построить десять дополнительных помещений для гостей, а издержки компенсировать в последующие несколько лет за счет того, что поток доходов от изначально запланированного числа участников программ будет выше. Иными словами, тщательный расчет окупаемости помог руководителям проекта найти оптимальное решение для предложенных изменений.
Следуя предложенным здесь рекомендациям по фазам планирования и исполнения вашего проекта, вы сможете исключить те изменения масштаба, которые не выдержат такого анализа. Если вы сразу определите четкие границы, поступающие к вам запросы на изменения, скорее всего, будут действительно достойны серьезного рассмотрения.
Рассматривая возможные изменения, убедитесь, что заинтересованные лица вашего проекта полностью понимают их назначение. Например, действительно ли рыночные условия таковы, что имеет смысл ускорить исполнение проекта, чтобы начать поставлять продукт раньше, чем это было запланировано изначально? Нужно ли учитывать в проекте новые отраслевые стандарты, возникшие после того, как вы завершили планирование? Требуется ли новое технологическое решение, так как выбранное вначале себя не оправдало?
Затем объясните, как предлагаемые изменения повлияют на все — содержание проекта, его план, доступные ресурсы, общие затраты и график. Наконец, предложите заинтересованным лицам представить себе, что произойдет, если изменения не будут сделаны. При принятии таких решений, говорит Моффатт, мнение людей, которые представляют конечных пользователей, должно иметь решающее значение.
Если вы, как менеджер проекта, выступаете за изменения, вы должны придумать план их финансирования. Если будущий доход, полученный благодаря этим изменениям, не перекроет издержек, попробуйте найти другие части проекта, на которых можно сэкономить, и сосредоточьтесь на вещах, которые в ближайшие 30–90 дней графика сможете контролировать напрямую, советует Рид.
Лорен Гэри — бывший редактор Harvard Management Update.
Войти с помощью соц. сетей: