Мы уже говорили о том, что выполнение проекта должно быть предсказуем, и обсуждали проблемы, связанные с обещаниями исполнителей главным участникам (так мы для краткости называем все заинтересованные стороны. — Прим. ред.) проекта. Эти проблемы перекликаются со следующими вопросами: «Что такое неудача проекта? Почему проекты заканчиваются неудачами?»
Если мы принимаем положение управления проектами, согласно которому успех проекта определяется исходя из ограничений, связанных с рамками проекта, его сроками и бюджетом, и если:
- по завершении проекта участники получили все (не больше и не меньше, чем было обещано) запланированные результаты;
- мы достигли результата именно в те сроки, какие намечали;
- мы уложились в тот бюджет, который был нам выделен, мы можем сказать, что наш проект был успешен.
Когда я рассматриваю это положение на своих курсах, всякий раз возникает дискуссия на тему: «Не следует ли все-таки, если есть такая возможность, предоставлять участникам результаты, превышающие заранее согласованные?» Должны ли мы уведомлять заказчика об открывающихся уже в ходе выполнения проекта возможностях по улучшению результатов? Например, если в проекте предусмотрена установка 25 персональных компьютеров и в ходе проекта появилась возможность установить самые последние модели с новым процессором, который дешевле, быстрее и, естественно, лучше, чем согласованный, должны ли мы делать это изменение?
Ответ на этот вопрос — НЕТ! Разумеется, нельзя вносить изменения до тех пор, пока мы не обсудим их возможных последствий со всеми участниками, на которых изменения могут оказать влияние. В некоторых случаях наш проект может быть подпроектом другого проекта заказчика, и с использованием нового оборудования могут возникнуть проблемы. Могут быть различными операционные системы, возможны и иные причины. Достаточно и того, что приложение может быть критичным для бизнеса, а не прошедший полного тестирования продукт, вне зависимости от показателей его надежности, это совсем не то же самое, что протестированный полностью. Вы можете припомнить, как несколько лет тому назад пользователи обнаружили, что центральные процессоры их ПК неверно выполняли некоторые арифметические операции. Очень редко, но такие казусы бывают.
Итак, обещания очень важны. Ну а как насчет обещаний по срокам и бюджету проектов? Многие заказчики (например, магазин цифрогид) директивно назначают (навязывают) руководителям проектов даты выполнения проектов (плановые, целевые, окончательные…). Несмотря на это, заказчики РЕАЛЬНО более заинтересованы в том, чтобы проекты выполнялись к обещанным нами датам, чем в том, чтобы работы проектов форсировались. Примером таких заказчиков часто являются наши собственные руководители, которые волевым путем устанавливают даты выполнения проектов. Часто они считают, что без навязанных напряженных сроков мы, руководители проектов, можем затянуть сроки их выполнения.
То же самое справедливо и в отношении бюджетов проектов. Нашим заказчикам и нашим руководителям часто кажется, что если предоставить команде проекта полную свободу, то бюджеты будут высоки, а сроки длительны. Говоря другими словами, в этих вопросах к нам нет полного доверия ни со стороны заказчиков, ни со стороны нашего собственного руководства, поэтому наши предложения по бюджетам и срокам проектов будут каждый раз сокращаться. Предвидя это, мы можем умышленно завышать свои предложения, но при этом следует ожидать от руководства еще больших сокращений.
Очевидно, что такой подход неприемлем, поскольку ведет к порочному кругу завышений предложений и сокращений сроков и бюджета проекта, которые в результате окажутся настолько далеки от реальных, что их нельзя будет использовать для управления проектом.
Во многих проектах после сокращения сроков и бюджета случается курьезный факт — проекты выполняются в сокращенные сроки и укладываются в урезанный бюджет. Такие факты укрепляют мнение руководства, что первоначальные сроки и бюджеты проектов обычно завышаются.
Почему это происходит? Каким образом удается выполнить весь объем работ в сокращенные сроки и с урезанным бюджетом? Неужели наши оценки были действительно ошибочны? Или мы умышленно завышали сроки и бюджет? Вероятно, это не так.
Скорее всего, общий объем работ проекта, который предусматривался при первоначальной оценке, был занижен, с тем чтобы сокращенный проект был выполнен в сжатые сроки и в рамках сокращенного бюджета. Фактически это достигается за счет ухудшения качества проекта. Например, некоторые тесты могут быть сокращены в объеме, или вообще пропущены, или могут быть приняты необоснованно некоторые рискованные решения.
Единственное, что мы как хорошие руководители проектов можем сделать, — разорвать порочный цикл. Чтобы сделать это, надо установить доверие со стороны наших руководителей и участников проекта.
Такое доверие установится только тогда, когда мы будем выполнять проекты в соответствии с обещанными нами сроками и бюджетами, для чего нам необходимо уметь обоснованно прогнозировать стоимость и продолжительность работ проектов.
В следующий раз мы обсудим, почему не следует использовать наиболее вероятное значение в качестве прогнозной оценки величин сроков и бюджетов проектов.
Майк Ньюэлл
Опубликовано в журнале «Директор ИС», #06, 2001 год