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

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

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

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

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

Формулирование проблемы

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

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

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

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

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

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

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

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

Руководитель проекта оказался прав. В его команде не было единого мнения ни о том, в чем состояла проблема, ни о способах ее решения. Я с этим сталкиваюсь настолько часто, что начинаю думать, что у всех нас есть некий дефектный ген, который мешает правильно сформулировать проблему, прежде чем приступать к работе над ней. Помните: руководитель проекта решает проблему в большом масштабе. И от того, как вы ее сформулируете, зависит, как вы будете ее решать. Если проблема определена неправильно, то вы можете найти правильное решение, но не для данной конкретной проблемы!

Я убедился, что проекты редко терпят неудачу под конец. Как правило, они проваливаются на этапе определения проекта. Как подсказывает само это слово, определительная фаза наступает очень рано: когда формулируется проблема, определяется цель и проясняется миссия проекта. Я называю проекты без правильного определения «курицами без головы», потому что они похожи на кур с только что отрубленными головами, которые мечутся по двору, заливая все кровью, и только через несколько минут падают замертво. С проектами происходит то же самое. Они «разбрызгивают кровь» повсюду, пока кто-нибудь не скажет: «Думаю, этот проект мертв». Так оно и есть на самом деле. Но мертвым-то он стал тогда, когда мы отрубили ему голову в самом начале. Просто потребовалось некоторое время для того, чтобы все это осознали.

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

Стратегия

Стратегическая фаза проекта определяет максималистский подход, который закладывается в ваш проект, чтобы он достиг предъявляемых к нему требований. Хороший пример – история судоверфей Avondale. Во время Второй мировой войны производители вооружений столкнулись с жесткой необходимостью производства военной техники максимальными темпами. В то время были изобретены многие новые методы сборки, особенно в военном судостроении и авиастроении. Судоверфи Avondale на реке Миссисипи к северу от Нового Орлеана тоже взяли на вооружение новые судостроительные технологии. Традиционно суда строились в положении днищем книзу. Однако стальные корабли требовали сварки именно по днищу, в области киля. А сделать это чрезвычайно трудно. Тогда на верфях Avondale решили строить суда в положении днищем кверху, что оказалось гораздо проще, а потом переворачивать их в традиционное положение для строительства внутренних механизмов и палубных надстроек. Эта стратегия оказалась настолько успешной, что судоверфи Avondale смогли строить военные корабли быстрее, дешевле и с более высоким качеством, чем их конкуренты. И что примечательно: эта же технология используется и сегодня, 70 лет спустя.

Имплементационное планирование

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

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

Исполнение и контроль

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

Закрытие

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

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

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

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

Шаги в управлении проектами

Реальные шаги в управлении проектами достаточно понятны. А вот их выполнение – не совсем. Рисунок 1.4 иллюстрирует эти шаги. В следующих главах подробно описывается каждый шаг. Сейчас приведем только краткое описание соответствующих процессов.

Рис. 1.4. Шаги в управлении проектом

Сформулировать проблему

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

Разработать варианты решения проблемы

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

Спланировать проект

Планирование – это ответ на вопросы: что должно быть сделано, кем, на какие средства, как, когда и т. д. Для того чтобы ответить на эти вопросы, понадобится магический кристалл, с помощью которого можно увидеть будущее. Мы обсудим эти шаги подробнее в главах 2, 3 и 5.

Начать выполнение плана

Это очевидно. Если план составлен, он должен быть выполнен. Примечательно, что нередко люди много сил вкладывают в составление плана… а потом не выполняют его. Если не придерживаться собственного плана, то зачем его вообще выдумывать?

Осуществить мониторинг и контроль за продвижением проекта

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

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

Закрыть проект

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

Свод знаний по управлению проектами (PMBOK® Guide)

Институт управления проектами (PMI) определил минимальный свод знаний, которыми должен обладать эффективный руководитель проектов. Как уже было отмечено, РМBOK® Guide выделил пять групп процессов наряду с десятью областями знаний, речь о которых пойдет далее. Если хотите увидеть весь этот материал, можете обратиться к сайту Института управления проектами www.pmi.org/.

Процессы управления проектом

Процесс – это способ совершения того или иного действия. PMBOK® Guide идентифицирует пять групп процессов, которые применяются в управлении проектами. Хотя некоторые из них на определенных фазах проекта иногда доминируют, все они могут быть задействованы в любое время. Однако если говорить в общем, они используются в той последовательности, в которой развивается проект. То есть сначала осуществляются процессы инициации проекта, затем процессы планирования, исполнения и т. д. Если проект сбивается с намеченного пути, в действие вступает его перепланирование; если же оказывается под серьезной угрозой, может возникнуть необходимость вернуть его на этап инициации для повторного запуска.

Инициация

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

Планирование

Одной из главных причин неудач проектов является их плохое планирование. Это я еще деликатно выражаюсь. В большинстве случаев проблемы возникают из-за полного отсутствия планирования проектов! Команда просто пытается «поймать ветер в паруса» и сделать работу без всяких планов. Как я уже подчеркивал, многие ориентированы исключительно на решение задач и считают планирование пустой тратой времени, поэтому и несутся вперед сломя голову. Когда речь пойдет о контроле за продвижением проекта, мы увидим: неудача планирования означает, что такого контроля по ходу реализации проекта вообще не будет. Мы просто обманываем себя.

Исполнение

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

Второй аспект – это собственно управление выполнением проектом. Оно включает в себя выдачу заданий, так называемую авторизацию работ. Вы должны подойти к сотруднику и сказать ему: «Делай эту задачу и сдай мне результат через неделю». Или провести совещание и совместно с участниками команды договориться, кто что сделает в ближайшую неделю. Управление предполагает контроль исполнения поставленных задач и качества, а также реагирование на изменение, если что-то пошло не так.

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

Мониторинг и контроль

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

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

Закрытие

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

Области знаний

Итак, Руководство РМBOK® Guide определяет десять областей знаний, которыми управляющие проектами должны владеть для того, чтобы считаться профессионалами.

Управление интеграцией проекта

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

Управление содержанием проекта

Проект часто губят изменения в его содержании. Управление содержанием объекта включает в себя авторизацию работ; разработку устава (описания) проекта, который определяет его границы; создание ИСР (иерархической структуры работ), которая позволяет проверить выполнение работ на каждом этапе; определение процедур по изменению содержания работ.

Управление сроками проекта (тайм-менеджмент)

Я считаю термин «тайм-менеджмент» не очень удачным (по-английски time management – «управление временем»), потому что управление временем скорее относится к личным усилиям человека по организации своего времени. Управление сроками проекта подразумевает разработку графика проекта; затем организацию контроля работ, который подтвердит, что соответствие графику действительно имеет место! Ведь все так просто! Поскольку все относятся к этому аспекту как аспекту расписания, его следовало назвать управлением расписанием. (Знаю, что меня могут вышибить из Института по управлению проектами за такую ересь!)

Управление стоимостью проекта

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

Управление качеством проекта

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

Управление человеческими ресурсами проекта

Управление человеческими ресурсами, которым при реальном исполнении проектов часто пренебрегают, включает в себя определение людей, необходимых для выполнения работы; определение их функциональных ролей, ответственности и взаимной подчиненности; подбор этих людей и управление ими в процессе исполнения проекта. Обратите внимание, что это не имеет отношения к повседневному руководству людьми. Руководство РМBOK® Guide упоминает о необходимости этих навыков для руководителя проекта, но не перечисляет их. Однако поскольку такие навыки и есть то самое важное, чем должен владеть управляющий проектом, РМBOK® Guide ошибается, упуская их из виду.

Управление коммуникациями проекта

Из самого термина ясно, что управление коммуникациями проекта включает в себя планирование, исполнение и контроль всех действий, связанных с получением и распространением любой информации, имеющей отношение к потребностям заинтересованных сторон проекта. Она может касаться состояния проекта, достижений по его выполнению или событий, способных повлиять на других заинтересованных лиц или проекты. Следует подчеркнуть, что эта область знаний или тема не имеет отношения к практическим коммуникациям с конкретными лицами. Эта тема затрагивается, но не включена в Руководство РМBOK® Guide.

Управление рисками проекта

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

Управление закупками проекта

Покупка или приобретение необходимых товаров и услуг является логистическим аспектом управления проектом. Управление закупками проекта включает в себя принятие решения об объемах закупок, подготовку заявок на покупку, подбор поставщиков, управление договорами и их закрытие после окончания работ.

Управление заинтересованными сторонами проекта

Управление заинтересованными сторонами проекта включает в себя процессы, необходимые для идентификации людей, их групп или организаций, которые могут воздействовать на проект (и наоборот). Термин «заинтересованные стороны» соответствует заключенному в нем смыслу. Руководитель проекта должен задать себе вопрос: «Кто заинтересован в результатах проекта?» Если те, кого можно считать заинтересованными, способны оказать воздействие на проект или он, в свою очередь, может оказывать воздействие на них, то важно их правильно определить и соответствующим образом ими управлять. Не следует рассматривать все заинтересованные стороны как равные. Время и усилия, затрачиваемые на управление вовлечением заинтересованных сторон в проект, должны планироваться и осуществляться в зависимости от степени их влияния на проект и возможностей его поддержки.

Резюме

• Проект есть временное мероприятие, направленное на создание уникального продукта, услуги или результата.

• Проект также является некоей проблемой, запланированной к решению.

• Управление проектами есть приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Управление проектом осуществляется посредством следующих процессов: инициации, планирования, исполнения, мониторинга и контроля, закрытия.

• Ко всем проектам предъявляются требования по результатам, срокам, стоимости и содержанию (объему). Только три из этих параметров имеют заданные величины. Четвертый должен определяться руководителем проекта.

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

• Основными фазами проекта являются концепция проекта, его определение, планирование, исполнение и закрытие.

• Заинтересованные стороны проекта должны быть идентифицированы и управляемы.

Упражнения

1. Управление проектом – это не только:

а) планирование;

б) переделка работы;

в) составление расписания работ;

г) осуществление контроля.

2. Если руководитель проекта выполняет в нем какую-то еще работу кроме управления, в результате конфликта между рабочими и менеджерскими обязанностями:

а) вы не знаете, каких приоритетов придерживаться;

б) ваш босс может думать, что вы уклоняетесь от своих обязанностей;

в) у вас никогда не будет времени, чтобы хорошо выполнять обе группы обязанностей;

г) предпочтение будет отдаваться вашей собственной работе, а руководство проектом будет страдать.

3. РМBOK® Guide представляет собой:

а) свод знаний, определенных Институтом по управлению проектами в качестве необходимых для эффективного менеджмента проектов;

б) тест, проводимый Институтом на сертифицирование соискателя в качестве менеджера проектов;

в) аббревиатуру специального анализа рисков типа FMEA (Анализ моделей и эффектов неудач);

г) ничего из названного.

4. Содержание проекта определяет:

а) визирную ось руководителя проекта, наведенную на день его окончания;

б) масштаб или объем работ;

в) то, как часто проект подвергается изменениям;

г) пределы полномочий менеджера проекта.

Ответы на вопросы

Глава 2. Роль руководителя проекта

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