Возвращение чепухи проектного менеджмента

После публикации первого набора чепухи о проектном управлении автор не сидел без дела. Даже сделал искреннюю попытку написать кандидатскую диссертацию по управлению проектами, но штабная работа была какой-то малоувлекательной, поэтому он «взял шинель и пошел на фронт». А в полевых условиях управление проектами «почему-то» выглядит совсем не так, как в книжках. Поэтому стали обнаруживаться новые чепуховины. И хотя их было достаточно много, мы остановимся на очень подходящей нашему кризисному времени цифре 13. Итак, продолжим…

Чепуха восьмая: «Компетентская»

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

(Прикладная область – Application Area – категория проектов, обладающих общими значимыми элементами, но не являющимися необходимыми или присущими всем проектам. Прикладные области обычно определяются в терминах продукта: по схожим технологиям или методам производства; типах заказчика: внутренние или внешние, государственные или коммерческие; или отрасли: коммунальные услуги, автомобилестроение, космонавтика, информационные технологии. Прикладные области могут перекрываться).

А ведь верно – если менеджер может организовать все и всех, нацелить команду на достижение результата и договориться со всеми заинтересованными лицами проекта, то, в принципе, без разницы, какова прикладная область этого проекта – будь-то разработка нового ПО, строительство моста или запуск спутника связи. Так в чем же чепуха?

А чепуха здесь во временной точке приложения компетенций проектного менеджера. То есть, до начала переговоров руководитель может ничего не знать о прикладной области проекта, но на момент подписания контракта на управление проектом он должен четко понимать, какие будут применяться технологии, и как взаимосвязаны технологические процессы в этой области, в каких отраслях искать подрядчиков для реализации работ. Более того, он должен в совершенстве владеть терминологией. Руководитель проекта – это переводчик с языка исполнителей на язык заказчика и наоборот. И если с заказчиком он может говорить об управлении и организации, то с исполнителями он должен говорить о технике и технологии. Причем все это должно происходить в рамках одного коммуникационного поля, где все друг друга должны слышать и понимать.

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

Чепуха девятая: «временно-денежная»

(Критерием успешности проекта является минимальное отклонение от запланированных сроков и бюджета).

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

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

Итак, давайте расставлять точки над «Ё». Действительно грамотный и опытный руководитель для повторяющихся проектов может с точностью до 5-10% спланировать график и бюджет проекта и уложиться в эти сроки, деньги и погрешность при реализации. Но если никто из участников раньше не достигал аналогичного результата в новом проекте, то критерии его успешности явно лежат не в минимальном отклонении от запланированных сроков и бюджетов. А как же определить, успешен проект или нет? Давайте рассмотрим два примера.

Команда проекта во главе с руководителем в два раза превысила сроки и в четыре раза бюджет, и сделала немного не то, что планировали изначально. Более того, постоянно отслеживая потребности рынка и общаясь со всеми заинтересованными сторонами, они внесли в ходе работ столько изменений, что уму непостижимо! Но почему-то все довольны результатом – у всех участников от эйфории кружится голова. Заказчик жмет всем руки, выражает отдельную благодарность руководителю проекта за хорошую работу…

Планируя проект, все заинтересованные стороны договариваются, что необходимо сделать именно это, в такие сроки, за столько-то денег. Все понимают, что только в таком случае результат «принесет всем счастье», поэтому записывают «это, такие и столько» на бумагу, ламинируют и, радуясь, вывешивают у каждого в кабинете. Руководитель проекта «гонит лошадей», отвергает любые изменения в проекте, поскольку они влекут за собой изменение бюджета и сроков (при этом все участники с ним соглашаются), и укладывается в «такие» сроки и «такие» деньги с минимальным отклонением: -1% по срокам и +1% по деньгам. Но под конец заказчик не знает, кому и как впарить это, поскольку самому уже это давно не нужно. Руководитель, уже успевший вписать в резюме заведомо успешный проект, скромно стирает его кнопочкой Backspace. Команда на премиальные уже давно не рассчитывает.

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

Чепуха десятая: «заказчеговая»

(Роль заказчика в проекте исключительна и непоколебима).

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

Рыночная экономика не устает нам доказывать, что заказчик всегда прав! Но здравый смысл и опыт руководителей проектов заставляет их держать заказчика в роли консультанта по проекту и формального центра принятия решений (то есть, чтобы бумажечки подписывал). И такое удается не всем руководителям: одни идут на поводу у заказчика, боясь его разочаровать и, как следствие, выполняя все его прихоти; другие доводят заказчика до белого каления своими отказами и закрытостью информации проекта, и заказчик в итоге выгоняет их взашей. Как правило, и в том и в другом случае цели проекта не достигаются, заказчик результатами не доволен, проект провален.

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

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

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

Чепуха одиннадцатая: «хедхантерская»

(Руководителей проектов не хватает).

Это самая распространенная чепуха 2007-2008 годов. Сегодня ее продолжают распространять, но с эпитетами, мол, не хватает «опытных», «грамотных», «профессиональных» менеджеров…

Миф о нехватке проектных менеджеров придумали и распространяют хедхантеры и HR‑менеджеры. Хотя они это сделали не со зла, и даже не из корысти – им помогли те, кто вдруг понял, что им срочно нужны руководители проектов, причем сразу умудренные опытом, сертифицированные и за небольшие деньги. А поскольку такая потребность возникла как-то сразу, да еще и по всему миру, – вот на свет и появилась очередная чепуха. Но все-таки хорошее время – «кризис». Он почти убил эту чепуху, а мы добьем!

Вы действительно хотите получить сразу гуру? Тогда рассчитывайте ежемесячное вознаграждение этого человека как 0,1-0,5% от полного бюджета проекта. Более того, не рассчитывайте на этого человека более чем на один-два проекта. Даже если вы готовы будете оплачивать его постоянно возрастающую стоимость, ему уже будет неинтересно в ваших проектах, и его КПД резко упадет.

Разоблачение этой чепухи лежит в понимании, что проектными менеджерами не становятся – ими рождаются. Если сравнить людей с шариками, а их трудовую деятельность – с огромной полусферой, то силы, действующие на основную массу людей (назовем их FG – «желание стабильности»), заставляют их скатиться по этой полусфере в самое равновесное положение, и уже там, в этой куче шариков, под действием другой силы (назовем ее FA – «амбиции»), пытаются подняться повыше. Если же случаются какие-то катаклизмы, и эта полусфера переворачивается или пропадает, то эти шарики мучаются, депрессируют, катаются в поисках равновесного состояния, частенько закатываясь не туда, куда следует.

Но есть «шарики», которые «катаются» постоянно! На них действуют совсем другие силы или действуют по-другому, и они умудряются закатиться на вершину перевернутой полусферы и там балансировать; прокатиться по тоненькой, натянутой высоко под потолком, проволоке; со всей скоростью подкатиться к краю обрыва и даже взлететь над ним… Это особый склад характера людей – они боятся равновесного состояния. Когда все спокойно – им плохо, когда все движется – им хорошо. Вот из них-то и получаются отличные проектные менеджеры, а еще предприниматели и исследователи. Да, часто эти люди ничего не знают о существовании PMBOK и ни разу не видели Microsoft Project. Более того, они вряд ли рассматривали свои реализованные проекты с точки зрения сроков и бюджетов, и никогда не загоняли их в рамку «инициализация – планирование – исполнение – контроль – завершение». Но на каком-то подсознательном уровне они умудрялись доводить дело до победного конца. Когда же на вооружение попадает методология УП, их сразу начинают называть успешными руководителями проектов. Ищите именно таких людей! От остальных их отличает не образование и опыт работы, а наличие всех следующих качеств:

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

Если же они молоды, их нужно делать правой рукой более опытного руководителя проекта, и постоянно «бросать под поезд», то есть давать небольшие «неразрешимые» задачи (каковых, «к счастью», очень много в проектах). Если они умудряются их решать, то вскоре им можно поручать самостоятельное управление – опыт они получат в бою, а PMBOK во время передышек почитают.

Чепуха двенадцатая: «ломовая»

(Руководитель проекта может совмещать обязанности проектного менеджера и должностные обязанности сотрудника фирмы).

Сделаю одно замечание – все написанное ниже не относится к компаниям с сильно-матричными организационными структурами и проектно-ориентированным компаниям, то есть к компаниям, в которых менеджер проекта – это и есть штатная единица оргструктуры.

Вы наверняка слышали выражение «Кто везет, на том и едут». Это выражение часто и относится к проектным менеджерам, совмещающим обязанности по руководству проектом и функциональные обязанности сотрудника фирмы.

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

Но почему-то большинство компаний стараются привлечь именно сотрудника, а не контрактника. Мотивируется это заботой о коммерческой тайне, о будущем компании (которая хочет всегда получать выгоду от выращенных ею сотрудников) или простым непониманием (как можно практически постоянно находиться на территории фирмы, не будучи ее сотрудником?).

Что же получается в итоге? Руководитель проекта, находясь в штате и выполняя работы по проекту, постепенно превращается в «ломовую лошадь», медленно обрастая функциональными обязанностями, совершенно не относящимися к проекту. Ему говорят «ты это уже делал», «у тебя это получается лучше всех», «нам нужен твой опыт в этом вопросе», «ты в прошлый раз здорово договорился с этими людьми» и так далее. Поэтому компания пользуется им еще раз, и еще, и еще…

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

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

Поэтому старайтесь не смешивать функции руководителя проекта и функции сотрудника, особенно, если проект разовый и не является основным бизнесом компании.

Чепуха тринадцатая: «антикризисная»

(Кризис – это плохо).

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

Помню, в детстве мы из подручных средств мастерили мечи, луки и стрелы и днями напролет играли в «робингудов» и рыцарей. Сегодня, покупая своим детям игрушечный арбалет промышленного производства со всевозможными наворотами, дальностью и точностью стрельбы, значительно превышающей наши луки, мы видим, как они делают десяток выстрелов и забрасывают игрушку в дальний угол, а потом и не вспоминают о ней. Почему так происходит? Эпоха потребления разрушила основу человеческого развития – творчество. Все можно купить в супермаркете. Не придумать, не сделать своими руками, а купить!

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

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

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

Слышен шелест чепухи…

Уже традиционно заканчиваем статью этим разделом. Чепуха, описанная в этих двух статьях, далеко не вся, существующая в управлении проектами. Если вы видите явную чушь в проектном управлении – присылайте информацию об этом автору, а он уж поглумится над этой чепухой и вывесит на доску позора. И все это для того, чтобы управление проектами (прекрасная идеология новой экономики) иногда сбрасывало листву и представало пред нами в голом виде, а мы могли разглядеть его недостатки и оценить достоинства.

Впервые статья была опубликована на Executive.ru 26 марта 2009 года в рубрике «Творчество без купюр». Реанонсирована в контентном блоке в рамках специального проекта редакции