Основы проектного менеджмента. Классическое руководство - Страница 4

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

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

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

Вопрос о том, как отбирать управляющих проектами, выходит за пределы этой книги. Но для заинтересованного читателя могу подсказать, что эта тема хорошо раскрыта в книге Роберта Высоцки и Джеймса Льюиса «Менеджеры проектов мирового уровня» (Pobert K. Wysocki and James P. Lewis “The World-Class Project Manager”, Perseus, 2001).

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

Взаимозависимость между результатом, стоимостью, сроками и содержанием проекта может быть выражена формулой

то есть стоимость проекта является функцией его результата, сроков и содержания. Графически это можно выразить в виде треугольника, в котором результат, стоимость и сроки являются тремя сторонами, а содержание – его площадью (рис. 1.1).

Рис. 1.1. Зависимость между результатом, сроками, стоимостью и содержанием проекта

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

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

Он обязательно воскликнет: «Почему так дорого?» У него в голове была своя цифра, а ваша ее явно превосходит. Он может сказать: «Если это столько стоит, мы не оправдаем свои расходы». Вот именно! Это именно то решение, которое заказчик должен принять. Однако он уверен, что ему удастся склонить руководителя проекта на снижение стоимости. И если вы согласитесь, то только ввяжете и заказчика, и себя в гораздо более серьезные проблемы, которые возникнут позднее.

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

Разумеется, есть и другая возможность. Если визави говорит, что может позволить себе заплатить только такую-то ограниченную сумму за проект, вы можете предложить ограничить его содержание или объем. Если проект годится и с таким объемом, он может быть осуществлен. Иначе разумнее и экономнее вообще забыть о нем и взяться за что-то другое, более прибыльное. Кто-то сказал, что скорее в проекте случайно что-то пойдет не так, чем все пройдет идеально. Что касается стоимости проекта, бюджет наверняка будет превышен. Это просто другой вариант изложения закона Мёрфи: «Если какая-нибудь неприятность может случиться, то она обязательно произойдет».

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

Рис. 1.2. Жизненный цикл проблемного проекта

Я показывал этот рисунок разным людям по всему миру, и все они улыбались и говорили: «Да, именно так все и происходит». Меня в этой ситуации успокаивает лишь то, что не только американцы сталкиваются с подобными проблемами. Плохо то, что если все признают эту модель, то многие проекты обречены на неудачу.

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

Рис. 1.3. Правильный жизненный цикл проекта

Несколько лет назад управляющий проектом одной компании, которая тогда была моим клиентом, пригласил меня к себе и сказал: «Я только что провел онлайн-конференцию с ключевыми сотрудниками моей команды и понял, что мы не можем прийти к единому мнению о том, чего должен достичь наш проект».

Я ответил, что такая ситуация складывается довольно часто.

«И что же мне делать?» – спросил он.

Я ответил, что ему придется заставить членов своей команды двигаться в одном направлении, объяснив им, какая высокая цель или миссия стоят перед проектом. Он попросил меня помочь провести такую встречу.

На встрече я подошел к доске и сказал: «Давайте запишем, какая проблема стоит перед нами». Кто-то сразу же возразил: «Не нужно, мы и так знаем, в чем проблема».

Я, не смутившись, ответил: «Ну что ж, если так, то записать ее – пустая формальность, на это потребуется всего несколько минут. Мне удобнее, если она будет изложена письменно. Поэтому прошу вас помочь нам начать».

Далее можно было позабавиться. Кто-то сказал: «Но…» Я записал это на доске. Кто-то воскликнул: «Я с этим не согласен!»

Через три часа мы, наконец, завершили письменное формулирование проблемы.