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

Вообще говоря, проблематика управления проектами осознана уже давно, однако как дисциплина управление проектами в современном виде появилось только в пятидесятых годах 20­го века, то есть немногим более 50 лет назад. Старейший метод календарного планирования — диаграмма Ганта (ленточный тип диаграммы, где по оси Y располагаются этапы проекта в порядке сверху вниз, а по оси X откладывается время) — был предложен еще в 1917 году. Но для управления проектами как дисциплины гораздо важнее, что в 1956­м был придуман метод критического пути (для управления комплексными работами по модернизации заводов фирмы DuPont), а в 1958­м — диаграмма и метод PERT (по заказу ВМС США для проекта создания ракетной системы Polaris). Напомним, что PERT (Program Evaluation and Review Techniques) — это метод событийного сетевого анализа, используемый для определения длительности проекта в ситуации, когда есть неопределенность в оценке продолжительности индивидуальных операций. Он основан на методе критического пути, длительность операций в котором рассчитывается как средневзвешенная величина оптимистического, пессимистического и ожидаемого прогнозов. PERT рассчитывает стандартное отклонение даты завершения от длительности критического пути. Наконец, в 1969­м образовалась ассоциация PMI (Project Management Institute), и в последующие годы была проделана огромная работа по методологическому развитию и стандартизации управления проектами.

Казалось бы, пятидесятилетняя история развития методологии управления проектами должна была привести к тому, что исполнение проектов станет делом механическим и практически все они будут выполняться в срок и укладываться в намеченный бюджет. Однако это совсем не так. Например, проект по строительству здания нового шотландского парламента в Эдинбурге первоначально оценивался в 40 млн. фунтов стерлингов, но закончился на отметке в 431 млн. фунтов. Специальный комитет, который должен был разобраться, почему так получилось, выяснил, что формальной оценки проектного бюджета вообще не было и цифра 40 млн. взялась неизвестно откуда. Другой пример: на проект реконструкции и строительства центральной магистрали в Бостоне было выделено 2,3 млрд. долл. Проект стартовал в 1991 году, но до сих пор не закончен, и затраты уже превысили 14,6 млрд. долл. Сколько руководителей этого проекта сменилось и было уволено, не знает никто. Конечно, корень неудач этих проектов — в полном несоблюдении методологий и стандартов управления. Казалось бы, если эти подходы правильно применять, то успех проектов будет обеспечен. Но, увы, и это не так.

Провальный проект года

Кроме неприятия и неиспользования стандартов и методологий есть и еще более опасная тенденция, которая влияет на успех проектов, — это увеличивающаяся сложность и динамизм бизнес­среды. Оказывается, некоторые проекты бывают неудачными не потому, что не смогли достичь плановых показателей по расходам или по срокам. Иногда с точки зрения расходов и соблюдения графика проекты могут быть очень успешными и тем не менее признаются провальными. Один из таких примеров — создание нового фотоаппарата и совершенно новой технологии (пленка, система проявки, печать) в фирме Kodak. Несмотря на всю сложность задачи, огромные масштабы (в нем участвовало пять компаний) и большую неопределенность, это был отличный проект. Завершился он в срок, и результатом его стала Kodak Advanced Photo System. В 1997 году PMI даже объявила его проектом года. Но изменилась внешняя ситуация: пока Kodak трудился над этой системой, другие поставщики фотоаппаратов разрабатывали цифровые модели, и рынок выбрал «цифру». Kodak вложил в этот проект огромные деньги, но рынок отвернулся от него, стоимость его акций упала до 67% от первоначальной, и компании пришлось уволить 50 тыс. служащих. Трудно такой проект считать удачным…

Старая парадигма

Какие выводы можно извлечь из приведенного выше примера? Прежде всего — что PMI права: проект действительно был блестящим, но только по канонам и критериям науки проектного управления. А по критериям бизнеса он был суперпровальным, и понятно почему: в процессе его выполнения сильно изменилась внешняя среда, а соответственно и приоритеты компании. И такая ситуация совсем не редкость. В США среди профессионалов в области проектного управления был проведен опрос, в котором респондентам предлагалось назвать причины провальных проектов. И на первом месте оказалось именно изменение приоритетов бизнеса. Не плохое планирование, не ошибки в учете рисков и не человеческий фактор — именно изменение внешних по отношению к проекту факторов, то есть те факторы, на которые руководитель проекта никак не может влиять. Они просто находятся все зоны его компетенции.

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

Заметим, что это не было упущением, на самом деле никто такой задачи в середине прошлого века и не ставил, поэтому не удивительно, что она и не была решена. Еще 20 лет назад управление проектами рассматривалось как инструмент создания продукта, обычно материального — дома, машины или ИТ­системы. При этом основной задачей было создать методологии, согласно которым будут достигнуты цели проекта, и по умолчанию предполагалось, что эти конкретные цели суть именно то, что нужно бизнесу. Управление проектами лишь решало задачу правильной организации движения к поставленной цели. Однако вскоре стало понятно, что в современной бизнес­среде этого недостаточно. Повышение конкуренции и динамизма бинес­среды привело к тому, что стало необходимо модифицировать традиционный ограниченный взгляд на успех проекта.

Новая парадигма

Понятно, что в новой бизнес­ситуации менеджмент компаний занялся поиском инструментов управления. И наряду с новыми подходами, например BSC, неплохо зарекомендовавшее себя управление проектами показалось более­менее подходящим средством для этого. В результате возникла идея расширить рамки понятия «успех проекта» и связать его с более далекими критериями — стратегическими приоритетами организации, показателями ее деятельности и т. д. Управление проектами стало постепенно отождествляться с управлением всеми изменениями в компании.

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

Затем — модифицировались критерии успеха проектов. В старой парадигме мы измеряли эффективность проект­ного управления в таких единицах, как расход ресурсов (людей и денег), отклонение от графика и степень выполнения спецификаций задачи. Однако в новой парадигме руководителя больше беспокоит следующий уровень информации: достижение целей организации, неважно, в каких показателях — будь то рыночная доля, прибыль или успешность вывода нового продукта.

Теперь когда мы говорим об успешных проектах, это не значит, что мы имеем в виду только качественное выполнение проекта. Например, в 2003 году PMI назвала проектом года проект, который выполнен в срок, но с перерасходом бюджета на 100 млн. долл. Почему же? Уже в самом начале работ руководители проекта поняли, что они неминуемо перерасходуют деньги, несмотря даже на резерв затрат. Что в таких случаях рекомендует делать стандартная парадигма управления проектами? Искать способы, во­первых, сокращения проектных расходов, а во­вторых, уменьшения содержания проекта либо через процедуру изменения попытаться утвердить новый бюджет. Однако руководители проектной команды поступили по­другому — они задумались над тем, что дополнительно можно сделать, чтобы потом, по окончании проекта, получить больший доход. В результате они, наоборот, расширили содержание проекта, перерасходовали средства, но им удалось добиться прибыли в 400 млн. долл. Таким образом, этот проект оказался успешным, но отнюдь не с традиционной точки зрения, с которой мы привыкли оценивать проекты. Ключом успеха в данном случае стало то, что руководители ориентировались прежде всего на будущую прибыль, а не на формальные критерии оценки уже запущенного проекта.

Очень похожий пример был и в моей практике: я вел проект по реорганизации системы управления производством программных продуктов в одной из канад­ских компаний, занимавшейся заказной разработкой. Первоначально мы предполагали, что проект будет выполнен за 18 месяцев, а эффект ожидали на уровне 25—30%, и это подтверждали реальные оценки. Увы, я закончил работу только за три года. Однако компания была очень довольна этим проектом, потому что его целью было повышение производства, а мне удалось повысить эффективность более чем на 50%.

На самом деле мне повезло, потому что, как и большин­ство проектных менеджеров, я старался просто придерживаться того содержания и плана, который был разработан первоначально, и его реализовывал. Так все и шло, и, возможно, проект окончился бы полной неудачей, но сработал риск недобросовестности подрядчика, из­за чего посередине проекта случилась задержка. Саму по себе задержку демпфировал бы резерв времени, зато появилась возможность спокойно посидеть и подумать — а то ли мы вообще делаем? И в результате такого обдумывания мы поняли, что можем решить задачу совершенно по­другому и сделать более ценные для компании вещи. Проектная команда выступила инициатором по резкому изменению содержания, сроков и бюджета проекта, и компания осталась очень довольна, потому что главным объектом успеха было производство.

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

Подытожим. Чтобы быть успешным менеджером проектов, к работе обязательно надо подходить с точки зрения потребностей заказчиков. А заказчикам проекты нужны не для того, чтобы в них соблюдались сроки или бюджеты. Как видно из приведённых примеров, успех или провал проекта не всегда зависит от того, что происходит в области его выполнения, а определяется с точки зрения портфеля проектов и корпоративной стратегии. Возможно, руководитель проекта и не имеет полного представления о корпоративной стратегии, но для него жизненно важно знать, чего хотела компания, когда утверждала этот проект.

И здесь встает вопрос — а имеет ли в таком случае значение контроль бюджета и сроков проекта, не нужно ли старые подходы выбросить на помойку? Конечно, нет, во многих случаях соблюдение бюджета и сроков является очень важной частью работы проектного менеджера. Однако если мы всё свое внимание сосредотачиваем только на этом, мы можем упустить из виду реальные цели бизнеса, забыть, для чего собственно мы этот проект выполняем.