|
 Изменения, запрашиваемые в ходе выполнения проекта, являются неизбежной частью любого проекта. Они могут являться результатом внешних изменений в бизнесе или могут быть внутренними изменениями, запрошенными, потому что первоначальные цели проекта не были четко сформулированы или поняты.
Запросы на изменения, обусловленные внешними факторами, обычно не зависят от руководителя проекта, и остается лишь справляться с ними. Самые успешные руководители проектов уже в начале проекта вводят процесс для обработки таких запросов, и план является достаточно гибким, чтобы справиться без излишнего влияния на конечный результат.
Но запросы на изменения, обусловленные внутренними факторами, должны обрабатываться совсем иначе. В идеальном проекте многих из них можно было бы избежать путем слежения за тем, чтобы цели проекта были четко определены, требования были четко задокументированы и сообщены всем заинтересованным лицам, и заинтересованные лица понимали, чего ожидать от конечного продукта. Конечно, мир не идеален, и, независимо от того, насколько основательны и детальны начальные этапы проекта, всегда требуется наличие эффективного процесса изменений.
Не все заинтересованные лица и конечные пользователи способны мысленно представить конечный продукт путем чтения документации и изучения диаграмм. Даже когда прототипы используются для улучшения выработки требований, они, по сути, являются не полнофункциональными продуктами, и разногласия и допущения неизбежны в сложных проектах.
Все же хорошее документирование и четкое разъяснение целей и требований проекта минимизирует количество запросов на изменения.
Каков лучший способ контроля над запросами на изменения в проекте при одновременной возможности реализовать готовый проект в рамках приемлемого бюджета, сроков и масштаба?
Различать необходимое и желательное
Каждый запрос на изменение должен сопровождаться экономическим обоснованием так же, как и весь проект. Разумеется, оно может быть очень простым и коротким описанием, но является обязательным элементом всех запросов на изменения, прежде чем их можно будет рассматривать на предмет включения в проект.
Самый важный элемент экономического обоснования запроса на изменение – ожидаемая выгода, показывающая ценность, которую изменение добавит к проекту. Это само по себе показывает, какие изменения, скорее всего, понадобятся. Важно осознавать, что описание некоторых экономических обоснований далеко не всегда может принести выгоду проекту в плане сроков и бюджета, но оно необходимо клиенту для сохранения конкурентоспособности на рынке.
Если выгоды не прописаны четко, обсудите вопрос с человеком, запросившим изменение, чтобы определить, имеется ли истинная коммерческая выгода.
Лучше спроектированные решения или более привлекательные возможности не являются выгодами, если они не подкреплены тем обоснованием, что они положительно повлияют на бюджет и график проекта или на усилия конечного пользователя, требуемые для выполнения регулярных задач. Экономическое обоснование запроса на изменение должно отвечать на следующие типовые вопросы:
• "Какое внешнее коммерческое изменение привело к данному запросу на изменение?"
• "Какой внутренний фактор привел к данному запросу на изменение?"
• "Как данное изменение повлияет на срок выполнения проекта?"
• "Как данное изменение повлияет на использование конечного продукта?"
• "Какое снижение расходов даст реализация данного изменения?"
Избегайте растраты времени и сил
Самый очевидный способ избежать растраты ценных ресурсов проекта на лишние запросы на изменения и на весь процесс управления изменениями – убедиться, что проект начинается с четко сформулированными целями и требованиями. Также необходимо кратко задокументировать в начале проекта критерий, используемый для определения успешности проекта. Убедитесь, что все эти документы разосланы заинтересованным лицам и конечным пользователям, и что копии легкодоступны.
Включите в план проекта время на разбор запросов на изменения, и если время вышло, отложите неизученные запросы до следующей недели. Убедитесь, что все заинтересованные стороны знают, что именно так работает процесс.
Имейте четкие критерии допустимости и отбраковки
Используйте некие четкие критерии для отсеивания запросов, которые не будут или не могут быть реализованы. Единственный основной критерий – экономическое обоснование, поэтому любые запросы без него можно сразу отправлять инициатору запроса. Не теряйте время на выслеживание инициатора запроса, чтобы выяснить, в чем заключается экономическое обоснование. Его предоставление изначально должно быть обязанностью инициатора запроса (даже если позже вам придется обсуждать и уточнять его).
Будьте готовы подкрепить ваши доводы отклонения запросов на изменения продуманным описанием того, почему невозможно включить изменение. Придерживайтесь вашего решения, если спонсор проекта не готов увеличить доступные для проекта бюджет или сроки.
Но проявляйте гибкость и договаривайтесь о компромиссе путем удаления плановой задачи вместо изменения, когда отсутствует бюджет или дополнительное время.
Всегда применяйте передовые методики управления проектами во всех сферах проекта, если вам нужны максимальные шансы на успех.
|
