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

Данная статья была опубликована 26 марта 2009 года на сайте Сообщества менеджеров “E-xecutive” в рубрике «Пятничный менеджер».

Уже прошло больше трёх лет с момента опубликования первого набора чепухи о проектном управлении. Ох, какой шум тогда поднялся! Одни ругали автора всякими словами, мол, губит он на корню только зарождающееся в России благое дело; другие восторгались и звали на работу. Но потом страсти улеглись и статью стали “перепечатывать” в журналах и на других сайтах, каждый раз внося что-то новое. Сначала у статьи поменялось название. Она, почему-то, стала называться “Engineering: Чепуха Проектного Менеджмента”. Что такое “Engineering” и с какой стати он появился в названии, горе-перепечатники, наверное, сами не знают, но её уже стали дублировать и в таком варианте. Потом статья потеряла фамилию и имя автора, а значит стала народной! Вот этого то мы и добивались – статья стала народной, а значит осела в спинном мозгу народа, превратилась в фольклор, в традицию, и теперь нашему брату трудно будет доказать обратное.

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

Но всё это время автор без дела не сидел. Даже сделал искреннюю попытку написать кандидатскую диссертацию по управлению проектами, но штабная работа была какой-то мало увлекательной, поэтому он взял шинель и пошел на фронт. А в полевых условиях управление проектами “почему-то” выглядит совсем не так как в книжках. Поэтому стали обнаруживаться новые чепуховины. И хотя их было достаточно много, мы остановимся на очень подходящей нашему кризисному времени цифре 13 (с 1-й по 7-ю читайте в статье “Чепуха проектного менеджмента”, которая находится по адресу www.pmdoc.ru/?p=7), а 14-ю и последующие оставим для следующей статьи, которая будет называться, к примеру, “Новые приключения чепухи ПМ” или что-то в этом роде, и выйдет она, наверное, так же как и эта года через три.

Итак продолжим…

Чепуха восьмая (компетентская)

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

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

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

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

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

Чепуха девятая (временно-денежная)

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

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

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

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

1. Команда проекта во главе с руководителем проекта в два раза превысила сроки и в четыре раза бюджет, и сделала немного не то, что планировали изначально. Более того, постоянно отслеживая потребности рынка и общаясь со всеми заинтересованными сторонами проекта, они внесли в проект столько изменений, что уму не постижимо! Но почему-то все довольны результатом – у всех участников от эйфории кружится голова, Заказчик жмет всем руки, выражает отдельную благодарность руководителю проекта за хорошую работу…
2. Планируя проект, все заинтересованные стороны договариваются, что необходимо сделать именно ЭТО, в ТАКИЕ сроки, за СТОЛЬКО денег. Все понимают, что только в таком случае результат проекта “принесет всем счастье”, поэтому вписывают ЭТО, ТАКИЕ и СТОЛЬКО в бумагу, ламинируют и радуясь вывешивают у каждого в кабинете. Руководитель проекта “гонит лошадей”, отвергает любые изменения в проекте, поскольку они влекут за собой изменение бюджета и сроков (при этом все участники с ним соглашаются), и укладывается в заламинированные ТАКИЕ сроки и СТОЛЬКО денег с минимальным отклонением: -1% по срокам и +1% по деньгам. Но под конец Заказчик не знает кому и как впарить ЭТО, поскольку самому уже ЭТО давно не нужно. Руководитель проекта, уже успевший вписать в резюме заведомо успешный проект, скромно стирает его кнопочкой Backspace. Команда на премиальные уже давно не рассчитывает…

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

Чепуха десятая (заказчеговая)

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

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

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

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

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

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

Чепуха одиннадцатая (хеадхантерская)

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

Это самая распространенная чепуха 2007-2008 годов. Сегодня её продолжают распространять, но с прилагательным, мол “опытных”, “грамотных”, “профессиональных” и т.д. руководителей проектов не хватает…

Миф о нехватке проектных менеджеров придумали и распространяют HeadHunter-ы и HR ы. Хотя они это сделали не со зла, и даже не из корысти – им помогли те, кто вдруг понял, что им срочно нужны руководители проектов, причем сразу умудренные опытом, сертифицированные и за небольшие деньги. А поскольку такая потребность возникла как-то сразу, а ещё и по всему миру – вот на свет и появилась очередная чепуха. Но всё таки хорошее время – “кризис”. Он почти убил эту чепуху, а мы добьем!Вы действительно хотите себе в проект сразу гуру затащить? Тогда рассчитывайте ежемесячное вознаграждение этого человека – как 0,1-0,5% от полного бюджета проекта. Более того, не рассчитывайте на этого человека более чем на один-два проекта. Даже если Вы готовы будете оплачивать его постоянно возрастающую стоимость, ему уже будет не интересно в Ваших проектах и его КПД резко упадет.

Разоблачение этой чепухи лежит в понимании, что проектными менеджерами не становятся – ими рождаются. Если сравнить людей с шариками, а их трудовую деятельность – с огромной полусферой (см. рисунок), то силы, действующие на основную массу людей (назовём их F^G – “желание стабильности”), заставляют их скатиться по этой полусфере в самое равновесное положение, и там уже в этой куче шариков, под действием другой силы (назовём её F^A – “амбиции”), пытаются подняться повыше. Если же случаются какие-то катаклизмы и эта полусфера переворачивается, или пропадает, или что-то ещё, то эти шарики мучаются, депрессируют, катаются в поисках равновесного состояния, частенько закатываясь ни туда куда следует. Но есть “шарики”, которые “катаются” постоянно! На них действуют совсем другие силы или действуют по-другому, и они умудряются закатиться на вершину перевернутой полусферы и там балансировать; прокатиться по тоненькой, натянутой высоко под потолком, проволоке; со всей скоростью подкатиться к краю обрыва и даже взлететь над ним… Изучению этих сил автор когда-нибудь посвятит отдельную статью.

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

1. Нацеленность на результат и удовольствие от процесса;
2. Способность решать проблемы, а не желание констатировать факт их наличия;
3. Азарт от преодоления преград;
4. Умение договариваться с людьми.

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

Чепуха двенадцатая (ломовая)

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

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

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

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

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

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

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

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

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

Чепуха тринадцатая (антикризисная)

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

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

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

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

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

Для проектного менеджмента сейчас звёздный час. Все инструменты и методы проектного менеджмента как раз и создавались чтоб достигать запланированных результатов в рамках временнЫх и финансовых ограничений. Настал момент истины для проверки накопленного теоретического и практического багажа и очищения от балласта!

Так что можете назвать кризис как угодно – “это интересно”, “это трудно”, “это неопределенность”, “это новые возможности” и т.д., но и уж точно не “это плохо”.

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

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

Уже традиционно заканчиваем статью этим разделом.

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

* Прикладная область (Application Area) – Категория проектов, обладающих общими элементами, значимыми для таких проектов, но не являющимися необходимыми или присущими всем проектам. Прикладные области обычно определяются в терминах продукта (т.е. по схожим технологиям или методам производства), типа заказчика (т.е. внутренние или внешние, государственные или коммерческие) или отрасли (т.е. коммунальные услуги, автомобилестроение, космонавтика, информационные технологии и т.д.). Прикладные области могут перекрываться.
A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition©2008 Project Management Institute, 14 Campus Blvd., Newtown Square, PA 19073-3299 USA

** Д-Т-Д’ (Деньги-Товар-Деньги’) – простая формула кругооборота денежного капитала процесса производства капитала.
Карл Маркс. Капитал. Критика политической экономии. Том II. Книга 2.
Процесс обращения капитала / Издан под ред. Ф. Энгельса. – М.: Политиздат, 1984.