ГЛАВА 1

ОБЩИЙ ВЗГЛЯД НА УПРАВЛЕНИЕ ПРОЕКТАМИ

Со времени выхода первого издания этой книги в 1997 году количество членов международного Института по управлению проектами (Project Management Institute, PMI) возросло с нескольких тысяч до 462 000 в 2015 году. Для тех, кто не в курсе, поясним, что PMI — это профессиональная организация людей, управляющих проектами (менеджеров проектов). Она обеспечивает своих членов целым набором услуг; однако главная ее задача — развитие области управления проектами как отдельной профессии. Для этого разработаны специальные программы сертификации, благодаря которым отдельные физические лица могут получить квалификацию «профессионал в управлении проектами» (РМР) при наличии профессионального опыта (примерно 5000 часов работы по специальности) и условии прохождения серии онлайновых тестов и экзаменов, построенных на основе информационного пакета Руководства к Своду знаний по управлению проектами (PMBOK® Guide).

Профессиональная организация? Только для управления проектами? Разве управление проектами не является всего лишь одной из разновидностей общего управления, или менеджмента?

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

И все же, что такое управление проектами и что такое проект? Институт по управлению проектами определяет проект как «временное предприятие, направленное на создание уникального продукта, услуги или результата» (PMBOK® Guide, PMI, 2015, с. 5). Это означает, что проект осуществляется только единожды. Если мероприятие повторяется, то это уже не проект. Проект должен иметь определенные точки начала и завершения (время), бюджет (стоимость) и четко определенные объемы или величину работы, которую надлежит выполнить, а также специфические требования к результатам. Я говорю «должен», потому что редко какой проект соответствует всем этим определениям. В книге данные условия проектов определяются как «цели РССС» (результат, стоимость, сроки, содержание).

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

Проект — это некая проблема, запланированная к решению.

Дж. М. Джуран

НЕУДАЧИ ПРОЕКТОВ

Современные исследования указывают на неоднозначные результаты управления проектами. Последний доклад транснациональной консалтинговой корпорации Standish Group, который, как обычно, в основном сконцентрирован на проектах IT, в частности в области разработки новых программ компьютерного обеспечения, показывает, что из общего числа новых проектов 29% оказались успешными, 52% столкнулись с труд­ностями, а 19% закончились неудачей. Следует отметить, что факторы успеха были «актуализированы», то есть проекты были завершены вовремя, в пределах выделенного бюджета и с удовлетворительными результатами. Этот показатель успешности проектов практически не изменился с предыдущего доклада от 2011 года. Standish Group особо выделяет то обстоятельство, что меньшие по размерам проекты имеют значительно большие шансы на успех, чем более крупные. Gartner, консалтинговая компания в области высоких технологий, в своих последних отчетах дает аналогичные данные, отмечая, что большие по размерам проекты (с бюджетами, превышающими $1 млн) чаще терпят неудачу. Это происходит примерно в 28% случаев.

Наиболее убедительными оказались данные, опубликованные недавно Институтом по управлению проектами (Project Management Institute). PMI осуществляет постоянный мониторинг состояния управления проектами, программами и портфелями проектов. Исследование института под названием «Пульс профессии», обнародованное в 2015 году, отмечает появление позитивных трендов, однако при этом подчеркивает, что доля проектов, достигших своих целей, осталась практически неизменной по сравнению с 2012 годом: 64%. Для исправления ситуации PMI предлагает организациям вернуться к фундаментальным основам проектного менеджмента, а именно трем составляющим.

1. Корпоративная культура. Необходимо создавать специфический психологический настрой у работников.
2. Профессионализм. Следует сконцентрировать внимание на работе по подбору и подготовке адекватных кадров, их постоянном обучении и стимулировании к обмену знаниями и навыками.
3. Организация процесса управления проектами. Сферу управления проектами необходимо поддерживать путем разработки и принятия в компании стандартизированной практики и требований к организации процесса управления проектами.

Мой личный опыт — 28 лет управления проектами, изучения практики, консультационной деятельности и организации профессионального обучения — убеждает меня в том, что чем больше меняются вещи, тем больше все остается по-старому. Давно ясно, что во многих наших бедах виновато плохое планирование. Успешные проекты — крупные и небольшие, будь то в области IT, исследований и развития или организационной практики — все основаны на хорошем планировании. Однако слишком многие менеджеры проектов с самого начала работы с ходу занимают «позиции на огневом рубеже» в попытке завершить проект как можно быстрее. Во многих организациях им не отпускают достаточного времени на планирование работы, если отпускают вообще. В результате много времени и усилий уходит на исправление ошибок, успокоение недовольных заказчиков и партнеров и выход из блуждания по тупикам. Короче говоря, именно недостаток адекватного планирования приводит проект к неудаче.

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

ЧТО ТАКОЕ УПРАВЛЕНИЕ ПРОЕКТАМИ?

Руководство к Своду знаний по управлению проектами (PMBOK® Guide) определяет управление проектами как «приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Управление проектом осуществляется посредством надлежащего применения и интеграции логически сгруппированных 47 процессов управления проектом, объ­единенных в пять групп:

• инициация;
• планирование;
• исполнение;
• мониторинг и контроль;
• закрытие.

(PMBOK® Guide, PMI, 2015, с. 6).

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

PMBOK® Guide

Новый PMBOK® Guide вводит пять новых процессов в управлении проектами.

1. Процесс управления содержанием проекта.
2. Процесс управления расписанием проекта.
3. Процесс управления стоимостью проекта.
4. Процесс управления заинтересованными сторонами проекта.
5. Процесс контроля вовлечения заинтересованных сторон проекта.

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

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

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

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

Лучшее определение лидерства, которое я нашел до сих пор, — это определение Вэнса Паккарда, данное им в книге «Покорители пирамид» (The Pyramid Climbers, Crest Books, 1962). Он говорит: «Лидерство — это искусство заставлять других хотеть сделать то, что, как вы считаете, должно быть сделано». Главное слово здесь — «хотеть». Диктаторы заставляют других делать то, чего хотят сами диктаторы. То же самое с тюремщиками, которые выступают в качестве надсмотрщиков за трудом заключенных. Однако лидер заставляет людей хотеть выполнить работу, и в этом состоит принципиальное различие в этих ситуациях.

Лидерство — это искусство заставлять других хотеть сделать то, что, как вы считаете, должно быть сделано.

Вэнс Паккард

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

И ВСЕ ЖЕ ЭТО НЕ ТОЛЬКО ПРАВИЛЬНЫЙ РАСЧЕТ ВРЕМЕНИ!

Распространенной ошибкой является представление о проекте исключительно как о расписании действий. Судя по последнему отчету, корпорация Microsoft продала огромное количество копий программы Microsoft Project®, однако процент неудачных проектов по-прежнему высок. Важными инструментами осуществления проекта являются составление и контроль сроков его реализации. Однако по своей важности они все же уступают таким аспектам, как достижение общего понимания командой целей проекта, а также формирование действенной системы распределения работ, которая покрыла бы все действия команды. (Об этой системе я подробнее расскажу в .) Если не удастся осуществить другие звенья в управлении проектом, то его детальное расписание позволит лишь с большой точностью задокументировать свои неудачи!

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

СЛУЧАЙНЫЕ МЕНЕДЖЕРЫ ПРОЕКТОВ

Случалось ли вам неожиданно оказаться в роли управляющего проектом без соответствующего должностного обозначения «менеджер проекта» или без особенной поддержки? И не приходилось ли тогда считать себя одновременно и менеджером проекта, и рядовым работником? Если да, то вы не одиноки. Все чаще и чаще работа попадает под определение проекта, данного Руководством к Своду знаний по управлению проектами (PMBOK® Guide) в 2013 году (PMI 3, 2013): «временное предприятие, направленное на создание уникального продукта, услуги или результата». Есть сроки выполнения работы, ее содержание, ограниченные ресурсы и зачастую строго ограниченный бюджет. Такие проекты или программы менее формализованы и не имеют отдельной команды, однако их тоже необходимо планировать, четко рассчитывать по времени и контролировать. Уникаль­­ный или просто приемлемый продукт следует произвести и доставить заказчику, а тот должен быть восхищен или как минимум удовлетворен.

Я веду семинар «Основы управления проектами для НЕ менеджеров проектов» в некоммерческой образовательной и консультационной организации American Management Association International в Нью-Йорке. Он стал весьма популярным и обратил на себя внимание управляющих проектами с нестандартными подходами, экспертов в различных сферах бизнеса, спонсоров и филантропов. Типичные слушатели — менеджеры по продажам, администраторы, менеджеры по маркетингу, менеджеры по снабжению и другие. У меня создалось впечатление, что большинство из них в той или иной степени связаны с управлением проектами. Они не являются менеджерами проектов в традиционном смысле этого слова, однако в какой-то мере им приходится заниматься этой работой. Методики и инструментарий, которыми оперируют менеджеры проектов, могут им быть полезны. Я люблю говорить моим слушателям о том, что инструменты в управлении проектами применимы везде, но их ценность зависит от того, каким именно образом они применяются.

Первое: оцените работу. Ограничены ли вы ее содержанием, сто­имостью и ресурсами? Существует ли конкретный срок завершения? И тогда переходите к организации этой работы как проекта. Определите, какие инструменты управления проектами наиболее подходят в этом случае. Например, проект со сроком завершения через две недели потребует значительно меньшего объема инструментов управления, чем проект со сроком исполнения в 50 недель. Ужмите или, наоборот, увеличьте «широту охвата» вашего менеджмента в соответствии с продолжительностью, глубиной и масштабами проекта.

ОПАСНАЯ ЗАПАДНЯ: РАБОТАЮЩИЕ МЕНЕДЖЕРЫ ПРОЕКТА

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

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

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

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

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

НЕЛЬЗЯ ПОЛУЧИТЬ ВСЕ И СРАЗУ!

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

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

Стоимость = f(x) (Результат, Сроки, Содержание),

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

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

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

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

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

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

ФАЗЫ ПРОЕКТА

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

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

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

ФОРМУЛИРОВАНИЕ ПРОБЛЕМЫ

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

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

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

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

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

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

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

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

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

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

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

СТРАТЕГИЯ

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

ИМПЛЕМЕНТАЦИОННОЕ ПЛАНИРОВАНИЕ

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

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

ИСПОЛНЕНИЕ И КОНТРОЛЬ

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

ЗАКРЫТИЕ

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

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

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

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

ШАГИ В УПРАВЛЕНИИ ПРОЕКТАМИ

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

СФОРМУЛИРОВАТЬ ПРОБЛЕМУ

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

РАЗРАБОТАТЬ ВАРИАНТЫ РЕШЕНИЯ ПРОБЛЕМЫ

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

СПЛАНИРОВАТЬ ПРОЕКТ

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

НАЧАТЬ ВЫПОЛНЕНИЕ ПЛАНА

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

ОСУЩЕСТВИТЬ МОНИТОРИНГ И КОНТРОЛЬ ЗА ПРОДВИЖЕНИЕМ ПРОЕКТА

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

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

ЗАКРЫТЬ ПРОЕКТ

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

СВОД ЗНАНИЙ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ (PMBOK® GUIDE)

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

ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТОМ

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

Инициация

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

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

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

Исполнение

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

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

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

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

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

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

ЗАКРЫТИЕ

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

ОБЛАСТИ ЗНАНИЙ

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

УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА

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

УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА

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

УПРАВЛЕНИЕ СРОКАМИ ПРОЕКТА (ТАЙМ-МЕНЕДЖМЕНТ)

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

УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА

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

УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОЕКТА

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

УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ ПРОЕКТА

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

УПРАВЛЕНИЕ КОММУНИКАЦИЯМИ ПРОЕКТА

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

УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА

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

УПРАВЛЕНИЕ ЗАКУПКАМИ ПРОЕКТА

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

УПРАВЛЕНИЕ ЗАИНТЕРЕСОВАННЫМИ СТОРОНАМИ ПРОЕКТА

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

РЕЗЮМЕ

• Проект есть временное мероприятие, направленное на создание уникального продукта, услуги или результата.
• Проект также является некоей проблемой, запланированной к решению.
• Управление проектами есть приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Управление проектом осуществляется посредством следующих процессов: инициации, планирования, исполнения, мониторинга и контроля, закрытия.
• Ко всем проектам предъявляются требования по результатам, срокам, стоимости и содержанию (объему). Только три из этих параметров имеют заданные величины. Четвертый должен определяться руководителем проекта.
• Проект может потерпеть неудачу из-за того, что команда не уделила достаточно времени тому, чтобы правильно сформулировать решаемую проблему.
• Основными фазами проекта являются концепция проекта, его определение, планирование, исполнение и закрытие.
• Заинтересованные стороны проекта должны быть идентифицированы и управляемы.

УПРАЖНЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отправить