Статьи

Проект должен быть предсказуем

Что такое неудача проекта? Почему проекты заканчиваются неудачами?

Если мы принимаем положение управления проектами, согласно которому успех проекта определяется исходя из ограничений, связанных с рамками проекта, его сроками и бюджетом, и если:

  • по завершении проекта участники получили все (не больше и не меньше, чем было обещано) запланированные результаты;
  • мы достигли результата именно в те сроки, какие намечали;
  • мы уложились в тот бюджет, который был нам выделен, мы можем сказать, что наш проект был успешен.

Когда я рассматриваю это положение на своих курсах, всякий раз возникает дискуссия на тему: «Не следует ли все-таки, если есть такая возможность, предоставлять участникам результаты, превышающие заранее согласованные?» Должны ли мы уведомлять заказчика об открывающихся уже в ходе выполнения проекта возможностях по улучшению результатов? Например, если в проекте предусмотрена установка 25 персональных компьютеров и в ходе проекта появилась возможность установить самые последние модели с новым процессором, который дешевле, быстрее и, естественно, лучше, чем согласованный, должны ли мы делать это изменение?

Ответ на этот вопрос — НЕТ! Разумеется, нельзя вносить изменения до тех пор, пока мы не обсудим их возможных последствий со всеми участниками, на которых изменения могут оказать влияние. В некоторых случаях наш проект может быть подпроектом другого проекта заказчика, и с использованием нового оборудования могут возникнуть проблемы. Могут быть различными операционные системы, возможны и иные причины. Достаточно и того, что приложение может быть критичным для бизнеса, а не прошедший полного тестирования продукт, вне зависимости от показателей его надежности, это совсем не то же самое, что протестированный полностью. Вы можете припомнить, как несколько лет тому назад пользователи обнаружили, что центральные процессоры их ПК неверно выполняли некоторые арифметические операции. Очень редко, но такие казусы бывают.

Итак, обещания очень важны. Ну, а как насчет обещаний по срокам и бюджету проектов? Многие заказчики директивно назначают (навязывают) руководителям проектов даты выполнения проектов (плановые, целевые, окончательные…). Несмотря на это, заказчики РЕАЛЬНО более заинтересованы в том, чтобы проекты выполнялись к обещанным нами датам, чем в том, чтобы работы проектов форсировались. Примером таких заказчиков часто являются наши собственные руководители, которые волевым путем устанавливают даты выполнения проектов. Часто они считают, что без навязанных напряженных сроков мы, руководители проектов, можем затянуть сроки их выполнения.

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

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

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

Почему это происходит? Каким образом удается выполнить весь объем работ в сокращенные сроки и с урезанным бюджетом? Неужели наши оценки были действительно ошибочны? Или мы умышленно завышали сроки и бюджет? Вероятно, это не так.

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

Единственное, что мы как хорошие руководители проектов можем сделать, — разорвать порочный цикл. Чтобы сделать это, надо установить доверие со стороны наших руководителей и участников проекта.

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

Майк Ньюэлл, журнал «Директор ИС», #06, 2001 год

Отзыв о внедрении программного комплекса «1С:Управление производственным предприятием для Украины 8» в компании «Лукойл» (Одесса) Отзыв о внедрении регламентированного и бухгалтерского учета в компании «Винфорт» (Киев, Одесса) Отзыв о проекте IT-аудита в компании «Олдi» (Киев, Донецк, Житомир, Днепропетровск, Симферополь) Отзыв о проекте комплексной автоматизации в компании «Виола» (Запорожье) Отзыв о внедрении проекта комплексной автоматизации в компании «Пласке» (Одесса) Отзыв о внедрении проекта комплексной автоматизации в компании «Солнечная долина» (Одесса) Отзыв о внедрении программного комплекса «1С:Управление торговлей для Украины 8» в компании «Тумен» (Одесса) Отзыв о внедрении проекта автоматизации оперативного учета в компании «Эста Холдинг» (Донецк, Киев) Отзыв по обучению работе в программном комплексе ABIS-ISO сотрудников «Таврия-В» (Киев, Одесса, Николаев, Харьков, Львов и пр.)