Шесть мифов проектного управления

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

Миф №1: проекты есть не во всех организациях

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

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

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

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

Миф №2: план проекта – точные указания по его выполнению

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

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

Миф №3: руководитель проекта – единственный, кто несет ответственность за результат

Иными словами, объявив руководителя проекта ответственным за достижение его результатов, можно переложить на него всю ответственность за судьбу проекта. После назначения проект-менеджера, этот несчастный становится «виновным за все», и вместо того, чтобы помочь ему, каждый считает своим долгом указать, где «прокололся» коллега, что он упустил.

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

Миф №4: проект-менеджер управляет сроками, бюджетом и качеством проекта

А как же? Разве не нарушение этих трех показателей является следствием плохого управления проектом? Конечно, это наиболее распространенные последствия. Однако это именно следствия, в то время как воздействовать нужно на причины. Хорошенько поразмыслив, чем на самом деле в состоянии (и должен) управлять проект-менеджер, мы придем к короткому списку:

  • командой проекта,
  • рисками проекта и
  • ожиданиями.

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

Что же такое управление рисками проекта? Оказывается, это интригующее своим названием понятие также успело обрасти своими мифами.

Миф №5: управление рисками – мистическое знание, доступное лишь прожженным финансистам с Уолл-стрит

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

Еще 20% риск-менеджмента в проектах составляет резервирование. Следует создавать резервы на непредвиденные расходы, отношение к которым все еще неоднозначное. Многие руководители компаний и подразделений не понимают эту строку в бюджете проекта. Такая политика ведет к тому, что руководители проектов «прячут» резервы внутрь статей бюджета. Это «раздувает» смету и не решает главную проблему – когда возникают обстоятельства, неучтенные на старте проекта, команда не имеет «запасного парашюта». Напротив, в технически зрелой компании на руководителя проекта, который планирует без резервов, посмотрят косо. При этом опытные руководители проектов резервируют не только деньги, но и время. И снова: нельзя «зашивать» временные резервы внутрь сроков выполнения задач. Для этого следует создавать лаги (промежутки, так называемые «ефрейторские зазоры») между работами. Это не расхолаживает команду проекта, но позволяет сманеврировать в критических ситуациях (а они обязательно будут – иначе не было бы самой дисциплины риск-менеджмента).

И, наконец, оставшиеся 10% – это непосредственное реагирование на наступившее рисковое событие. Как легко догадаться, если внимание руководителя проекта на предусмотрительность, резервирование и реагирование распределено правильно (в соотношении 70% – 20% – 10%), то реагирование на риски пройдет гораздо менее болезненно (что будет выражаться в сокращении финансовых потерь и других неблагоприятных последствий). К сожалению, негативный опыт в проектах обусловлен именно ситуационным управление рисками (пока гром не грянет, мужик не перекрестится), в то время как очень многое можно сделать на старте. Как мы видим, риск-менеджмент в проекте – отнюдь не что-то сверхъестественное; так давайте же не будем забывать применять в наших проектах вполне посильные меры по управлению рисками.

Миф №6: чем короче установишь сроки проекта, тем быстрее получишь результат

Работа заполняет выделенный на нее срок, поэтому нужно урезать сроки вдвое (втрое, вчетверо) – это будет только на пользу. Кому из читающих эту статью не знакомо давление сроков? Кто не чувствовал над собою дамоклов меч неотвратимо приближающейся назначенной даты? Это подстегивает? А как же! Это повышает результативность работы? С ответом на этот вопрос торопиться не будем. Порой в условиях сжатых сроков мы совершаем подвиги и творим чудеса продуктивности, недоступной нам в обычных условиях. Но кто не крутился, как белка в колесе, разрываясь между неотложными делами, при этом, не добиваясь результата ни в одном вопросе?

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

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

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

Источник фото: facebook.com

Расскажите коллегам:
Комментарии
Владимир Зонзов +10253 Владимир Зонзов Директор по производству, Украина
Обсуждаемую статью Ярослав Рашевски дополняет (14.09.15 1:17) следующим: [COLOR=blue=blue]>>> 7-й миф: Руководитель проекта обязательно должен хорошо разбираться в предметной области проекта. [/COLOR] На Е-хе неоднократно затрагивался вопрос необходимости «предметных» знаний для технократов. Поэтому, сейчас я ограничился (15.09.15 15:05) ссылкой на мнение, высказанное в книге «Прединвестиционные исследования …» (Раздел 1. инвестиционный цикл. Организация и управление инвестиционными проектами). К мнению из книги добавил следующее: «И в те времена, никому в голову не приходило отрицание необходимости, для ГИП-а, иметь профессиональные знания в «предметной» области проекта. ПОЧЕМУ не приходило? Вот в ответе на этот вопрос и ключ к пониманию необходимости «предметных» знаний, как для ГИП-а, так и для руководителя проекта». Ярослав Рашевски отвечает (16.09.15 21:46): [COLOR=blue=blue]>>> Не очень просматривается ключ. Да и зачем на проекте 2 спеца с одними и теми же предметными знаниями? Чтобы была почва для конфронтации между ними?[/COLOR] Голословное сообщение «[COLOR=blue=blue]Не очень просматривается ключ[/COLOR]», мне не интересно. На следующее предложение (о 2-х спецах …) отвечу так: – У ГИП-а (руководителя разработки рабочей документации на строительство) и у руководителя проекта разные «ареалы обитания». Но, это неизвестно Ярославу Рашевски, который работает в ИТ-области. Поэтому, какой смысл дискутировать с ним? Так же, голословно Ярослав Рашевски указует (16.09.15 21:46): [COLOR=blue=blue]>>> ПУ не стоит путать с управлением стройработами. ПУ оно не стройплощадке, оно в офисе. [/COLOR] И сие «подтверждает» тем, что-де: [COLOR=blue=blue]>>> Мы с вами в LinkedIn уже ведь это обсудили[/COLOR]. Я вот не знаю, что такое па-де-де и тому подобное. Поэтому, не стану указывать что-либо художественному руководителю Большого театра; сопровождая указание ссылкой типа «Это мы с вами уже обсудили, вчера в пабе». Также, и Ярослав Рашевски, о работе стройфирмы – «ни в одном глазу». Поэтому, какое обсуждение могло быть между ним и исп.директором стройфирмы? =====================================. Кстати, почему «предметные» знания необходимы руководителю проекта, я достаточно подробно написал в Е-хе-статье «Руководители инвестиционных проектов – кто они?» («Царь и бог проекта»).
Менеджер, Санкт-Петербург
Владимир Зонзов пишет: На следующее предложение (о 2-х спецах …) отвечу так: – У ГИП-а (руководителя разработки рабочей документации на строительство) и у руководителя проекта разные «ареалы обитания».
Владимир Иванович Вы правы, немного уточню Ареалы обитания ГИПа и ГАПа определены СП 48.13330.2011 Организация строительства, а также СНиП 1.06.04-85 Положение о главном инженере (главном архитекторе) проекта, который вроде еще действует: Техническое руководство разработкой проектной и рабочей документации на строительство, а также авторский надзор в ходе него... Проект строительства может включать в себя проекты и разработки проектно-сметной документации и авторского надзора, Руководство таким частным проектом может быть ограничено чисто технической составляющей и быть поручено ГИПу, или ГАПу ... Руководство таким частным проектом может включать также и инвестиционною составляющую и быть поручено РМ Рекомендации FIDIC в части инвестиционных проектов предлагают в т.ч. и этапы возврата инвестиций... т.е. инвестиционный проект может включать в себя проектирование, строительство и эксплуатацию объекта строительства... Руководство таким проектом требует помимо знаний предметных областей (проектирование, строительство и эксплуатацию объекта строительства) знание и области инвестиций
Партнер, Беларусь
Уважаемые коллеги, по интенсивности дискуссии вижу, что статья, написанная мной около 7 лет назад, актуальна и в наши дни. Это отрадно. Также делаю вывод, что вам интересно друг с другом. Мне уже сложно уследить за всеми ответвлениями дискуссии, поэтому я отреагирую только на замечание Ярослава Рашевски относительно ответственности эксперта в проекте. Эксперт -- по определению внешнее по отношению к проекту лицо. Его приглашают для консультации, для получения информации. Если эксперт наделен ответственностью в проекте, правильно называть его ''функциональным лидером''. Примерами функционального лидера в проекте являются ''дизайнер проекта'', ''архитектор продукта'', ''бухгалтер проекта'' и т.д. Хорошая классификация ролей в проекте дана в книге ''Консалтинг в управлении проектами'' Филипа Уикхэма, рекомендую. [COLOR=gray=gray]***ссылка удалена модератрром***[/COLOR]
Нач. отдела, зам. руководителя, Москва

Александр Воробьев
...проект в строительстве и проект в проектном управлении не синонимы... проектная организация в строительстве и проектная организация по PM BoK это разные ...

А арифметика в школьном учебнике и в бухгалтерии тоже разные?
Вы хотите сказать. что руководствуясь РМВОКом нельзя внедрить проектное управление в строительстве?

Менеджер, Санкт-Петербург
Ярослав Рашевски пишет:
Александр Воробьев ...проект в строительстве и проект в проектном управлении не синонимы... проектная организация в строительстве и проектная организация по PM BoK это разные ...
А арифметика в школьном учебнике и в бухгалтерии тоже разные? Вы хотите сказать. что руководствуясь РМВОКом нельзя внедрить проектное управление в строительстве?
Внедрить можно, Управление строительством изначально проектное, надо только одни стандарты проектного управления дополнить другими... Правда превратить формальное внедрение в реальное потребует много ресурсов, которые нужнее для другого... как только инвестор начнет устанавливать требования к системам управления проектами и аудировать соответствие им, а не смотреть на наличие сертификатов PMI, процесс реального внедрения пойдет гораздо быстрее
Руководитель проекта, Москва
Александр Воробьев
В СП все прописано, СНиПы как СП уже три года как пересмотрели, да и ГОСТы СПДС тоже ... А выделение разделов в ПД легко реализуется по требованию Заказчика в ТЗ...
Я несколько отстал от строительной темы. Работал в ней раньше. Но сам подход очень часто применяется и сейчас. Ну не существует ИТшного сметообразования. Появилось? Это прекрасно. Буквально 3 года назад был у меня проект по созданию распределённой ИТ системы. В проекте были объекты автоматизации стационарные и мобильные. И разработка. И всю эту тему ''Давайте сделаем состав проекта, давайте вы не будете пуско-наладку'' и пр... я прошёл в полном объёме.
И еще раз, проект в строительстве и проект в PM BOOK разные сущности...
Я полностью согласен. Именно поэтому навязывание ПО для управления проектом мне не нравится.
Руководитель проекта, Москва
Коллеги, давайте определимся. Не претендую на новизну но всё же. Есть ''Спонсор'', ''РП'' и ''ГИП'' в смеси старой терминологии и PMBOK. Так вот. Раньше, в СССР, были только Спонсор и ГИП. Обязанности РП распределялись между ними. В роли спонсора абстрактный министерский чиновник, Генеральный директор и т.п. В роли ГИПа собственно ГИП, доросший до этой должности снизу. Потому что в плановой экономике больше части того, чем занимается РП просто не было. Кроме того, было очень много людей, которые в ''Спонсоры'' попали также снизу. И, уж тем более, не было постоянных перемещений по отраслям, когда ''Спонсоры'' из мебельщиков в налоговики, а затем в министры обороны переходят. Теперь у нас появилась необходимость в РП, который тянет на себе юрчасть, финчасть, инвесторов, маркетинг, PR, и ... ''управление проектом''. Напомню, что получает в среднем больше ГИПа. Казалось бы, пусть забирает всё перечисленное, а ''тело проекта'' оставит ГИПу, снимая статус. Но вот беда, ГИПы у нас сейчас низкой квалификации либо просто не умеют работать с РП ибо для них не существует всего остального. Поэтому они просто дезинформируют РП, который не разбирается в теме. Также безтемный РП не может правильно поставить задачу ГИПу даже по подготовке правильной отчётности. Не учитываются риски, неверно докладывается ситуация Спонсору и т.п. Результат: постоянные проблемы на проекте. Вывод: РП должен выходить из проектной команды, в идеале из ГИПа для контроля работы самого ГИПа.
Виталий Елиферов +4100 Виталий Елиферов Менеджер, Москва
Ярослав Рашевски пишет: Вы хотите сказать. что руководствуясь РМВОКом нельзя внедрить проектное управление в строительстве?
Ярослав! А Вы пробовали применять PMBoK Portfolio Management в строительстве? - управлять портфелем строительных проектов. Или из РМВоК 5.0 ''Управление качеством проекта'' - тоже в строительстве? - Статистика говорит, что 50% зданий и сооружений сдаются с недоделками. Ни одна отрасль себе такого позволить не может. Представьте себе, что Вы купили автомобиль и в 50% случаев его надо переделывать после того, как Вы заплатили деньги и начали ездить (стекла не все вставлены, лампочки не все горят, двери перекошены, краска осыпается, замок не работает - все неисправности похожи на строительные ''недоделки'') :-)) Большей глупости, чем раздел ''Управление качеством проекта'' я не видел (кстати, в кулуарах, многие специалисты и преподаватели РМВоК с этим соглашаются). Но, только в кулуарах ....
Нач. отдела, зам. руководителя, Москва
Виктор Степанов ...Эксперт -- по определению внешнее по отношению к проекту лицо... Внешний эксперт нужен тогда, когда не хватает компетенции членов команды. И способ его привлечения должен быть таким, чтобы за последствия принятых решений и выданных консультаций он нес ответственность. Как, например, врач. Способы как этого добиться за пределами проектного управления. Иначе РП принимает на себя серьезный риск. И даже будь РП предметником, все равно эксперту придется доверять, т.к. уровень эксперта > уровня РП, иначе зачем эксперт. А как называть эксперта это уже не столь важно. Одним словом все. кто хоть как то влияют на ход проекта и на его результат, должны отвечать за такое влияние.
Нач. отдела, зам. руководителя, Москва

Владимир Зонзов
...неоднократно затрагивался вопрос необходимости «предметных» знаний для технократов...
Для ТЕХНОКРАТОВ он естественно необходим. Речь про РП, а не про технократов.
...я достаточно подробно написал в Е-хе-статье ...
Статья не доказывает правоту.
...не знаю, что такое па-де-де ...не стану указывать что-либо художественному руководителю Большого театра...
У худ.рука (предметника) БДТ есть еще директор (управленец). Что как раз доказывает

Владимир, когда заканчиваются аргументы, то в ход идут фразы :''Но, это неизвестно Ярославу Рашевски'', ''Ярослав Рашевски, о работе стройфирмы – «ни в одном глазу»'', и т.п. Вы мои глаза не проверяли и объемы знаний тоже, а суждения выносить считаете вправе.

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии