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

Основы проектного менеджмента. Классическое руководство (fb2) - Основы проектного менеджмента. Классическое руководство (пер. Михаил Михайлович Попов) 3982K скачать: (fb2) - (epub) - (mobi) - Джозеф Хигни

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

Под редакцией Вадима Богданова, PMP, PfMP, IoD Cert. Dir., CFA Member

Fundamentals of Project Management, Fifth Edition Copyright © 2016 American Management Association.

Published by AMACOM, a division of the American Management Association, International, New York. All rights reserved

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

© American Management Association, 2016.

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2018

* * *

Посвящается Сьюзан Хигни, моей жене и другу вот уже 40 лет

От научного редактора российского издания

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

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

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

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

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

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

Вадим Богданов, PMP, PfMP, IoD Cert. Dir., CFA Member, автор книги «Управление проектами. Корпоративная система шаг за шагом»

От автора

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

В пятое издание Руководства к Своду знаний по управлению проектами (PMBOK® Guide) в 2013 году в качестве новой области знания было включено управление заинтересованными сторонами проекта. Аналогичная глава есть и в этой книге. Представьте, сколько людей помогают вам в продвижении проекта по его жизненному циклу. А теперь подумайте, сколько из них окажется под воздействием результатов, которые даст ваш проект. Эти люди и группы называются заинтересованными сторонами. Знаете ли вы их? Управляете ли ими от момента инициации проекта до его закрытия? К сожалению, многие управляющие проектами не могут этим похвастаться, и результаты говорят сами за себя. Глава 4 описывает лучшие методики, инструменты и приемы, которые помогут вам при взаимодействии и управлении сторонами, заинтересованными в вашем проекте.

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

Настоящее издание «Основ проектного менеджмента» полностью соответствует пятому изданию Руководства к Своду знаний по управлению проектами (PMBOK® Guide).

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

Глава 7 «Использование иерархической структуры работ в планировании проекта» включает в себя некоторые аспекты управления закупками для проекта, а также описание оценки среды проекта, без которой вы, по существу, блуждаете в потемках.

Я рассматриваю проектный менеджмент как одну из величайших загадок бизнеса. Базовые инструменты управления проектами остаются почти теми же самыми, однако нюансы их применения для достижения успеха изменяются постоянно, каждый раз адаптируясь к новому сейчас. Проект необходимо приспособить к развитию технологий, демографии рабочей силы на предприятии, колебаниям в мировой экономике и прочим факторам. Успешное управление проектами – настоящий вызов, и оно никогда не бывает скучным. Именно поэтому я избрал проектный менеджмент своей профессией. Новое издание «Основ проектного менеджмента» содержит и проверенные временем приемы и методы, и новые знания, которые позволят вам шагать в ногу с современными требованиями к управляющим проектами. Читая эту книгу, напоминайте себе о необходимости учиться на прошлом и смотреть в будущее.

Джозеф Хигни ноябрь 2015

Глава 1. Общий взгляд на управление проектами

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

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

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

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

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

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

Дж. М. Джуран

Неудачи проектов

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

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

1. Корпоративная культура. Необходимо создавать специфический психологический настрой у работников.

Профессионализм. Следует сконцентрировать внимание на работе по подбору и подготовке адекватных кадров, их постоянном обучении и стимулировании к обмену знаниями и навыками.

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

Мой личный опыт – 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) было четко указано, что менеджер проекта должен всячески содействовать его планированию. Одна из частых ошибок молодых профессионалов по управлению проектами состоит в том, что они пытаются все спланировать за свою команду. По этой причине их планы не воспринимаются членами команды, к тому же они полны пустот. Менеджеры не могут продумать все за всех; их оценки временных затрат на решение тех или иных задач, как правило, ошибочны, и уже на старте проекта все их планы разваливаются. Первое важнейшее правило в управлении проектами состоит в том, что люди, выполняющие в них ту или иную работу, должны помогать в ее планировании.

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

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

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

Вэнс Паккард

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

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

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

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

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

Случалось ли вам неожиданно оказаться в роли управляющего проектом без соответствующего должностного обозначения «менеджер проекта» или без особенной поддержки? И не приходилось ли тогда считать себя одновременно и менеджером проекта, и рядовым работником? Если да, то вы не одиноки. Все чаще и чаще работа попадает под определение проекта, данного Руководством к Своду знаний по управлению проектами (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.1. Зависимость между результатом, сроками, стоимостью и содержанием проекта

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

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

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

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

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

Фазы проекта

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

Рис. 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 выделил пять групп процессов наряду с десятью областями знаний, речь о которых пойдет далее. Если хотите увидеть весь этот материал, можете обратиться к сайту Института управления проектами /.

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

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

Инициация

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

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

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

Исполнение

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

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

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

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

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

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

Закрытие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

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

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

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

Упражнения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое управление?

Определение управления проектами, данное Институтом PMI, не вполне охватывает истинную природу проектного менеджмента. Если вы помните, оно гласит: «Управление проектами – это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Управление проектом осуществляется посредством надлежащего применения и интеграции логически сгруппированных 47 процессов управления проектом, объединенных в пять групп: инициация, планирование, исполнение, мониторинг и контроль, закрытие» (PMBOK® Guide, PMI, 2015, с. 6). Звучит красиво, но что на самом деле делает человек, когда он управляет?

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

Определения управления

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

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

Это все о людях!

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

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

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

Работающий руководитель проекта

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

Властные полномочия

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

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

Момент истины

Ян Карлсон – самый молодой в истории СЕО авиакомпании SAS – Scandinavian Airlines, и он успешно омолодил дряхлеющую организацию. Частично достичь этого ему удалось благодаря тому, что он создал систему наделения сотрудников полномочиями, чтобы они не спрашивали разрешения на каждое действие, которое, по их мнению, решало проблемы клиентов. Карлсон подчеркивал, что каждое взаимодействие между сотрудником компании и пассажиром – это момент истины, в ходе которого клиент оценивает сервис компании. Если этот сервис его устраивает, он с большой вероятностью вновь воспользуется услугами SAS. И наоборот, если качество услуг окажется невысоким, пассажир вряд ли вернется.

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

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

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

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

Наконец, поскольку работа руководителя проекта – это в основном работа с людьми, жизненно необходимо демонстрировать лидерские качества, равно как и навыки управления (см. главу 14). Я определил управление как инициативный вклад индивидуума в работу организации. Вот определение лидерства из «Покорителей пирамид» (The Pyramid Climbers), которое, по моему мнению, лучшим образом выражает значение этого слова: «Лидерство – это искусство заставить других захотеть сделать что-то такое, что, по вашему мнению, должно быть сделано». Ключевое слово здесь – «захотеть».

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

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

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

Так хотите ли вы быть руководителем проекта?

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

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

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

Резюме

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

• Основной навык, который необходим руководителю проекта, – это навык работы с людьми.

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

• Вместо запрашивания полномочий сами принимайте решения и осуществляйте действия, которые не нарушают политику компании, а уж потом информируйте руководителя о том, что предпринято.

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

• Руководитель проекта должен обладать одновременно качествами и лидера, и управленца.

Глава 3. Планирование проекта

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

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

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

– Что ты делаешь?

– Занимаюсь планированием нашего проекта.

– Разве у тебя есть время на такую чепуху? Немедленно выгони всех оттуда, пусть займутся делом!

Понятно, что этот начальник не верил в планирование. Тогда зачем он отправил своего подчиненного на семинар по управлению проектами, если не верил в то, что там преподается? Попробуйте угадать.

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

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

И тем не менее, когда людей заставляют планировать проект, они находят это неудобным и сопротивляются дискомфорту. В сухом остатке у них часто остается так называемая «кривая болезненности» 1, изображенная на рис. 3.1. Испытываемый дискомфорт представляет собой пространство под линией 1.

Рис. 3.1. «Кривые болезненности» применительно ко времени

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

Планирование – абсолютный императив

Главная функция управления – добиться поставленных организацией целей путем контроля за ограниченными ресурсами компании. Однако слово «контроль» имеет два значения.

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

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

Во-вторых, если вы не знаете точку своего местонахождения, то не можете ее контролировать. Понять, где вы в данный момент находитесь, не так легко, как кажется, особенно если это касается умственной работы. Например, за сегодняшний день вы вознамерились написать 10 000 строк кода, но написали только 8000. Означает ли это, что вы находитесь на рубеже 80 % от того, где должны быть? Не обязательно. Возможно, вы нашли более эффективный способ записи кода.

В любом случае запомните: нет плана – нет контроля. Планирование не может осуществляться или не осуществляться по выбору.

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

Фриц Дресслер

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

Определение планирования

Планирование очень просто отвечает на вопросы, показанные на рис. 3.2. Это цепочка из слов кто / что / когда / где / почему / сколько / как долго, с которой вы наверняка знакомы, если изучали методы собеседования. Это так просто. И так сложно. Я говорю «сложно», потому что ответ на такие вопросы, особенно «Сколько времени это займет?», требует обращения к магическому кристаллу. Это очень трудный вопрос для задач, которые не имеют предыстории решений. Я уже цитировал слова своего коллеги: «Нельзя планировать креативность».

Рис. 3.2. Планирование – это ответы на вопросы

Стратегия, тактика и логистика

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

Стратегия – это метод, который вы задействуете для выполнения работы. Иногда ее называют «планом игры». Как я рассказывал в главе 1, тысячи лет корабли строились килем вниз, чтобы перед спуском на воду они были в нужном положении. Этот способ с успехом использовался до 1940 года, когда Вторая мировая война поставила судоверфи перед необходимостью строить военные корабли значительно быстрее, а они создавались уже не из дерева, а из стальных листов. Производить сварочные работы в районе киля – чрезвычайно трудоемкое дело: с внешней стороны трудно подлезать под киль, а с внутренней неудобно варить.

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

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

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

Прежде чем начать строить корабль килем кверху, надо продумать все детали. Это фаза, в которой следует поставить точки над i. Именно здесь вы отвечаете на вопросы кто/что/когда/где. Говоря о планировании, люди в большинстве случаев думают как раз об имплементационном планировании. Однако хорошо разработанный имплементационный план при неверной стратегии лишь поможет вам более эффективно провалить проект.

Логистика

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

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

Компоненты плана

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

Вот позиции, которые должны входить в план проекта.

• Документальное формулирование проблемы.

• Миссия проекта (см. главу 5 с рекомендациями по разработке миссии проекта).

• Цели проекта (также см. главу 5).

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

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

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

• Иерархическая структура работ (ИСР). Это иерархическая декомпозиция всех работ, которые необходимо выполнить для полного достижения целей проекта. ИСР является также прекрасной графической формой содержания проекта (см. главу 7).

• Расписания (должны быть представлены как расписания основных этапов проекта, так и рабочие расписания; см. главу 8 и главу 9).

• Необходимые ресурсы (люди, оборудование, материалы, помещения). Они должны быть сформулированы в увязке с расписаниями (см. главу 8 и главу 9).

• Система контроля (см. главу 10, главу 11 и главу 12).

• Основные исполнители и участники. Необходима схема их взаимной ответственности (см. главу 7).

• Зоны риска и его преодоления там, где это возможно (см. главу 5 и главу 6).

Согласование плана

Когда план подготовлен, он должен быть передан на подписание всем заинтересованным сторонам.

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

Поясню значение подписей заинтересованных сторон и дам некоторые советы по осуществлению процесса согласования.

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

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

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

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

Изменение плана

Было бы здорово, если бы однажды разработанный план никогда не менялся. Однако это нереально. Никто не может предвидеть на 100 %. Всегда возникают неожиданные трудности, поэтому важно вносить в план соответствующие изменения, следуя стандартной процедуре изменений.

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

• Изменения следует вносить только при появлении серьезных отклонений от плана. Серьезность отклонения обычно выражается в процентах «переносимости» относительно первоначальных целей.

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

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

Плох любой план, который не может быть изменен.

Бартоломео де сан Конкордио (1475–1517)

Подробности управления процессом внесения изменений в проект приведены в главе 11.

Рекомендации к эффективному планированию

Вот некоторые предложения по повышению эффективности планирования проектов.

• Планируйте планирование. Всегда трудно собрать людей вместе для разработки планов, поэтому мероприятие по планированию должно быть запланировано, иначе оно рискует превратиться в стихийную встречу (что нередко и происходит). Это означает, что следует разработать повестку дня; по возможности ограничить время совещания; поведение людей должно оставаться в определенных рамках, за этим должен следить руководитель или модератор. Существует множество руководств по проведению подобных мероприятий (например, книга Тома Кайзера «Фасилитация на практике» (McGraw-Hill, 1990)[5], сведения о них содержатся в примечаниях к этой книге.

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

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

• Поскольку всегда могут возникнуть неожиданные препятствия, следует анализировать риски, чтобы быть готовым к наиболее вероятным из них (см. главу 6). На случай, если не сработает план А, всегда имейте план Б. Почему же не использовать план Б с самого начала? Потому что план А лучше, но имеет несколько слабых моментов. У плана Б такие моменты тоже есть, но они отличаются от аналогичных моментов плана А, иначе нет смысла расценивать план Б как альтернативу.

• Самый простой способ проанализировать риски – это задать себе вопрос «Что может пойти не так?» и отнести его к расписанию, производительности и другим частям плана проекта. Иногда сама по себе идентификация рисков помогает их избежать. Но если это невозможно, у вас есть план Б. Одно предупреждение: если вы имеете дело со слишком сильными в анализе людьми, помните, что они склонны к параличу решений. Так что не старайтесь предусмотреть все возможные риски, предупредите хотя бы наиболее вероятные.

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

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

Плавт (254–184 гг. до н. э.)

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

Пошаговое планирование проекта

Обратите внимание, что некоторые из этих тем рассматриваются в следующей главе.

• Сформулируйте проблему, которую необходимо решить с помощью проекта.

• Разработайте документ о миссии проекта наряду с документом о его главных целях.

• Разработайте стратегию проекта, которая позволит решить его цели.

• Создайте документ о содержании проекта, который очертит его границы (что будет и не будет сделано).

• Разработайте иерархическую структуру работ (ИСР).

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

• Подготовьте генеральное расписание проекта и его бюджет.

• Решите, по какому принципу строить организационную структуру проекта: по матричному или иерархическому (если можете выбирать).

• Составьте план проекта.

• Побудите все заинтересованные стороны подписать план проекта.

Резюме

• Если у вас нет плана, то нет и контроля.

• Люди, которые должны исполнять план, должны участвовать и в его подготовке.

• План должен быть подписан на специальной встрече, а не путем рассылки писем.

• Вся информация по плану должна храниться в файлах в электронном виде.

• Используйте «критерии выхода», чтобы определить выполнение значимого этапа плана.

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

• Управление рисками должно быть составной частью работы по планированию проекта.

• Парадигма – это вера в то, как устроен мир.

• Планирование – это ответы на цепочку вопросов кто / что / когда / где / почему / сколько / как долго.

• Логистика связана с обеспечением людей материалами и ресурсами, необходимыми для выполнения работы.

Упражнение

Мы говорили о стратегии, тактике и логистике.

В отношении чего нужно принимать решение в первую очередь?

а) стратегии;

б) тактики;

в) логистики;

г) не имеет значения.

Какова функция тактики?

Когда нужно планировать логистику проекта?

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

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

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

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

Определение приоритета заинтересованных сторон по их отношению к проекту

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

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

2. Кто участвует в проекте? Определите индивидуумов или группы, на которых будете рассчитывать в реализации проекта. Это могут быть члены команды проекта, его спонсор или эксперты по предметным областям, не входящие в команду проекта.

3. На кого может повлиять проект? Результаты проекта могут оказать влияние на тех лиц или организации, которые не обязательно получают от него выгоду. Например, когда отдел IT обновляет программное обеспечение для покупателей продукта или предоставляет важную информацию для маркетинговой кампании. Такие индивидуумы и группы должны рассматриваться как заинтересованные стороны.

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

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

Рис. 4.1. Матрица заинтересованных сторон

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

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

• Лицо 5. Отношение к проекту позитивное, но влияние ограниченное. В целом это хороший фактор, хотя и не особенно помогает делу.

• Лица 3 и 4. Эти заинтересованные стороны позитивно относятся к проекту, и уровень их влияния высокий. Их можно использовать для убеждения других заинтересованных сторон в пользу проекта.

• Лицо 1. Это лицо опасно, потому что негативно относится к вашему проекту и обладает большим влиянием. Если им не управлять правильно, оно способно погубить проект. Работа с ним может потребовать формальной встречи, кофе по утрам, хорошего обеда или пары добрых выпивок в «счастливые часы». Ваша задача – выяснить, в чем конкретно состоят его возражения по поводу проекта, и «затащить» его в свой угол.

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

Вовлечение ключевых заинтересованных сторон в проект

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

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

Таблица 4.1. Матрица оценки уровня вовлеченности заинтересованных сторон

Обозначения:

Неосведомленная. Не осведомлена о проекте и его потенциальном эффекте.

Сопротивляющаяся. Осведомлена о проекте и его потенциальном эффекте, но не приемлет перемен.

Нейтральная. Осведомлена о проекте, но не поддерживает его и не сопротивляется.

Поддерживающая. Осведомлена о проекте и его потенциальном эффекте и поддерживает перемены.

Продвигающая. Осведомлена о проекте и его потенциальном эффекте и активно участвует в обеспечении успеха проекта.

Т = текущее вовлечение

Ж = желаемое вовлечение

В табл. 4.1 заинтересованная сторона 1 не осведомлена о проекте, но вы хотите, чтобы она его поддержала. Для этого придется проделать определенную работу. Заинтересованная сторона 2 нейтральна, но вы хотите, чтобы она тоже поддержала проект. Возможно, стоит встретиться за чашкой кофе и постараться побудить ее к этому. Заинтересованная сторона 3 уже поддерживает проект. Это явно хорошая новость, и вам не потребуется больших усилий, чтобы побудить ее свою поддержку проявить. Время от времени можно проверять, остается ли эта сторона довольна проектом.

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

Выработка единого языка общения с заинтересованными сторонами и коммуникации с ними

Согласны ли все заинтересованные стороны вашего проекта с каждым положением, зафиксированным в его уставе? Скорее всего, нет. Заинтересованных сторон много, и они очень разные. И результаты проекта воздействуют на них по-разному. У заинтересованных сторон различный уровень технической подготовки и знаний о продукте/проекте.

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

Для того чтобы преодолеть «проклятие знания» при общении с заинтересованными сторонами, Карен Фили рекомендует классифицировать и учитывать четыре различные группы (табл. 4.2).

Таблица 4.2. Классификация аудитории в соответствии с ее профессиональной подготовкой в коммуникациях с заинтересованными сторонами

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

Управление заинтересованными сторонами, представляющими различные корпоративные культуры

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

Управление изменениями, основанными на различиях в корпоративных культурах разных заинтересованных сторон

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

В 2008 году я вел курс МВА по управлению в Городском университете Нью-Йорка. Один из моих слушателей пригласил финдиректора крупной транснациональной финансовой компании выступить на курсе. Она говорила о шоке, подстерегающем человека в незнакомой корпоративной культуре, и вспомнила о своей работе в предыдущей компании. Если совещание было назначено на 10:00, то прибыть следовало в 9:55, иначе считалось, что вы опоздали. В ее нынешней корпорации 10:00 означает, что можно опоздать на 5–10 минут и все с удовольствием выслушают причину, например рождение ребенка у вашего брата. Наша выступающая долго не могла привыкнуть к этому, и ей даже потребовалась помощь коллег, чтобы адаптироваться.

Пять параметров культуры

При взаимодействии с заинтересованными сторонами проекта его управляющий должен принимать во внимание привычную для них культуру. В 1974 году голландский социальный психолог Герт Хофстеде провел масштабное исследование, к которому привлек множество сотрудников корпорации IBM из разных стран. По результатам он сделал вывод, что существующая в данном обществе система ценностей определяется комбинацией пяти важнейших факторов (табл. 4.3), которые определяют нормы поведения работников в различных корпоративных культурах. Тенденция индивидуумов руководствоваться в своем поведении похожими комбинациями этих параметров формирует особую культуру организации. Понимание этих факторов и их комбинаций может служить действенным инструментом управления заинтересованными сторонами.

Таблица 4.3. Пять факторов культуры

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

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

В конечном счете я завоевал их доверие, но если бы я тогда воспользовался пятифакторным подходом, то сделал бы это гораздо эффективнее.

Работа с внешними и удаленными заинтересованными сторонами

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

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

Объединение заинтересованных сторон

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

Шаг 1. Проясните для себя позицию заинтересованной стороны до того, как предпримете какие-то меры. Убедитесь, что понимаете ее резоны.

Шаг 2. Опишите, какое влияние на проект окажет реализация новой идеи. Часто такое разъяснение вызывает реакцию типа «Ах, вот в чем дело…», что немедленно разряжает ситуацию.

Шаг 3. Если ваше заинтересованное лицо хорошо подготовлено, его альтернативные идеи могут быть убедительными. Подготовьте свои «за» и «против» по каждой такой идее.

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

• проявите необходимое прилежание – планируйте их;

• заранее продумайте, какие изменения в плане проекта возможны, а какие недопустимы;

• сопровождайте возможные изменения в содержании проекта переговорами об изменениях его сроков и ресурсов;

• добивайтесь компромисса. Ищите такие точки, в которых соприкасались бы и интересы заинтересованной стороны, и интересы проекта.

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

Резюме

• Заинтересованная сторона – это любое лицо или организация, имеющие в проекте свои интересы.

• Управление заинтересованными сторонами проекта начинается с определения индивидуальных представителей этой категории путем постановки трех основных вопросов:

1. Кто получает выгоду от проекта?

2. Кто участвует в проекте?

3. На кого может повлиять проект?

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

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

• Не жалейте времени и сил на индивидуальное общение с внешними и удаленными заинтересованными сторонами.

Глава 5. Выработка миссии, видения, целей и задач проекта

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

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

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

По существу, проблема сформулирована в виде вопроса «Как отремонтировать машину?». Настоящая же проблема состоит в том, что человеку не на чем ездить на работу. Или он по крайней мере так говорит. Но разве он не может воспользоваться автобусом, как коллега, или велосипедом, пока его машину не починят? Конечно, отсутствие денег на ремонт машины – тоже проблема. Однако важно проводить грань между проблемами базовыми и вторичными.

Однажды я слышал, как менеджер по продажам укорял молодого продавца: «Компания потратила такие деньги на разработку нового продукта, а никто из вас его не продает. Если продаж так и не будет, я найду тех, кто сможет их делать!»

Понятно, как он определил для себя проблему: у него есть группа продавцов, которые не умеют продавать. Однако поскольку товар не может продать ни один из продавцов, я уверен, что менеджер неправ. Что-то не так с самим товаром, или рынком, или у них слишком сильная конкуренция. Маловероятно, что все продавцы плохие!

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

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

Путаница в терминах

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

– У меня проблема. Я должен найти жилье.

Вы спрашиваете, какова его миссия.

– Найти жилье, – отвечает он.

– А как насчет видения?

– Иметь жилье, – отвечает он, слегка сконфуженный.

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

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

– В своем жилье в новом городе, – ответил бы он.

– А что сейчас? – спросите вы.

– Сейчас у меня жилья нет, – скажет он.

Таким образом, разрыв состоит в наличии или отсутствии жилья. Это можно сформулировать очень просто: «У меня нет жилья». Это и есть та проблема, которую человек пытается решить.

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

Следовательно, миссия человека состоит в том, чтобы найти жилье, которое совпало бы с его видением. Иными словами, миссия проекта – достичь того, что представляет собой его видение. Таким образом, миссия решает поставленную проблему. Графически это изображено на рис. 5.1: обратите внимание, что видение решения проблемы изложено в колонке «Обязательно должно быть», а также в колонках «Хотелось бы» и «Хорошо бы».

Рис. 5.1. Шеврон, показывающий миссию, видение и проблему

Реальный мир

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

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

Реальная миссия для любого проекта

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

Миссию проекта можно записать, дав ответ на два вопроса:

1. Что мы собираемся делать?

2. Для кого мы собираемся это делать?

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

Определение целей проекта

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

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

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

Цель обозначает желаемый результат. Задача обозначает действие, совершаемое для достижения этого результата. Цель обычно выражается существительным, тогда как задача – глаголом.

Одна аббревиатура поможет вам запомнить основные характеристики документа, который можно назвать постановкой целей. Мы говорим, что цель должна быть SMART: конкретной, измеримой, достижимой, реальной и определенной по времени (сокращение от соответствующих английских слов: specific, measurable, attainable, realistic, time limited).

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

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

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

Все мы знаем, что одни люди способны на большее, чем другие. Поэтому сделать какую-то цель или группу целей измеримыми и достижимыми очень трудно. Я расскажу об этом подробнее в главе 6, когда буду говорить об оценке срока проекта.

Для определения целей и задач проекта и мониторинга прогресса в их достижении полезно поставить два вопроса.

1. Каков желаемый результат? Это система координат по результату. Она помогает сосредоточиться на том результате, который вы хотите достичь, а не на усилиях, которые для этого затрачиваете.

2. Как мы узнаем, что достигли желаемого результата? Я называю этот вопрос «доказательным». Он помогает установить критерии выхода в тех случаях, когда результат не может быть измерен количественно.

Приведу два примера целей.

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

• Наша цель состоит в том, чтобы собрать в фонд пожертвований от местных телезрителей $600 000 к 18 сентября 2016 года.

Характер цели

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

Оценка рисков проекта

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

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

Целесообразно оценивать возможность возникновения в проектах рисков по следующим параметрам:

В расписании проекта

В его бюджете

В качестве проекта

В удовлетворенности заказчика

Таблица 5.1. Пример анализа рисков по проекту

Такой анализ рисков поможет вам избежать некоторые из них. Если же риск наступает, у вас по крайней мере имеется резервный план. Неожиданно возникающие риски способны сбросить проект в «штопор».

Я уже отмечал, но не могу не повторить: старайтесь идентифицировать не каждый возможный риск, а только наиболее вероятные. Это следует отдельно разъяснить тем членам команды, которые имеют особую склонность к анализу или часто занимают позицию отрицания. Анализ рисков несет в себе позитивный заряд – вы как бы спрашиваете: «Если произойдет то-то и то-то, что мы будем с этим делать?» Вы же не провоцируете людей кричать: «Это будет ужас!»

В главе 6 я приведу подробные данные об инструментах и методиках управления рисками в проектах.

Резюме

• Как вы сформулируете проблему, так и будете ее решать.

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

• Видение – это то, как должен выглядеть конечный результат. Оно определяет то, что мы представляем себе выполненным.

• Миссия состоит в том, чтобы достичь видения. Она отвечает на два вопроса: «Что мы собираемся делать?» и «Для кого мы собираемся это делать?»

• Цели должны быть SMART: конкретными, измеримыми, достижимыми, реальными и определенными по времени (сокращение от соответствующих английских слов: specific, measurable, attainable, realistic, time limited).

Упражнение

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

1. Чего вы хотите достичь этим проектом? Какую потребность вашего заказчика или клиента он удовлетворяет? Кто конкретно реально воспользуется конечным результатом(-ами) проекта? (То есть кто является вашим настоящим заказчиком или клиентом?)

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

3. Сформулируйте и запишите миссию проекта, ответив на два основных вопроса: «Что мы собираемся делать?» и «Для кого мы собираемся это делать?».

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

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

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

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

Определение управления рисками проекта

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

Многие руководители проектов затягивают с оценкой рисков и откладывают разработку плана их управления, полагая, что многих деталей проекта они еще не знают и в нем много неизвестных факторов. Это известная западня, которой следует остерегаться. Еще на фазе инициации жизненного цикла проекта необходимо осуществить общую первичную оценку рисков. Руководитель проекта и члены команды должны со стратегической точки зрения ответить на вопрос «Что может пойти не так?» и заложить основу детального плана соответствующих действий. Без такого основания проекты часто подвергаются негативному воздействию рисков, которые неожиданно становятся реальностью, хотя их можно было предотвратить или вообще устранить, имея планы на случай непредвиденных ситуаций. Такой подход характеризуется как реактивно-пассивный, то есть лишь реагирующий на возникший раздражитель, тогда как успешный руководитель проекта должен занимать проактивную, наступательно-опережающую позицию. Иногда в ходе проекта возникают и потенциальные возможности – «позитивные риски», которые руководитель проекта должен использовать для достижения целей проекта.

В Руководстве к Своду знаний по управлению проектами (PMBOK® Guide) управление рисками проекта определяется в качестве одной из областей знаний. PMBOK описывает управление рисками проекта как «процессы, связанные с планированием управления рисками, идентификацией, анализом, планированием реагирования, а также с мониторингом и контролем рисков в проекте» (PMBOK, 555). Таким образом, эти процессы нужно понимать как строящиеся по заданным правилам и контролируемые мероприятия, не допускающие вариаций или допускающие их в минимальной степени. Применительно к процессам проекта вариации обычно равнозначны неэффективности. Важно управлять рисками правильно, хотя с учетом реальностей и переменных в типичной среде проекта какая-то степень гибкости, конечно, возможна. По мере накопления опыта в управлении рисками у вас начнет развиваться интуитивное ощущение возможных пределов этой гибкости в зависимости от типа, продолжительности, объема, глубины и широты проекта.

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

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

Шаг 1. составьте список рисков

Мозговой штурм. Составление списка потенциальных рисков проекта не должно носить характер аналитической разработки; нужен настоящий мозговой штурм, когда подхватываются на лету все идеи. Шаги 2 и 3 позволяют подробно рассмотреть их. В идентификацию потенциальных угроз и того, что может пойти не так, важно вовлечь всю команду. Некоторые руководители проектов пытаются проделать эту работу самостоятельно, чтобы дать членам коллектива возможность выполнить другие задачи. Это близорукий и вредный подход. Начальный шаг должен осуществляться в атмосфере тесного сотрудничества и включать в себя всех членов команды, являющихся специалистами в своих сферах и отвечающих за свои части проекта. Максимально задействуйте интеллектуальный капитал всей команды. Если за пределами такого мозгового штурма окажется хотя бы один член коллектива, весьма вероятно, что часть рисков останется неидентифицированной и успех проекта будет под угрозой. Помните, что нужно вовлекать всех: специалисты по закупкам (снабженцы) не помогут определить возможные проблемы разработки программного обеспечения, а программисты – проблемы с закупками.

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

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

Шаги 2 и 3. определите вероятность материализации риска и его возможное негативное воздействие на проект

Я объединяю шаги 2 и 3, поскольку они оба связаны с классификацией рисков по приоритетности. Они помогают расставить риски в порядке очередности и определить, сколько времени, усилий, человеческих ресурсов и денег следует направить на предотвращение каждой из идентифицированных угроз или на смягчение ее негативных последствий. Это также следует осуществлять с полным участием членов команды и привлеченных экспертов по предметной области (Subject Matter Experts, SME).

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

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

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

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

В соответствии с данными таблицы главное внимание команды должно быть направлено на проект В из-за высокой стоимости риска по нему: $28 000. По тому же принципу можно определить негативный эффект для графика или распределения ресурсов.

Шаг 4. предотвращайте риски или минимизируйте их последствия

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

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

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

Шаг 5. заранее разрабатывайте меры на случай чрезвычайных ситуаций

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

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

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

Шаг 6. определите «точку пуска» для включения чрезвычайного плана

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

Если у надежного поставщика возникли проблемы с персоналом и он вынужден был остановить производство из-за забастовки, то, скорее всего, у вас на такой случай предусмотрены альтернативные поставщики Б и В. У каждого имеются на складе нужные вам устройства, и каждый поставил условие, что ему необходимо две недели для поставки. Если устройства нужны к 15 февраля, «точка пуска» даст вам эти две недели плюс-минус несколько дней. Значит, оптимальной «точкой пуска» будет 31 января. Если меры на непредвиденный случай приходятся на особо сложный период исполнения проекта, необходимо предусмотреть возможность прибавить еще несколько дней.

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

Создание резервов

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

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

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

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

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

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

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

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

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

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

Точки координации

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

Матрица рисков

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

Рис. 6.1. Матрица рисков

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

Реестр рисков

Эффективным инструментом управления рисками проектов является также реестр рисков (табл. 6.1).

Таблица 6.1. Реестр рисков

Источник: семинар Американской ассоциации менеджмента «Повышение навыков управления проектами: основа успеха».

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

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

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

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

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

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

Разве вам не приходилось получать электронные сообщения на пяти машинописных страницах с бесчисленными параграфами? Некоторые сообщения напоминают новеллы, посвященные любимым. И наоборот, некоторые имейлы из трех слов оставляют адресата в недоумении по поводу того, что же хотел сказать отправитель. Такую манеру использования электронной почты я называю «коммуникациями Дикого Запада». В ней не существует никаких правил, законов или норм. Электронные коммуникации по проекту зависят от вкусов и привычек отправителей и получателей. Это оставляет впечатление «свободного полета мысли» и никоим образом не сочетается со средой проекта, в котором есть строгие ограничения по содержанию, расписанию и расходам.

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

Несколько рекомендаций руководителям проектов и членам команды по использованию электронной переписки по проекту.

• Посылайте электронные сообщения только тем, кому они необходимы.

• Внимательно перечитайте имейл перед отправкой, используйте режим проверки правописания.

• Используйте раздел «Тема сообщения».

• Создайте в команде правила использования электронной почты и придерживайтесь их.

• Если вы рассердились… подождите немного, прежде чем отправлять сообщение.

• Не пишите романов, будьте кратки.

• Соблюдая краткость, старайтесь включать в сообщение всю необходимую информацию.

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

• Если информация носит деликатный или закрытый характер, встречайтесь со своими корреспондентами лично.

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

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

• Что является предметом коммуникаций по проекту?

• Когда эти коммуникации должны осуществляться (в конце года, в другое время)?

• Как будут осуществляться коммуникации (по электронной почте, путем направления бумажных документов с оригиналами подписей, на совещаниях)?

• Как часто должны осуществляться коммуникации?

• Кто отвечает за коммуникации (и обеспечивает их осуществление)?

• Кто является адресатом коммуникаций?

Дав ответы на эти вопросы, вы сможете составить план управления коммуникациями проекта (табл. 6.2).

Таблица 6.2. План управления коммуникациями проекта

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

Резюме

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

• «Процесс в шесть шагов» по разработке плана управления рисками включает в себя составление списка потенциальных рисков; определение вероятности их материализации и потенциального негативного эффекта; предотвращение рисков или минимизацию их негативных последствий; разработку мер на случай непредвиденных ситуаций и установление «точек пуска» для применения чрезвычайных мер.

• Создание резервов на случай чрезвычайных ситуаций и управленческих резервов позволяет максимально использовать потенциал вашего плана по управлению рисками.

• Стандартная матрица рисков – полезный инструмент при управлении большим количеством рисков в проекте.

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

• Создайте порядок использования электронной почты в проекте; привлеките к этому членов вашей команды для достижения единого понимания.

• Разработайте собственный план управления коммуникациями проекта. Этот процесс так же важен, как и все другие процессы управления проектами.

Упражнение

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

• превентивные меры;

• чрезвычайные меры;

• «точки пуска».

Достаточно двух-трех таких точек для каждого риска.

Глава 7. Использование иерархической структуры работ в планировании проекта

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

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

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

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

Простой пример

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

Рис. 7.1. Схема ИСР по уборке комнаты

Для того чтобы пропылесосить комнату, нужно достать пылесос из кладовки, присоединить шланг, вставить штепсель в розетку, перемещать пылесос по комнате, выбросить пыль из мешка, а потом убрать пылесос обратно в кладовку. Это еще более мелкие задачи по отношению к субзадаче «пропылесосить». На рисунке 7.1 показано, как это может быть отображено в формате ИСР.

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

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

Рис. 7.2. Уровни иерархической структуры проекта

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

Рис. 7.3. Компоненты ИСР

Рекомендации по разработке ИСР

Один очень важный вопрос при разработке ИСР заключается в следующем: «До какой степени можно «измельчать» работы»? Общий принцип состоит в том, чтобы разбивать (декомпозировать) работы по проекту до такой степени, до какой можете определить их срок и стоимость с желаемой точностью; или до такой степени, когда работа станет занимать минимальный отрезок времени, с которым вы планируете составлять ее расписание. Если это расписание до ближайшего дня, разбейте работу на такие порции, в которых выполнение очередных задач занимает примерно день; если до ближайшего часа, то продолжительность выполнения задачи должна составлять около часа.

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

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

Существует по крайней мере одно программное обеспечение, которое называется «Эксперт по суперпроектам» (SuperProject Expert™), которое сразу компонует и распечатывает ИСР после того, как заложены данные о расписании проекта. Это неплохая программа, тем более что она сразу «выдает» привлекательную картинку ИСР. Однако, прежде чем ее запускать, нужно составить хотя бы приблизительный рисунок ИСР, потому что до тех пор, пока каждый член команды не согласится, что идентифицированы все задачи, любое расписание будет обманчивым. Нет уверенности в том, что главный путь исполнения проекта, намеченный на основании частичного расписания, совпадет с тем, который определен на основе полной гармонограммы проекта.

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

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

Использование иср

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

Важной функцией ИСР является распределение ответственности за решение тех или иных задач. Каждая намеченная к выполнению задача должна быть поручена конкретному исполнителю, который несет ответственность за ее решение. Форма распределения ответственности показана в табл. 7.1.

Таблица 7.1. Схема распределения задач

Оценка сроков, стоимости и ресурсов проекта

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

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

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

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

Такова общая идея. Однако по закону Паркинсона («работа занимает все отведенное на нее время») выполнение задачи может занять больше отведенного времени, но почти никогда – меньше. Одна из причин – если остается время, люди стремятся улучшить сделанное. Другая причина – работники опасаются, что, если они будут сдавать работу раньше срока, им установят более жесткие временные нормативы или увеличат нормативы производительности.

Это очень важный момент: если людей наказывать за то, что они работают лучше, чем установлено нормативом, они перестанут это делать. Следует также принимать во внимание вариабельность результатов труда. Если один и тот же человек сортирует карты снова и снова, результаты у него будут различаться. Иногда ему потребуется две минуты, иногда – четыре. В среднем это три минуты, но можно ожидать, что в половине случаев результат составит три минуты и менее, а в половине – три минуты и более. Очень редко он будет равняться точно трем минутам.

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

То же самое относится и ко всем задачам по проектам. Время их выполнения различается вследствие действия сил и обстоятельств, неподконтрольных индивидууму. Карты в колоде перемешаны каждый раз по-новому. Внимание работника может отвлекать громкий посторонний шум. Работник может уронить карту во время сортировки. Может устать. И так далее.

Можно ли избавиться от вариабельности? Никогда.

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

Опасности, связанные с оценками

Вот история Кэрен. Однажды руководитель остановился около ее рабочего стола примерно в час дня. «Нужно сделать для меня оценку проекта, – сказал он Кэрен. – Я обещал шефу представить ее к четырем часам. Сделаешь?»

Кэрен кивнула и несмело улыбнулась шефу. «Мне нужна только приблизительная оценка», – сказал он и выплыл из комнаты.

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

Прошло два месяца. И вдруг разорвалась бомба. На пороге ее комнаты появился улыбающийся руководитель. «Помнишь ту оценку, которую ты готовила для меня по проекту XYZ?»

Кэрен напряглась, припоминая. Руководитель не уходил, и она наконец вспомнила то задание. На стол Кэрен легла толстая пачка документации. «Вот теперь твоя работа», – сказал он и уплыл в руководящие сферы.

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

В конечном счете она составила новую оценку стоимости проекта, основываясь на переданных боссом документах. Она оказалась почти на 50 % выше, чем первоначальная. Она еще раз проверила все цифры, убедилась, что ее расчеты правильны, и пошла к руководителю.

Едва взглянув на цифры, он буквально взорвался. «Ты что со мной делаешь?! Я уже сказал шефу, что мы сделаем все за ту цену. Я не могу теперь заявить, что проект стоит настолько дороже. Он убьет меня!»

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

«Ничего не могу поделать, – уперся руководитель. – Я уже ознакомил его с теми цифрами. Тебе придется найти способ уложиться в них».

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

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

Некоторые идеи об эффективной работе по оценке проектов

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

Опора на предыдущий опыт

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

Уровень детализации оценок

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

Персональная ответственность за подготовку оценок

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

В таблице 7.2 показано, что стандартная 40-часовая рабочая неделя должна учитывать неизбежные потери в проекте (15 %), переделки/исправления (10 %) и дополнительные затраты труда. Как показывают цифры, оценочные затраты труда составляют 56 часов, а не 40, оценочная потребность в рабочих днях составляет семь, а не пять дней.

Таблица 7.2. Производительность труда работника

Менеджеры проектов должны работать в реальном мире. Мы выполняем работу в трех координатах: содержание, время и стоимость (см. рис. 11.1). Следовательно, при составлении оценок по проектам нужно учитывать реальную производительность труда.

Баланс между сроками, стоимостью и ресурсами проекта

Работая над созданием среды проекта, не забывайте о динамике человеческой природы. Помните, что члены вашей команды не роботы.

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

Рис. 7.4. Взаимозависимость между сроками, стоимостью и ресурсами проекта

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

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

Первая оценка оптимистичная, или оценка, основанная на наилучшем сценарии. Вторая – пессимистичная, или оценка, основанная на наихудшем сценарии. И третья оценка – наиболее вероятная.

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

где О – оптимистичная оценка, НВ – наиболее вероятная оценка, П – пессимистичная оценка.

Один из вариантов оценок по трем точкам – техника оценки и анализа проектов (Program Evaluation and Review Technique, PERT). Она была разработана в 1957 году для проекта по конструированию ракет Polaris для подводных лодок специальной командой, в которую входили представители Департамента исследований военно-промышленных корпораций Booz Allen Hamilton, департамента ракетостроения Lockheed и отделения оценки программ ВМФ США.

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

где О – оптимистичная оценка, НВ = оценка наибольшей вероятности, П = пессимистичная оценка.

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

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

Повышение способности к оценочной деятельности

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

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

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

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

Закупая продукт, управляющий проектом должен поставить три вопроса:

Что должно быть закуплено?

Когда именно этот продукт необходим?

Как это будет приобретено?

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

Просмотрите данные по предыдущим проектам, поговорите с коллегами и внимательно изучите действующие правила и законоположения! Например, в корпорации Northrop Grumman я был связан Правилами федеральных закупок в сфере обороны (FAR), которые содержат массу требований и ограничений. Коммерческие закупки в частном бизнесе значительно меньше «зарегулированы» и предоставляют больше свободы действий. Если же вы в чем-то не уверены… спрашивайте.

Запросы по закупкам бывают следующими.

• Запрос информации. Обычно это простой начальный запрос потенциальному продавцу относительно товаров или услуг, которые поставляет его компания.

• Запрос цены. Это наиболее распространенное обращение к поставщикам об имеющихся в наличии товарах.

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

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

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

а) договоры с фиксированной ценой. Цена товара или услуги согласуется заранее и не подлежит корректировке или изменению;

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

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

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

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

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

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

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

Резюме

• Не пытайтесь определить последовательность действий по проекту, разрабатывая иерархическую структуру работ. Это вы сделаете при разработке расписания проекта.

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

• Оценка – это предположение, а точная оценка – нонсенс!

• Остерегайтесь превращения черновых или приблизительных оценок в фиксированные цели проекта.

• Методика трехточечных оценок используется, чтобы оценить уровень неопределенности оценок.

• Техника PERT отлично подходит тогда, когда оценка осуществляется в условиях высокой неопределенности.

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

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

Упражнение

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

• Составить список необходимых продуктов и снаряжения.

• Выбрать конкретный кемпинг.

• Попросить подготовить место в кемпинге.

• Зарезервировать место размещения в кемпинге.

• Договориться об отпуске на работе.

• Выбрать дорогу к кемпингу.

• Разработать меню питания.

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

• Загрузить машину.

• Упаковать сумки и рюкзаки.

• Закупить продукты.

• Организовать поездку в кемпинг (проект).

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

Глава 8. Разработка расписания проекта

Один из главных элементов, которые отличают проектный менеджмент от общего, – особое внимание к расписанию проекта. Вспомните приведенное в главе 1 высказывание д-ра Дж. М. Джурана о том, что проект – это проблема, запланированная к решению.

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

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

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

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

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

Краткая история эволюции разработки расписания проектов

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

Рис. 8.1. Линейчатая диаграмма (диаграмма Гантта)

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

Для того чтобы преодолеть этот недостаток, в конце 1950-х – начале 1960-х годов были разработаны еще два метода составления расписаний проектов. Оба основаны на стрелочных диаграммах, чтобы показать последовательность или параллельность работ по проекту. Один из этих методов, созданный Дюпоном, называется метод критического пути (Critical Path Method, СРМ), а другой – уже упомянутый в главе 7 метод PERT – техника оценки и анализа проектов (на их основе составляются сетевые программы PERT). Хотя в настоящее время стало привычным называть все стрелочные диаграммы сетевыми диаграммами PERT, строго говоря, этот метод использует определения вероятностей, тогда как метод критического пути – нет. Другими словами, на основе метода PERT можно рассчитать вероятность того, что такой-то компонент работы по проекту будет завершен к определенному времени. А метод критического пути (СРМ) этого сделать не позволяет.

Сетевые диаграммы

Для того чтобы показать последовательность выполнения работ по проекту, используются диаграммы, подобные изображенной на рис. 8.2. На этих диаграммах отражено, что задача А выполняется до задачи Б, а задача В – параллельно с ними обеими.

Рис. 8.2. Стрелочные диаграммы

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

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

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

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

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

Причины необходимости расписаний проектов

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

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

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

Я часто слышу, что содержание и приоритетные задачи в проектах меняются так часто, что не имеет смысла тратить время на определение критических путей. Здесь нужно подчеркнуть два момента. Во-первых, если содержание проекта изменяется слишком часто, это означает, что перспективному планированию было уделено недостаточно внимания. Содержание чаще всего меняется из-за того, что в проекте что-то было забыто изначально. Если проекту с самого начала уделять достаточно внимания, то обычно необходимость в ревизии его содержания снижается.

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

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

Определение терминов для сетевых диаграмм

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

КРИТИЧЕСКАЯ: критическая работа или событие являются такими составными частями проекта, которые должны быть завершены или приурочены к определенному времени. По ним не может быть никаких допусков или задержек.

КРИТИЧЕСКИЙ ПУТЬ: критический путь – это самый длинный отрезок в расписании и сетевой диаграмме, который определяет самый ранний срок завершения проекта.

СОБЫТИЯ: начальная точка и точка окончания работы или действия называются событиями. Событие – это определенная точка во времени. Графически события обычно изображаются кружками и могут иметь некие обозначения (словами, цифрами или элементами буквенно-цифрового кода).

ВАЖНЫЙ РУБЕЖ ИЛИ ВЕХА ПРОЕКТА: важный рубеж, или веха проекта, представляет собой точку во времени, совпадающую с важным событием для проекта. Обычно под этим понимается завершение важнейших фаз работы по проекту. Анализ проектов часто осуществляется по таким вехам.

СЕТИ: сетями обычно называют стрелочные диаграммы. Они графически изображают проект и взаимосвязь различных работ и действий по нему.

Создание стрелочной диаграммы

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

Рис. 8.3. ИСР по проекту уборки участка

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

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

Вот хорошее правило: ни одна задача расписания не должна занимать более 4–6 недель. Можно разбить 26-недельную работу на 5–6 субзадач. Такой метод обычно удерживает людей от бесконечных переносов работы на последние дни исполнения проекта.

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

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

Рис. 8.4. Диаграмма уборки участка (метод «критического пути»)

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

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

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

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

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

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

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

Резюме

• Управление проектом не сводится к составлению расписания.

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

• Уровнем детализации расписания можно управлять.

• Не следует оставлять ни одной задачи расписания продолжительностью более 4–6 недель. Протяженные задачи разбивайте на субзадачи для достижения этого ориентира. Задачи в программном обеспечении и инженерных технологиях следует разбивать на еще более мелкие отрезки, не превышающие по продолжительности 1–3 недель.

Упражнение

Нарисуйте стрелочную диаграмму для ИСР (рис. 8.5). Одно из решений приводится в разделе «Ответы на вопросы».

Рис. 8.5. ИСР по уборке комнаты

Глава 9. Создание рабочего расписания проекта

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

Расчет расписания проекта

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

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

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

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

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

Правила сети расписания проекта

Для расчета времени начала и окончания сети расписания проекта применяются только два правила: правило 1 и правило 2. Другие правила компьютерные программы могут применять сами. Обычно, это функция конкретной программы, поэтому не имеет отношения ко всем сетям.

ПРАВИЛО 1. Прежде чем начнется выполнение конкретной задачи или работы, все предшествующие работы должны быть завершены.

ПРАВИЛО 2. Стрелки обозначают логический порядок работ.

Базовые расчеты расписания

Расчеты расписания проиллюстрированы в диаграмме сети (рис. 9.1). Сначала внимательно посмотрим на квадратики в диаграмме. В каждом из них содержатся сокращения РС, ПС, РФ, ПФ и ПР.

РС – ранний старт;

ПС – поздний старт;

РФ – ранний финиш;

ПФ – поздний финиш;

ПР – продолжительность (выполнения работы или решения задачи).

Рис. 9.1. Сеть расписания, которая иллюстрирует принципы его расчета

Вычисления с направленностью вперед

Посмотрите на какую-нибудь отдельную работу, внесенную в сеть расписания, например уборку мусора на участке. Ее продолжительность 15 минут. Если предположить, что она начнется с временной точки 0, то может быть закончена через 15 минут. Значит, мы можем внести число 15 в ячейку, помеченную как РС.

Заправка бензином газонокосилки и культиватора для устранения сорняков занимает всего пять минут. Логика диаграммы говорит нам, что обе эти задачи должны быть выполнены до того, как мы начнем выпалывать сорняки, косить траву и убирать ее с дорожек. Уборка мусора занимает 15 минут, а заправка косилки и культиватора – только пять. Когда могут быть начаты следующие работы? Только тогда, когда закончится уборка мусора, потому что это самая продолжительная задача из первых работ.

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

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

Рис. 9.2. Сетевая диаграмма расписания с указанием ранних финишей

ПРАВИЛО. Когда две или более работ или задач предшествуют другой задаче, самое раннее время ее начала определяется наибольшей продолжительностью предшествующей работы.

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

Вычисления с обратной направленностью

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

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

Если до окончания операции по вывозу мусора должно пройти 165 минут, а сама операция занимает 45 минут, то каков самый поздний срок ее начала? Понятно, что если мы вычтем 45 из 165, то получим 120 минут, что и определяет самое позднее время начала этой операции. Действуя таким же образом, получаем самое позднее время начала упаковки травы в мешки 90 минут, а самое позднее время связывания подрезанных веток – 105 минут. Одно из этих чисел должно быть временем позднего финиша для каждой из предшествующих операций. Какое именно?

Предположим, мы остановимся на 105 минутах. Тогда расписание проекта подскажет нам, что упаковка травы в мешки может начаться самое позднее через 105 минут после начала проекта, поскольку последующие задачи могут решаться только по выполнении предыдущих. Если мы прибавим время, необходимое на упаковку, – 30 минут – к 105 минутам раннего старта, то закончим эту операцию через 135 минут после начала проекта, что больше тех 120 минут, которые были определены ранее. Таким образом, мы превысим срок исполнения проекта, который должен составлять 165 минут.

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

Теперь посмотрите на сетевую диаграмму расписания, представленную на рис. 9.3. Обратите внимание, что некоторые операции выделены жирным шрифтом. Каждая такая операция имеет одинаковое время раннего старта / позднего старта и раннего финиша / позднего финиша. На этом пути нет резерва времени. По определению, трудовая операция или задача, для которой не предусмотрены временные резервы, называется критической. А вся цепочка таких операций, не имеющих временных резервов, именуется критическим путем (подразумевается, что в случае задержки любой операции на этом пути соответствующим образом изменится и дата окончания проекта). Все те пакеты работ, у которых различное время РС/ПС или РФ/ПФ, располагают определенным временным резервом. Например, в операции по уборке сорняков время раннего старта – 15 минут, а позднего – 60 минут. Таким образом, временной резерв составляет 45 минут.

Рис. 9.3. Сетевая диаграмма, показывающая «критический путь»

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

Работы и трудовые операции по проекту, которые находятся на критическом пути, не имеют запасов времени. Они должны быть завершены точно в соответствии с расписанием, или срок исполнения всего проекта превысит 165 минут. Зная, где именно в проекте проходит критический путь, менеджер проекта понимает, на чем конкретно должно быть сосредоточено его внимание. Другие задачи имеют временной лаг. Это не означает, что к их выполнению можно относиться легкомысленно, но они с меньшей вероятностью задержат весь проект, если при их решении возникнут трудности. Например, уборка проросшей на дорожках травы имеет РС 15 минут и ПС 75 минут. Разница между этими показателями составляет 60 минут, что является временным резервом для этой операции.

Что дает нам временной резерв? Как минимум мы знаем, что можем начать выполнение данной операции даже через 75 минут после начала проекта и все же успеем завершить его вовремя. Если вы поручили эту работу своему сыну, то в течение 60 минут он может смотреть телевизор и все равно исполнит задание в срок.

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

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

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

Использование сетевых диаграмм расписания в управлении проектом

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

• Старайтесь придерживаться расписания. Труднее догонять, чем с самого начала равномерно продвигаться к цели.

• Всегда имейте резервное время на случай непредвиденных проблем или неправильных оценок.

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

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

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

• Я уже говорил в главе 7, но считаю нужным повторить: ни одна операция или задача в проекте не должна быть рассчитана более чем на 4–6 недель, иначе люди погружаются в ложное ощущение безопасности, откладывая работу и говоря себе: «Я всегда могу начать». Ко времени фактического начала работы они обнаруживают, что уже отстают на несколько дней и не могут закончить ее в соответствии с расписанием. Мы говорим, что они откладывают все усилия на последний отрезок установленного срока. Если выполнение задачи или операции требует более шести недель, полезно разделить их на несколько этапов, установив между ними при необходимости искусственные перерывы. В ходе этих перерывов целесообразно проанализировать достигнутый прогресс. Это позволит держать всю работу нацеленной на конечную цель.

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

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

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

Перевод стрелочных диаграмм в линейчатые

Хотя стрелочные диаграммы и важны для правильного анализа взаимосвязи между отдельными работами и операциями в проекте, линейчатые диаграммы Гантта представляются мне более удобными. Подчиненные сразу понимают, когда им следует начать работу, а когда – закончить ее. Стрелочная (сетевая) диаграмма на рис. 9.3 изображена как линейчатая диаграмма на рис. 9.4. При этом мы пользуемся тем, что узнали о расписании проекта из анализа сетевой диаграммы.

Рис. 9.4. Линейчатая диаграмма расписания проекта по уборке участка

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

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

Обеспечение проекта ресурсами

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

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

Посмотрите на расписание на рис. 9.5. Оно включает в себя всего четыре задачи. Две из них критические, а две имеют временные резервы. Для выполнения в течение трех недель задачи А необходимы два работника. Задачи Б и В требуют по одному работнику каждая. Однако когда подходит время для исполнения проекта, вы обнаруживаете, что у вас всего три работника. Как это произошло?

Рис. 9.5. Расписание с перегруженными ресурсами

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

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

Рис. 9.6. Расписание, в котором резервы времени используются для выравнивания ресурсов

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

Рис. 9.7. Расписание с недостаточным временным резервом по операции В для выравнивания ресурсов

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

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

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

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

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

Предположим, вы попробовали и это и снова ничего не получилось. Вы решаете: единственное, что осталось, – это отказаться от работы. Ведь вы никогда не хотели быть руководителем проекта. Подождите. Может быть, можно еще кое-что предпринять?

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

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

Рис. 9.8. Расписание проекта с критическим выравниванием ресурсов

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

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

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

Ресурсное обеспечение

Важнейшим фактором распределения ресурсов проекта является правильный учет способности каждого человека выполнять свою работу. Инженеры в промышленности обычно исходят из того, что ни один работник не может уделять собственно работе больше 80 % своего рабочего времени. При восьмичасовом рабочем дне это 6,4 часа. С учетом здоровой предусмотрительности реально это шесть часов. 20 % потерянного рабочего времени распределяются на три фактора, называемых ЛУЗ[6]: Л – факторы личного порядка (любому работнику нужны перерывы, вызванные физиологическими причинами); У – фактор усталости (производительность труда людей снижается по мере накопления усталости); З – фактор задержек (люди теряют время в ожидании рекомендаций коллег, поставки комплектующих и деталей или указаний со стороны руководства).

Опыт показывает, что даже уровня в 80 % достигают только те, кто привязан к своему рабочему месту. Это относится прежде всего к людям, занятым физическим трудом, или тем, кто выполняет достаточно однообразные операции, например к сотрудникам страховых компаний, которые принимают заявления по страховым случаям (но даже они время от времени передвигаются по помещению). Что касается работников интеллектуального труда, нельзя ожидать, что они посвятят 80 % своего рабочего времени продуктивной работе. Этот показатель обычно ближе к 50 %, а то и ниже! В одной компании, занимающейся проектами, провели эксперимент, в ходе которого люди фиксировали свои занятия через каждые два часа в течение двух недель. В результате оказалось, что собственно работа над проектами составила только 25 % их рабочего времени. Остальное ушло на совещания, сопутствующие операции, старые проекты, которые были завершены прежде и теперь поступили для анализа к разрабатывавшим их работникам, составление бюджетов на следующий год, работу с заказчиками и так далее.

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

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

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

Резюме

• Начиная разработку расписания, исключите возможность ограничения проекта в ресурсах.

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

• Никто не в состоянии обеспечить продуктивную работу на протяжении более 80 % продолжительности рабочего дня.

Упражнение

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

Рис. 9.9. Диаграмма сети расписания в качестве упражнения

Глава 10. Контроль и анализ проекта

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

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

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

Я задавал один и тот же вопрос ряду высших руководителей корпоративного сектора (президентам и вице-президентам компаний):

– В ваших руках большая власть. Гарантирует ли она, что люди станут делать то, что вы считаете необходимым?

Ответ был неизменным: нет.

– Что же тогда может заставить их сделать то, что, по вашему мнению, должно быть сделано?

– В конечном счете только их собственное желание.

– В чем же тогда состоит ваша власть?

– Она дает мне право налагать на работников какие-то санкции, но не более того.

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

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

Подумайте над посылами, которые получают упомянутые руководители проектов. С одной стороны, им говорят: «Мы доверяем вам управление 35 миллионами долларов наших денег». С другой – тут же замечают: «Но вы должны получать одобрение каждой траты у того, кто обладает полномочиями большими, чем у вас». Один посыл позитивный: «Мы вам доверяем». Второй – негативный. И какой из них, по вашему мнению, сильнее? Давайте поспорим! Конечно, негативный.

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

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

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

Обеспечение самоконтроля со стороны членов команды проекта

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

Для этого необходимо соблюдать пять базовых условий.

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

2. Личный план выполнения порученной каждому работы.

3. Навыки и ресурсы, соответствующие поставленной задаче.

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

5. Точное определение полномочий сотрудников на принятие корректирующих действий в случае отклонения от установленного плана (и эти полномочия не могут равняться нулю!).

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

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

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

Четвертое требование предполагает, что работник получает обратную связь о своей работе. Если эта обратная связь идет через третьи руки, то настоящего самоконтроля у работника не получится. Для ясности скажем так: у того, кто строит стену, должна быть возможность лично измерить ее высоту, сравнить с планом и прийти к выводу, выдерживает ли он заданную линию.

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

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

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

• Что важно для организации?

• Что мы пытаемся сделать?

• Какие аспекты работы наиболее важны с точки зрения мониторинга и контроля?

• Каковы критические точки процесса исполнения проекта, в которых должен осуществляться контроль?

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

Осуществление корректирующих действий

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

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

Временные рамки реагирования на проблемы в проекте

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

Конечно, любой руководитель проекта хочет знать, сколько часов сотрудники действительно работают над проектом, и сравнить эти данные с параметрами плана. Это означает, что ему нужны точные данные. В некоторых случаях люди составляют недельные отчеты о своей работе, не записывая результаты ежедневно. Часто это что-то из области фантастики, потому что большинство не могут с точностью помнить, что делали неделю назад.

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

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

Особо выделим один момент. Если каждый член команды проекта будет правильно применять методы самоконтроля, то еженедельные отчеты превратятся в настоящий итог работы, а это очень желательно.

Создание адекватной системы контроля

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

Принцип простоты

Принцип простоты отражен в английской аббревиатуре KISS (Keep it simple, stupid! – «Делай проще, тупица!»). В соответствии с ним следует применять самые простые и мелкие средства контроля, если они дают желаемый результат. С другой стороны, нужно отбрасывать в сторону любые данные, не имеющие существенного отношения к делу. Однако, как я только что заметил, одной из самых распространенных ошибок являются попытки контролировать сложные проекты с помощью слишком простых систем!

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

Чарли Браун (Чарльз Шульц, «Мелочь пузатая») [7]

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

Совещания по анализу исполнения проектов

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

1. Анализ статуса реального состояния объекта.

2. Анализ процесса исполнения проекта и извлеченных из него уроков.

3. Анализ дизайна проекта.

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

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

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

Оценка проекта

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

Оценивать: определять или выносить суждение о ценности или стоимости чего-то.

Словарь английского языка The Random House Dictionary

Цели оценивания проектов

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

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

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

Причина? Конкуренты не сидят в сторонке, отдыхая. Возможно, сейчас они производят что-то лучшее по сравнению с тем, что делаете вы. Если вы не улучшаете самих себя, то вас обгонят и отберут вашу долю рынка.

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

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

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

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

Перечислим причины, по которым необходим периодический анализ процесса движения проекта. Вы должны быть в состоянии:

• улучшить качество исполнения проекта наряду с улучшением управления им;

• обеспечить, чтобы качество исполнения проекта не приносилось в жертву его расписанию и стоимости;

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

• определить области, в которых другие проекты (как текущие, так и будущие) должны управляться по-другому;

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

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

Анализ процесса проекта

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

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

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

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

Отчет об анализе процесса проекта

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

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

2. Ожидаемое состояние проекта. Это своеобразный прогноз состояния проекта в перспективе. Ожидаются ли серьезные отклонения в расписании, стоимости, качестве или содержании проекта? Если так, то в отчете необходимо подробно сформулировать характер и объем возможных изменений.

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

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

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

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

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

Резюме

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

• Для того чтобы проект действительно находился под контролем, необходимо, чтобы все члены его команды контролировали собственную работу.

• Усилия по контролю проекта должны быть соразмерными. Вы же не станете тратить 100 долларов, чтобы купить батарейку за три доллара?

• Если вы не предпринимаете никаких действий для исправления отклонений, то в руках у вас система мониторинга, а не контроля.

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

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

Глава 11. Процесс контроля изменений проекта

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

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

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

Источники изменений

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

Рис. 11.1. Треугольник тройственных ограничений

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

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

Содержание

• К содержанию в порядке консолидации добавляются другие проекты.

• Клиент меняет свои требования.

• Изменяются условия рынка.

• Возникают технические проблемы.

Расписание

• Ускоряются сроки завершения проекта.

• На рынке ужесточается конкуренция.

• Клиент интересуется возможностью досрочного получения результатов.

Стоимость

• Руководство срезает 20 % бюджета проекта.

• Увеличивается стоимость сырья и материалов.

• Работы по проекту требуют увеличения команды на одного человека.

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

Шесть шагов в процессе контроля изменений

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

Шаг 1. Занесите начальную информацию о контроле изменений в свой журнал изменений.

• Внесение всей первоначальной информации по контролю изменений в журнал подытоживает действия в отношении данного изменения, как запрошенные, так и рассмотренные. Детальный журнал изменений может в конечном счете послужить «биографией» проекта по мере его развития (см. табл. 11.1).

Шаг 2. Определение целесообразности рассмотрения запрошенного изменения.

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

• Оценивая возможное влияние изменений, принимайте во внимание качество и цели проекта. Подготовьте рекомендации для исполнения, потом заполните форму контроля изменения.

Шаг 3. Передайте свои рекомендации руководству и/или заказчику, для того чтобы они рассмотрели и одобрили их.

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

Шаг 4. Обновите план проекта.

• Не забудьте обновить план проекта! Об этом часто забывают. Именно в этот момент вы должны создать новый базовый план. Именно он станет текущим.

Шаг 5. Разошлите обновленный план заинтересованным лицам.

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

Шаг 6. Проводите мониторинг осуществляемого изменения и следите за продвижением проекта по обновленному плану.

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

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

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

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

Форма для контроля проекта

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

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

Рис. 11.2. Форма для контроля изменений проекта

Вы можете в чем-то сократить этот шаблон или расширить отдельные его части. Решать вам. Если документ станет слишком запутанным, вы потеряете эффективность. Если вы его слишком упростите, то рискуете потерять важную информацию.

В верхней части формы содержатся общие данные о вносимом изменении или осуществляемой коррекции: номер проекта, номер коррекции (изменения) и дата корректировки проекта. Я всегда включаю цель проекта в свои формы, чтобы обеспечить последовательность действий и исключить неопределенность. Любое изменение может породить неопределенность, а она не относится к числу ваших друзей. По мере того как в процессе реализации проекта множатся изменения, важно постоянно помнить об основной первоначальной его цели. Это удержит заинтересованные стороны от сомнений, не изменилась ли цель проекта в связи с последними коррекциями. Если вносимые в проект изменения существенны, может возникнуть необходимость согласовать и зафиксировать в форме новую цель. В документе полезно давать описание нового изменения, а также причины его внесения. В турбулентной среде проекта, длящегося уже семь месяцев и претерпевшего 37 изменений, бывает сложно вспомнить, почему в нем возникло изменение № 2. А если прибавить к этому еще пять проектов, которыми вы одновременно руководите, то совсем нетрудно представить, насколько полезен этот элемент контроля. Фиксация причины изменения обеспечивает дополнительную ценность в процессе реализации изменения.

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

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

Моя коллега, менеджер групповых программ обучения в Американской международной ассоциации менеджмента (АМА), получила от старшего менеджера просьбу рассмотреть вопрос об оживлении содержания и цветовой гаммы (25 %) руководства Train the Trainer («Учим учить»), предназначенного для интенсивной подготовки руководителей различных курсов. При этом менеджер оговорился, что, возможно, идея не такая уж жизненная, потому что ее реализация требует значительных расходов. Когда моя коллега принесла свой вариант решения этой задачи с довольно скромным бюджетом, менеджер выступил с инициативой изменения, увеличив расходы почти на $10 000. На заседании руководящего совета ассоциации ему задали вопрос о причине внесения такого изменения. Ожидая этого вопроса, он продемонстрировал слайд, запечатлевший форму запроса на изменение, на которой красовались подписи двух членов совета. Совет легко утвердил изменение, и нашему менеджеру даже не понадобился валидол.

Пороги изменений

Сколько изменений нужно для того, чтобы запустить процесс? Существуют ли изменения, которые недостаточно значительны для того, чтобы заполнять на них форму, получать чьи-то подписи и вообще тратить на них время и усилия? Это важные вопросы для руководителя проекта, и они порождают необходимость подумать о порогах изменений. Большинство проектов требуют от управляющих хороших менеджерских и бизнес-навыков. Если какое-то изменение рассматривается как незначительное, а план проекта может «поглотить» его без заметных последствий, просто сделайте необходимые корректировки и двигайтесь дальше (см. пример 1). Однако если при имплементации изменения превышен «порог чувствительности», это должно вызвать соответствующие действия и ваши, и вашей команды, направленные на «включение» процесса контроля изменений (см. пример 2).

Пример 1

Если проект стоимостью $5 000 000 вполне может выдержать изменение в $10, то запускать по нему процесс контроля изменений – неправильное решение. Адекватным порогом здесь может быть сумма в $500 (разумеется, в зависимости от ограничений по бюджету и стандартам отрасли).

Пример 2

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

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

Журнал контроля изменений

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

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

Таблица 11.1. Журнал контроля изменений проектов

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

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

Побочные результаты изменений проектов

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

Часто в проектах возникают «ответвления», которые приобретают настолько серьезный характер и размеры, что и руководитель проекта, и его команда принимают решение создать полностью независимые проекты. Такое происходит вследствие «взрыва содержания», то есть резкого увеличения объема проекта, или по каким-то другим причинам, о которых я уже упоминал. Если новый проект продвигается параллельно с существующим, то они могут и управляться параллельно, требуя, однако, взаимодействия. Если бразды правления переходят к новому менеджеру, вас могут попросить помочь ему в организации нового жизненного цикла проекта. И здесь в ваших интересах проделать самую тщательную работу. Ведь какие-то человеческие и другие ресурсы вашего исходного проекта могут быть оттянуты к нему.

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

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

Принятие изменений

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

Резюме

• Реализация изменения должна быть проконтролирована и доведена до заинтересованных сторон.

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

• Важно все время поддерживать базовый план проекта в актуальном состоянии.

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

• Главные документы руководителя проекта – форма для контроля изменений и журнал контроля изменений.

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

• Часто в проектах возникают «ответвления», которые принимают настолько существенный характер и размеры, что руководитель проекта и его команда принимают решение создать для них полностью независимые проекты.

Упражнение

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

1. Следует ли соглашаться с таким изменением?

2. Следует ли создавать документ по контролю за изменением?

3. Как это изменение сказалось на устойчивости «треугольника проекта»?

4. До кого следует довести вашу реакцию?

5. Какие пороги изменений следует установить для данного проекта?

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

Глава 12. Контроль проектов методом определения освоенного объема

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

Как отмечено в главе 10, анализ, связанный с поддержанием прямого контроля выполнения проекта, заключается в оценке его текущего статуса. Он проясняет, в каком состоянии находится проект с точки зрения всех четырех переменных РССС (результат, сроки, стоимость, содержание). В каждом таком случае вы должны задать три вопроса.

1. Где мы находимся (с точки зрения РССС)?

2. Когда возникло отклонение; что его вызвало?

3. Что следует делать с этим отклонением?

Обратите внимание, что в ответ на вопрос 3 могут быть предприняты следующие четыре действия.

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

2. Проигнорировать отклонение.

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

4. Обновить план, чтобы отразить в нем фактическое состояние проекта, которое не может быть скорректировано.

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

Еще один день, еще одно зеро.

АЛЬФАЛЬФА (Карл Швитцер), комедийный сериал «Банда»

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

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

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

Измерение прогресса

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

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

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

Это «предположение».

Так что в описанных случаях мы просто предполагаем, где находимся.

Да. Когда мы прибудем в точку назначения, точно узнаем об этом. А пока еще не прибыли, мы «предполагаем».

Не созвучно ли это словам героев «Алисы в Стране чудес»?

О боже.

Так как звучало определение контроля? Давайте посмотрим: сравнение того, где вы находитесь… А как вы узнаете, где находитесь?

Путем предположений.

…с тем, где должны находиться… А как вы узнаете, где должны находиться?

Ну, это очень просто. Об этом нам говорит план.

А план откуда взялся?

Он тоже в определенном смысле является оценкой.

Вот это да! Значит, если одно предположение не совпадает с другим, мы обязаны предпринимать корректирующие действия, чтобы они совпали, так?

Именно так этот человек утверждает в этой своей книге.

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

Нет, неправильно. Тот факт, что измерения состояния продвижения проектов не очень точны, не говорит о том, что их не нужно использовать вовсе. Помните: если у вас нет плана, то нет и контроля. А если вы к тому же и не пытаетесь отслеживать выполнение плана, то контроля нет и подавно. А если нет контроля, то вы даже близко не управляете проектом. Вы просто околачиваетесь вокруг него.

Вместе с тем важно и то, что одни проекты поддаются более плотному контролю, чем другие. Хорошо определенную работу, которую можно точно измерить, можно и плотно контролировать. Работы более расплывчатого характера (например, интеллектуальный труд) предполагают более значительные допуски степени контроля. Руководство и менеджеры должны понимать и принимать это. Иначе вы сойдете с ума, пытаясь добиться максимума допуска в контроле в 3 %. Это все равно что продевать лапшу в игольное ушко или прибивать студень к стене.

Измерение результатов/качества исполнения проекта

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

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

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

Контроль методом определения освоенного объема

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

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

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

• Отклонение по стоимости. Сравнение освоенных объемов работы и ее фактической стоимости.

• Отклонение по срокам. Сравнение освоенных и плановых объемов.

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

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

• Фактическая стоимость выполненных работ. Объем денежных средств (или усилий), фактически затраченных на завершение данных работ в указанный период.

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

Отклонение по стоимости = Реально выполненный объем работ, указанных в бюджете – Фактическая стоимость выполненных работ, указанная в бюджете

Отклонение – любое нарушение плана

Объединяя отклонения по стоимости и отклонения по срокам, можно получить интегрированную систему, указывающую состояние параметров стоимость/сроки:

Отклонение по срокам = Реально выполненный объем работ, указанных в бюджете – Стоимость запланированных работ, указанная в бюджете

Анализ отклонений с использованием кривых расходов

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

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

Если компьютерная программа не может обеспечить вас необходимой информацией, на рис. 12.2 показано, как можно рассчитать эту кривую вручную. Перед вами простая линейчатая диаграмма. На ней показаны три задачи. Для решения задачи А необходим недельный труд, то есть 40 рабочих часов стоимостью $20 в час. Общие расходы на нее составят $800 в неделю. Задача Б требует затраты 100 рабочих часов по $30 в час, то есть всего $3000 затрат. Наконец, задача В требует затрат $2400, поскольку для ее решения нужно 60 рабочих часов стоимостью $40 за один час.

Рис. 12.2. Линейчатая диаграмма, иллюстрирующая совокупные затраты

Внизу таблицы мы видим, что в первую неделю затраты на оплату труда составляют $800. Во вторую неделю выполняются одновременно задачи А и Б, поэтому затраты на оплату труда уже $3800. На третьей неделе выполняются все три задачи, так что затраты на оплату труда составляют уже сумму трех чисел, то есть $6200. Это недельные расходы.

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

Рис. 12.3. Совокупные расходы в контрольном графике

Посмотрите на кривую, изображенную на рис. 12.4. На указанный период по проекту должно быть освоено $40 000 затрат на выполнение работ, указанных в бюджете (СЗРБ). Фактическая стоимость выполненных работ (ФСВР) составляет $60 000. Эти цифры обычно дает бухгалтерский учет, и основываются они на учете рабочего времени, затраченного на проект. Однако СЗРБ проекта равняется $40 000. Это означает, что проект отстает от расписания и расходы по нему превышают запланированные.

Рис. 12.4. Ситуация, когда проект отстает от расписания, а расходы по нему превышают запланированные

На рисунке 12.5 показан другой вариант. В этом случае кривые СЗРБ и ФСВР практически сходятся в одной точке, на уровне $60 000. Это означает, что проект обгоняет расписание, но расходы по нему соответствуют фактически выполненной работе.

Рис. 12.5. Ситуация, когда проект обгоняет расписание, а расходы по нему не превышают запланированные

Следующий график демонстрирует иную ситуацию. На рисунке 12.6 кривые СЗРБ и ФСВР сходятся в точке $40 000. Это означает, что проект отстает по срокам, а затраты по нему ниже бюджетных. Однако поскольку менеджер потратил $40 000 и получил $40 000 освоенных объемов, расходы соответствуют тому, что было сделано. В данном случае мы имеем дело с отклонением по срокам, но не по стоимости.

Рис. 12.6. Ситуация, когда проект отстает по срокам, но затраты по нему соответствуют бюджету

График на рис. 12.7 выглядит почти так же, как на рис. 12.4, но кривые СЗРБ и ФСВР имеют противоположное направление. Этот проект обгоняет сроки, а расходы по нему ниже запланированных.

Рис. 12.7. Ситуация, когда проект обгоняет сроки и затраты по нему ниже бюджетных

Анализ отклонений с использованием расчета рабочих часов

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

Результаты будут следующими.

• СЗРБ становится общим запланированным (или содержащимся в расписании) количеством рабочих часов.

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

• ФСВР становится количеством фактически отработанных часов.

При использовании часов работы в качестве единицы отчетности получаем следующие формулы:

Отклонение по срокам = РВРБ – СЗРБ = Отработанные в рамках проекта часы – Запланированные часы

Отклонение по затратам труда = РВРБ – ФСВР = Учитываемые в рамках проекта рабочие часы – Фактически отработанные рабочие часы

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

Реагирование на отклонения

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

• Когда ФСВР и РВРБ почти одинаковы и превышают ЗСРБ (см. рис. 12.5), это означает, что к проекту были привлечены дополнительные ресурсы, однако рабочие расценки остались прежними. Это может произойти в нескольких случаях. Например, вы планировали задержки продвижения проекта из-за погоды, но она не подвела, и вы успели выполнить в указанный для анализа период больше работы, чем планировалось, но по прежним расценкам. Таким образом, вы обгоняете сроки проекта, но остаетесь по затратам в рамках бюджета.

• Когда значения ФСВР и РВРБ близки, но ниже ЗСРБ (рис. 12.6), это обычно характеризует ситуацию, обратную только что описанной. То есть вы не выделили на проект достаточного количества ресурсов. Возможно, их у вас просто украли; возможно, дождливая погода длилась дольше, чем вы планировали; а возможно, все ваши работники вдруг взяли отпуск в одно и то же время. Проблема в том, что в попытках догнать график вы превышаете запланированные затраты.

• Когда ФСВР ниже ЗСРБ, а РВРБ выше ЗСРБ (см. рис. 12.7), это значит, что проект обгоняет сроки, а траты по нему ниже запланированных. Такое обычно случается, когда первоначальные оценки по проекту слишком консервативны (возможно, они сделаны преимущественно по соображениям безопасности). Другой вариант – это если на вас свалилось счастье. Работа оказалась проще, чем вы думали, так что вы солидно продвинулись вперед. Иногда это случается, когда на проект собирается гораздо более работоспособная команда, чем предполагалось сначала. Однако и здесь существует своя проблема: проект начинает связывать ресурсы, которые могли бы быть направлены на другие проекты. Экономисты называют такие ситуации стоимостью неиспользованных возможностей. Помните: систематически завышая сроки и стоимость проектов в своих предложениях, вы рискуете проиграть в борьбе с конкурентами. Если конкурент использует средние оценки для определения сроков исполнения проекта, а вы свои завышаете, вы, скорее всего, потеряете предложение.

Приемлемые отклонения

Что такое приемлемые отклонения? Единственным ответом на этот вопрос может быть фраза: «Все зависит от обстоятельств». В хорошо распланированном строительном проекте отклонения обычно в пределах от +3 до – 5 %. Если проект относится к области НИОКР, границы приемлемых отклонений расширяются от +10 до – 15 %. А когда предметом проекта являются чистые исследования, пределом может быть только небо. Представьте себе, например, что вы работаете на фармацевтическую компанию и ваш руководитель спрашивает: «Скажите, сколько вам понадобится времени и средств для разработки лекарства от ВИЧ-инфекции?»

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

Использование метода процентной оценки завершенности работ по проекту

Наиболее распространенным методом измерения степени продвижения проекта является простая процентная оценка его завершенности, или готовности. Она похожа на показатель СЗРБ, только тот имеет денежное выражение, а процент завершенности в деньгах не определяется.

Когда измерение процента готовности проекта осуществляется во времени, обычно мы получаем кривую, подобную изображенной на рис. 12.8. Она поднимается более или менее линейно до уровня 80–90 %, потом становится горизонтальной (что означает отсутствие на этом участке прогресса). Кривая некоторое время остается в таком состоянии, а затем, довольно неожиданно, работы по проекту завершаются.

Рис. 12.8. Кривая процентной оценки завершенности

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

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

Представьте себе задание, на выполнение которого требуется 10 недель. Если вы спросите исполнителя, где, по его мнению, он окажется в конце первой недели в плане исполнения проекта, он ответит «на уровне выполнения 10 %»; о второй неделе скажет «на уровне выполнения 20 %» и т. д. В данном случае он занимается обратным отсчетом. Суть его логики такова: «Заканчивается первая неделя выполнения 10-недельного задания. Значит, процент завершенности у меня 10 %». Однако правда в том, что он сам точно не знает, в какой точке выполнения задания находится. Естественно, при таких условиях контроль очень приблизителен. И тем не менее во многих случаях степень продвижения проекта может быть определена только таким путем.

Резюме

• Контроль осуществляется путем анализа плана.

• Хорошо спланированные проекты могут контролироваться на предмет отклонений жестче, чем плохо проработанные.

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

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

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

Упражнение

В таблице 12.1 приведены показатели освоенных по проекту объемов. На основе анализа указанных данных ответьте на следующие вопросы. (Правильные ответы приведены в разделе «Ответы на вопросы».)

1. Выполнение задания обгоняет расписание или отстает от него?

2. Затраты по нему больше или меньше бюджета? Насколько?

3. Когда работа будет выполнена, общие затраты по ней окажутся выше или ниже бюджетных?

Таблица 12.1. Отчет об освоенных объемах

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

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

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

Инструменты и техника управления проектом – это необходимые, но отнюдь не достаточные условия для успеха предприятия. Как я уже отмечал, если вы не умеете работать с людьми, то будете испытывать большие трудности в управлении проектами, особенно когда персонал «не ваш».

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

Тимбилдинг, или построение команды

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

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

Далее в этой главе я сформулирую правила, позволяющие создать у членов команды чувство ответственности за общее дело. А пока обратимся к тому, как создать команду, чтобы она эффективно работала с самого старта. (Эта тема глубоко раскрыта в книге Джима Леви Team-Based Project Management, Beard Books, 2004.)

Создание атмосферы команды на стадии планирования

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

Любое планирование включает в себя оценочную работу: сколько потребуется времени для выполнения того или иного задания при наличии конкретного объема ресурсов и т. д. На своих семинарах я иногда спрашиваю: «Шеф часто полагает, что вы можете выполнять работу гораздо быстрее, чем делаете это на самом деле?» Слушатели смеются и соглашаются. А я говорю им, что склонность их шефов к оптимистической оценке сроков становится своеобразным психологическим законом.

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

Как организовать команду

Далее перечислены четыре главных шага в организации команды проекта.

1. Решите, что должно быть сделано, с помощью ИСР, формулирования проблем и других инструментов планирования.

2. Определите необходимые требования к персоналу.

3. Подберите членов команды проекта.

4. Подготовьте план проекта с участием членов команды.

Подбор персонала

Теперь перечислим критерии подбора команды проекта.

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

• Участие в проекте приносит пользу самому кандидату (см. Правило Д. Марча и Г. Саймона в разделе «Воспитание приверженности людей команде» далее в этой главе).

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

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

Уточнение миссии, целей и задач команды

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

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

Вопросы, над которыми должна работать команда

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

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

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

Задача руководителя проекта – создать атмосферу открытого общения с командой, когда ни один ее член не побоится прямо высказывать то, что думает. Лучший способ – откровенно сказать: «Я знаю, не все любят высказываться прямо, а тем более признавать, что чего-то не понимают. Но так работать мы не можем. Не бойтесь быть откровенными. Если чего-то не понимаете, признавайте это. Если с чем-то не согласны, не стесняйтесь высказывать свое несогласие. Это наш единственный путь к успеху. Всем нам будет хорошо, если какую-то работу мы сможем сделать за один раз. Будет гораздо хуже, если придется изыскивать время, чтобы переделывать ее из-за того, что кто-то не понял, что требовалось».

Выработка правил действий

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

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

Взаимоотношения в командах

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

Следует помнить: столкновения и конфликты возникают там, где отсутствуют хорошие навыки межличностного общения. Некоторых людей вообще не учили разрешать противоречия в спокойной атмосфере. Поэтому, когда неизбежные конфликты возникают, ситуация просто взрывается. Лучший способ минимизировать негативный эффект от таких проблем – организовать тренинг для всех членов команды (включая и руководителя проекта) по вопросам межличностных взаимоотношений. Эту возможность многие руководители нередко игнорируют. Им кажется, что решение психологических проблем во взаимоотношениях работников не дает немедленной финансовой или материальной отдачи. Действительно, очень трудно продемонстрировать руководству, что от вложения $1 в психологический тренинг компания получила $10 прибыли. Зато если проблемы касаются основных средств, на их решение затрачиваются любые ресурсы.

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

Этапы развития команды

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

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

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

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

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

Руководство командой на разных стадиях

Только что созданная команда должна быть структурирована, в противном случае она не сможет приступить к работе. В предыдущем разделе отмечено, что лидера, который не в состоянии создать работоспособную структуру на стадии 1, или стадии формирования, группа может отвергнуть и выбрать себе другого лидера. Поэтому на стадии формирования команды, как правило, применяется директивный стиль руководства.

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

«Стартовая» вечеринка или обед – отличный способ познакомиться друг с другом в неформальной обстановке, вне психологического давления, которое каждый человек, естественно, испытывает во время напряженной работы. Если такие мероприятия по какой-то причине нежелательны, следует изыскать другие возможности.

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

Многие руководители стремятся «перескочить» через этот этап, потому что испытывают дискомфорт в связи с возникающими в этот период конфликтами. Замести такие конфликты под ковер и притвориться, что их нет, – большая ошибка. Конфликтом нужно управлять так, чтобы он не приобрел деструктивного характера. Избегать конфликтов нельзя: группа все равно будет возвращаться на эту стадию в попытках разрешить внутренние противоречия. А это помешает продвижению проекта. Так что лучше заплатить положенную цену сразу и освободиться от конфликта.

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

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

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

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

Воспитание приверженности людей команде

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

В своей книге Organizations (Blackwell, 2-е изд., 1993) Д. Марч и Г. Саймон перечисляют пять правил для формирования у людей приверженности команде или организации.

1. Необходимо обеспечивать членам команды возможность как можно более часто взаимодействовать, чтобы у них сформировалось чувство команды.

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

3. Необходимо добиваться, чтобы каждый член команды понимал, почему проект важен. Люди не любят участвовать в обреченных на неудачу проектах.

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

5. Необходимо сводить конкуренцию в команде к минимуму. Конкуренция и сотрудничество – это антиподы. Соревноваться нужно с теми, кто находится вне команды, а не внутри нее.

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

Последняя рекомендация

Если вы хотите понаблюдать за моделями работы команд, присмотритесь, как работают со своими коллективами лучшие спортивные тренеры. Однако будьте при этом исключительно осторожны, чтобы не копировать брутальное поведение некоторых наставников. Оно хорошо действует в спортивных командах, в которые спортсмены хотят попасть. Но методы в стиле мачо вряд ли сработают в команде проекта, в которую сотрудники входят по обязанности. Посмотрите фильм «Выстоять и сделать»[10] и понаблюдайте, как главный герой Хайме Эскаланте работает со своими учениками. И в следующий раз, когда вам снова захочется пожаловаться на то, как много у вас обязанностей и как мало полномочий, спросите себя: как смог простой учитель (у которого полномочий еще меньше, чем у вас) заставить группу ребят работать с таким усердием? Как смог заставить их ходить в школу летом или заниматься математикой два урока в день? И тогда вы начнете понимать, что такое настоящее лидерство.

Резюме

• Команды не появляются случайно – их нужно строить!

• Тимбилдинг начинается с вовлечения всех членов команды в планирование проекта.

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

• Личные конфликты часто возникают из-за отсутствия у членов команды достаточных навыков межличностного общения. Чтобы команда работала успешно, все ее члены должны пройти соответствующий тренинг.

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

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

Руководитель проекта в своей работе должен проявлять одновременно и искусство, и дисциплинированность, используя процессы, действующие в проекте, таким образом, чтобы он стал успешным. Я слышу эту сентенцию постоянно, потому что она верна. Из собственного опыта я сделал непреложный вывод: человеческий фактор может быть (и нередко является) самой трудной переменной «уравнения» проекта. Для успеха проекта его руководителю нужно эффективно управлять спонсорами, членами команды, функциональными менеджерами, экспертами в предметных областях проекта и вообще практически всеми заинтересованными сторонами. В главе 1 и главе 2 речь шла об общих принципах лидерства, а в главе 13 мы подробнее остановились на разных стилях руководства, применяемых лидером на разных этапах становления команды проекта. Сейчас сосредоточимся на том, что означает быть лидером проекта, понимать все его сильные и слабые стороны, создавать свои группы поддержки и осознавать важность мотивации в действиях людей. Я расскажу также о проблеме разрешения конфликтов, сплавления энергии всех членов команды в одно целое и практических аспектах лидерства в совещаниях и собраниях команды (а не в управлении ими).

Закладывая основу

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

Понимание характеристики лидерских качеств

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

Понимание стилей руководства

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

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

Рис. 14.1. Взаимосвязь между стилями руководства, сценариями развития проекта и поведением заинтересованных сторон

Создание групп приверженцев проекта

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

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

Создание групп поддержки в рабочей среде

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

Поощрение людей к риску и устранение страха перед возможной неудачей

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

Формирование позитивной культуры несогласия

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

Мотивация

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

Некоторые руководители проектов используют методику самооценки работников, чтобы выявить их возможные мотивационные стимулы. Эти методики доказали свою эффективность, однако я предпочитаю традиционный подход: личное общение с членами команды и другими основными заинтересованными сторонами с целью выяснить мотивы их действий. Потратьте время на то, чтобы выслушать членов своей команды за утренним кофе во вторник (избегайте в этом плане понедельников, чтобы дать людям отойти от выходных) либо признайте их достижения за бокалом пива в «счастливые часы» или за обедом – и вы сильно укрепите отношения с ними и сможете взглянуть на них с другой стороны. Чем лучше вы знаете своих сотрудников, тем лучше подготовитесь к ситуациям, когда их придется мотивировать на какую-то работу. В 1970-х годах основатели корпорации Hewlett-Packard Билл Хьюлетт и Дэйв Паккард заложили революционные принципы современного менеджмента, один из которых получил название «управляй похаживая» (management by walking around, MBWA). Эта методика до сих пор широко применяется руководителями проектов, СЕО и менеджерами самых разных уровней. Особенно она актуальна в обычной проектной среде, где лидер часто управляет без достаточных формальных полномочий. Если у вас не хватает власти, чтобы приказывать сотрудникам, нужно научиться мотивировать их.

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

Лидеры проектов и командная среда

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

Определение и формирование ролей членов команды

Хотя обычно руководитель проекта воспринимается людьми в качестве «клея», который объединяет команду, его можно представить и как своеобразного «шеф-повара», который правильно смешивает ингредиенты – роли членов команды, их навыки и личные качества – чтобы «на выходе» получить максимальную эффективность работы. Разумеется, это метафоры, но они отражают важную идею. Если проект развивается правильно, то члены команды принимают на себя свои роли естественно и вписываются в среду команды без трений или с минимальными шероховатостями. А если «химия» команды составлена неправильно, дело заканчивается ежедневными конфликтами и негативным несогласием. Сегодня в сфере управления проектами руководители должны быстро определять сильные и слабые стороны членов команды, их личные качества и манеру поведения, чтобы обеспечить продолжительное единство команды. Каждый член команды входит в нее ради какой-то цели, нередко функциональной, или в качестве специалиста в какой-то предметной области.

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

Выработка оптимальных подходов к разрешению конфликтов

На каком-то этапе своего существования все команды проектов сталкиваются с внутренними конфликтами. В большинстве своем это явление здоровое и позитивное. Руководителю следует предпринимать решительные действия только тогда, когда конфликты становятся деструктивными для самого проекта или для внутренних отношений в команде. Основные причины возникновения конфликтов – личные противоречия, столкновение приоритетов, несогласованность между заинтересованными сторонами, жесткие графики работ и завершения проекта, а также технические проблемы. От умения разрешать эти конфликты зависит ваша эффективность в качестве руководителя проекта. Большинство людей вырабатывают собственные методы противодействия конфликтам. Но помните, что это может загнать вас в комфортную зону и помешать реализации ваших способностей по решению проблем. Сьюзан Джунда выделяет пять подходов к разрешению конфликтов в среде проекта (Project Team Leadership: Building Commitment Through Superior Communication, American Management Association, 2004).

1. Избегание. Часто называемое синдромом бегства, избегание конфликтов имеет место тогда, когда человек откладывает проблему, уклоняется от ситуации или вообще избегает конфликта.

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

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

4. Сотрудничество. В данной ситуации обе стороны стремятся прийти к взаимовыгодному решению. Это типичный сценарий удовлетворяющей обе стороны ничьей.

5. Наступление/состязание. При таком подходе одна из сторон соблюдает только свои интересы и проталкивает только свои подходы или решения.

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

Руководство совещаниями по анализу продвижения проекта

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

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

• Готовьте совещания заранее, не тратьте ценное время на выполнение задач, которые можно решить до совещания.

• Установите основные нормы таких совещаний:

– минимальное количество участников для кворума;

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

– все должности остаются за дверью (это следует подчеркнуть еще раз);

– конфиденциальность (все сказанное на совещании остается в пределах совещательной комнаты);

– говорит всегда только один выступающий, никто никого не перебивает;

– совещание начинается и заканчивается в строго определенное время.

• Назначьте ответственного за регламент, это поможет соблюдать продолжительность выступлений.

• Назначьте ведущего протокол и распространите затем запись среди заинтересованных лиц.

• Не допускайте на совещании отвлеченных дискуссий.

• Обеспечьте, чтобы все электронные устройства были выключены или поставлены на режим беззвучного приема.

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

Работа с виртуальными командами

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

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

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

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

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

Резюме

• Чем более умело вы руководите другими людьми, тем больше шансов на успех вашего проекта.

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

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

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

Упражнения

Проанализируйте среду проекта в своей организации.

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

• Из этого списка выберите три наиболее важных качества.

• Сравните этот список с собственными способностями.

Какое ваше качество самое сильное?

В каких аспектах вам следовало бы совершенствоваться?

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

Глава 15. Закрытие проекта

Большинство руководителей проектов не умеют правильно их закрывать. И здесь, как и в других процессах (хотя они не так уж сложны для понимания и исполнения), подлинной цели бывает нелегко достичь. Вспомните, что происходит, когда спортсмены приближаются к финишной ленточке. Многие расслабляются и замедляют бег на финишной прямой. А что происходит, к примеру, когда вы завершаете ремонт дома? В моем домашнем кабинете на потолке одно маленькое незакрашенное пятнышко, которому уже три или четыре года. А в остальном кабинет выглядит потрясающе!

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

Два вида закрытия проектов

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

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

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

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

2. Создание документальных материалов о работе команды на проекте. Одни члены команды проекта добьются отличных результатов, другие «проедутся» на коллегах с небольшой отдачей для общего дела. Обязательно отметьте лучших. Это может быть бонус, или подарочный сертификат, или особое благодарственное письмо за работу человека, отправленное руководству. Руководителю проекта в таких случаях следует поработать с HR-отделом организации, чтобы найти подходящую форму оценки вклада конкретного человека. Это может оказаться инвестицией в будущее: не исключено, что вам еще когда-нибудь придется работать с членами своей команды. И нужно позаботиться об их мотивации на этот случай.

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

• план проекта;

• переписка по нему;

• журнал контроля изменений;

• журнал рисков;

• журналы возникавших проблем и действий по ним;

• документация по качеству;

• план коммуникаций;

• отчет о закупках по проекту.

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

5. Суммирование данных по отклонениям, возникшим в проекте, включает в себя:

• содержание;

• расписание;

• бюджет.

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

6. Закрытие всех отчетов, включая финансовые. Вы не должны оставлять никаких «хвостов». Однажды мне поступил телефонный звонок от сотрудника Northrop Grumman через год после того, как я ушел из корпорации. Это был весьма деликатный вопрос, но тогда я смог «перебросить» его на своего преемника в компании. Вам может повезти меньше.

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

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

9. Идентификация извлеченных из проекта уроков и их систематизация. Обязательно проанализируйте, что прошло в завершенном проекте удачно, что могло быть сделано лучше.

Создание в организации централизованного архива проектной документации и информации

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

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

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

Анализ вынесенных из проекта уроков

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

Таблица 15.1. Анализ вынесенных из проекта уроков

Таблица вынесенных из проекта уроков проста, но ее не всегда легко правильно составить. Хотя мысли о том, что в проекте удалось, доставляют удовольствие, вспоминать о своих ошибках не всегда приятно. Для того чтобы хорошо сформулировать вынесенные уроки, и руководителю, и команде придется честно заглянуть в себя. Это как раз пример деятельности руководителя проекта в качестве лидера: он должен мотивировать команду на вдумчивый анализ, подчеркивая важность постоянного совершенствования и персонального роста каждого члена коллектива. Вы и ваша команда должны после каждого проекта анализировать вынесенные уроки и использовать их для постоянного самосовершенствования.

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

Что касается моей команды, я поощряю ее на создание и реализацию списка пунктов «улучшить/ввести в практику» даже по текущим проектам по мере их продвижения по жизненному циклу. Это позволяет сразу же включиться в составление таблицы на специальном совещании по обсуждению полученных уроков. Не ждите последнего совещания. Оставьте последнее совещание для празднования! Даже если проект и не был безумно успешным (или даже в чем-то был хуже ожидаемого), отмечайте ту напряженную работу, которую завершила ваша команда.

Вот несколько последних рекомендаций.

1. Возможно, вы захотите в предложенном образце таблицы (табл. 15.1) выделить отдельные колонки для пунктов «Улучшить / Ввести в практику». Это ваше право. Здесь все зависит от ваших вкусов.

2. Выделяйте пункты «Улучшить» красным, а пункты «Ввести в практику» – зеленым. Это не только поможет быстрее пользоваться таблицей, но и коррелирует с цветами светофора (красный/желтый/зеленый), что упрощает процесс отслеживания различных моментов, связанных с проектом. В последнее время такая цветовая гамма часто применяется в проектной среде.

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

Проверка списка мероприятий по закрытию проекта

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

Много лет назад я разработал свою методику закрытия проектов.

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

Таблица 15.2. Список мероприятий по закрытию проекта

Х = завершено.

? = нет данных.

По мере продвижения проекта по его жизненному циклу добавляйте в этот список и другие мероприятия. Например:

• Завершение фазы 1. Добавьте два мероприятия, которые должны быть выполнены и подтверждены при закрытии проекта.

• Завершение фазы 2. Добавьте одно мероприятие.

• Завершение фазы 3. Добавьте три мероприятия.

К закрытию проекта у вас сформируется обобщенный список всех действий. Затем вы с командой проанализируете свою работу в ходе проекта и подтвердите выполнение всех мероприятий. Тем самым и руководитель проекта, и его команда вырастут профессионально, ответив на вопрос «Как мы все сделали?». По моему опыту, почти наверняка одно-два мероприятия останутся под вопросом. Анализируя их, команда поймет, что данный пункт списка не выполнен. Может быть, он остался без ответственного или, наоборот, ответственными за него оказались сразу два члена команды, понадеявшихся друг на друга. Как бы то ни было, ревизия списка мероприятий по закрытию проекта – мощное резервное средство контроля, благодаря которому коллектив убедится, что все необходимые действия по завершению работы осуществлены.

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

Преждевременное закрытие проектов

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

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

• Кончились отведенные на проект деньги, «колодец иссяк».

• Ситуация на рынке сделала продукт или результат проекта устаревшим.

• Изменилась стратегия организации.

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

• Ваш шеф или спонсор проекта передумали.

• Ваш проект «сглазили». (Эта причина скорее виртуальная, однако мысль об этом время от времени всем нам приходит в голову.)

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

Рис. 15.1. Преждевременное прекращение/отмена проекта

Резюме

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

• Выполняйте все необходимые действия по контрактному и административному закрытию проектов.

• Участвуйте в создании централизованных документальных и информационных архивов по проектам.

• Анализируйте вынесенные из проектов уроки. Старайтесь создавать базу для своих дальнейших успехов и избегать повторения ошибок.

• Составляйте список мероприятий, связанных с закрытием проекта, и анализируйте их выполнение.

• Помните: проект не закрыт до тех пор, пока заказчик не примет его продукт.

• Празднуйте!

Глава 16. Как заставить проектный менеджмент работать в вашей компании

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

Я два десятка лет боролся с этой проблемой и вот, наконец, добился некоторых ответов.

Д-р У. Эдвардс Деминг еще пятьдесят лет тому назад понял, что программы, в которые не вовлечено высшее руководство организации, обречены на короткую жизнь. Но это не означает, что достаточно льстить и подыгрывать руководству. Как писал Том Питерс в своей книге «Процветание на хаосе» (Thriving on Chaos. Harper Perennial, 1988), если руководитель хочет, чтобы в его компании что-то сдвинулось, он должен поменять свой рабочий календарь: тратить время на разговоры о проектном менеджменте, присутствовать на совещаниях по планированию и анализу проектов, интересоваться заметками своих сотрудников относительно управления проектами и задавать вопросы о том, как развиваются проекты в компании. Другими словами, следует проявлять интерес к проектному менеджменту.

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

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

• Я обнаружил, что высшее руководство компаний тоже нуждается хотя бы в кратком знакомстве с принципами проектного менеджмента, чтобы понимать, чего ожидать от своих сотрудников. Одна из распространенных причин неудач проектов как раз и состоит в том, что руководство организаций возлагает на них слишком большие надежды. Однако, как правило, оно настолько занято, что может посвятить брифингу максимум три часа. Мы в Ассоциации менеджмента сократили это время до 1 часа 15 минут и сделали видеоверсию, чтобы загруженные капитаны бизнеса сами выбирали то, что им необходимо для оценки и поддержки соответствующих инициатив и усилий работников. Нынешние бизнес-лидеры обязательно должны пользоваться онлайн-возможностями, которые имеются в сфере тренинга по управлению проектами.

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

• Планируйте маленькие победы. Забудьте принцип Парето[11]. В данном случае он неправилен даже с экономической точки зрения. По мысли Парето, надо начинать с самых трудных задач и постепенно переходить к более простым. В экономическом смысле звучит вроде бы здраво, но в действительности с трудными задачами люди чаще терпят неудачи, расстраиваются и в конце концов сдаются. Ни одна спортивная команда, занимающая в рейтинге десятое место, не захочет играть свой первый матч с командой номер один. Скорее предпочтет провести матч с девятой или даже одиннадцатой командой. Не подставляйте свою команду под разгром!

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

• Чаще практикуйте анализ работы для вынесения из нее уроков и совершенствования деятельности.

• Если вы замечаете, что в команде есть «проблемный ребенок», начинайте с ним работу как можно быстрее. Если вы не знаете, что с таким человеком делать, посоветуйтесь с тем, у кого есть соответствующий опыт. Не отмахивайтесь от проблемы, потому что она может погубить всю команду.

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

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

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

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

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

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

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

• Побуждайте членов своей команды становиться пропагандистами разных частей процесса управления проектом. Возможно, вы даже сделаете кого-то «особо ценным работником» и поручите ему распространить опыт вашей команды по всей организации. Другой член команды может лучше других пропагандировать ваши методы создания ИСР.

• Вступите в члены Института по управлению проектами (Project Management Institute, PMI), посещайте его тематические конференции и узнавайте больше об управлении проектами от профессионалов.

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

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

• Превратите проектный менеджмент в предметную область и соберите в ней приверженцев проектного управления. Ведь не все в вашей организации занимаются бухгалтерским учетом. И далеко не все способны хорошо делать эту работу. То же самое и с управлением проектами. Превращая ее в предметную область, вы даете заинтересованным людям возможность оттачивать свои навыки и умения, чтобы достигать в своей работе подлинных высот. Советую пособие Роберта Грэма и Рандалла Энглунда «Создание среды успешных проектов» (Creating an Environment for Successful Projects, Jossey-Bass, 1997).

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

И, наконец, удачи вам!

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

Глава 1

1. в

2. г

3. а

4. б

Назад к тексту

Глава 3

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

Назад к тексту

Глава 5

Проверьте свою работу на предмет:

Факторов приоритетности: вероятности и возможное воздействие на проект.

Помните:

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

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

«Точки пуска» чрезвычайных планов должны прямо сопрягаться с ними.

Назад к тексту

Глава 7

ИСР поездки в кемпинг:

Рис. А1. Схема ИСР по организации поездки в кемпинг

Назад к тексту

Глава 8

Ответ на задание по составлению ИСР:

Рис. А2. Стрелочная диаграмма уборки дома

Назад к тексту

Глава 9

Решение упражнения на составление расписания.

Рис. А3. Решение упражнения на составление расписания

Назад к тексту

Глава 11

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

Назад к тексту

Глава 12

1. Проект отстает от расписания на $160 по выполненной работе.

2. Перерасход средств по проекту сейчас составляет $240.

3. Общий перерасход бюджета по проекту составит $416.

Назад к тексту

Глава 14

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

Назад к тексту

Указатель рисунков

1.1. Зависимость между результатом, сроками, стоимостью и содержанием проекта

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

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

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

3.1. «Кривые болезненности» применительно ко времени

3.2. Планирование – это ответы на вопросы

4.1. Матрица заинтересованных сторон

5.1. Шеврон, показывающий миссию, видение и проблему

6.1. Матрица рисков

7.1. Схема ИСР по уборке комнаты

7.2. Уровни иерархической структуры проекта

7.3. Компоненты ИСР

7.4. Взаимозависимость между сроками, стоимостью и ресурсами проекта

8.1. Линейчатая диаграмма (диаграмма Гантта)

8.2. Стрелочные диаграммы

8.3. ИСР по проекту уборки участка

8.4. Диаграмма уборки участка (метод «критического пути»)

8.5. ИСР по уборке комнаты

9.1. Сеть расписания, которая иллюстрирует принципы его расчета

9.2. Сетевая диаграмма расписания с указанием ранних финишей

9.3. Сетевая диаграмма, показывающая «критический путь»

9.4. Линейчатая диаграмма расписания проекта по уборке участка

9.5. Расписание с перегруженными ресурсами

9.6. Расписание, в котором резервы времени используются для выравнивания ресурсов

9.7. Расписание с недостаточным временным резервом по операции В для выравнивания ресурсов

9.8. Расписание проекта с критическим выравниванием ресурсов

9.9. Диаграмма сети расписания в качестве упражнения

11.1. Треугольник тройственных ограничений

11.2. Форма для контроля изменений проекта

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

12.2. Линейчатая диаграмма, иллюстрирующая совокупные затраты

12.3. Совокупные расходы в контрольном графике

12.4. Ситуация, когда проект отстает от расписания, а расходы по нему превышают запланированные

12.5. Ситуация, когда проект обгоняет расписание, а расходы по нему не превышают запланированные

12.6. Ситуация, когда проект отстает по срокам, но затраты по нему соответствуют бюджету

12.7. Ситуация, когда проект обгоняет сроки и затраты по нему ниже бюджетных

12.8. Кривая процентной оценки завершенности

14.1. Взаимосвязь между стилями руководства, сценариями развития проекта и поведением заинтересованных сторон

15.1. Преждевременное прекращение/отмена проекта

А1. Схема ИСР по организации поездки в кемпинг

А2. Стрелочная диаграмма уборки дома

А3. Решение упражнения на составление расписания

Благодарности

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

Спасибо Кайлу Хигни за то, что он окончил колледж вовремя и в пределах бюджета.

Об авторах

С 2001 года Джозеф Хигни является президентом консалтинговой компании QMA International. Компания специализируется на распространении по всему миру обучающих программ по вопросам менеджмента. Хигни часто выступает на семинарах, организуемых для крупнейших корпораций, которые входят в список Fortune 500, а также на конференциях и симпозиумах. Среди его клиентов – компании PepsiCo, Federal Express, Verizon, Merck, Высшая школа экономики Harvard Business School, армия США и известная корпорация, работающая в области высоких технологий SAP America.

В 1996 году Дж. Хигни пришел в Американскую ассоциацию менеджмента (American Management Association International, AMA), где в качестве менеджера программы занялся разработкой, контролем качества и распространением продуктов АМА в виде семинаров. Вскоре он был назначен менеджером группы Центра изучения и развития менеджмента в Нью-Йорке и руководил менеджерами программ в области управления проектами и профессиональной подготовки кадров, коммуникаций, закупок и общего менеджмента. Через некоторое время Дж. Хигни был назначен руководителем глобальных программ по распространению самых эффективных методик в области проектного менеджмента. В этом качестве он возглавлял международную команду, которая изучала лучшие примеры управления проектами и включала их в свои образовательные программы для распространения по всему миру.

Дж. Хигни является также внештатным преподавателем в Городском университете Нью-Йорка, а также в институте и колледже Dowling в Нью-Йорке, где преподает и студентам, и докторантам. В настоящее время он ведет многочисленные курсы в программе Dowling Executive MBA Program. Среди них: управление проектами, управление производством и операциями, вопросы НИОКР в текущей операционной деятельности, лидерство, общий менеджмент, системы управления персоналом, управление качеством, контроль качества статистической работы и подготовка руководящих кадров.

Дж. Хигни начал свою карьеру в авиастроительной корпорации Grumman Aerospace (Northrop Grumman), где продвигался по служебной лестнице в департаменте материального обеспечения и корпоративных закупок. Свою работу в корпорации он закончил в должности руководителя проекта по созданию корпоративной системы оценки эффективности работы поставщиков компании.

Дж. Хигни имеет степень бакалавра в педагогике, полученную в колледже C.W. Post College, и магистра промышленного менеджмента, полученную в университете штата Нью-Йорк в Стоуни-Брук. По своей профессиональной деятельности Дж. Хигни тесно связан с Институтом по управлению проектами (PMI), Международной ассоциацией проектного менеджмента, а также с Американским обществом качества.

Книга «Основы проектного менеджмента» не стала бы бестселлером без участия Джеймса Льюиса, доктора наук (PhD) и автора первых трех изданий. Д-р Льюис – президент компании Lewis Institute, с 1981 года занимающейся консалтингом и тренингом для компаний, специализирующихся на управлении проектами. Опытный менеджер проектов, д-р Льюис провел множество семинаров по всему миру и участвовал в образовательных программах для более чем 40 000 специалистов.

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

Сноски

1

Больше информации об этой организации вы можете получить на веб-сайте .

(обратно)

2

Standish Group International – независимая транснациональная консалтинговая компания, основанная в 1985 году и занимающаяся изучением состояния высокотехнологичных отраслей и подготовкой аналитических обзоров по международному рынку IT как в частной, так и в публичной сфере. Доклады компании под названием Chaos Reports особое внимание обращают на неудачные проекты и пути возможного решения их проблем. Прим. перев.

(обратно)

3

Вэнс Паккард (1914–1996) – известный американский журналист и психолог, автор ряда нашумевших книг по психологии бизнеса, вышедших в 1960–1970-х годах. На русский язык переведена книга «Тайные манипуляторы». М.: Смысл, 2004. Прим. перев.

(обратно)

4

Арджирис К. Организационное научение. М.: ИНФРА-М, 2004. Прим. перев.

(обратно)

5

Готовится к выпуску издательством МИФ.

(обратно)

6

В оригинале PFD – Personal, Fatigue, Delays. Прим. ред.

(обратно)

7

«Мелочь пузатая» – ежедневный американский комикс, созданный Чарльзом Шульцем и выходивший со 2 октября 1950 года по 13 февраля 2000 года. По комиксу был сделан одноименный мультсериал, который начал выходить в 1965 году. Произведение насчитывает 17 897 выпусков, считается одним из самых популярных комиксов, оказавших большое влияние на всю индустрию. Чарли Браун – один из главных персонажей комикса. Прим. перев.

(обратно)

8

Питерс Т., Уотермен Р. В поисках эффективного управления. М.: Прогресс, 1986.

(обратно)

9

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

(обратно)

10

«Выстоять и сделать» – драма режиссера Рамона Менендеса, выпущенная в 1988 году. В основу фильма легла реальная история учителя математики Хайме Эскаланте. Прим. перев.

(обратно)

11

Закон Парето, или принцип Парето, или принцип 20/80 – эмпирическое правило, названное в честь экономиста и социолога Вильфредо Парето, в наиболее общем виде формулируется как «20 % усилий дают 80 % результата, а остальные 80 % усилий – лишь 20 % результата». Прим. перев.

(обратно)

Оглавление

От научного редактора российского издания

От автора Глава 1. Общий взгляд на управление проектами

  Неудачи проектов

  Что такое управление проектами?

  Нельзя получить все и сразу!

  Фазы проекта

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

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

  Области знаний Глава 2. Роль руководителя проекта

  Что такое управление?

  Определения управления

  Работающий руководитель проекта

  Так хотите ли вы быть руководителем проекта? Глава 3. Планирование проекта

  Планирование – абсолютный императив

  Определение планирования

  Стратегия, тактика и логистика

  Согласование плана

  Изменение плана

  Рекомендации к эффективному планированию Глава 4. Управление заинтересованными сторонами в планировании проекта

  Определение приоритета заинтересованных сторон по их отношению к проекту

  Вовлечение ключевых заинтересованных сторон в проект

  Выработка единого языка общения с заинтересованными сторонами и коммуникации с ними

  Управление заинтересованными сторонами, представляющими различные корпоративные культуры

  Управление изменениями, основанными на различиях в корпоративных культурах разных заинтересованных сторон

  Работа с внешними и удаленными заинтересованными сторонами

  Объединение заинтересованных сторон Глава 5. Выработка миссии, видения, целей и задач проекта

  Формулирование проблемы Реальная миссия для любого проекта Определение целей проекта Глава 6. Планирование управления рисками и коммуникациями проекта

  Определение управления рисками проекта

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

  Создание резервов

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

  План управления коммуникациями проекта Глава 7. Использование иерархической структуры работ в планировании проекта

  Простой пример

  Рекомендации по разработке ИСР

  Оценка сроков, стоимости и ресурсов проекта

  Управление закупками проекта Глава 8. Разработка расписания проекта

  Краткая история эволюции разработки расписания проектов

  Сетевые диаграммы

  Причины необходимости расписаний проектов

  Создание стрелочной диаграммы Глава 9. Создание рабочего расписания проекта

  Расчет расписания проекта

  Перевод стрелочных диаграмм в линейчатые

  Обеспечение проекта ресурсами Глава 10. Контроль и анализ проекта

  Обеспечение самоконтроля со стороны членов команды проекта

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

  Оценка проекта Глава 11. Процесс контроля изменений проекта

  Источники изменений

  Шесть шагов в процессе контроля изменений

  Форма для контроля проекта

  Пороги изменений

  Журнал контроля изменений

  Побочные результаты изменений проектов

  Принятие изменений Глава 12. Контроль проектов методом определения освоенного объема

  Измерение прогресса

  Измерение результатов/качества исполнения проекта

  Контроль методом определения освоенного объема

  Реагирование на отклонения

  Приемлемые отклонения

  Использование метода процентной оценки завершенности работ по проекту Глава 13. Управление персоналом проекта

  Тимбилдинг, или построение команды

  Создание атмосферы команды на стадии планирования

  Вопросы, над которыми должна работать команда

  Этапы развития команды

  Последняя рекомендация Глава 14. Руководитель проекта в роли лидера

  Закладывая основу

  Создание групп приверженцев проекта

  Мотивация

  Лидеры проектов и командная среда Глава 15. Закрытие проекта

  Два вида закрытия проектов

  Создание в организации централизованного архива проектной документации и информации

  Анализ вынесенных из проекта уроков

  Проверка списка мероприятий по закрытию проекта

  Преждевременное закрытие проектов

Глава 16. Как заставить проектный менеджмент работать в вашей компании

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

Указатель рисунков

Благодарности

Об авторах Fueled by Johannes Gensfleisch zur Laden zum Gutenberg