Paula Martin, Karen Tate
GETTING STARTED
IN PROJECT
MANAGEMENT
WILEY
John Wiley &C Sons, Inc.

П. Мартин, К. Тейт
УПРАВЛЕНИЕ
ПРОЕКТАМИ
Москва Санкт Петербург Нижний Новгород Воронеж
Ростов на Дону Екатеринбург Самара Новосибирск
Киев Харьков Минск
2006

ББК 65.290 21
УДК 658.1
М29
Научные редакторы: Д. э. н., проф. В. П. Галенко, д. э. н., проф. О. А. Страхова
Мартин П., Тейт К.
М29 Управление проектами / Пер. с англ.
--- СПб.: Питер, 2006.
--- 224 е.: ил.
---
(Серия «Практика менеджмента»).
ISBN 5 94723 249 9
Эта книга станет вашим гидом в сложном мире такой важной отрасли деятельности
в бизнесе, как управление проектами. В ней очень доступно и понятно описываются все
основные этапы подготовки и реализации проектов на разных уровнях управления. Боль-
шое внимание уделяется правилам распределения полномочий в команде и умению рабо-
тать в коллективе.
Книга безусловно будет интересна студентам, изучающим экономику и управле-
ние, а также самому широкому кругу читателей.
ББК 65.290 21
УДК 658.1
Права на издание получены по соглашению с Wiley
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы
то ни было форме без письменного разрешения владельцев авторских прав.
© 2001 by Martin Tate, LLC.
ISBN 0 471 13503 8 (англ.) © Перевод на русский язык ЗАО Издательский дом «Питер», 2006
ISBN 5 94723 249 9
© Издание на русском языке, оформление
ЗАО Издательский дом «Питер», 2006

Содержание
Предисловие научного редактора
11
Введение
13
Глава 1. Основы управления проектом
17
Что такое проект?
17
Что такое управление проектом?
19
Особенности метода управления проектом
20
Директивное управление проектами
21
Совместное управление проектами
22
Роли при управлении проектом
24
Лидер проекта
24
Член команды проекта
,
25
Спонсор
26
Заказчик проекта
27
Менеджер по ресурсам (функциональный менеджер)
28
Четыре этапа проекта
29
Подготовка проекта
29
Планирование
30
Воплощение проекта
30
Завершение проекта
30
Последовательность этапов
31
Утверждение в процессе управления проектом
34
Успех проекта
34
Глава 2. Начало проекта
36
Заполнение раздела о масштабе проекта
37
Раздел описания масштаба для нашего проекта «выполнения заказов» 41
Заполнение раздела о ресурсах
41
Раздел «Ресурсы» для нашего примера
46
Утверждение чартера
46
Список проблем
47
Как правильно работать со списком проблем
48
Контролирование списка проблем
49

6
Содержание
Список усвоенных «уроков»
49
Формирование проектной команды
50
Мелкие проекты
50
Крупные проекты
51
Проверка содержания и процесса
53
Глава 3. Лидерство в команде, работающей над проектом
54
Принцип 1
54
Принцип 2
55
Принцип 3
57
Принцип 4
58
Принцип 5
60
Принцип 6
60
Принцип 7
61
Стадия формирования
63
Стадия возмущения
64
Стадия стабилизации
65
Стадия выполнения
66
Стадия расставания
66
Стадии развития и совместная работа
67
Высокоэффективные команды
67
Навыки руководителя проекта
69
Глава 4. Запуск проекта
70
Запуск проекта и работа команды
70
Подготовка к «пусковому» собранию
70
Помещение
70
Места для сидения
71
Необходимые материалы
71
Доска объявлений
72
Кого следует пригласить на собрание?
73
Повестка собрания
73
Знакомство
74
Раскрепощающая игра
75
Обзор чартера
,
76
Командный договор
77
Метод А
78
Метод Б
78
График собраний по планированию проекта
79
Пример собрания, посвященного запуску проекта
80

Содержание
7
Процесс планирования
82
Запуск проекта: проверьте себя
82
Переход к основным этапам работы
84
Глава 5. Определение масштаба проекта
85
Определение потребителя
86
Потребности заказчика
87
Конечный продукт
89
Критерии заказчика по приему продукта
90
Требования заказчика
91
Масштаб проекта
92
Границы проекта
93
Заинтересованные стороны (дольщики)
95
Определение масштаба проекта: проверьте себя
96
Документ, отражающий план проекта
97
Глава 6. Организация проекта
,
98
Как разделить конечный продукт на отдельные составляющие
98
Определение промежуточных продуктов проекта
99
Создание подпроектов
100
Определение подпроекта
102
Оценка навыков
103
Оценка уровня представительства интересов дольщиков в проекте
104
Связи с членами команды
106
Внесение изменений в состав команды
107
«Дерево» подпроектов
107
Передача полномочий команде
110
Организация проекта: проверьте себя
111
Документальная форма проектного плана
112
Глава
7.
Оценка
рисков
113
Классификация рисков
114
Собрание, посвященное оценке рисков
115
Первый этап --- выявление рисков
117
Второй этап --- анализ рисков
118
Вероятность риска
118
Влияние риска
119
Матрица вероятности рисков/потерь
120
Оценка суммарного риска
121
Третий этап --- разработка и анализ контрмер
121

8
Содержание
Повторная оценка общего риска
123
Оценка рисков: проверьте себя
124
Документальная форма проектного плана
124
Глава 8. Составление графика работ
126
Выделение вех в проекте
127
Оценка занятости персонала при получении продукта
129
Создание сетки графика
131
Определение взаимозависимостей
132
Перенос данных о взаимозависимостях на график
133
Преимущества метода разработки графика работ вручную
135
Резервное время
137
Определение критического пути
138
Включение в график дополнительного «страхового» времени
138
Сокращение графика работ
140
Возможности выбора при составлении графика работ
141
Составление графика работ: проверьте себя
,
142
Документальная форма проектного плана
142
Глава 9. Разработка бюджета
143
Затраты на работу персонала
143
Трудовые затраты
144
Трудовые затраты на управление проектом
144
Завершение оценки затрат
145
Точность оценки
146
Разработка бюджета: проверьте себя
148
Форма проектного плана
148
Глава 10. Составление окончательного проектного плана
150
Описание масштаба проекта
150
Организация проекта
151
Риск
151
Планирование ресурсов
152
Планирование процесса управления изменениями
154
Процесс управления изменениями
155
Шаг первый --- запрос на внесение изменения
158
Шаг второй --- анализ воздействия
158
Шаг третий --- одобрение
158
Журнал изменений
159
Составление проектного плана
160

Содержание
9
Руководящее резюме
161
Утверждение проектного плана
161
Составление проектного плана: проверьте себя
161
Глава 11. Приемы работы с командой
163
Построение диаграммы по сходству параметров (О, С)
165
Диграф взаимосвязей (А, В)
168
Матрица принятия решения МТ(А, В)
172
Многозначное голосование (А, В)
178
Инструменты для процесса ОСАВ
179
Примечание
179
Глава 12. Претворение плана в жизнь
180
Кто должен присутствовать на собраниях?
181
Повестка дня для собрания команды
181
Мониторинг потенциальных проблем
182
Обзор отчета о состоянии работы
183
Риск
184
График работ
184
Соответствие масштаб)'
186
Трудовые затраты и финансовые расходы
187
Обзор запросов на внесение изменений
188
Обзор и обновление списка рассматриваемых проблем
190
Завершение отчета о состоянии работ
191
Просмотр всех листочков на доске объявлений
192
Признание достижений
192
Оценка результатов собрания
192
Обзорные собрания с заказчиком и спонсором проекта
193
Передача конечного продукта заказчику
194
Претворение плана в жизнь: проверьте себя
194
Глава 13. Завершение проекта
196
Оценка проекта заказчиком
197
Беседа с заказчиком
197
Итоговый отчет о результатах работы
200
Оценка проекта спонсором
200
Оценка проекта другими заинтересованными сторонами
201
Оценка проекта членами команды
203
Усвоенные уроки
203
Рекомендации по усовершенствованию
204
Отчет о завершении проекта
204

10
Содержание
Праздник
204
Завершение проекта: проверьте себя
205
Глава 14. Подведение итогов
206
Семь ключей к успеху
206
Секрет 1 --- использовать эффективные методы работы
206
Секрет 2 --- не жалеть времени на планирование проекта
207
Секрет 3 --- привлечь к работе заказчика
208
Секрет 4 --- сделать проект управляемым
209
Секрет 5 --- сформировать единую команду
210
Привлекайте команду к планированию проекта
210
Пользуйтесь визуальными методами и приемами работы в команде
210
Будьте помощником, а не начальником
211
Управляйте процессами внутри команды
211
Секрет 6 --- организовать эффективный обмен информацией
212
Секрет 7 --- учиться на своих ошибках
213
Заключение
213
Приложение А. Тест для самооценки способностей
руководителя проекта
214
Приложение В. Стили мышления
216
Аналитическое мышление
216
Последовательное мышление
216
Целостное мышление
216
Межличностное мышление
216
Приложение С. Пример командного договора
218
A. Обязательства
218
B. Собрания команды. Основные правила: участие в работе
218
C. Собрание команды. Основные правила: обмен информацией
219
D. Собрание команды. Основные правила: решение проблем
219
E. Собрание команды. Основные правила: принятие решений
219
F. Собрание команды. Основные правила: разрешение конфликтов
220
G. Нормативы для собраний
220
Н. Процедуры, связанные с собранием
220
Приложение D. Методология решения проблем
MartinTate (MT)
222

Предисловие научного редактора
Анализируя тенденции бизнеса на рубеже веков, аналитики разных
стран отмечают несомненное усиление движения к переходу от тради-
ционной культуры бизнеса, основанной на долгосрочном планирова-
нии, к Миру проектов (Project World) --- работе по проектному прин-
ципу. Это мир, где бизнес дробит свою деятельность на отдельные
проекты, позволяющие более быстро и гибко удовлетворять требова-
ния рынка и выживать в новых условиях. Последние исследования
показывают, что преуспевающие компании все больше начинают мыс-
лить категориями этой новой реальности, двигаясь к более экономич-
ным, эффективным, гибким и чувствительным организациям, способ-
ным к самоорганизации и самообучению.
Такая смена подхода к организации деятельности требует от управ-
ленцев не только развития качеств, соответствующих новым реалиям,
но и весьма глубокого знания, если можно так выразиться, технологии
управления проектами. Не менее необходимо это знание и специали-
стам, привлекаемым к осуществлению того или иного проекта.
Предлагаемая вашему вниманию книга содержит весьма подробное
описание того, как управлять проектами, но главное --- как добиться
того, чтобы работа над проектами и их реализацией стала более эф-
фективной.
Предложенная авторами книги методика The CORE Project Mana-
gement PMTM успешно использовалась ими при руководстве разнооб-
разными проектами, и этот опыт является залогом того, что и вы смо-
жете использовать данную методику в своей деятельности.
Авторы стремились представить материал так, чтобы на доступном
уровне донести до читателя сложные понятия и технологии управле-
ния проектами, выделяя этапы реализации проектов и особенности
каждого из них.
Представляется чрезвычайно важным, что авторы ни на минуту не
забывают: любые проекты реализуются людьми, которым необходимо
взаимодействовать в процессе совместной работы над проектом. В этом

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

Введение
Итак, вы новичок в области управления проектами. Что ж, вы не оди-
ноки! Множество людей уже поняли, что управление проектами --- это
именно то средство, с помощью которого можно достичь успеха. Ско-
рее всего, вы уже не раз реализовывали проекты: на службе --- при раз-
работке новой продукции, совершенствовании технологических про-
цессов, внедрении новых видов услуг --- и дома --- например, собираясь
жениться или разводиться. К проектам также можно отнести семей-
ный отпуск и другие события, требующие значительных денежных
расходов.
Для многих людей работа над проектом омрачена досадой и разоча-
рованиями. Члены команды не могут прийти к единому мнению о том,
что или как именно нужно сделать. Сроки выполнения работ срыва-
ются. Клиенты недовольны. Командный дух слаб. Так не должно быть!
Проекты вполне могут стать и увлекательными и успешными, если
воспользоваться приемами, которые помогут вам на каждом этапе во-
площения проекта. Как раз об этом и пойдет речь в нашей книге: о не-
сложной, удобной в применении методике управления проектами.
Освоенный вами метод управления The CORE Project Management
PMTM поможет улучшить результаты всех ваших проектов. Все, что от
вас потребуется, --- подобно Элли из сказки «Волшебник Изумрудно-
го города», пройти по дороге, вымощенной желтым кирпичом, обра-
щая внимание на приведенные в книге рекомендации и приемы рабо-
ты и применяя их к вашему проекту. И все! Ваш проект рационально
организован, вы преуспеваете, а сам процесс управления проектом ста-
новится весьма увлекательным. Можно ли желать лучшего!
Что вы найдете в этой книге?
Главы книги расположены в том же порядке, что и шаги, которые вам
необходимо сделать, чтобы реализовать свой проект. К счастью, про-
екты в большинстве случаев линейны --- у них есть начало, середина и
конец --- то же самое можно сказать и о книге, которая, как лестница,
ступенька за ступенькой приведет вас к созданию большого проекта.

14
Введение
Глава 1. Основы управления проектом. Из этой главы вы узнае-
те об основных характеристиках проекта и о том, чем он отлича-
ется от обычного способа выполнения той или иной работы. Вы
поймете, зачем нужно искать новый подход к управлению проек-
тами. Вы определите типы людей, обычно участвующих в работе
над проектами, и те роли, которые они играют. Наконец, вы по-
знакомитесь с четырьмя этапами стандартного проекта, а также
узнаете, что нужно сделать на каждом этапе, чтобы успешно реа-
лизовать проект.
Глава 2. Начало проекта. Вы узнаете, какие данные нужно вклю-
чить в каждый раздел чартера --- документа, с которого начинается
проект. Вы научитесь правильно составлять чартер, определять
перечень задач и формулировать полезные выводы, необходимые
для того, чтобы перейти к следующему этапу. Кроме того, в этой
главе обсуждается проблема подбора команды для реализации
проекта.
Глава 3. Лидерство в команде, работающей над проектом. Про-
ект реализуют люди, и одна из функций руководителя проекта
заключается в том, чтобы стать лидером команды. В этой главе
вы познакомитесь с ключевыми принципами лидерства и пойме-
те, почему так важно участие всей команды в управлении проек-
том. Затем мы расскажем о пяти этапах развития команды, что
поможет вам понять, как создается высокоэффективная коман-
да. И наконец, вы сможете оценить свои способности в качестве
руководителя проекта.
Глава 4. Запуск проекта. «Пусковая» встреча --- момент, когда
команда впервые собирается вместе; здесь она в первый раз зна-
комится с программой проекта. Такое собрание задает тон и темп
всему проекту в целом. Вы узнаете, как правильно провести соб-
рание, рассмотрите примерный план того, что и как нужно сде-
лать.
Глава 5. Определение масштаба проекта. Очень важно точно
определить масштаб, поскольку тем самым мы правильно опреде-
ляем моменты для перехода на каждый последующий этап проек-
та. Вы узнаете, как выбрать подходящую цель проекта, распознать
различные типы потребителей и правильно определить потреб-
ности заказчиков.
Глава 6. Организация проекта. Вы узнаете, как грамотно разбить
проект на отдельные части и затем преобразовать их в задачи,

Введение
15
которые можно распределить между членами команды. Вы про-
ведете анализ состава команды, чтобы убедиться, что включен-
ные в нее люди выбраны правильно, и узнаете, что требуется для
эффективного делегирования.
Глава 7. Оценка рисков. Проблемы возникают при воплощении
любого проекта. Чтобы избежать хаоса, надо предотвратить как
можно больше проблем. Раскрывая процесс оценки рисков, мы
затронем ряд вопросов. Кого следует пригласить на встречу, по-
священную оценке рисков? Как лучше всего обнаружить и про-
анализировать риски? И наконец, как, если это возможно, избе-
жать рисков?
Глава 8. Составление графика работ. Для каждого проекта не-
обходимо составить график работ, а большинству проектов требу-
ются два вида графиков: один описывает проект в целом и исполь-
зуется при обсуждении проекта с людьми, не входящими в состав
команды, а другой необходим самой команде, чтобы закончить
проект в установленные сроки. Вы также узнаете, что делать, если
не удается выполнить работу вовремя.
Глава 9. Разработка бюджета. Для воплощения проектов требу-
ются ресурсы, а в большинстве случаев --- и большие денежные
расходы. Для каждого проекта следует составлять бюджет. Вы
научитесь правильно оценивать расходы и включать этот бюджет
в свой проектный план.
Глава 10. Составление окончательного проектного плана. Прой-
дя все этапы, связанные с планированием проекта, вы готовы со-
ставить окончательный письменный план проекта и представить
его на утверждение. Вы узнаете, что представляет собой такой
план и как написать краткое руководство по проекту. Мы погово-
рим и о том, как лучше вносить изменения в план уже после его
утверждения.
Глава 11. Приемы работы с командой. Помимо методов управ-
ления проектами, которые уже были рассмотрены в предыдущих
главах, вам потребуется знание некоторых приемов принятия ре-
шений, которые помогут вам справиться с оставшейся частью
проекта. Вы узнаете, как эффективно провести «мозговую ата-
ку», проанализировать ее результаты, а затем принять решение
на основе идей и предложений, выдвинутых командой.
Глава 12. Претворение плана в жизнь. После того как план одоб-
рен, надо приступить к работе. Однако необходимо постоянно

16
Введение
следить за продвижением проекта, чтобы быть уверенным, что
все идет по плану. Вам придется постоянно оценивать окружа-
ющую обстановку, выясняя: не возникли ли неожиданно новые
риски, не предусмотренные заранее.
Глава 13. Завершение проекта. Цель близка. Вы закончили ра-
боту и готовы поставить точку. Подождите! Необходимо оценить,
насколько доволен заказчик, подытожить полезные выводы, сде-
ланные во время воплощения проекта, а также подготовить ито-
говый отчет. И только потом начинайте праздновать вашу побе-
ду. Поздравляем! Вы добились того, чего хотели!
Глава 14. Подведение итогов. Краткий обзор основных элемен-
тов эффективного взаимодействия в команде и семь ключей к ус-
пешной реализации любого проекта.
Управление проектом --- это непрерывное движение. Мы вместе
пройдем все этапы управления проектом, откроем новые горизонты,
победим страхи и решим многие из тех проблем, с которыми вы уже
сталкивались. Мы еще раз обратим внимание на ключевые моменты
и наконец достигнем Изумрудного города, т. е. успешного завершения
нашего замечательного проекта.
Управление проектами больше не является исключительной пре-
рогативой менеджеров. Если вы не менеджер проектов, но страстно
желаете стать им или работаете в проектной команде и хотите выпол-
нять свою работу лучше, то эта книга для вас. Чего же мы ждем? Наш
домик только что упал на злую волшебницу Гингему, и нам, как и Элли,
пора отправляться в дорогу.

Глава 1
Основы управления проектом
Что такое проект?
Перед тем как мы отправимся в путешествие по стране управления
проектами, рассмотрим некоторые основные понятия и концепции.
Первый вопрос, на который нужно ответить, --- что конкретно стоит за
словом «проект»? Например, является ли проектом строительство зда-
ния по индивидуальному проекту? А если вы застройщик, руководя-
щий бригадой рабочих, которая раз за разом строит одинаковые типо-
вые дома? Будет ли это проектом? Действительно, первый пример ---
это проект, а вот возведение типовых домов --- уже бизнес процесс.
Давайте обратимся к общим чертам проектов и бизнес процессов:
в обоих случаях первоначальные вложения преобразуются в ка-
кой либо конечный продукт благодаря решению ряда задач или
выполнению последовательных действий. В нашем примере это
будет закладка фундамента, построение каркаса здания, кровель-
ные работы и т. п.;
и в том и в другом случае конечный продукт или результат полу-
чается только после полного завершения процесса. Конечный
продукт проекта --- здание по индивидуальному проекту. Резуль-
тат бизнес процесса --- готовые типовые дома.
Очевидно, что проекты и бизнес процессы --- это не одно и то же.
Чем же они различаются?
Во первых, возведение одного здания по индивидуальному проек-
ту --- это временное занятие, нерегулярное и неповторяющееся. Вы
строите всего одно здание и на этом заканчиваете свою работу над про-
ектом. Если вы постоянно строите дома, то строительный процесс все
время повторяется. Во вторых, когда вы строите здание по индивиду-
альному проекту, то конечный результат работы уникален. Других зда-
ний, в точности соответствующих этому, не существует. Когда вы стро-
ите типовые дома, все они похожи друг на друга. В третьих, если вы

18
Глава 1. Основы управления проектом
возводите всего одно здание, то вы набираете команду субподрядчи-
ков и поручаете им выполнить определенные задачи. Если же вы всерь-
ез занимаетесь строительством типовых домов, то водопроводчики,
электрики, плотники и другие рабочие, уже входящие в штат вашей
фирмы, построив одно здание, переключаются на строительство дру-
гого (табл. 1.1).
Рассмотрим другой пример. Допустим, вам нужно разработать и
внедрить новый процесс получения заказов и доставки продукции
(прием заказа, сортировка, упаковка, доставка). Проект ли это? Вре-
менно, да; внедрив этот процесс один раз, вам не придется снова его
разрабатывать и внедрять. Конечным результатом этой работы будет
уникальный процесс выполнения заказа; при этом должностные инст-
рукции, описывающие разработку и внедрение подобных процессов,
в компании отсутствуют. Поэтому разработка процесса выполнения
заказа удовлетворяет критериям проекта.
Таблица 1.1
Сравнительная характеристика проектов и бизнес процессов
Проект
1. Временный процесс: имеет начало
и конец
2. Результат уникален
3. Не существует должностных
инструкций
Бизнес процесс
1. Непрерывный процесс: постоянно
повторяются одни и те же действия
2. Одинаковые результаты каждый раз
при выполнении задачи
3. Имеются определенные должност-
ные инструкции
А что мы можем сказать о процессе выполнения заказов после того,
как он внедрен? Это проект или бизнес процесс? Вы будете регулярно
принимать и выполнять заказы, т. е. будете многократно повторять
один и тот же процесс. И конечный результат всегда будет один и тот
же --- отправленные коробки с заказами. И наконец, получать, сорти-
ровать и упаковывать заказы будут ваши сотрудники, поэтому, конеч-
но же, процесс выполнения/обработки заказов --- это бизнес процесс.
Итак, если вы создаете что то новое --- новую компьютерную про-
грамму или новую программу обучения или если хотите улучшить что
либо, например изменить процесс, продукт или способ оказания услуг, то
вы работаете над проектом. Если же вы хотите продолжать то, что де-
лали в прошлом, то вы вовлечены в бизнес процесс. Бизнес процес-
сами руководят, используя процесс менеджмент --- управление про

Глава 1. Основы управления проектом
19
цессами. Руководство проектами осуществляется через project mana-
gement --- управление проектами.
Что такое управление проектом?
Управление проектом --- это набор инструментов, технологий и зна-
ний, применение которых к вашему проекту помогает достичь наилуч-
ших результатов. Попытка руководить проектом без применения этой
науки похожа на игру в футбол без игровой стратегии. Представьте
себе тренера, собравшего игроков и сказавшего им: «Как мы должны
сыграть в этом матче? Нам нужно набрать больше очков, чем другая
команда, а следовательно, забить больше голов. Поэтому выходите на
поле и делайте все, что считаете необходимым, чтобы выиграть».
Каковы шансы на победу у такой команды? Явно не слишком высо-
кие. Чего же не хватает? Не хватает игровой стратегии, объясняющей,
как следует действовать, чтобы выиграть. Не хватает скоординирован-
ного претворения этой стратегии в жизнь. Необходимо также преду-
смотреть возможность изменения стратегии в зависимости от того, как
развивается игра. Применительно к проекту все эти составляющие
обеспечиваются управлением проектом.
Большинство команд относится к проектам примерно так же, как
и описанная выше футбольная команда к игре. Члены команды полу-
чают свои задания и начинают «играть». Вместе они собираются лишь
в минуты кризисов, которые, впрочем, следуют один за другим, пото-
му что члены команды работают без какого бы то ни было стратеги-
ческого плана. А когда (и если) проект удается завершить, члены
команды расстаются в надежде, что им больше никогда не придется ра-
ботать таким образом. Почему команда так ведет себя? Во первых, из
за того, что члены команды не знают о существовании метода, кото-
рый может помочь им в разработке стратегического плана. Во вторых,
не исключено, что они ошибочно полагают, будто создание стратеги-
ческого плана задержит выполнение проекта. На самом деле сдача
проекта задерживается именно из за того, что разработке плана было
уделено слишком мало внимания и времени. Потратив время на раз-
работку плана, вы сэкономите время на выполнение работы в целом
(рис. 1.1).
Управление проектом поможет вам разработать план действий и про-
делать ряд шагов, которые помогут ответить на основные вопросы до
того, как вы приступите к непосредственному выполнению работы. Вот
некоторые из них: что вы собираетесь производить? Каковы желания

20
Глава 1. Основы управления проектом
Рис. 1.1. Сравнение предварительного планирования
с минимальным планированием
и потребности заказчиков? Кто будет выполнять работу? Сколько вре-
мени она займет? Сколько потребуется средств? Какие сбои возмож-
ны в работе? Как можно избежать потенциальных проблем? На эти
вопросы необходимо ответить заранее, чтобы дальнейшая работа над
проектом протекала гладко и эффективно.
Помимо помощи в разработке плана управление проектом помога-
ет следить за процессом воплощения проекта, способствует решению
проблем по мере их возникновения. Это позволяет вам вносить из-
менения в проект, если в этом возникнет необходимость. Например,
будущий владелец здания, строящегося по индивидуальному проекту,
может решить, что ему не обойтись без видеокамеры наблюдения
у крыльца. Потребуется внести изменения в план строительства. На-
конец, управление проектом поможет зафиксировать все, что проис-
ходило во время работы над проектом, для того чтобы при разработке
следующего проекта получить лучшие результаты.
Особенности метода управления проектом
Метод --- это система действий, предпринимаемых для того, чтобы до-
биться желаемого результата. Если вы занимаетесь проектом в оди-
ночку, то можете использовать любую систему, которая вам нравится.

Глава 1. Основы управления проектом
21
Однако когда вы работаете с группой людей, вам нужен общий метод
управления проектом, так как члены команды должны работать сооб-
ща. Для поиска подходящего метода существуют два подхода. Первый
состоит в том, что команда может изобрести свой метод самостоятель-
но, а второй сводится к использованию уже разработанной, проверен-
ной методологии.
Ценность использования испытанных методов состоит в том, что вся
работа по разработке метода уже проделана за вас. Это позволяет вам
сосредоточиться на том, что действительно важно, --- на самой работе.
Методология, которая рассматривается в этой книге, называется
«Метод управления проектом CORETM», или сокращенно CORE PMTM.
CORE означает по первым буквам латинского алфавита Collaborative,
Open Architecture, Results Oriented, Easy to Use:
сотрудничество {Collaborative) --- позволяет обеспечить активное
участие в проекте каждого члена команды;
открытая структура (Open Architecture) --- может использоваться
для любых видов проектов, в любой организации;
ориентация на результаты (Results Oriented) --- помогает создавать
успешные проекты, удовлетворяющие требованиям заказчиков;
простота в использовании (Easy to Use) --- метод легок в примене-
нии благодаря подходу «шаг за шагом».
Метод CORE PMTM был разработан авторами с применением но-
вейших технологий управления, таких как современные способы от-
четности, всеобщий контроль качества, теория ограничений, делеги-
рование, командная работа и, конечно, управление проектами. Этим
методом пользуются лидеры и команды по всему миру, работающие
над самыми разными проектами. Он не раз подтверждал как свою лег-
кость в использовании, так и высокую эффективность. Вы увидите,
что этот метод дает наилучшие результаты в случае, когда вся команда
вовлечена в планирование и мониторинг проекта; однако его может
использовать и руководитель проекта, проводящий планирование и
мониторинг самостоятельно. Первый подход называют совместным
управлением, а второй --- директивным управлением проектами. Рас-
смотрим различия между ними.
Директивное управление проектами
Директивный подход представляет собой довольно старую и хорошо
известную технологию управления. Предполагается, что менеджер

22
Глава 1. Основы управления проектом
проекта --- это человек, который лучше всех справляется с задачами
планирования и контроля проекта. Руководитель проекта планирует,
а затем делегирует выполнение конкретных задач членам команды.
Далее он тщательно следит за работой каждого сотрудника, чтобы удо-
стовериться, что тот выполняет свои задания правильно и укладыва-
ется в график. В этом случае канал общения связывает руководителя
и его подчиненных. Если возникает какая то проблема, то ее решение ---
это задача лидера (рис. 1.2).
Хотя при некоторых обстоятельствах директивный стиль очень эф-
фективен, так как экономит время при планировании проекта, он все
же имеет ряд значительных недостатков:
проект в целом занимает больше времени, так как этап выполне-
ния работы, который является самым длительным этапом любого
проекта, затягивается еще сильнее из за неразберихи, недопони-
мания и исправления сделанного (работу приходиться выполнять
повторно, так как первоначально что то делается неверно);
члены команды плохо понимают цель проекта вообще, а также
то, как отразится их работа на общих результатах;
команда практически не связана с проектом ни обязательствами,
ни правами собственности.
Совместное управление проектами
Совместное управление проектами --- это более современная техноло-
гия управления. Руководитель проекта принимает участие в процессе
управления проектом, ведя за собой команду. Команда под управле-
нием лидера проводит мониторинг результатов выполнения проекта
после завершения работы. Рабочие решения принимаются при участии
Рис. 1.2. Директивный стиль общения

Глава 1. Основы управления проектом
23
всей команды, а информация циркулирует не только от руководителя
к членам команды и обратно, но и между членами команды (рис. 1.3).
Преимущества совместного подхода к управлению заключаются
в следующем:
каждый член команды понимает, как выполняемая им часть про-
екта отразится на результатах работы в целом;
возникает больше идей;
когда в разработке решений принимают участие все члены ко-
манды, решения оказываются более рациональными;
совместная работа усиливает чувства причастности и ответствен-
ности за результаты работы;
моральный дух членов команды при совместном подходе к управ-
лению обычно выше;
реже возникает потребность в переделке работы;
повышается производительность как отдельных сотрудников, так
и команды в целом.
Совместный подход к управлению проектами обычно дает лучшие
результаты. На сегодняшний день метод CORE PMTM, описываемый
в этой книге, является наиболее часто используемым совместным под-
ходом к управлению проектами.
Рис. 1.3. Совместный стиль общения

24
Глава 1. Основы управления проектом
Как директивный, так и совместный подход зависит от людей. Ни-
чего не выйдет, если не будет сотрудничества. Давайте рассмотрим те
роли, которые должны играть люди, чтобы проект стал успешным.
РОЛИ при управлении проектом
Множество людей либо непосредственно участвуют в проекте, либо
претендуют на часть его результатов. Такие люди называются доль-
щиками. Основными дольщиками в большинстве проектов являются:
лидер проекта --- часто его также называют менеджером проекта;
это человек, который возглавляет проект;
член команды проекта --- тот, кто непосредственно занимается
осуществлением проекта. Он также принимает участие в процес-
се управления проектом;
спонсор --- это член правления, который выступает в качестве
связующего звена между правлением компании и лидером про
екта;
заказчик проекта --- человек или группа людей, которые получат
конечный продукт проекта. Конечный продукт --- это результат
проекта, поставляемый заказчику, чьи желания и потребности
и были основополагающими в этом проекте;
менеджер по ресурсам --- также известен как функциональный
менеджер. Это человек, отвечающий за ресурсы, в частности за
персонал, непосредственно занятый в проекте.
В проекте в качестве дольщиков также могут быть задействованы
и другие люди или группы, например сотрудники тех отделов, на ко-
торые окажет влияние конечный продукт проекта. Давайте рассмот-
рим роль каждого из основных дольщиков более подробно.
Лидер проекта
Лидера проекта также называют менеджером проекта. Однако при со-
вместном подходе к управлению проектом его основная роль --- лидер-
ство, поэтому в дальнейшем мы будем говорить о нем как о лидере
проекта. Он должен:
задать команде исполнителей направление работы;
руководить командой исполнителей во время процесса управле-
ния проектом (создания и выполнения плана по проекту);
получить одобрение проектного плана;

Глава 1. Основы управления проектом
25
постоянно публиковать данные о состоянии текущих результа-
тов работы над проектом, сравнивая их с запланированными по-
казателями;
реагировать на запросы по изменению плана;
способствовать сплочению команды --- межличностному процес-
су, направленному на объединение исполнителей проекта в еди-
ную команду;
устранять препятствия по ходу работы, чтобы команда могла до-
вести выполнение проекта до конца;
выполнять роль посредника при взаимодействии с организато-
ром проекта;
выполнять роль посредника при взаимодействии с заказчиком
проекта;
организовывать и проводить собрания команды;
подготовить заключительный отчет по результатам проекта.
Основная функция руководителя проекта --- направить усилия ко-
манды исполнителей таким образом, чтобы проект был успешно за-
вершен. Руководитель проекта несет ответственность за успех проекта.
Член команды проекта
Член команды проекта является одним из важнейших факторов успе-
ха проекта. Член команды должен:
обеспечивать техническую экспертизу;
предлагать идеи, которые могут помочь команде создать качест-
венный продукт вовремя и в рамках бюджета;
выполнять свою часть работы над проектом вовремя;
сообщать команде о возникающих проблемах;
участвовать в командном процессе планирования;
контактировать с поставщиками по своей части проекта;
если требуется, информировать лидера проекта о возникающих
проблемах;
выполнять обязательства по проекту, данные команде;
помогать команде не сойти с правильного пути при воплощении
проекта;
предоставлять последние данные о состоянии проекта менедже-
ру логистического отдела;

26
Глава 1. Основы управления проектом
стремиться к взаимодействию с командой и поддерживать ее бое-
вой дух.
Член команды проекта играет активную роль в совместном управ-
лении проектом. Он не только обеспечивает техническую экспертизу
и производит конечный продукт, но также помогает в планировании
и наблюдении за проектом. Член команды отвечает за то, чтобы его
часть работы способствовала успеху всего проекта.
Спонсор
Спонсор --- это кто то из руководства компании, назначенный для конт-
роля над проектом. Он должен убедиться в том, что проект будет удов-
летворять как потребностям заказчика, так и потребностям организа-
ции. Спонсора часто называют защитником проекта.
Спонсор должен:
начать проект, выбрав лидера проекта;
убедиться, что цели проекта не противоречат стратегическим це-
лям организации;
обозначить общее направление проекта;
убедиться, что у команды есть все ресурсы, необходимые для
успешного воплощения проекта;
заручиться обязательством логистического отдела по поддержке
проекта;
проанализировать и утвердить план проекта;
изучать данные по текущему состоянию проекта;
вместе с лидером проекта анализировать результаты проекта;
помогать устранять препятствия, с которыми не могут справиться
лидер и члены команды;
наставлять или инструктировать лидера проекта;
проанализировать и утвердить итоговый отчет.
Спонсор проекта должен убедиться, что лидер проекта обладает
необходимыми ресурсами, поддержкой, а также достаточной квали-
фикацией для успешной работы. Спонсор несет ответственность за
успех работы лидера проекта.
Что произойдет, если у вашего проекта не будет спонсора? Тогда
функции спонсора должен будет взять на себя ваш начальник или за-
казчик проекта, если этот заказчик является частью вашей компании.
Спонсор приводит проект в соответствие с интересами правления ком-
пании. Начинать проект без спонсора очень рискованно.

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

28
Глава 1. Основы управления проектом
анализирует отчеты о ходе работ по проекту;
поддерживает постоянную обратную связь с лидером проекта;
оценивает готовую продукцию и весь процесс воплощения про-
екта.
Внутренние заказчики часто выполняют и дополнительные функции:
анализ и утверждение проектного плана в целом (внешние заказ-
чики обычно ограничиваются только теми разделами плана, ко-
торые связаны с объемом работ);
анализ итогового отчета о состоянии работ.
Если вы имеете дело с проектом, предназначенным для внешнего
заказчика, то вам жизненно необходимо иметь внутреннего спонсора
для работы над проектом. Работа внутреннего спонсора будет заклю-
чаться в согласовании потребностей внешнего заказчика и собствен-
ной организации. Если же проект разрабатывается для внутреннего
заказчика, то последний может взять на себя и роль спонсора.
Менеджер по ресурсам (функциональный менеджер)
Менеджер по ресурсам, или функциональный менеджер, обычно от-
вечает за контроль ресурсов (главным образом человеческих), кото-
рые могут потребоваться для воплощения проекта. Люди, работающие
над проектом, отбираются менеджером по ресурсам, а затем закрепля-
ются за проектом на полную ставку или, что бывает чаще, по совме-
стительству. Лидеру проекта довольно трудно добиться сотрудниче-
ства и преданности от тех, кто не подчиняется непосредственно ему.
Эту трудность легче преодолеть, используя совместный подход к управ-
лению проектом.
Менеджер по ресурсам должен:
предоставлять человеческие ресурсы, необходимые для проект-
ной команды;
анализировать и утверждать проектный план в областях, затра-
гивающих его компетенцию;
при необходимости направлять деятельность тех членов коман-
ды, которые являются сотрудниками логистического отдела;
отвечать за то, чтобы члены проектной команды обладали надле-
жащими знаниями и квалификацией для выполнения работы;
гарантировать, что у членов команды будет достаточно времени
для выполнения работы;

Глава 1. Основы управления проектом
29
устранять препятствия, с которыми сталкивается проектная
команда.
Работа над проектом пройдет гладко, если каждый участник будет
эффективно выполнять свои обязанности. Тем не менее именно на-
блюдение за тем, чтобы эти обязанности полностью выполнялись, яв-
ляется задачей лидера проекта при поддержке спонсора. Обязанности
могут изменяться в зависимости от той фазы, в которой находится
проект. Рассмотрим четыре фазы или основных подраздела процесса
управления проектом.
Четыре этапа проекта
Последовательность действий любой команды, от запуска проекта до
его полного завершения, примерно одинакова для любого проекта вне
зависимости от того, простой это проект или сложный, большой он или
маленький, работают ли над ним несколько человек или большая груп-
па. Все эти действия можно разложить на четыре этапа проекта. Каж-
дый этап включает в себя набор основных действий, которые необхо-
димо выполнить при управлении проектом. Эти четыре этапа следуют
один за другим, начиная с подготовки проекта и заканчивая его завер-
шением.
Подготовка проекта
Первый этап, подготовка проекта, начинается сразу после того, как
руководство компании принимает решение о разработке данного про-
екта. Цель первого этапа --- обозначить для проектной команды направ-
ление работы, определить круг задач и существующие ограничения.
Завершается первый этап составлением документа, который называ-
ется программой проекта. Проведение этапа подготовки проекта --- это
зона ответственности спонсора, но на самом деле программу проекта
в большинстве организаций составляет лидер проекта, а спонсор за-
тем утверждает ее (табл. 1.2).
Таблица 1.2
Этап подготовки проекта
Этап
Подготовка
проекта
Описание задачи
Спонсор должен указать лидеру проекта
общее направление работы над проектом.
Определяются ограничения, сдерживающие
факторы и приоритеты проекта
Результат
Программа
проекта

30
Глава 1. Основы управления проектом
Планирование
Следующий этап работы над проектом называется планированием
(табл. 1.3). На этом этапе проектная команда разрабатывает план, опи-
сывающий, как и когда будет выполнена работа. Планирование --- это
наиболее важный этап проекта, потому что именно сейчас принима-
ются решения о том, кто и чем будет заниматься и как обеспечить эф-
фективную совместную работу. Если пропустить этап планирования
и позволить членам команды делать то, что они сами посчитают нуж-
ным, то обязательно будут упущены какие либо важные части проек-
та. В результате вам придется переделывать работу, что довольно до-
рого и трудоемко и может поставить проект на грань срыва. Когда вы
спланировали работу заранее, то каждый разбирается в проекте в це-
лом, и его выполнение протекает более гладко.
Таблица 1.3
Этап планирования
Этап
Планирование
Описание задачи
Подобрать членов команды
Определить масштаб проекта
Выявить риски, связанные с проектом, и разра-
ботать способы их предотвращения
Оценить ресурсы, требующиеся для воплоще-
ния проекта
Результат
План проекта
Результатом этапа планирования является план проекта, т. е. подроб-
ный план выполнения работ. Этот документ должны утвердить спон-
сор, заказчик проекта и менеджеры по ресурсам.
Воплощение проекта
После утверждения проектного плана можно приступать к его выпол-
нению. На этапе воплощения проекта проводится непосредственная
работа, связанная с созданием конечного продукта. Чтобы убедиться,
что работа идет согласно графику, команда должна отслеживать вы-
полнение работы и требовать изменений проектного плана, если это
необходимо. Команда также информирует других дольщиков о ходе
воплощения проекта. Этот этап завершается передачей конечного про-
дукта заказчику проекта (табл. 1.4).
Завершение проекта
После того как заказчик принимает конечный продукт, начинается этап
завершения проекта. На этом этапе заказчик оценивает степень своей

Глава 1. Основы управления проектом
31
Таблица 1.4
Этап воплощения проекта
Этап
Воплощение
проекта
Описание задачи
Создание конечного продукта
Контроль за ходом работ над проектом
Решение проблем
Обмен информацией о результатах работ
Внесение изменений в план проекта
Результат
Отчеты о состоянии
работ
Конечный продукт
удовлетворенности результатами проекта. Спонсор и команда также
оценивают проект. Затем команда обсуждает, чему она научилась за
время работы, и на этой основе делает выводы по улучшению общей
системы управления проектами. Подготавливается заключительный
отчет о состоянии проекта, который включают в итоговый отчет по
проекту (иногда называемый отчетом о завершении проекта). Этот
отчет отправляют спонсору, заказчику и основным дольщикам проек-
та (табл. 1.5).
Таблица 1.5
Этап завершения проекта
Этап
Завершение
проекта
Описание задачи
Оценка степени удовлетворенности
заказчика
Анализ «уроков», полученных во время
воплощения проекта
Результат
Отчет о завершении
проекта
После подготовки отчета о завершении проекта проект считается
полностью выполненным. Однако важно помнить, что нужно не толь-
ко отмечать завершение проекта, но и устраивать небольшие праздни-
ки во время его осуществления, после того как ваша команда выпол-
нила что нибудь важное или сложное.
Этапы работы над проектом также можно представить в виде блок
схемы последовательных действий, приведенной на рис. 1.4.
Последовательность этапов
Каждый последующий этап основан на результатах тех этапов, кото-
рые ему предшествовали. Если на начальном этапе работа велась не-
качественно, то и последующие могут закончиться провалом. Если
недостаточно квалифицированно велась работа на этапе планирова

32
Глава 1. Основы управления проектом
Рис. 1.4. Последовательность этапов проекта (блок схема)
ния, то пострадают этапы воплощения и завершения проекта. И нако-
нец, если ошибки были допущены при воплощении проекта, то постра-
дает весь проект целиком.
Каждый этап должен заканчиваться процессом утверждения, кото-
рый следует завершить до того, как вы перейдете к следующему этапу

Глава 1. Основы управления проектом
33
Таблица 1.6
«Этапные ворота»
Этап
Подготовка проекта
Планирование проекта
Воплощение проекта
Завершение проекта
«Этапные ворота»
Утвержденная программа проекта
Одобренный проектный план
Принятый конечный продукт
Утвержденный отчет о завершении проекта
работы. Этот процесс не позволит вам перейти к следующему этапу
преждевременно. Процесс утверждения в конце каждого этапа назы-
вают этапными воротами, т. е. ограничительными требованиями по
завершению этапа (табл. 1.6).
Одно из преимуществ утверждения результатов в конце каждого
этапа состоит в том, что таким образом затраты на проект минимизи-
руются, так как издержки по воплощению проекта экспоненциально
увеличиваются по мере того, как вы переходите от этапа подготовки
проекта к этапу планирования, а затем к этапу воплощения. Затем на
этапе завершения проекта затраты значительно уменьшаются. Убеж-
даясь в том, что вы выполнили все основные поставленные задачи пе-
ред тем, как перейти к следующему этапу, вы не только снижаете за-
траты, но и избегаете бесполезной траты бесценного времени (рис. 1.5).
Всякий раз, когда вам предстоит использование важных ресурсов
(неважно, деньги вы расходуете или рабочее время), полезно заранее
четко сформулировать систему параметров принятия или непринятия
Этапы
Рис. 1.5. Расходы на каждом этапе проекта

34
Глава 1. Основы управления проектом
решения. Такой системой, к примеру, являются «этапные ворота», ко-
торые позволяют принять решение о дальнейшей работе над проектом.
Если ваш проект среднесрочный или долгосрочный (более шести меся-
цев), вам также потребуется несколько раз принять решение о продол-
жении или прекращении работ на протяжении этапа воплощения про-
екта. Это поможет вам убедиться в том, что все делается правильно и что
конечный продукт, который вы получите, все еще будет нужен заказчи-
ку и организации. Такие решения, принимаемые на протяжении этапа
воплощения проекта, называются этапными воротами или внутриэтап¬
ными ограничениями и должны быть одобрены спонсором проекта.
Утверждение в процессе управления проектом
Утверждение перехода от одного этапа к другому или правомерности
прохождения через «внутри этапные ворота» должно быть неотъемле
мой частью организационной системы управления проектом, которая
создается и поддерживается руководством. Утверждать результаты
работы в процессе управления проектом рекомендуется следующим
образом (табл. 1.7).
Таблица 1.7
Утверждение основных этапов работы
Составляющая процесса
управления проектом
Программа проекта
Проектный план
«Внутри этапные ворота»
этапа воплощения проекта
Требования об изменении
плана
Отчет о завершении проекта
Спонсор
Составляет
и утверждает
Утверждает
Утверждает
Утверждает
Утверждает
Заказчик*
Утверждает
Утверждает
Утверждает
Утверждает
Получает
Менеджер
по ресурсам
Утверждает
Утверждает
Утверждает
выборочно
Утверждает в случае,
если вопрос находится
в его компетенции
Получает
* В случаях, когда заказчиком является внешний клиент, необходимо опреде-
лить, какие документы следует ему передать, чтобы он смог их проанализиро-
вать и одобрить ход выполнения проекта
Успех проекта
Проект считается успешно завершенным, если удовлетворены как нуж-
ды заказчика, так и потребности организации, а в результате заверше-

Глава 1. Основы управления проектом
35
ния проекта организация приобретает значимый опыт. Заказчики до-
вольны, если получают конечный продукт, который соответствует их
запросам или превосходит их ожидания. Конечным продуктом может
быть товар (материальный или нематериальный), услуга, процесс, план
или комбинация вышеперечисленного.
Заказчики счастливы, когда конечный продукт превосходит все их
ожидания. Они разочаровываются, если продукт не отвечает их за-
просам (табл. 1.8).
Таблица 1.8
Ожидания заказчика
Реакция заказчика
Счастлив
Доволен
Недоволен
Конечный продукт и ожидания
Готовый продукт превосходит ожидания
Готовый продукт соответствует ожиданиям
Готовый продукт не соответствует ожиданиям
Ожиданиями можно управлять. Можно пообещать заказчику мень-
ше, чем сможете дать ему на самом деле. Если заказчик рассчитывает
на меньшее, а получит в результате большее, то наверняка будет в во-
сторге. Но если он рассчитывает на большее, а получит меньшее, то
будет разочарован. В обоих случаях вы передадите ему один и тот же
продукт; разница лишь в том, как этот продукт будет выглядеть в гла-
зах заказчика --- на фоне его ожиданий.
Вторым критерием успеха проекта является удовлетворение потреб-
ностей организации. К таким потребностям относится получение при-
были или расширение возможностей в новой технологической обла-
сти. Потребности организации представляет спонсор проекта, и они
должны быть включены в программу проекта.
Третий критерий успеха проекта состоит в том, чтобы в результате
воплощения проекта вы лично, команда и организация научились бы
чему то такому, благодаря чему в следующий раз вы или кто то из со-
трудников организации сможет работать, повторяя ваши успехи и из-
бегая ваших ошибок. Такой процесс обучения должен вестись на про-
тяжении всей работы над проектом и стать основной задачей на этапе
завершения проекта.
Теперь, когда мы рассмотрели основы управления проектом, наста-
ло время более подробно остановиться на первом этапе проекта --- его
подготовке.

Глава 2
Начало проекта
Первый этап работы над проектом, который называется подготовкой
проекта, начинается сразу после того, как руководство одобрит проект.
Цель начала проекта состоит в том, чтобы задать направление (опре-
делить, что именно нужно будет сделать), а также выяснить все огра-
ничения по проекту. Как направление проекта, так и ограничения для
него должны исходить от спонсора проекта, поскольку именно он при-
надлежит к высшему руководству и отвечает за то, чтобы проект соот-
ветствовал стратегическим целям организации, а также за то, чтобы
прибыль от проекта превышала затраты на него.
Направление проекта и ограничительные факторы описываются
в документе, который называется чартером. За составление данного
документа несет ответственность спонсор. Однако многие спонсоры
либо не знают, как составить чартер, либо заявляют о том, что у них
нет на это времени. В результате очень вероятно, что именно вам при-
дется разработать чартер и только потом представить документ уже
в готовом виде спонсору на проверку и утверждение. (Кроме того, же-
лательно получить одобрение со стороны заказчика проекта.)
Чартер должен содержать ответы на следующие основные вопросы:
что именно вы собираетесь произвести? Для кого? К какому сроку?
По какой цене?
В качестве примера составим чартер по разработке и внедрению
нового процесса выполнения заказов для компании XYZ. (В настоя-
щее время выполнением заказов для компании XYZ: их отбором, упа-
ковкой, перевозкой и получением инвентаря занимается подрядчик.
Руководство решило перенести этот процесс «внутрь» компании. Ме-
неджера, который будет отвечать за процесс выполнения заказов по-
сле его внедрения, зовут Кен; он же является спонсором проекта.)
Чартер будет легче составить, если для этого воспользоваться го-
товыми формами или шаблонами. (Формы, представленные в этой
книге, можно приобрести через Интернет на сайте автора по адресу
www.projectresults.com.) Давайте рассмотрим процесс заполнения каж-
дого раздела общей формы чартера.

Глава 2. Начало проекта
37
Заполнение раздела о масштабе проекта
Первый раздел чартера посвящен масштабу проекта; здесь оговарива-
ется, что будет сделано и для кого.
Первая графа в разделе о масштабе проекта --- название проекта.
Выберите какое нибудь не слишком длинное и сложное для произне-
сения название --- ведь вам придется часто писать его и постоянно упо-
минать в разговоре. Название также должно отражать основную цель
проекта (табл. 2.1).
Таблица 2.1
Общая форма чартера --- раздел о масштабе проекта
Название
Название проекта
Описание
Название проекта. Оно должно отражать основные цели
проекта
Далее опишите бизнес ситуацию, говорящую в пользу осуществле-
ния данного проекта. Каким потребностям бизнеса отвечает проект?
Как данный проект поможет организации в достижении ее стратеги-
ческих целей? Как он поможет развитию компании? Какие преиму-
щества получит компания в результате воплощения данного проекта
(табл. 2.2)?
Таблица 2.2
Общая форма чартера --- раздел о масштабе проекта
Название
Бизнес ситуация
Описание
Коммерческое обоснование проекта. В этом разделе объясня-
ется, почему данный проект имеет большое значение для
организации
Затем следует изложить цели проекта, т. е. то, чего вы хотите до-
биться в результате его выполнения. Сформулировать цели нужно
кратко и четко, одной фразой или с несколькими подпунктами.
Убедитесь, что поставленные задачи содержат только то, за что вы
действительно готовы отвечать. Все преимущества, которые компания
получит в результате выполнения проекта, следует указать в графе
«Бизнес ситуация», а не в графе «Цели». За соответствие проекта по-
требностям компании отвечает спонсор. Лидер проекта отвечает лишь
за достижение целей проекта. Организационные преимущества про-
екта не входят в раздел описания масштаба проекта и не должны фи-
гурировать в графе «Цели проекта» (табл. 2.3).

38
Глава 2. Начало проекта
Таблица 2.3
Общая форма чартера --- раздел о масштабе проекта
Название
Цели проекта
Описание
Цели и задачи проекта. Команда проекта отвечает за достиже-
ние этих целей
Например, для компании XYZ одна из причин переноса процесса
выполнения заказов «внутрь» --- это экономия денежных средств орга-
низации в долгосрочной перспективе. Таково коммерческое обосно-
вание проекта. Оно не должно вноситься в графу «Цели проекта»,
поскольку проектная команда, которая будет распущена после его за-
вершения, не может отвечать за долгосрочный результат. Кроме того,
ответственным за долгосрочную экономию от процесса выполнения
заказов будет Кен --- менеджер процесса, а не члены проектной коман-
ды. Цель проекта может быть сформулирована как «внедрение рента-
бельного процесса выполнения заказа от получения конкретного за-
каза до момента оплаты».
Далее мы должны определить конечный продукт проекта. Конеч-
ным продуктом может быть какой либо товар, услуга, процесс, план
или комбинация вышеперечисленного. Конечный продукт --- это за-
конченный результат на этапе воплощения проекта, который будет
передан заказчику. Он же является основной целью проекта, поскольку
проект осуществляется для того, чтобы удовлетворить заказчика, а за-
казчик будет доволен только в том случае, если конечный продукт со-
ответствует его ожиданиям или превосходит их (табл. 2.4).
Таблица 2.4
Общая форма чартера --- раздел о масштабе проекта
Название
Конечный продукт (продукты) Описание
Конечный продукт, услуга, процесс или план,
которые будут созданы для заказчика проекта
Если конечных продуктов несколько, то необходимо описать каж-
дый из них. Например, если вы собираетесь выпустить какой то про-
дукт, вам понадобится разработать процесс его производства. Или если
вы оказываете какую то услугу, то вам могут понадобиться вспомога-
тельные продукты, например учебные пособия, если услуга носит об-
разовательный характер. Остерегайтесь проектов, которые подразуме-
вают много конечных продуктов. Это может быть показателем того,
что вы слишком размахнулись. Стремитесь, чтобы число конечных

Глава 2. Начало проекта
39
продуктов не превышало двух, тогда масштаб проекта останется ра-
зумным и управляемым (табл. 2.5).
Таблица 2.5
Типы конечных продуктов
Тип конечного продукта
Продукт
Процесс
Услуга
План
Описание
Материальный или нематериальный товар
Последовательность действий, приводящая к появ-
лению продукта
Деятельность одного человека, осуществляемая
для другого человека
В основе услуги лежит процесс, однако сама она
создается в момент ее предоставления --- напри-
мер, в случае обучения
Документ, который описывает, как что то будет
или должно быть сделано
Заказчик проекта --- это человек или группа людей, которые полу-
чают конечный продукт. Если вы разрабатываете и воплощаете какой
либо бизнес процесс, то заказчиком выступает менеджер, который бу-
дет руководить бизнес процессом после окончания вашей работы. Если
вы работаете над продуктом или услугой, то вашим заказчиком может
стать любой человек или организация, которые планируют впослед-
ствии продавать этот продукт или услугу. Задайте себе вопрос: «Кому
я передам полученный конечный продукт?» Это и будет ваш заказчик
(табл. 2.6).
Таблица 2.6
Общая форма чартера --- раздел о масштабе проекта
Название
Заказчик проекта
Описание
Человек или группа людей, которые получат конечный
продукт проекта
Не путайте заказчика проекта с конечными пользователями, людь-
ми, которые будут непосредственно потреблять то, что вы производи-
те. Заказчик процесса --- это человек или группа людей, которым вы
передадите конечный продукт вашего проекта сразу после его завер-
шения. Все еще не совсем осознаете различия? Не волнуйтесь, мы по-
говорим о заказчиках проекта более подробно в гл. 5.
Далее следует зафиксировать те качества и характеристики, кото-
рыми должен обладать конечный продукт по мнению заказчика про

40
Глава 2. Начало проекта
екта. Какие именно эксплуатационные качества (функции) или эле-
менты дизайна (дополнительные украшения) ему необходимы? Это
требования заказчика проекта, и на этом этапе их достаточно определить
в общих чертах. Не стоит упоминать более 5 6 ключевых функций или
характеристик --- просто потому, что пока вы знаете о них мало. Вы
еще вернетесь к этому пункту и раскроете его более подробно на этапе
планирования проекта. На данный же момент вам необходимо лишь
осознать наиболее важные, с точки зрения заказчика, характеристики
продукта. Проще всего составить список требований, выяснив все у са-
мого заказчика (табл. 2.7).
Таблица 2.7
Общая форма чартера --- раздел о масштабе проекта
Название
Требования заказчика проекта
Описание
Особенности дизайна или специальные функции
конечного продукта проекта
Последний подраздел в данном разделе чартера называется «Нуж-
ды заказчика проекта». Это та проблема, которую заказчик пытается
разрешить путем использования конечного продукта данного проек-
та. Ведь заказчик проекта не конечный продукт стремится получить.
На самом деле ему нужно решение его проблемы. Вам ведь в действи-
тельности нужен не автомобиль, а средство передвижения и/или сим-
вол, демонстрирующий ваше положение в обществе. Автомобиль --- это
лишь способ удовлетворения ваших нужд.
В разделе, посвященном нуждам заказчика, вам следует попытать-
ся определить настоящую причину, вызвавшую возникновение дан-
ного проекта: проблему заказчика, которую хотя бы отчасти можно
решить с помощью конечного продукта проекта. (Проблема не обяза-
тельно исчезнет после завершения вашего проекта; достаточно, если
благодаря конечному продукту проекта она потеряет остроту.) В нашем
примере с разработкой процесса выполнения заказов заказчиком про-
екта является менеджер процесса (Кен), а его проблема связана с тем,
что торговая фирма посредник осуществляет поставку учебных мате-
риалов ненадежно и с опозданием. Осознавая его нужды, вы в любой
момент можете удостовериться, соответствует ли ваша работа запро-
сам заказчика проекта. Если нет, то вы идете по ложному пути. Пони-
мание нужд потребителя --- это один из тех компасов, которые помога-
ют сориентировать ваш проект в нужном направлении (табл. 2.8).

Глава 2. Начало проекта
41
Таблица 2.8
Общая форма чартера --- раздел о масштабе проекта
Название
Нужды заказчика
Описание
Проблема заказчика проекта, которую поможет разрешить
конечный продукт проекта
Сядьте и обстоятельно поговорите с заказчиком проекта, выясните
у него, какую бизнес проблему он собирается разрешить при помощи
конечного продукта проекта. Чем глубже вы осознаете ту потребность,
которая движет проект, тем лучше вы в конечном итоге удовлетворите
нужды потребителя.
В конце мы должны перечислить лиц, заинтересованных в данном
проекте, так называемых дольщиков (табл. 2.9). Дольщики --- это люди
или группы, на которых данный проект окажет то или иное воздей-
ствие. Сюда могут входить основные поставщики, менеджеры по ре-
сурсам и любые другие группы, на которые может повлиять конечный
результат данного проекта, например профсоюз. Заказчики, спонсор
и члены проектной команды также являются заинтересованными ли-
цами, однако о них речь пойдет в других разделах чартера.
Таблица 2.9
Общая форма чартера --- раздел о масштабе проекта
Название
Дольщики
Описание
Все, кого затрагивает данный проект, за исключением его
заказчика, спонсора и членов проектной команды
Раздел описания масштаба для нашего проекта
«выполнения заказов»
На этом заканчивается раздел описания масштаба проекта, в котором
мы в общих чертах попытались ответить на вопросы, что мы хотим
получить и зачем (табл. 2.10). Теперь пришло время задать те ограни-
чительные факторы, в рамках которых осуществляется проект. Они
подробно описываются в разделе, посвященном ресурсам.
Заполнение раздела о ресурсах
Второй раздел, называемый «Ресурсы», отвечает на вопросы «кто»,
«когда» и «сколько». Первый вопрос --- «кто» --- относится к проект-
ной команде: кто войдет в ее состав?

42
Глава 2. Начало проекта
Таблица 2.10
Раздел описания масштаба для нашего проекта «выполнения заказов»
Название
Название проекта
Бизнес ситуация
Цели проекта
Конечный продукт (продукты)
Заказчики проекта
Требования заказчика проекта
Нужды заказчика
Дольщики
Описание
Выполнение заказов
Оцениваемый рост оборота остается на уровне
25% в год. Оценка основных компетенций,
необходимых для достижения такого роста,
показала, что компания должна обеспечить
выполнение заказов своими силами. Это снизит
наши накладные расходы и, что более важно,
повысит уровень удовлетворенности
покупателей
Разработка и внедрение рентабельного процесса
обработки заказов, начиная с момента поступ-
ления заказа и заканчивая оплатой
Внедренный процесс выполнения заказов
Ответственный за бизнес процесс --- Кен
Процесс обработки заказов, который позволит
выполнять разнообразные заказы клиентов
Интеграция с системой учета
Возможность контроля запасов
Точность исполнения заказов
Заказы на учебные пособия изменяются в зави-
симости от программ и клиентов; поэтому в от-
личие от выполнения заказов на поставку книг
здесь возможна существенная разница между
заказами. Внешние подрядчики оказались не
в состоянии справиться с этим разнообразием
и оперативно выполнять заказы, как это требу-
ется в нашем бизнесе. В настоящее время удов-
летворенность заказчиков поддерживается
только беспрецедентными усилиями внутрен-
него персонала
Бухгалтерия, продавцы
Если вы составляете чартер, то сейчас как раз самое время задуматься
о том, кого стоит привлечь к работе над проектом (табл. 2.11). Просмот-
рите еще раз раздел, в котором описывается масштаб проекта. Какие
навыки необходимы для того, чтобы создать конечный продукт, требу-
ющийся заказчику? Кого из дольщиков вы хотели бы включить в ко-
манду проекта? (В конце этой главы, в разделе, посвященном форми-

Глава 2. Начало проекта
43
рованию команды, указанная тема рассматривается более подробно.)
Если чартер составляет сам спонсор, то у него есть выбор: либо подо-
брать участников команды лично, либо назначить лидера проекта и пре-
доставить ему возможность самому набирать команду.
После этого мы должны определить рамки проекта. Во первых, ка-
ков крайний срок завершения проекта? Если такого срока нет, то су-
ществуют ли какие либо ожидания относительно того, когда будет
получен конечный результат проекта? Если нет, отметьте, что крайний
срок не установлен. (Такое случается достаточно редко. Обычно край-
ний срок задается заранее, и зачастую оказывается, что уложиться в него
нереально.) Есть ли какие то другие временные рамки, с которыми
должна считаться команда? Объясните, чем мотивирован каждый из
крайних сроков. Это поможет команде понять причину установления
именно таких временных рамок.
Таблица 2.11
Общая форма чартера --- ресурсы
Название
Формирование команды
Описание
Люди, принятые в команду исполнителей
Графа «Крайний срок» не должна использоваться для создания рас-
писания работы команды. Это микроменеджмент, который никак не
поможет команде и не увеличит ее шансов завершить проект вовремя.
На этапе планирования команда сама составит удобное для нее распи-
сание работы, а у спонсора и заказчика проекта будет возможность
рассмотреть это расписание и одобрить его (табл. 2.12).
Таблица 2.12
Общая форма чартера --- ресурсы
Название
Крайний срок
Описание
Дата передачи конечного результата (результатов)
проекта; причины возникновения предельных сроков
Ограничивается ли время, которое члены команды могут затратить
на работу над данным проектом? Время, затраченное на проект внут-
ренним персоналом фирмы, называется внутренними трудовыми из-
держками или просто внутренними трудозатратами. В некоторых орга-
низациях сотрудникам не позволяется расходовать на проект больше,
чем Х% своего времени, или считается, что проект не должен отнимать
у человека более чем Y рабочих часов. Если у вас существуют какие

44
Глава 2. Начало проекта
либо ограничения на внутренние трудозатраты, укажите их здесь. При-
ведите также основания для введения таких лимитов (табл. 2.13).
Таблица 2.13
Общая форма чартера --- ресурсы
Название
Ограничения на внутренние
трудовые издержки
Описание
Максимальная продолжительность рабочего
времени, которое персонал компании может
посвятить данному проекту; причины такого
ограничения
А как насчет денег? Какое максимальное количество средств можно
израсходовать на проект? Постарайтесь выяснить, какая сумма вам
отводится, даже если бюджет проекта еще не составлен. Во многих
организациях денежными средствами проекта распоряжаются не ме-
неджеры проектов, а менеджеры по ресурсам. В таком случае нужно
указать суммы денег, которые готов выделить для проекта каждый из
отделов. Эти данные будут очень важны на этапе планирования для
составления плана расходов на проект. Приведите причины установ-
ления именно такого лимита расходов (табл. 2.14).
Таблица 2.14
Общая форма чартера --- ресурсы
Название
Ограничения на расходы
Описание
Максимальная сумма денег, которая может быть
затрачена на реализацию данного проекта; причины
установления такого ограничения
Существуют ли еще какие нибудь ограничения на ресурсы? Может
быть, на какие то действия? Возможно, вы не вправе нанимать кон-
сультантов или должны использовать только имеющееся оборудова-
ние. Приведите все ограничения, установленные спонсором проекта
(табл. 2.15).
Таблица 2.15
Общая форма чартера --- ресурсы
Название
Организационные ограничения
Описание
Ограничения по проекту, не связанные с край-
ними сроками, внутренними трудозатратами
и денежными расходами

Глава 2. Начало проекта
45
Наконец, команде необходимо определить приоритеты внутри про-
екта (табл. 2.16). Что для данного проекта важнее: масштаб, сроки или
затраты? Перечисленные три переменные взаимосвязаны, и важно
понять, какой из них следует отдавать предпочтение, если на этапе
планирования придется принимать компромиссное решение.
Таблица 2.16
Общая форма чартера --- ресурсы
Название
Приоритеты проекта
Описание
Определить порядок важности таких показателей, как
масштаб работы, сроки и расходы на проект
Эти три переменные известны как тройное ограничение (рис. 2.1).
Увеличение или сокращение одной из этих величин отражается на двух
других. Например, если включить в процесс обработки заказов допол-
нительные функции, такие как возможность автоматической сорти-
ровки, то нам придется увеличить сроки и бюджет. Уменьшить срок
выполнения проекта можно, если приложить больше усилий и/или
увеличить бюджет или сократить масштабы проекта.
Для того чтобы команда сделала правильный выбор между этими
тремя переменными, она должна знать, каковы приоритеты спонсора
проекта. Возможно, важнее всего сроки, на втором месте масштаб проек-
та и лишь потом идут издержки? Или главное --- это цели (убедитесь,
что заказчик проекта с этим согласен), затем издержки и в последнюю
очередь сроки? Один из надежнейших способов определить приоритет-
ность этих величин --- спросить спонсора проекта: «Если бы у вас был
выбор: превзойти ожидания заказчиков, осуществить проект в макси-
мально сжатые сроки или затратить на проект меньше денег, чем это
предусмотрено бюджетом, что бы вы предпочли? Что бы поставили по
значимости на второе место, а что --- на последнее?»
Масштаб
Рис. 2.1. Тройное ограничение

46
Глава 2. Начало проекта
Пронумеруйте переменные от 1 до 3 в порядке убывания важности.
ЕСЛИ одна из переменных намного важнее остальных, отметьте ее звез-
дочкой. Объясните причины именно такой расстановки приоритетов.
В нашем примере приоритеты расставлены в следующем порядке: сроки,
масштаб, издержки. Это означает, что, работая над проектом, в первую
очередь надо стремиться завершить его как можно скорее. На втором
месте по значимости идет масштаб проекта, а на третьем --- издержки.
Раздел «Ресурсы» для нашего примера
Давайте рассмотрим раздел «Ресурсы» на примере чартера нашего
проекта по выполнению заказов (табл. 2.17).
Таблица 2.17
Раздел «Ресурсы» для чартера по выполнению заказов
Название
Формирование команды
Крайний срок
Ограничения на внутренние
трудозатраты
Ограничения на расходы
Организационные ограничения
Приоритеты проекта
Описание
Кэролин, лидер проекта
31 декабря
Не более 25% от общего рабочего времени для
членов команды проекта; не более 50% общего
рабочего времени для лидера проекта. (Члены
проектной команды должны успевать выпол-
нять свои обычные рабочие обязанности)
$25 000
Использовать только имеющиеся технические
средства и компьютерное оборудование
Сроки (контракт с подрядчиками истекает
31 декабря)
Масштаб
Издержки
Чартер является основой всего проекта в целом, это первый этап, на
котором определяется, что именно потребуется для проекта. По этой
причине, возможно, составление чартера --- это одна из самых трудных
задач в управлении проектом. Если вам придется писать чартер вме-
сто спонсора, попросите его добавить кое что от себя, а также обяза-
тельно включите личное мнение заказчика проекта.
Утверждение чартера
Просмотрите черновик чартера вместе со спонсором проекта. Проверь-
те раздел описания масштаба проекта вместе с заказчиком, чтобы удо-

Глава 2. Начало проекта
47
стовериться, что последний согласен с вашим представлением о том,
что должно быть получено в результате. Также следует согласовать с за-
казчиком крайний срок окончания проекта и, в случае, если заказчик
оплачивает проект, обсудить с ним вопросы ограничения внутренних
трудозатрат и денежных расходов. Теперь заказчик должен расписаться.
Если заказчик потребует внесения изменений в чартер, то обсудите
этот вопрос со спонсором. Когда и вы и спонсор будете удовлетворены
данным документом, вы оба должны его подписать. Если возможно,
попросите, чтобы заказчик также завизировал чартер.
После утверждения чартера начинается следующий этап --- этап
планирования. Утвержденный чартер служит прочным фундаментом
для последующего процесса планирования. Нередко случается так, что
команды спешно начинают что то планировать, а потом узнают, что
они потратили несколько дней или даже недель, двигаясь в неправиль-
ном направлении. Не допускайте, чтобы подобное произошло с вами.
Уделите еще немного времени тому, чтобы удостовериться, что чартер
составлен правильно, --- это убережет вас от неприятностей в будущем.
Перед тем как начать планирование, необходимо подготовить так
называемый список проблем и усвоенных уроков.
Список проблем
Первый инструмент планирования, который вам следует подготовить, ---
это список проблем. В нем вы будете фиксировать все разногласия
и вопросы, требующие разрешения. Также туда следует заносить лю-
бые задачи, которые нужно выполнить, но не стоит включать в распи-
сание проект, который вы составите позднее во время планирования.
(В дальнейшем мы будем говорить о подобных действиях и вопросах
как о проблемах.) Список проблем подготавливается и ведется лидером
проекта (рис. 2.2).
В первой колонке указывается номер проблемы. Каждой проблеме
нужно присвоить отдельный порядковый номер. Если вы работаете
с программой табличных вычислений, то можно использовать функ-
цию автоматической нумерации строк.
В следующей колонке кратко опишите проблему или действие, ко-
торое нужно выполнить. Что конкретно вызывает затруднения?
Затем опишите, кому конкретно нужно устранение этой проблемы?
Чья это проблема? Далее укажите имя члена проектной команды,
который будет отвечать за решение данной проблемы. Ему не обяза-
тельно бороться с проблемой в одиночку, но так или иначе он обязан

48
Глава 2. Начало проекта
СПИСОК ПРОБЛЕМ
Название проекта
Спонсор проекта
No
проб-
лемы
1
2
3
4
5
6
7
Описание
проблемы
У кого
возникла
проблема
Ответственный
за решение
проблемы
Крайняя;
дата
проблемы
Дата
проблемы
Как была
решена
проблема?
Рис. 2.2. Список проблем
с ней справиться. (Поскольку мы можем распоряжаться лишь члена-
ми команды, то за решение проблемы должен отвечать кто то из них.)
Теперь --- когда должна быть решена эта проблема? Установите дату.
Последние две колонки заполняются после того, как проблема бу-
дет решена.
Как правильно работать со списком проблем
Список проблем ведется лидером проекта и обновляется на каждом
собрании членов проектной команды. Он не заменяет графика выпол-
нения проекта. Список используется в фазе планирования, еще до того,
как составлен график, чтобы не упустить ни одной планировочной за-
дачи, которую необходимо выполнить. Кроме того, он необходим в про-
цессе воплощения проекта для того, чтобы отмечать проблемы, кото-
рые не настолько значительны, чтобы вносить их в график проекта.
Его не следует использовать для того, чтобы наметить результаты, ко-
торые необходимо получить при работе над проектом, или задания,
которые требуется для этого выполнить --- действия, направленные
непосредственно на создание конечного продукта. Для этого существу-
ет график.

Глава 2. Начало проекта
49
Контролирование списка проблем
Список проблем должен проверяться и корректироваться на каждом
собрании команды, работающей над проектом. Обсудите текущие про-
блемы вместе с командой, узнайте у членов команды о том, как про-
двигается решение проблем, возникших ранее. Удалось ли с ними спра-
виться? Если да, то как? Когда? Если нет, то что необходимо для того,
чтобы их решить, и когда это будет сделано? В идеале руководитель
должен быть сразу же уведомлен, если человек, ответственный за ре-
шение проблемы, не в состоянии с ней справиться или нуждается в по-
мощи, чтобы решить данную проблему в срок. В этом случае руково-
дитель проекта сможет принять меры до того, как решение проблемы
будет просрочено. Если команда не может справиться с проблемой
своими силами, заручитесь поддержкой спонсора проекта.
Перед тем как завершить собрание проектной команды, еще раз оста-
новитесь на тех проблемах, которые необходимо решить к следующему
собранию, чтобы каждому стало ясно, какие вопросы вы планируете
закрыть.
Список усвоенных уроков
Помимо списка проблем вам понадобится список усвоенных уроков,
который поможет зафиксировать все, что вы узнаете в ходе выполне-
ния проекта. Вы еще вернетесь к этому списку, подводя итоги на за-
вершающем этапе, однако, заполняя список по ходу выполнения про-
екта, вы не упустите из виду и не забудете важные уроки, полученные
во время работы над проектом.
Примерный список усвоенных уроков приведен на рис. 2.3.
СПИСОК УСВОЕННЫХ УРОКОВ
Название проекта
Спонсор проекта
No
урока
1
2
3
4
Описание инцидента
Дата инцидента
Описание усвоенного
урока
Рис. 2.3. Список усвоенных уроков

50
Глава 2. Начало проекта
Формирование проектной команды
У вас уже есть чартер проекта, и вы подготовили списки проблем и
усвоенных уроков; настало время собрать первоначальную команду.
Первоначальной она называется потому, что до тех пор, пока не закон-
чится планирование, вы не можете быть полностью уверены в том, что
именно эти члены команды понадобятся вам для работы над проек-
том. Сейчас вы должны создать первоначальную команду, которая зай-
мется планированием, и будем надеяться, в том же составе приступит
к воплощению проекта. Выделите время для того, чтобы заранее обду-
мать, кого вам необходимо будет включить в команду, потому что в про-
цессе работы над проектом состав команды лучше не менять.
Даже если спонсор проекта уже подобрал для вас первоначальную
команду, стоит провести анализ и выяснить, существуют ли очевид-
ные «дыры», от которых необходимо избавиться перед тем, как при-
ступать к планированию.
Для начала вам нужно оценить, какой проект вы выполняете: круп-
ный или мелкий, поскольку состав команды во многом зависит от раз-
маха проекта (табл. 2.18).
Таблица 2.18
Сравнение крупного и мелкого проектов
Объем проекта
Мелкий проект
Крупный проект
Описание
Для выполнения проекта достаточно десяти или менее
членов команды
Для выполнения проекта требуется более десяти членов
команды
Мелкие проекты
Мелкий проект --- это проект, для выполнения которого требуется не
более десяти человек. Другими словами, проект может быть выполнен
относительно небольшой группой людей, и, следовательно, все люди,
задействованные в проекте, могут войти в основную команду. Для мел-
кого проекта главным критерием отбора членов команды являются их
навыки и знания, а также опыт работы, близкой к тому, чем придется
заниматься в ходе выполнения проекта.
Чтобы определить оптимальный состав проектной команды, составь-
те список основных ресурсов, которыми вы будете пользоваться для
создания конечного продукта вашего проекта. Затем поговорите с ме-
неджерами, отвечающими за каждый из этих ресурсов, и узнайте у них,

Глава 2. Начало проекта
51
какие виды навыков понадобятся для выполнения проекта. Менедже-
ры по ресурсам наверняка выделят вам людей с требуемыми навыка-
ми из числа тех, кто имеется в их распоряжении. Напротив, попытка
привлечь к работе конкретных лиц может вызвать недовольство. Как
правило, менеджеры по ресурсам охотнее идут навстречу, когда вы
просите найти для вас человека, обладающего теми или иными каче-
ствами.
Следующее, что вам необходимо сделать, --- это просмотреть список
дольщиков в чартере проекта. Проверьте, адекватно ли в вашей проект-
ной команде представлены интересы каждой из основных заинтересо-
ванных сторон. Проект касается каждого из них; а поскольку ход про-
екта им всем небезразличен, то каждый человек (или группа) хочет
иметь право голоса в вопросах, связанных с выполнением проекта.
Лучше всего вовлечь этих людей в работу с самого начала, поскольку:
их участие и идеи можно применять при работе над проектом;
они могут внести свой вклад в конечный результат проекта;
участвуя в проекте, они будут понимать, почему принимаются
именно такие решения, и участвовать в их реализации;
они будут оказывать поддержку, а не сопротивление.
Особенно важно включить этих людей в команду, если выполняе-
мый вами проект подразумевает внедрение. Многие проекты по внед-
рению терпят неудачу из за того, что люди, которых затрагивают из-
менения, не желают ничего менять. В нашем примере с процессом
выполнения заказов мы включили в команду Кена, ответственного за
данный бизнес процесс. Ведь именно ему придется руководить цент-
ром выполнения заказов, после того как мы разработаем и внедрим
процесс их обработки.
Крупные проекты
Если вы работаете над крупным проектом, который выполняют более
десяти членов проектной команды, то необходимо разбить основной
проект над подпроекты. Подпроект --- это подраздел основного проек-
та. Над каждым подпроектом крупного проекта работает отдельная
команда, за которой следит лидер подпроекта. Лидер подпроекта вы-
полняет ту же роль, что и лидер основного проекта, за исключением
того, что он управляет командой подпроекта, а не командой основного
проекта (рис. 2.4).
Причина разбиения основного проекта на подпроекты заключается
в том, что группа, в которой больше десяти человек, слишком велика,

52
Глава 2. Начало проекта
Рис. 2.4. Крупный проект с подпроектами
чтобы эффективно сотрудничать с ней. Лучше разбить эту команду на
подгруппы такого размера, чтобы каждая из них была легкоуправляема.
В крупном проекте головная команда состоит из лидеров подпроек-
тов. Под их началом находятся команды подпроектов (если им нужна
помощь для выполнения работы), состоящая из тех, кто непосредствен-
но выполняют работу и создают конечные продукты подпроектов (ЧК ---
члены команды). Результаты подпроектов позже будут объединены для
получения конечного продукта главного проекта. Одна из обязанно-
стей лидера подпроекта заключается в том, чтобы результаты его под
проекта соответствовали требованиям основного проекта.

Глава 2. Начало проекта
53
Поэтому в крупном проекте команда основного проекта состоит из
лидеров подпроектов, которые являются представителями основных
дольщиков (обычно по каждой группе ресурсов). Проанализируйте
различные категории дольщиков, чтобы определить, кто именно дол-
жен войти в вашу команду.
Чтобы правильно выбрать лидеров подпроектов, воспользуйтесь
следующими указаниями:
лидеры подпроектов должны обладать теми же навыками, что и ли-
дер проекта. Часто это будущие лидеры проектов, проходящие
подготовку;
они должны уметь принимать решения в своей области ресурсов;
они должны быть хорошими посредниками между вами и доль-
щиками --- представлять интересы своей группы дольщиков и в то
же время находить компромисс с целями проекта;
они должны уметь убеждать дольщиков в целесообразности дан-
ного проекта или каких то конкретных действий по этому проек-
ту. Их работа --- получить от группы дольщиков положительный
отзыв на решения, принятые проектной командой.
На уровне подпроекта создается промежуточный продукт проекта,
поэтому здесь необходимы рабочие навыки. Определить необходимые
навыки для своей команды могут лидеры подпроектов.
После того как первоначальная команда собрана, можно приступать
к работе над проектом.
Проверка содержания и процесса
Перед тем как двинуться дальше, полезно проверить то, что уже сде-
лано, чтобы удостовериться, что ничего не упущено.
Составили ли вы или спонсор черновой вариант чартера проекта,
включив в него все ожидания от данного проекта и ограничения
для него?
Принял ли заказчик участие в заполнении раздела о масштабе
проекта?
Подписали ли заказчик и спонсор проекта чартер после того, как
он был составлен?
Подготовили ли вы список проблем?
Подготовили ли вы список усвоенных уроков?
Собрали ли вы первоначальную команду для эффективной рабо-
ты по созданию плана проекта?

Глава 3
Лидерство в команде, работающей
над проектом
Важно помнить, что лидер проекта не должен выполнять весь проект
в одиночку. Реализация большинства проектов и получение конечного
продукта, нужного заказчику, требуют наличия разнообразных навы-
ков, опыта и специальной квалификации. Это означает, что для рабо-
ты над проектом требуется группа людей, каждый из которых привно-
сит в команду что то уникальное, а значит, выполнение задач каждого
участника зависит от остальных. Такой взаимозависимости участни-
ков группы можно добиться, только превратив их в единую команду.
Именно благодаря взаимодействию членов команды сырые материа-
лы (информация, идеи и знания) сводятся воедино и преобразовыва-
ются в конечный продукт, отвечающий целям проекта.
Команду можно считать сформированной только тогда, когда люди
начнут работать вместе, функционируя как единое целое. Добиться
этого вам помогут семь принципов формирования команды.
Принцип 1
Когда люди участвуют в создании чего либо, результаты работы ста-
новятся их личным достижением. Когда мы вкладываем наши время,
энергию и душу в какой то процесс, он приобретает для нас статус «на-
шего». Мы чувствуем себя его владельцами. Мы принимаем на себя
ответственность за него. Мэг Уитли {Meg Wheatley) в своей книге
«Управление и новая наука: как найти порядок в мире хаоса» (изда-
тельство Berrett Koehler, 2001) отметила: «В той области, где я рабо-
таю, --- области организационного поведения --- есть проверенный,
надежный принцип: люди всегда поддерживают и защищают то, что
создают сами».
За чувством собственности приходит чувство самостоятельности.
Оно сильно отличается от тех чувств, которые возникают, если вы ра-

Глава 3. Лидерство в команде, работающей над проектом
55
ботаете по чужому приказу или распоряжению. Самостоятельность ---
это мотивирующее чувство; простое получение указаний --- нет.
Когда члены проектной команды работают совместно, создавая план
проекта, а затем контролируя его выполнение, то их чувство собствен-
ности распространяется не только на личную работу, но и на весь проект
в целом. Тем самым снимается груз ответственности с лидера проекта
и он разделяет ответственность с членами своей команды. Когда ко-
манда «владеет» проектом, у участников возникает чувство общности.
Члены команды «идут ко дну» или «выплывают» вместе. Этот прин-
цип лежит в основе создания настоящей команды.
Принцип 2
Члены команды, которые понимают суть проекта, активнее стара-
ются добиться его успешного выполнения. Понять --- значит уяснить
смысл того, что требуется лично от тебя, и то, как твоя работа впишет-
ся в единое целое. Понимание подразумевает, что человек настолько
хорошо овладел информацией и знаниями, что они стали частью его
мировоззрения.
Когда члены команды понимают проект --- почему он создан, чего
конкретно от них ожидают, как их работа отразится на других и как
она вписывается в общую картину, --- они работают более эффективно
и сами по себе, и вместе. Они также более мотивированы, так как по-
нимание затрагивает не только мысли, но и сердца людей.
И напротив, если сотрудник понимает лишь свою небольшую часть
проекта, то он будет действовать так, как лучше для него лично, а не
для проекта в целом, и может непредумышленно вызвать проблемы
у других членов команды. Представьте, например, что вы входите в орг-
комитет праздничного мероприятия, посвященного тому, что ваша
компания успешно выпустила на рынок новый продукт. Вы отвечаете
за угощение, и, на ваш взгляд, проще всего будет закупить продукты,
уже разделенные на порции. Однако те, кто отвечают за уборку, не
знают о том, что вы запланировали не фуршет, а расфасованную еду.
В результате мусорных баков окажется недостаточно и помещение после
банкета будет выглядеть не самым приятным образом.
Когда каждый понимает весь проект в целом, то недоразумения меж-
ду членами проектной команды сводятся к минимуму. Понимания
проще всего достичь, вовлекая всю команду в процесс управления,
благодаря чему возникают чувство собственности и понимание, а ко-
манда становится сплоченной. Процесс вовлечения команды в совме-

56
Глава 3. Лидерство в команде, работающей над проектом
стную работу и процесс формирования команды --- далеко не одно и то
же. Формирование команды --- это деятельность, направленная на то,
чтобы помочь людям лучше понять друг друга и больше доверять окру-
жающим. Обычно она не имеет ничего общего с осознанием того, ка-
кую работу нужно будет выполнить в ходе проекта. В результате, когда
формирование команды уже закончено и люди возвращаются к вы-
полнению своих задач, снова всплывают те же самые противоречия и
возникают те же конфликты. Отказавшись от совместной работы ко-
манды и ограничившись ее формированием, вы совершите большую
ошибку. Оттеснив команду от деятельности по управлению проектом,
вы лишите ее возможности действовать эффективно и сильно ограни-
чите понимание и чувство собственности членов команды. Стремитесь
не к искусственному формированию команды, а к вовлечению ее в ре-
альный процесс принятия решений, связанных с реализацией проекта!
Если совместное принятие решений настолько эффективно, то по-
чему же люди так часто от него отказываются? Для начала они ссыла-
ются на то, что у них нет времени заниматься этим. Они утверждают, ---
быстрее и проще предоставить лидеру проекта самому решать, что
нужно сделать, а затем делегировать задания членам проектной коман-
ды. Совместная работа команды отнимает больше времени на этапе
планирования, но этот этап не является самым длинным и не требует
наибольшего расхода ресурсов. Таким этапом является реализация про-
екта, и если в команде отсутствует взаимодействие на этапе планиро-
вания, то реализация потребует гораздо больше времени.
Против участия команды в принятии решений выступают те, кто
считают, что лидер в этом случае потеряет контроль над проектом.
У лидера проекта возникнут опасения, что команда примет неверное
решение, а ему придется за это отвечать. Действительно, за результат
несет ответственность лидер, однако достичь лучшего результата по-
зволяет как раз совместная работа команды. Вновь и вновь подтверж-
дается тот факт, что группа людей принимает более верные решения,
нежели отдельный человек. Большинство проектов слишком сложны
для того, чтобы их лидеры смогли понять все технические аспекты
проекта. Попытки же лидера вникнуть во все тонкости, в то время как
у него в команде есть эксперты по каждому из специальных вопросов,
являются пустой тратой времени. Почему бы не задействовать специ-
алистов, позволив им участвовать в процессе управления проектом?
Лидеры боятся потерять контроль над проектом, но ведь он никуда
не девается, просто теперь контролируется не содержание проекта,
а сам процесс. Лидер обеспечивает команду необходимыми инструмен-

Глава 3. Лидерство в команде, работающей над проектом
57
тами и техникой, чтобы помочь ей принять верные решения. Таким
образом, лидер проекта гарантирует достижение прекрасных резуль-
татов. Широко распространено мнение: если вы делаете что то сами,
значит, вы и контролируете это. Но человек, который принимает ре-
шения и составляет план проекта в одиночку, обычно добивается не
самых лучших результатов. Быстрее и надежнее привлечь членов ко-
манды, чтобы они помогли вам в разработке плана, нежели пытаться
составить его самостоятельно, а затем представить команде для вы-
полнения уже в готовом виде. План, созданный лидером проекта без
притока свежих идей, неизбежно даст трещину и вряд ли будет выпол-
няться так, как задумывалось. Будет намного лучше, если вы откаже-
тесь от контроля над процессом планирования и мониторинга решений.
Вместо этого позаботьтесь о том, чтобы в вашей команде сложилась
атмосфера, благоприятная для выработки оптимальных совместных
решений. Вы можете оставить за собой право принимать некоторые
решения. Это ваша прерогатива как лидера проекта. Но пользоваться
таким правом следует только тогда, когда это действительно необхо-
димо для того, чтобы сделать проект или работу команды более эф-
фективными.
Принцип 3
Люди вдохновляются тем, что значимо для них. Наше основное жела-
ние --- найти смысл собственной жизни или сделать ее значимой. Мы
хотим заниматься тем, что позволит нам удовлетворить эту потреб-
ность. Проект должен быть значимым для тех людей, которые над ним
работают.
Чтобы сделать проект значимым для команды, вам необходимо свя-
зать его со стратегическими целями организации. Члены команды долж-
ны осознавать, что руководство поддерживает проект и что его резуль-
таты важны для организации.
Люди хотят думать, что деятельность каждого отдельно взятого чле-
на команды важна для проекта в целом. Несмотря на тот факт, что
людям будут платить вне зависимости от того, важна эта работа или
нет, они не желают напрасно тратить свое время на напряженный труд,
который никому не нужен. Они предпочитают заниматься работой,
которая что то меняет в целом.
Вы можете заставить людей ощутить эту значимость, если предо-
ставите им возможность участвовать в процессе управления проектом:
определять конечный продукт, распределять ответственность, устанав-

58
Глава 3. Лидерство в команде, работающей над проектом
ливать взаимозависимость различных конечных продуктов и т. д. Чем
лучше люди понимают суть проекта, тем большую значимость он для
них приобретает, если, конечно, этот проект важен для самой органи-
зации. Если же проект никому не нужен, то проблемы вам обеспечены,
поскольку мало кого можно заинтересовать работой, которая в конце
концов не будет иметь никакого значения. Если вам достался чей то
«замечательный» проект, до которого на самом деле никому нет дела,
и бизнесу этот проект никоим образом не поможет, то все ваши попыт-
ки создать команду заранее обречены на провал. Большинство людей
невозможно побудить к работе, если она бесполезна.
Принцип 4
Для планирования, контроля, генерирования идей, принятия решений
и разрешения конфликтов используйте приемы работы, которые по-
зволят членам команды принимать верные решения и быстро дости-
гать общего согласия.
Методы, основанные на приемах командной работы, позволяют всей
команде непосредственно участвовать в происходящем, будь то пла-
нирование, принятие решений, генерирование идей или разрешение
конфликтов. Эти методы предоставляют каждому члену команды воз-
можность вносить свой вклад в проект и вырабатывать решение об-
щими усилиями (достигать консенсуса). Консенсус не означает, что
будет выбрано именно то решение, которое выбрал бы каждый из чле-
нов команды. На практике оно означает лишь то, что все члены коман-
ды приходят к выводу, что выбранный вариант вполне приемлем. При
этом далеко не каждый участник непременно согласен с итоговым ре-
шением.
Узнать, достигли ли вы консенсуса, достаточно просто. Обойдите
комнату и спросите каждого, согласен ли он с принятым решением.
Если кто то ответит, что нет, спросите его, что нужно сделать для того,
чтобы он смог согласиться с таким решением. Посмотрите, можно ли
достичь компромисса и все ли согласятся на исправление? Иногда кон-
сенсус недостижим. Иногда какое то решение приходится навязывать
и даже диктовать. Стоит сохранить за собой такое право, если прийти
к единому мнению не удастся.
Использование методов совместной работы команды поможет груп-
пе достичь консенсуса с минимальными конфликтами. Приемы управ-
ления проектами, которые вам предстоит изучить, --- это приемы рабо-
ты в команде. Они:

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

60
Глава 3. Лидерство в команде, работающей над проектом
команды. Используя все эти приемы, можно гарантировать, что каж-
дый член вашей команды будет вовлечен в процесс и воспримет пред-
ставленную информацию. Методы принятия решений мы обсудим
более подробно в гл. 11.
Принцип 5
Демонстрируйте вашу признательность каждому члену команды за его
вклад в работу, а также признательность всей команде в целом. Когда
люди знают, что их ценят, они трудятся более продуктивно. Если вся
команда чувствует одобрение, она работает эффективнее. Способа
выразить свою признательность, общего для всех членов команды, нет.
Однако существуют стандартные способы, для того, чтобы показать
людям и команде, что ими дорожат и их ценят:
признавать достижения;
благодарить людей за работу, которую они выполняют;
праздновать успехи;
уважать вклад в работу и личное мнение каждого члена команды;
отстаивать интересы команды;
быть честным.
Вам необходимо на каждом собрании выделять несколько минут на то,
чтобы отдать должное достигнутым успехам и поблагодарить людей
за сделанный ими вклад. Помимо этого, достигнув какой либо значи-
тельной цели, нужно найти время и устроить по этому поводу неболь-
шой праздник. Не обязательно организовывать грандиозное торже-
ство --- достаточно чаепития с пирожными на очередном собрании или
ужина в пиццерии. Желательно по возможности предусмотреть неболь-
шую денежную сумму в бюджете проекта, чтобы позволить себе от-
праздновать очередной успех, пусть и не очень пышно.
Кроме вашего одобрения и маленьких праздников команде необхо-
дима уверенность в том, что вы на ее стороне и что если члены коман-
ды возьмут на себя какой то риск, то вы окажете им поддержку. Вы ---
это щит, который стоит между ними и окружающим миром, и именно
вы обеспечиваете им возможность спокойно работать над проектом.
Принцип 6
Чтобы организовать настоящую команду, вы должны создать и под-
держивать в ней атмосферу взаимного доверия и уважения.

Глава 3. Лидерство в команде, работающей над проектом
61_
Чтобы возникло доверие, требуется время. Для создания доверитель-
ной атмосферы используйте следующие подсказки:
уважайте различные точки зрения, различные способы восприя-
тия информации и прочие индивидуальные особенности;
не давайте обещаний, которых не сможете выполнить;
держите свое слово;
поддерживайте в людях уверенность;
цените личный вклад и идеи каждого человека;
будьте честны;
используйте ценные умения и навыки членов команды;
используйте ценные навыки тех, кто желает помочь;
избегайте в работе упреков и обвинений.
Хотя доверие появляется очень медленно, разрушить его можно
в считанные секунды, а на восстановление его потребуется довольно
долгий срок. Поэтому отведите время на то, чтобы развивать и под-
держивать доверительные отношения между вами и командой, а так-
же между членами команды. Если вы совершите что либо, что уронит
ваш авторитет в глазах команды, открыто признайте свои ошибки,
исправьте их и попросите прощения. Это поможет вам восстановить
доверие к себе. Если вы открыты и честны, люди закроют глаза на неко-
торые ваши недостатки. Если же вы делаете вид, что вы --- само совер-
шенство, вам не простят ни одной оплошности.
Принцип 7
Делегируйте полномочия своей команде. Команды, имеющие опреде-
ленные полномочия, более эффективны, нежели те, которые такими
полномочиями не обладают. Уполномоченная команда --- это команда,
в которой процесс принятия решений и ответственность за них про-
стираются до самого нижнего уровня рабочей иерархии. Когда у ко-
манды есть определенные полномочия, ее члены в большей степени
отвечают за результаты своей работы. Помимо этого, делегирование
полномочий позволяет лидеру переложить часть груза ответственности
за выполнение проекта на плечи команды. Чтобы делегировать полно-
мочия должным образом, вам необходимо соблюдать следующие пра-
вила:
четко обозначьте функции всех людей, задействованных в проек-
те, и следите за их выполнением;

62
Глава 3. Лидерство в команде, работающей над проектом
четко определите, что конкретно требуется от команды и от каж-
дого участника;
предоставьте людям соответствующие ресурсы для выполнения
работы. Одна из обязанностей лидера проекта состоит в том, что-
бы, заручившись помощью спонсора проекта, предоставлять ко-
манде все необходимые ресурсы. Если после того, как команда
составит план, ресурсов окажется недостаточно для достижения
намеченного и качественного результата, лидер проекта должен
обсудить этот вопрос со спонсором проекта и либо получить
большее количество ресурсов, либо уменьшить масштаб проекта.
Мы вообще не можем говорить ни о каких мотивации или деле-
гировании полномочий, если вы пытаетесь выполнить работу, не
имея в наличии необходимых для этого времени, средств или обе-
щанных для выполнения проекта ресурсов;
убедитесь, что члены команды обладают необходимыми для выпол-
нения работы знаниями и способностями. Убедитесь в том, что
ваша команда владеет всеми навыками, необходимыми для успеш-
ной работы над проектом, а также опытом командной работы;
четко определите ответственность за результаты. Делегирова-
ние полномочий работникам требует от них ответственности за
результаты, которые в конечном итоге вы будете докладывать
руководству. Согласно нашему методу CORE PMTM, каждому
результату, каждому заданию и каждому продукту должны соот-
ветствовать определенные ответственность и подотчетность, воз-
ложенные на конкретного сотрудника. Более того, механизм об-
ратной связи позволяет лидеру и команде узнать, насколько
качественно каждый из сотрудников выполняет свое задание;
сделайте так, чтобы процесс принятия решений осуществлялся
на возможно более низком уровне рабочей иерархии. Не хотите
же вы вдаваться в мельчайшие подробности работы команды или
отдельных ее членов. Главной заботой на уровне всей команды
должны быть те результаты и продукты, которые связаны с боль-
шинством участников команды. Слишком многие команды вни-
кают в детали того, чем занимается каждый отдельный работник.
Если четко определить обязанности и ответственность, а также
удостовериться, что люди обладают необходимыми навыками
и получают нужную поддержку, то уделять внимание вопросам,
которые конкретный работник может решить самостоятельно, не
понадобится.

Глава 3. Лидерство в команде, работающей над проектом
63
Большинство лидеров проектов обучены и подготовлены к тому, что-
бы заниматься непосредственно содержательной частью проекта. Они
принимают решения. Они знают, что приведет данный проект к успеху.
Они решают проблемы, возникающие в ходе выполнения проекта. Но
если вы полностью сосредоточитесь на содержании, это не принесет
впечатляющих результатов.
Для того чтобы устранить необходимость контроля и делегировать
команде полномочия, вам нужно помочь ей определиться с тем, что
именно она должна сделать, когда, кто и за что несет ответственность.
Кроме того, вы должны убедиться, что персонал обладает всеми навы-
ками и ресурсами, необходимыми для работы. Необходимо добиться
от команды регулярных отчетов о достигнутых результатах или о вы-
полнении порученных ей задач. На этом круг замыкается: задания
и обязанности распределяются, а затем ответственный исполнитель
отчитывается за их выполнение.
Эти семь основных принципов помогут вам создать более эффек-
тивную команду. Однако даже полностью сформированная команда
не сразу становится командой, выполняющей свою работу на пике воз-
можностей. Она развивается, минуя несколько стадий (рис. 3.1).
Первые четыре стадии были определены Брюсом Такманом (Вruce
Tuckman).
Стадия формирования
Первая стадия называется стадией формирования. Она начинается
с того момента, когда команда впервые собирается вместе. На этой ста
Рис. 3.1. Стадии развития команды

64
Глава 3. Лидерство в команде, работающей над проектом
дии развития команды ее члены сосредоточенно ищут ответы на сле-
дующие вопросы:
Зачем мы здесь?
Какова моя роль в этом проекте?
Кто эти люди и как мы сработаемся?
Что представляет собой лидер проекта и как он будет вести этот
проект?
На стадии формирования участники команды вежливы. Им инте-
ресно, что же будет дальше. В этот период вы будете постоянно слы-
шать вопросы: «Почему?», «Что?», «Кто?», «Когда?» Эта стадия нач-
нется сразу же, как только вы заговорите о проекте, и закончится, когда
люди забудут о вежливости и начнут возникать конфликты.
На стадии формирования важно руководить командой осторожно,
поскольку эта стадия быстро переходит в следующую --- стадию воз-
мущения. В гл. 4 мы обсудим, как преподнести проект таким образом,
чтобы сразу взять верный тон и поскорее проскочить первую стадию
развития команды.
Если стадия формирования успешно завершена, то команда есте-
ственным образом вступает в следующую стадию --- возмущение.
Стадия возмущения
Сразу после того, как проект запущен, а люди начинают общаться друг
с другом более раскованно и приступают к реализации конкретных
рабочих задач, видимое спокойствие команды нарушает стадия воз-
мущения. Разногласия возникают и по поводу того, что нужно делать,
и относительно того, кто это будет делать. Команда может разделить-
ся на противоборствующие группы. Если вы услышите фразы: «Я не
могу» и «Это невозможно», то знайте, что команда находится в стадии
возмущения. Чем более глобальными и труднодостижимыми окажут-
ся цели проекта, тем больше шума и криков будет на этой стадии. Од-
нако чем большей поддержкой со стороны руководства вы заручитесь
и чем большую значимость будет иметь проект, тем проще будет пре-
одолеть все разногласия. Цели проекта, важные для всех участников,
представляют один из наиболее существенных движущих факторов
разрешения конфликтов.
Как бы вы этого ни хотели, миновать данную стадию вам не удаст-
ся. К тому же конфликты и столкновения полезны, они помогают ко-
манде выработать понимание, правильную ориентацию и чувство соб

Глава 3. Лидерство в команде, работающей над проектом
65
ственности. Именно в это время участники приходят к единой точке
зрения на то, как вести работу по данному проекту, именно сейчас фор-
мируется групповое восприятие проекта.
Стадия возмущения, скорее всего, продлится большую часть про-
цесса планирования. Но конфликты по поводу того, что и как должно
быть сделано, полезны только до тех пор, пока они выходят на поверх-
ность и разрешаются. Используя методы командной работы (напри-
мер, описанные в данной книге), вы сможете быстро уладить конф-
ликты и создать атмосферу доверия и уважения. Вам также придется
решать проблемы, связанные с достижением общего согласия по по-
воду проекта. Пригласив работников принять участие в управлении
проектом на стадии возмущения, вы зарекомендуете себя наилучшим
образом; кроме того, вы поможете себе на следующей стадии развития
команды.
Стадия стабилизации
Как только команда устранит все разногласия, она переходит на сле-
дующую стадию развития, которая называется стадией стабилизации.
К этому моменту цели проекта, роли и масштабы уже определены
и одобрены членами команды. Вы поймете, что эта стадия наступила,
когда услышите: «Я могу...», «Я буду...»
Эта стадия нормальных рабочих отношений обычно наступает к кон-
цу планирования или на начальном этапе выполнения проекта в зави-
симости от его сложности и противоречивости и от того, как вы про-
явили себя на первых двух стадиях проекта. На данной стадии люди
просто выполняют свою работу; при этом и лидер проекта, и команда
чувствуют большое облегчение.
На стадии стабилизации вам необходимо проводить регулярные
рабочие собрания, чтобы члены команды могли оценить достигнутые
успехи и решить возникающие проблемы. При желании вы можете
также отточить свои навыки работы в команде с помощью:
проведения эффективных собраний;
применения активного слушания;
обеспечения конструктивной обратной связи;
разрешения конфликтов;
принятия командных решений.
Чем больше приемов командной работы вы используете, тем успеш-
нее будет ваша работа на данной стадии.
5 1815

66
Глава 3. Лидерство в команде, работающей над проектом
Если вы потрудились как следует на первых двух стадиях и продол-
жаете продуктивно работать, поощряя взаимодействие команды на
стадии стабилизации, то вы можете достичь следующей стадии разви-
тия команды, которая характеризуется наивысшим уровнем исполне-
ния проекта. Это --- стадия выполнения.
Стадия выполнения
Теперь команда становится настоящей командой, она работает слажен-
но и ее участники поддерживают друг друга. Управляет проектом не
лидер, а команда. Члены команды корректируют работу, придержива-
ясь намеченного ранее курса, отмечают успехи и вносят необходимые
изменения. Команда ощущает свою причастность к работе и ответ-
ственность не только за процесс, но и за отношения, складывающиеся
внутри команды. Ключевыми фразами становятся; "Мы можем...", «Мы
будем...» Когда вы услышите эти слова, то поймете, что команда до-
стигла наивысшего и самого успешного с точки зрения достижения
результатов уровня развития.
Но не слишком расслабляйтесь на этом этапе. Вам все еще нужно
уделять внимание и процессу управления проектом, и динамике раз-
вития отношений в команде. Но теперь это уже войдет у вас в привыч-
ку, станет вашей второй натурой. Не забывайте отдавать должное до-
стигнутым результатам и праздновать победы команды. Не каждая
команда достигает стадии выполнения. Практика показывает, что мно-
гие команды так навсегда и остаются на стадии возмущения. Однако
если вы принадлежите к одной из команд, добившихся успеха, то вам
придется столкнуться еще с одной проблемой --- с расформированием
команды на стадии расставания.
Стадия расставания
Люди не хотят покидать высокоэффективную команду, они в прекрас-
ных отношениях друг с другом, им нравятся результаты, которых они
достигли. Они получили удовольствие от того, что были членами од-
ной команды и сделали нечто большее, чем простое выполнение пер-
сональных обязанностей. Для многих это необычный опыт, и им не
хочется уходить. Однако все проекты неизбежно подходят к концу.
И команда должна пройти через печальную стадию расставания.
К торжеству победы примешивается грусть о том, что все закончи-
лось. Радости маленьких побед должны стать основой совместной ра-

Глава 3. Лидерство в команде, работающей над проектом
67
боты команды, иначе вы вряд ли вообще достигнете этой последней
стадии. Пришло время отпраздновать окончательный результат и под-
вести итоги работы команды. Кроме того, наступает пора завершения
работы --- надо попрощаться с друзьями и коллегами. Ритуал закры-
тия проекта поможет вам поставить точку.
Стадии развития и совместная работа
Надеемся, что к этому моменту вы уже поняли: команды проектов,
управление которыми строится на приказаниях и распоряжениях, не
способны пройти через все этапы развития. Как правило, проекты,
управление которыми опирается на директивный стиль, застревают на
этапе формирования команды. Если лидер проекта склонен к раздра-
жению, то отношения могут перейти к возмущению и даже достичь
стадии стабилизации, но на этом все и закончится. При подобном управ-
лении проектом невозможно создать высокоэффективную команду,
и когда проект подойдет к концу, никто не огорчится.
При директивном подходе просто трудно сформировать команду.
Взаимодействие в основном происходит между лидером проекта и каж-
дым из его членов. Вследствие этого у членов команды почти не оста-
ется возможностей для того, чтобы сплотиться в единый коллектив.
Высокоэффективные команды
Создание высокоэффективной команды не просто приводит к более
высокому уровню выполнения работы; участники получают удоволь-
ствие, работая в дружной команде, которая упорно трудится и дости-
гает цели (табл. 3.1).
Если вы уже работаете с командой, найдите пару минут, чтобы оце-
нить, в какой степени она обладает свойствами высокоэффективной
команды. Оцените ее по шкале от 1 до 6, где 1 --- «мы никогда не делаем
этого», а 6 --- «мы делаем это всегда». Затем суммируйте результаты
и получите итоговую оценку. Наилучший результат равен 60 очкам.
Если вы набрали 60 очков из 60, то, возможно, вы в чем то покривили
душой! Теперь разделите итоговую сумму на 10 и получите среднее
значение. Если оно равно 4 и выше, то ваши дела идут просто прекрас-
но, хотя нет пределов совершенству. Но даже если ваше среднее зна-
чение ниже, то отчаиваться не стоит. Наши учебные материалы помо-
гут вам улучшить результат.
Создание высокоэффективной команды требует огромных усилий
со стороны лидера проекта, который управляет не только самим про
5*

68
Глава 3. Лидерство в команде, работающей над проектом
Таблица 3.1
Оценка высокоэффективной команды
1. Стремления членов команды соответствуют целям
проекта
2. Команда стремится обеспечить взаимодействие всех
участников
3. Члены команды участвуют в планировании и монито-
ринге/контроле
4. Решения принимаются в основном путем полного
консенсуса
5. Лидер проекта и члены команды считают план проекта
и его выполнение собственным достижением
6. Членам команды делегированы некоторые полномочия
7. Возникающие конфликты решаются общими усилиями
8. Члены команды уверены, что их поддерживают и при-
слушиваются к их мнению
9. Команда относится с уважением к различиям в стилях
мышления и прочим индивидуальным особенностям
10. Команда интересуется личными потребностями своих
членов
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
3
4
4
4
4
4
4
4
4
4
4
5
5
5
5
5
5
5
5
5
5
6
6
6
6
6
6
6
6
6
6
ИТОГОВАЯ СУММА (сложите все полученные вами результаты)
СРЕДНЕЕ ЗНАЧЕНИЕ (разделите итоговую сумму на 10)
ектом, но и процессами формирования и развития команды. Лидер
проекта должен облегчить выполнение проекта, помогая команде по-
следовательно проходить стадии развития. Мы приводим несколько
подсказок, которые помогут вам сделать ход проекта более ровным:
создавайте условия для равного участия в проекте всех членов
команды;
поддерживайте доверительную атмосферу;
признавайте вклад каждого члена команды;
используйте основные правила командной работы;
сосредоточьте свое внимание на команде и на управлении проек-
том, а не на его содержании;
уважайте каждого члена команды как личность;
решайте конфликты сразу после их возникновения;
следите, чтобы команда не сбивалась с намеченного пути, и по-
могайте ей следовать утвержденному плану.

Глава 3. Лидерство в команде, работающей над проектом
69
Навыки руководителя проекта
Умение облегчить ход проекта --- это лишь малая доля тех навыков,
которые необходимы лидеру проекта и лидерам групп, занятых под
проектами, если они хотят создать высокоэффективную команду. С по-
мощью табл. 3.2 вы сможете оценить свои навыки по шкале от 1 до 6,
где 1 --- «я практически не знаком с этой областью», а 6 --- «в этой обла-
сти я преуспеваю». Сложите результаты, и вы получите итоговую сум-
му. Разделите ее на 10 и получите среднее значение. Независимо от
того, сколько очков вы набрали, не прекращайте совершенствовать свое
мастерство управления проектами.
Тест для более полной оценки навыков лидера проектов вы найдете
в приложении А.
Таблица 3.2
Оценка навыков лидера проекта
1. Лидерство в команде на всех этапах процесса управле-
ния проектом
2. Лидерство в команде на всех этапах ее развития
3. Навыки устного общения, как личного, так и в группе,
навыки письменного общения
4. Навыки управления людьми, такие как установление
действенной обратной связи, решение конфликтов,
работа с индивидуальными стилями и личностями
5. Навыки посредника, облегчающего выполнение
проекта
6. Умение скоординировать работу команды с организа-
цией в целом и устранение препятствий, затрудня-
ющих работу команды
7. Способность понять критику и реакцию членов коман-
ды, признать вклад других людей
8. Навыки использования приемов командной работы,
таких как «мозговая атака», плакирование, совместное
принятие решений, управление проектом, решение
конфликтов и т. д.
9. Навыки продаж. Способность найти и заинтересовать
покупателя как внутри организации, так и вне ее
10. Навыки лидерства
12
2
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
3
4
4
4
5
5
5
5
5
5
5
5
5
5
 6
6
6
6
6
6
6
6
6
6
ИТОГОВАЯ СУММА (сложите все полученные вами результаты)
СРЕДНЕЕ ЗНАЧЕНИЕ (разделите итоговую сумму на 10)

Глава 4
Запуск проекта
Собрание --- это первый шаг, который команда делает, приступая к ра-
боте; он одновременно знаменует начало этапа планирования процес-
са управления проектом и начало стадии формирования команды.
Запуск проекта и работа команды
На стадии формирования команды ее члены задаются вопросами: «Како-
вы цели проекта? Кто будет им управлять? Кто еще примет участие в ра-
боте команды? Насколько приятно будет работать над проектом?» Ли-
дер проекта должен помочь членам команды ответить на эти вопросы.
Собрание, посвященное запуску проекта, задает тон всей дальней-
шей работе. Члены команды оценивают способности своего лидера. Как
он взаимодействует с командой? Какой стиль работы использует? Бу-
дет ли защищать проект? Каковы его сильные и слабые стороны? Ко-
манда оценивает и сам проект. Ясна ли его цель? Большое ли значение
он имеет для организации? А для членов команды? Выполним ли он?
Целесообразен ли? Трудно ли будет его выполнить? Приятно ли бу-
дет над ним работать?
Важно тщательно спланировать первое собрание, чтобы как этап
планирования проекта, так и стадия формирования команды были
пройдены с максимальным эффектом.
Подготовка к «пусковому» собранию
Помещение
Зарезервируйте большое помещение. Каждому участнику собрания
должно хватить места, чтобы удобно расположиться и иметь возмож-
ность перемещаться. Постарайтесь подобрать комнату с небольшим
количеством окон, поскольку это позволит уменьшить число факто-
ров, отвлекающих внимание. Большую площадь стен можно будет
эффективно использовать для работы.

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

72
Глава 4. Запуск проекта
записи идеи или вопроса/проблемы. Кроме того, понадобится скотч,
чтобы закрепить ватман на стене.
Примечание: данное руководство по организации собрания, посвя-
щенного запуску проекта, можно использовать и для любых других
видов собраний.
Доска объявлений
Прежде чем начать собрание, нужно подготовить доску объявлений.
Это просто лист ватмана, на котором сверху крупно написано «Доска
объявлений» (рис. 4.2).
Эту заготовку будем использовать на каждом собрании команды в
течение всего проекта. Все идеи, вопросы или проблемы, возникаю-
щие по ходу собрания, если на них нельзя дать быстрый ответ или если
они выходят за рамки обсуждаемой темы, записывайте на липких лист-
ках и прикрепляйте их к ватману. В конце собрания снимите все за-
метки, при этом:
отбракуйте те заметки, ответы на которые уже найдены и кото-
рые больше не представляют интереса;
поместите некоторые заметки в список проблем (который мы
вскоре рассмотрим подробнее) для будущего обсуждения;
поместите некоторые заметки в список усвоенных уроков (кото-
рый также будет рассмотрен более подробно);
Рис. 4.2. Доска объявлений

Глава 4. Запуск проекта
73
включите некоторые заметки в повестку дня следующего собра-
ния команды.
Доска объявлений необходима для любого процесса, в котором ак-
тивно участвуют все члены команды. Она помогает команде вести со-
брание по намеченному плану, не упуская при этом из виду предлага-
емых идей или обнаруженных проблем. Записывая и учитывая идеи
или проблемы, команда тем самым проявляет уважительное отноше-
ние к человеку, идея которого будет признана, оценена или хотя бы
рассмотрена. Это помогает создать атмосферу доверия и защищенно-
сти, сохранив при этом прежнее направление обсуждения.
Кого следует пригласить на собрание?
Очевидно, что на собрание, связанное с запуском проекта, необходи-
мо пригласить первоначальную команду исполнителей. Кроме того,
должен присутствовать спонсор, так как одним из основных пунктов
повестки дня такого собрания является обзор программы проекта.
Выступление спонсора, который ответит на возникающие у команды
вопросы или рассмотрит связанные с проектом проблемы, будет очень
кстати.
Если проект достаточно важен и имеет большой масштаб, то можно
пригласить и других членов правления компании, поддержка которых
имеет большое значение. Их присутствие на собрании подчеркнет, на-
сколько они заинтересованы в успехе проекта. Если вы расширите со-
став участников собрания, пригласив членов правления, то разбейте
собрание на две части: в первой части --- заседание по общим вопросам ---
принимают участие приглашенные представители руководства, а на вто-
рую часть --- на рабочее собрание --- остаются только члены команды
исполнителей и спонсор. Роль спонсора во второй части собрания сво-
дится к тому, чтобы ответить на вопросы, связанные с чартером.
Повестка собрания
Повестку дня необходимо составлять перед любым собранием, и собра-
ние по поводу запуска проекта не является исключением. Ниже приве-
дены вопросы, которые могут войти в повестку дня такого собрания.
Заседание по общим вопросам (в обсуждении участвуют члены
правления компании):
знакомство --- все участники собрания называют себя и сообща-
ют, какой отдел они представляют;

74
Глава 4. Запуск проекта
обзор чартера (программы проекта) --- описание каждого раздела
чартера и ответы на задаваемые по нему вопросы/поставленные
проблемы. Обзор должен быть достаточно общим, так как более
подробный разбор чартера проводится на рабочем заседании.
Рабочее заседание (из всей управленческой команды в этом засе-
дании участвует только спонсор проекта):
знакомство --- все члены команды более подробно рассказывают
о себе;
раскрепощающая игра --- этот этап полезно включить в повестку
собрания, так как желательно, чтобы члены проектной команды
сразу же начали общаться друг с другом;
детальный обзор чартера --- на этом этапе нужно снова разобрать
чартер и обсудить более подробно каждый его раздел. Возможно,
существуют вопросы и проблемы, которые члены команды не хо-
тели бы обсуждать на общем заседании;
создание командного договора. Командный договор --- это согла-
шение между членами команды о правилах, на которых будет ос-
новано самоуправление;
определение первоначальных вопросов и задач --- существуют ли
вопросы или задачи, требующие немедленного внимания;
составление графика будущих собраний по планированию --- со-
браний, которые будут организовываться в ходе выполнения ра-
боты по планированию проекта.
Теперь рассмотрим каждый пункт повестки дня более подробно.
Знакомство
Знакомство является очень важным этапом, так как оно помогает уча-
стникам больше узнать друг о друге. В начале общей части заседания
все участники должны назвать себя и отделы компании, которые они
представляют. На рабочем заседании нужно снова попросить всех чле-
нов собрания рассказать о себе. Они должны детально описать, чем
они занимаются, и вкратце --- каков их опыт работы. Это позволит опре-
делить, какую пользу каждый из них может принести во время обсуж-
дения проекта. Кроме того, это будет способствовать сплочению ко-
манды.
Если люди в группе уже знают друг друга, то знакомство все равно
не помешает. Вы можете спросить членов группы, почему, по их мне-
нию, они привлечены к участию в проекте. Предложите им рассказать

Глава 4. Запуск проекта
75
о себе что нибудь не очень личное. Вот несколько вопросов, которые
можно задать членам команды:
Какое место на Земле, где вы еще не бывали, вы бы обязательно
хотели посетить?
Какое из ваших хобби самое необычное?
Самая захватывающая вещь, сделанная вами?
Кем вы хотели стать в детстве?
Вопросы не должны быть сложными. Не смущайте никого, но начи-
найте растапливать лед в отношениях между членами команды.
Раскрепощающая игра
При формировании команды очень важно помочь людям почувство-
вать себя комфортно. Один из способов достичь этого --- включить в
программу стартового собрания раскрепощающую игру. Это может
быть любая игра, которая:
поощряет взаимодействие между участниками;
заставляет людей чувствовать себя комфортно;
выявляет те качества человека и/или группы, которые необходи-
мы для воплощения проекта;
интересна;
кратковременна.
В качестве примера очень эффективной раскрепощающей игры мож-
но использовать игру «Стили мышления» (Diversitygame). Помимо того
что благодаря этой игре тает лед между членами команды, она позво-
ляет определить стиль мышления каждого члена команды и всей про-
ектной команды в целом. (Эту игру, разработанную организацией Applied
Creativity, можно приобрести на нашем веб сайте www.projectresults.com.)
Из колоды карточек, соответствующих 64 различным стилям мышле-
ния, членов команды просят отобрать 3 карточки, которые бы отража-
ли сильные стороны их стиля мышления. Затем, изучив все ответы,
вы определите сильные и слабые стороны команды. Это отличный при-
мер раскрепощающей игры, так как она не только стимулирует актив-
ность участников, которые немедленно начинают общаться (они пере-
мещаются по комнате, чтобы обменяться друг с другом карточками),
но и выявляет ценную информацию о каждом члене команды и о ко-
манде в целом. Если для выполнения проекта требуются стили мыш-
ления, отсутствующие в коллективе, то лидер проекта может опреде-

76
Глава 4. Запуск проекта
лить это уже в начале проекта. Для получения более подробной инфор-
мации смотрите приложение В. Игра «Стили мышления» --- это толь-
ко один пример игры, удовлетворяющей всем приведенным выше кри-
териям и помогающей участникам на стадии формирования команды.
Обзор чартера
Важно, чтобы каждый член команды четко представлял ожидаемые
результаты проекта, изложенные в чартере. Нужно раздать копии чар-
тера как членам команды, так и приглашенным гостям. Пусть спонсор
проекта обсудит чартер с присутствующими представителями руко-
водства, чтобы выяснить, есть ли у них какие либо предложения или
пожелания. На собрании спонсор должен по возможности обнародо-
вать эти пожелания или сформулировать вопросы. Если сразу решить
все вопросы не удастся, то лидеру проекта надо включить их в список
вопросов, которые будут рассмотрены позднее.
Когда приглашенные покинут собрание, чартер проекта нужно еще
раз обсудить с членами команды. При этом:
полезно сделать увеличенную копию чартера и повесить ее на сте-
ну. Это поможет членам команды не отклоняться от темы обсуж-
дения;
по мере анализа проекта задавайте вопросы, обсуждайте возмож-
ные изменения и дополнения. Запишите все вопросы, проблемы,
идеи и исходные данные на липкие листки бумаги и прикрепите
их к чартеру или листу ватмана;
в то время как спонсор рассматривает очередную проблему или
вопрос, записывайте решение на новом листочке липкой бумаги
и прикрепляйте его к предыдущему. Если вы этого не сделаете,
то после того, как спонсор уйдет с собрания, решение не сможете
вспомнить ни вы, ни команда или выяснится, что вы понимаете
это решение по разному;
включите все вопросы, оставшиеся без ответов, в список проблем
и рассмотрите их на следующем собрании.
Наверняка часть заданных вам вопросов окажется связанной с тем,
насколько проект реалистичен и выполним. Ответы на такие вопросы,
как «Успеем ли мы все выполнить в срок?» или «Осуществим ли этот
проект с технической точки зрения?» должны быть получены в ходе
планирования, и пытаться ответить на них с ходу совсем не обязатель-
но. С другой стороны, существует вероятность того, что команда не

Глава 4. Запуск проекта
77
захочет продолжать обсуждение до тех пор, пока не получит ответы
в той или иной форме. Нужно объяснить участникам, что поскольку
эти вопросы жизненно важны, то и решаться они будут по мере разра-
ботки плана. Если по завершении планирования команда решит, что
удовлетворить ожидания, записанные в чартере, невозможно, то вам
придется ознакомить с их расчетами спонсора, который должен при-
нять решение о дальнейшей судьбе проекта. Планирование необходи-
мо для ответа на вопрос: «Можно ли выполнить то, что заявлено в чар-
тере проекта, в рамках существующих ограничений?» Следовательно,
ставить под сомнение выполнимость чартера на этапе ее обсуждения
не обязательно. Цель этого этапа --- определить, каковы требования к
проекту с точки зрения спонсора. Даже то, что кажется сначала нере-
альным, может оказаться возможным, когда команда более подробно
спланирует ход работ.
Командный договор
Проведя обзор чартера проекта, нужно составить командный договор ---
набор правил, которым согласится следовать каждый член команды.
Любой, кто уже работал в команде, имеет опыт решения тех или иных
проблем с сотрудниками --- например, когда член команды опаздывает
на собрания или приходит неподготовленным и т. д. Командный дого-
вор --- это инструмент, который поможет избежать подобных проблем,
вместо того чтобы ждать, когда они возникнут, и только затем реаги-
ровать на них. Этот договор представляет собой набор установок или
основных правил о том, как должны себя вести все члены команды.
Правила, к примеру, могут быть такими:
обсуждать рабочие вопросы только внутри команды;
дать каждому равные возможности для участия в работе команды;
уметь выслушать собеседника и применять это умение на прак-
тике;
принимать обоснованные решения, если это возможно;
перед тем как принять решение, выслушать всех членов команды;
перед тем как принять решение или дать ответ, стараться понять
интересы и желания всех заинтересованных сторон;
начинать и заканчивать собрания вовремя;
приходить на собрание подготовленными.
Существуют два метода для создания и приведения в исполнение
договора по основным правилам работы в команде.

78
Глава 4. Запуск проекта
Метод А
Один из способов подготовки командного договора состоит в том, что-
бы сначала составить примерный договор, а затем собрать всех членов
команды для обсуждения и внесения поправок в соответствии с их
пожеланиями и опытом работы. Образец такого командного договора
представлен в приложении В. Команду нужно разбить на несколько
подгрупп из 3 4 человек и поручить каждой из них работу над опре-
деленным разделом примерного договора. Лучше всего распечатать раз-
делы командного договора на прозрачных пленках для проектора, а за-
тем попросить группы записать изменения маркерами прямо на пленке.
Это даст остальным группам возможность поделиться своими сообра-
жениями о предложенных изменениях.
Метод Б
Другой подход к разработке командного договора заключается в сле-
дующем:
попросите членов команды описать все виды командных проб-
лем, с которыми они сталкивались при работе над предыдущими
проектами. Каждому члену команды нужно дать маркеры и бу-
магу для заметок, чтобы они могли фиксировать свои идеи;
после того как все идеи будут записаны, пусть участники прикре-
пят свои заметки к листу ватмана, висящему на стене;
попросите команду подойти к плакату на стене и рассортировать
проблемы, расположив похожие виды проблем рядом. Лучше все-
го, если команда выполнит эту операцию молча;
после того как все идеи упорядочены, группа должна определить
категорию для каждого набора идей. Название категории должно
выражать законченную мысль, например, «Эффективно прово-
дить собрания». (Этот процесс организации работы/«мозговой
атаки» называется построением диаграммы по сходству. В гл. 11
приведены общие рекомендации по построению таких диаграмм.)
После того как у каждой категории появится название, нужно раз-
бить команду на подгруппы по 3 4 человека и поручить каждой из
них одну или несколько категорий. Попросите их составить правила
на основе идей каждой категории и записать их на ватмане, чтобы с ни-
ми могли ознакомиться остальные члены команды.
Когда все подгруппы закончат работу над своими разделами команд-
ного договора, используя либо метод А, либо метод Б, попросите их
рассказать о предлагаемых ими изменениях всей команде. (Если ко

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

80
Глава 4. Запуск проекта
опыт управления проектами, для планирования потребуется мень-
ше времени, чем неквалифицированной команде;
количество исторических статистических данных, накопленных
при работе над предыдущими проектами, --- чем больше инфор-
мации сохранилось от предыдущих попыток планирования по-
добных проектов и получения фактических результатов, тем про-
ще будет составить план нового проекта.
Пример собрания, посвященного запуску проекта
Прежде чем перейти к этапу планирования, обратимся еще раз к со-
бранию, посвященному запуску проекта. Рассмотрим ситуацию, когда
на собрании взят не совсем правильный тон обсуждения проекта. Рон,
лидер проекта, выступает как председатель собрания по запуску про-
екта. Попытайтесь определить, что он делает неправильно.
«Я рад приветствовать вас на собрании, посвященном обсуждению
проекта, который мы запускаем в работу. Как вы уже знаете, этот про-
ект действительно имеет огромное значение для будущего роста дохо-
дов нашей компании, поэтому каждый из нас должен гордиться тем,
что является частью команды. Я надеюсь, что вы ответственно отнесе-
тесь к проекту. Так как мы все уже знакомы друг с другом, то не будем
тратить время на представление. Сейчас я раздам всем чартер, кото-
рый разработала Сара, спонсор проекта. Если у вас есть какие либо
вопросы, то задайте их мне, а я передам ваши вопросы ей».
В комнате наступает молчание, так как все начинают читать чартер.
Ларри ставит вопрос о крайних сроках выполнения работы, и Рон от-
вечает: «Конечно, предстоит напряженная работа, но я уверен, что мы
справимся, если будем действовать заодно. Я разработал график рабо-
ты, который, на мой взгляд, вполне выполним, и раздам его сразу, как
только мы решим все вопросы с чартером. У кого еще есть вопросы?»
Бонни задает какой то вопрос, Рон отвечает на него: «В данный мо-
мент ваш вопрос не касается предмета нашего обсуждения; думаю, луч-
ше вернуться к нему позже».
Да, в данной ситуации Рон явно не является образцом для подража-
ния. Что же именно он сделал неправильно:
не включил в программу собрания знакомство участников и рас-
крепощающую игру, поэтому у людей не было возможности бли-
же познакомиться друг с другом;
не стал составлять командный договор;

Глава 4. Запуск проекта
81
проявил нетерпимость к вопросам, которые возникли после про-
чтения чартера проекта;
разработал график работ без участия членов команды;
не предусмотрел возможности записи идей, вопросов или проб-
лем, которые не касаются обсуждаемой темы.
Чтобы проект завершился получением необходимых результатов,
Рону придется изменить свой подход к работе. Возможно, в этом ему
поможет Сэм, который также является лидером проекта и использует
метод CORE PMTM.
Сэм начинает собрание, посвященное запуску проекта, со слов: «Хотя
все мы друг друга знаем, давайте потратим несколько минут на беседу
о том, чем каждый из нас занимался в последнее время, а затем я пред-
лагаю вам сыграть в интеллектуальную игру. Она позволит нам опре-
делить стиль нашего собственного и командного мышления. Этот стенд
я подготовил специально для того, чтобы фиксировать на нем все идеи,
проблемы или вопросы, которые у вас возникнут, чтобы ничего не упу-
стить. Мы решим, как поступить с каждым вопросом или идеей, в кон-
це собрания.
После определения наших стилей мышления, я бы хотел составить
командный договор, который мы все сочтем приемлемым для дальней-
шей совместной работы над проектом. Это поможет нам избежать ненуж-
ных проблем и конфликтных ситуаций во время работы в команде.
Вместе со спонсором проекта мы разработали чартер, который вы
только что получили. Я бы хотел собрать все ваши комментарии, во-
просы, проблемы и идеи относительно этого чартера. Мы запишем их
на листках клейкой бумаги для заметок и прикрепим к плакату, кото-
рый я повесил на стене. Когда мы разберемся с вопросами, касающи-
мися чартера, то вместе, всей командой, приступим к разработке про-
ектного плана».
В данной ситуации Сэм играет роль помощника, а не руководителя.
Он поощряет активное участие в обсуждении всей команды. Он инте-
ресуется вопросами и идеями участников собрания, относится уважи-
тельно к каждому члену команды, готов выслушать волнующие их
проблемы и заботится о том, чтобы у всех была возможность выска-
зать свое мнение. Своим поведением он демонстрирует, что заинтере-
сованность любого члена команды не вызывает сомнений и очень важна
для совместной работы.
Сэм уделяет внимание не только управлению проектом, но и фор-
мированию команды, привлекая всех к работе над проектом. Он очень
6 1815

82
Глава 4. Запуск проекта
разумно руководит проектом; такие лидеры умеют организовать со-
вместную работу команды.
Процесс планирования
Прежде чем заняться планированием проекта, давайте выясним, как
действия по планированию, необходимые для выполнения проекта,
связаны с его уникальными особенностями, которые обсуждались в гл. 1
(табл. 4.1).
Таблица 4.1
Действия по планированию и характеристики проекта
Характеристики
проекта
Временное
предприятие
Уникальный
продукт
Нет заранее опреде-
ленных рабочих
инструкций
Необходимые действия по планированию
Нужно набрать команду
Нужно организовать проект
Нужно определить даты начала и завершения проекта
и утвердить график проекта
Нужно разработать бюджет
Требования заказчика к готовой продукции должны быть
четко определены
Нужно определить то, что входит, а что не входит в проект
Нужно составить описание готовой продукции
Нужно решить, кто и что будет делать
Нужно определить круг ответственности
Все действия по планированию будут рассмотрены в последующих
пяти главах (табл. 4.2).
Пусть вас не пугает их количество. На практике действия по плани-
рованию не должны вызывать серьезных затруднений, а когда вы на-
беретесь опыта, вам станет еще проще. Кроме того, вам с удовольстви-
ем помогут члены команды. Вот одно из самых больших преимуществ
того, что вся команда принимает в процессе активное участие.
Запуск проекта: проверьте себя
Прежде чем перейти к планированию проекта, проверьте, не упустили
ли вы что нибудь на этапе запуска проекта.

Глава 4. Запуск проекта
83
Таблица 4.2
Действия по планированию (главы в книге)
Сегмент
Определение
масштаба проекта
Организация работы
Оценка риска
Составление графи-
ка выполнения
проекта
Разработка бюджета
Составление
проектного плана
Операции
Уточните у заказчиков, чего они
ждут от проекта
Четко определите конечный
продукт
Определите, что входит, а что
не входит в проект
Определите всех заинтересован-
ных участников проекта
Убедитесь, что вы подобрали для
работы в команде правильных
людей
Убедитесь, что интересы всех
заинтересованных сторон так или
иначе представлены в команде
Разбейте изготовление конечного
продукта на отдельные операции
Поручите выполнение каждой
из них членам команды
Попробуйте определить, что
может пойти не так, и найдите
способы для предотвращения
возможных проблем
Составьте график всех задач,
которые необходимо выполнить
Разработайте бюджет времени,
затрачиваемого сотрудниками
на работу над проектом
Разработайте бюджет расходов
по проекту
Опишите процедуры, которые
будут использоваться для внесе-
ния изменений в план
Объедините информацию, накоп-
ленную на этапе планирования,
в формальный проектный план
и получите его одобрение
Глава в книге
Глава 5. Определение
масштаба проекта
Глава 6. Организация
проекта
Глава 7. Оценка
рисков
Глава 8. Составление
графика работ
Глава 9. Разработка
бюджета
Глава 10. Составление
окончательного
проектного плана

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

Глава 5
Определение масштаба проекта
В конце этапа подготовки проекта спонсор утверждает чартер, в кото-
ром оговаривается, что необходимо получить в результате выполне-
ния проекта и какие для этого требуются ресурсы.
Чартер --- это «видение» проекта. В нем содержатся ожидания за-
казчиков и спонсора проекта, а иногда даже их мечты. То, что записа-
но в чартере проекта, может быть выполнимым, но может быть и нет.
Только на этапе планирования выясняется, достижимы ли поставлен-
ные цели, поскольку в это время речь идет о реальных показателях: что
можно сделать, сколько времени это займет, кто и чем будет занят, какие
потребуются затраты. Чартер отвечает на вопросы: «Почему?» и «Что?»
План проекта --- на вопросы: «Кто?», «Как?», «Когда?» и «Сколько?»
Довольно часто случается, что реальные результаты, которые можно
получить, выполнив проект с использованием имеющихся в наличии
ресурсов, отличаются от ожиданий, описанных в чартере. Планирова-
ние помогает определить, какие задачи выполнимы, а какие --- нет.
Однако приступать к планированию следует, намереваясь выпол-
нить требования чартера по максимуму. Иногда то, что сначала кажется
невыполнимым, становится вполне осуществимым, если к решению проб-
лем подойти творчески. И наоборот, иногда то, что казалось возмож-
ным, оказывается нереальным. Тогда возникает необходимость под-
корректировать ожидания или привлечь дополнительные ресурсы.
На этапе планирования также определяется «игровая стратегия»
того, как должен создаваться конечный продукт: что будет произво-
диться, когда, кем, какие для этого потребуются денежные затраты.
Именно такая проработанная в деталях стратегия будет впоследствии
использоваться в качестве руководства при выполнении проекта.
Первое, что необходимо сделать для составления плана проекта, ---
это точно установить масштаб проекта: какой продукт будет создавать-
ся для заказчика. Масштаб --- это наиболее важный элемент проекта,
так как он, в свою очередь, предопределяет все потребности в ресурсах.
Если масштаб проекта сравнительно велик, то потребуются большие

86
Глава 5. Определение масштаба проекта
затраты ресурсов. Если же он ограничен, то ресурсов будет затрачено
меньше.
Масштаб проекта определяется потребителями, поэтому прежде
всего нужно убедиться в том, что вы правильно определили потреби-
теля данного проекта.
Определение потребителя
Существуют два вида потребителей, которых нужно принимать в рас-
чет, приступая к любому проекту: конечный потребитель (конечный
пользователь) и потребитель проекта (заказчик проекта) (табл. 5.1).
Таблица 5.1
Характеристики потребителей
Тип потребителя
Конечный
потребитель
(конечный
пользователь)
Заказчик проекта
Характеристики
Непосредственный потребитель продукта, услуги, процесса
или плана, разработанного или улучшенного в результате
выполнения проекта
В случае, когда результатом проекта является подготовлен-
ный процесс, конечный потребитель --- это человек или
группа людей, которые будут управлять данным процессом
Человек или группа людей, получающие конечный продукт
проекта
Заказчик проекта --- это потребитель, который получает конечный
продукт в результате выполнения проекта. Он может быть конечным
пользователем продукта, а может и не быть им. В нашем примере раз-
работки процесса выполнения заказов Кен, менеджер, ответственный
за данный бизнес процесс, является и заказчиком проекта. Люди, ко-
торые будут затем работать в его отделе, станут конечными пользова-
телями разработанного процесса.
Нужно ли проводить анализ потребностей конечных пользователей?
Несомненно. Для разработки рабочего процесса необходимо опреде-
лить, что требуется конечному пользователю для эффективной и ре-
зультативной работы. Потребности конечного пользователя часто вы-
ясняются еще до начала проекта, в процессе исследования рынка или
определения концепции изделия. Если же они не были изучены или
если команда исполнителей не располагает данными исследования, то
их необходимо получить до начала разработки конечной продукции.
Часто на этапе выполнения проекта эти данные уточняются. Однако

Глава 5. Определение масштаба проекта
87
получать данные в некоторых случаях приходится уже на этапе пла-
нирования --- в случае, когда, например:
требования конечного пользователя вообще не были выяснены;
заказчик проекта не имеет ясного представления о потребностях
конечного пользователя;
потребности конечного пользователя значительно отличаются от
требований заказчика.
Процессы, позволяющие получить данные о потребностях, будь то
потребности конечного пользователя или заказчика проекта, очень
похожи. Следовательно, необходимо рассмотреть механизм оценки
требований и пожеланий заказчика проекта. Заказчик проекта --- это
тот, кому вы из рук в руки передадите полученные результаты. Имен-
но он обычно оценивает выполнение проекта. Если вам необходима
информация о потребностях конечного пользователя, то можно вос-
пользоваться тем же сценарием, что и для заказчика проекта.
Потребности заказчика
Первое, что необходимо сделать, --- определить, что именно нужно по-
требителю, т. е. какую проблему пытается решить заказчик проекта. Хотя
его потребности должны быть уже описаны в чартере проекта, нужно
убедиться, что они поняты правильно. Лучший способ сделать это ---
посетить потребителей и изучить проблемы, с которыми они сталки-
ваются, на практике.
Основная причина необходимости анализа потребностей потреби-
телей состоит в том, что нужно убедиться, правильно ли вы поняли
основные источники проблем. Ведь продукты проекта заказчик рас-
ценивает именно как решение своих проблем. Заказчики часто прихо-
дят с уже готовыми решениями: «Мне нужно разработать состав для
новых таблеток аспирина». Возможно, что такое решение проблемы
действительно является наилучшим из тех, с которыми сталкивались
заказчики. Однако, вероятно, вы сможете найти альтернативное ре-
шение, эффективность которого окажется выше. Изучая потребности,
нельзя ограничиваться предложенным вам решением существующей
проблемы.
Встретившись с заказчиком, попросите его рассказать и показать вам,
если это возможно, в чем состоит проблема, с которой он столкнулся.
Если у вас нет возможности наглядно изучить проблему во время бе-
седы с заказчиком, то вы сможете хотя бы разобраться в ней. Возможно,

88
Глава 5. Определение масштаба проекта
вам потребуется более тщательный анализ, чтобы понять, с какой имен-
но трудностью он столкнулся. Например, если бы Кен, менеджер, от-
ветственный за выполнение заказов, сказал, что он нуждается в новом
процессе выполнения заказов, который осуществлялся бы силами ком-
пании, то резонно было бы спросить его: «Что вас не устраивает в суще-
ствующей системе? Как новый процесс может помочь вам?» В данном
случае решением проблемы будет введение нового процесса обра-
ботки заказов силами компании. Проблема же заключается в недоста-
точной оперативности и в ошибках при доставке.
Вот несколько фраз, которые могут помочь выявить проблему, сто-
ящую перед потребителем:
Как эта проблема влияет на бизнес?
Из за чего, по вашему мнению, она возникла?
Исчезнет ли эта проблема, если мы реализуем предложенное вами
решение?
На самом деле вы исследуете лишь предположения заказчика отно-
сительно возможного решения или конечной продукции, которая ему
требуется. Предположения --- это то, в реальность чего мы верим. На-
пример, Кен предполагает (верит), что недостаточная оперативность
и ошибки при доставке --- это прямое следствие привлечения внешней
фирмы к выполнению заказов. Он пришел к выводу, что если выпол-
нение заказов производить силами компании, то эти трудности исчез-
нут. Его предположение может оказаться как верным, так и ошибоч-
ным.
Проверить это предположение нельзя, пока вы не выясните, в чем
на самом деле состоит проблема. Когда вы поймете, что именно беспо-
коит заказчика, нужно убедиться, что выдвинутое им предположение
действительно верно или что решение, предложенное заказчиком, яв-
ляется на данный момент наилучшим.
Существует много количественных методов для выявления реаль-
но существующей проблемы, а также для нахождения правильного ее
решения. (Решение --- это конечный продукт проекта, который требу-
ется получить в результате его воплощения.) Подобные методы реше-
ния проблем можно использовать для анализа проблемы и отбора наи-
лучшего из возможных решений. (Авторы этой книги Мартин и Тэйт
разработали трехэтапный метод, описанный в приложении D.) Если
вы не уверены в том, что проблема определена правильно, то не пере-
ходите к следующему этапу проекта, пока не проанализируете мето-
дологию решения проблемы.

Глава 5. Определение масштаба проекта
89
В чем заключается опасность неумения отличить потребности за-
казчика от его предположений? В нашем примере недостаточная опе-
ративность и неправильная доставка не имеют никакого отношения
к работе фирмы подрядчика. На самом деле эта проблема связана с кли-
ентским отделом, невнимательно оформляющим заказы. Потому мы,
конечно, можем разработать и внедрить систему выполнения заказов
силами компании, но не решим тем самым создавшуюся проблему. Это
не очень хорошая идея. Следовательно, лучше всего сначала обнару-
жить источник проблемы и лишь затем приступать к планированию
производства того продукта, который, как предполагается, поможет
справиться с возникшей ситуацией.
Конечный продукт
Разобравшись с проблемами заказчика, вы уже можете обосновать со-
здание конечного продукта. Будет ли конечный продукт вашего про-
екта наилучшим из всех возможных решений его проблемы? Если это
не так, то нужно вернуться к обсуждению вариантов решения со спонсо-
ром и заказчиком проекта. Необходимо найти такое альтернативное реше-
ние, которое бы максимально способствовало устранению проблемы.
Конечный продукт --- это не волшебная палочка. Он вряд ли полно-
стью избавит заказчика от проблем. Однако он должен в какой то сте-
пени сглаживать их остроту (рис. 5.1). Для полного решения проблем
заказчику, возможно, будет недостаточно одного проекта, а значит, ему
потребуется несколько Конечных продуктов различных проектов.
Хотя вам необходимо определить, какая именно проблема беспоко-
ит потребителя, вы вовсе не обязаны ее решать. За что вы действи-
тельно отвечаете, так это за поставку конечного продукта, который
удовлетворит заказчика. Однако если вы хотя бы не смягчите проблем-
ную ситуацию, заказчик вряд ли будет удовлетворен результатом про-
екта, даже если вы сделаете именно то, что он хотел. Поэтому не жа-
лейте времени на выявление проблемы, а затем убедитесь, что конечный
продукт поможет облегчить ситуацию. После этого вам останется лишь
Конечный продукт
должен способствовать
решению проблем
заказчика
Рис. 5.1. Конечный продукт удовлетворяет потребность

90
Глава 5. Определение масштаба проекта
одно --- определить, насколько заказчик доволен полученным резуль-
татом. Удовлетворение заказчика --- это основная цель любого проек-
та, но достигнута она будет только в том случае, если соблюдены все
поставленные заказчиком условия. Но выполнение каких условий он
считает необходимым при получении конечного результата проекта?
Спросите его об этом.
Критерии заказчика по приему продукта
Критерии заказчика по приему продукта --- это критерии, с помощью
которых он оценивает, насколько удовлетворительны результаты про-
екта. Достижение этих критериев, также известных как САС (Customer
Acceptance Criteria), и должно стать вашей целью. Если все они будут вы-
полнены, то заказчик останется доволен результатами. Если критерии
не заданы, то конечный результат работы определен нечетко, а это по-
чти всегда влечет за собой проблемы при выполнении работы (рис. 5.2).
Наилучший способ выявления САС --- это диалог с заказчиком.
Пусть он представит, что вы передали ему конечный продукт и он при-
ступает к его использованию. Попросите его назвать три или четыре
основные рабочие характеристики продукта, которые сделали бы его
полезным заказчику. Например, одной из характеристик, важных для
Кена, менеджера по выполнению заказов, будет краткосрочность цик-
ла обработки заказа.
Если критерии, определенные заказчиком, нельзя измерить, то нуж-
но попытаться разработать для них методы оценки. Например, Кен
поясняет, что он считает цикл краткосрочным, если тот не превышает
48 часов. Эту оценочную характеристику можно использовать в работе
как контрольный показатель. Такие формулировки, как: «Процесс вы-
полнения заказов должен быть хорошо налажен», не дают четкого
понимания того, как должна протекать работа. Критерий, предпола-
Рис. 5.2. САС используются для оценки готовой продукции

Глава 5. Определение масштаба проекта
91|
гающий, что заказ должен быть собран и упакован менее чем за 60 ми-
нут, дает более ясное представление о требованиях заказчика.
Требования заказчика
Во время обсуждения с заказчиком вопросов СА С целесообразно уточ-
нить требования заказчика к конечному результату проекта и прорабо-
тать их более детально. Требования заказчика могут касаться любых
свойств и функций конечного продукта. Свойства --- это физические
характеристики готового продукта. Например, для процесса выполне-
ния заказов такой характеристикой может быть штрих кодирование
всех товарно материальных ценностей. Функции --- это действия или
рабочие операции, которые будут выполняться с помощью конечного
результата проекта. В примере с процессом выполнения заказов функ-
цией может быть автоматическое регулирование уровня запасов через
программу бухгалтерского учета.
Требования заказчика должны быть отражены в чартере проекта.
На этапе планирования эти требования необходимо изложить более
подробно. Попросите заказчиков описать все необходимые им свойст-
ва и интересующие их функции (табл. 5.2). Запишите каждое из этих
требований на отдельном листке липкой бумаги. Когда все свойства и
функции будут описаны, попросите заказчика разделить их на три кате-
гории: необходимые, нужные и желательные. Это позволит вам соот-
нести каждую категорию с планируемым вами уровнем удовлетворен-
ности заказчика.
Для полной уверенности нужно еще раз убедиться, что все свойства
и функции из категории «необходимые характеристики» согласуются
Таблица 5.2
Категории свойств и функций
Категории свойств
и функций конечного
продукта
Необходимые
Нужные
Желательные
Влияние свойств и функций продукта
на удовлетворенность заказчика
Готовый продукт будет соответствовать САС
Заказчик будет удовлетворен конечным продуктом
Конченый продукт будет превосходить САС
Заказчик будет очень доволен полученными
результатами
Обычно имеющихся ресурсов недостаточно для
включения в проект желательных характеристик,
однако, если их учесть, заказчик будет в восторге

92
Глава 5. Определение масштаба проекта
с САС и что вы не упустили ни одного требования (рис. 5.3). Затем
проверьте «нужные характеристики» и подумайте, стоит ли включать
какие либо из них в описание конечного продукта. Нужно помнить,
что от перечня свойств и функций, присущих окончательному резуль-
тату проекта, зависит потребность проекта в ресурсах. Поэтому не ста-
райтесь придать конечному продукту проекта больше свойств и функ-
ций, чем это позволяет сделать объем финансовых средств, выделенных
на его получение. Впоследствии потребуется тщательнее проанализи-
ровать требования (преобразовав их в техническое описание), чтобы
приступить непосредственно к разработке конечного продукта. На дан-
ном этапе необходимо лишь разработать точный план, из которого стало
бы ясно, какого реального конечного результата можно ожидать.
Масштаб проекта
После того как требования заказчика выяснены, пора составлять опи-
сание конечного продукта. Обычно его называют описанием масшта-
ба проекта. Его цель --- точно определить результат, который будет
получен по завершении проекта, чтобы, когда потребитель прочтет это
описание, он мог сказать: «Да, это именно то, что мне нужно» или: «Нет,
вы здесь упустили некоторые моменты». Описание масштаба проекта ---
это способ обмена информацией, гарантирующий, что вы произведете
именно то, что необходимо спонсору или заказчику проекта.
Рис. 5.3. Требования заказчика и конечный продукт

Глава 5. Определение масштаба проекта
93
Возможно, описание займет лишь несколько параграфов. К нему
можно приложить перечень требований, включающий все свойства
и функции, которыми должен обладать конечный продукт проекта.
Если чертеж или диаграмма могут помочь создать представление о ко-
нечном продукте, то стоит добавить и их. Полезно привести все, что
позволит заказчику яснее представить себе конечный продукт.
Предположим, что вам поручили составить план организации празд-
нования по поводу недавнего успешного запуска новой продукции
вашей компании. В данном случае конечным продуктом выступает тор-
жественный обед с танцевальным вечером, на который придут сотруд-
ники и приглашенные ими гости. Описание масштаба данного проек-
та может начинаться следующим образом.
Конечный результат проекта --- торжественный обед состоится 15 сен-
тября в кафе «Magnolia Plantation». На обеде будет присутствовать не
более 100 приглашенных гостей (включая сотрудников и основных
поставщиков). Каждый из них, в свою очередь, имеет право привести
с собой одного знакомого. Следовательно, общее количество гостей не
должно превысить 200 человек. Празднование начнется в 19.00 с при-
ема на открытой площадке, а продолжится обедом в помещении кафе.
После обеда состоится официальная часть мероприятия. Для вечерней
развлекательной программы будут приглашены танцевальные ансамб-
ли. Обед и танцы продолжатся до 12 часов ночи. Форма одежды --- па-
радная. Помещения будут оформлены в стиле...
Описание масштаба проекта нужно продолжить, рассказав о свойст-
вах и функциях, присущих конечному результату проекта, а именно обе-
ду с танцевальным вечером. Заказчик проекта вице президент марке-
тингового отдела должен ознакомиться с данным описанием, чтобы
удостовериться, что все учтено и планирование проекта проведено.
Границы проекта
Охарактеризовав конечный продукт, мы должны уточнить, что вхо-
дит в проект, а что нет, т. е. задать границы проекта (рис. 5.4). Здесь
важно не запутаться во включенных в проект и исключенных из него
задачах, а также не сбиться с прямого курса в погоне за целями, кото-
рые преследует заказчик.
Чтобы определить границы проекта, напишите название готового
продукта на прикрепленном к стене листе ватмана и очертите вокруг
него большой прямоугольник. Этот прямоугольник будет обозначать
границы вашего проекта. Внутри перечислите основные задачи, кото-
рые необходимо выполнить для создания конечного продукта. Напри

94
Глава 5. Определение масштаба проекта
Рис. 5.4. Границы проекта
мер, для проекта по подготовке торжественного обеда с танцевальным
вечером такими задачами будут подготовка развлекательной програм-
мы, организация обеда в кафе и приглашение гостей.
За пределами этих границ перечислите то, что не вошло в проект.
Например, данный проект по организации обеда не имеет отношения
к обеспечению гостей транспортом для доставки к месту проведения
праздника.
Теперь, когда вы определили, что входит в проект, а что нет, нужно
выяснить, не пересекается ли сфера деятельности вашего проекта с дру-
гими проектами (рис. 5.5). Один из авторов этой книги работал над
проектом, целью которого было изменение дорогостоящей составля-
ющей продукта для снижения производственных издержек. Команда
трудилась над проектом в течение 18 месяцев и наконец достигла по-
ставленной цели. Без их ведома другая проектная команда, занимав-
шаяся снижением общей себестоимости продукта, изменила схему
Рис. 5.5. Пересечение сфер деятельности различных проектов

Глава 5. Определение масштаба проекта
95
продукта, исключив из нее эту дорогостоящую деталь! Следователь-
но, хотя первая проектная команда и достигла своей цели --- снизила
издержки на составляющую, --- в целом их проект оказался бесполез-
ным. Вы не должны допускать таких ситуаций. Нужно следить за ин-
формацией о других проектах, планируемых и уже реализуемых, кото-
рые могут повлиять на результаты вашего проекта. (В этом вам должен
помочь спонсор проекта.) Нарисуйте окружность, которая пересекается
с изображающим ваш проект прямоугольником, и перечислите в ней
все проекты, так или иначе связанные с вашим.
Анализ границ вашего проекта будет неполным, если вы не опреде-
лите точно, когда закончится этап выполнения проекта. Рассмотрим
для примера подготовку торжественного обеда с танцевальным вечером:
в какой момент будет достигнут конечный результат проекта? В 12 ча-
сов вечера, когда подойдут к концу танцы? После завершения вечера,
когда все будет уже убрано? После того как будут оплачены счета?
Еще труднее решить, когда считать оконченным проект по разработ-
ке процесса выполнения заказов. В какой момент станет очевидно, что
процесс проходит именно так, как было обещано? После первого проб-
ного запуска? После второго? После недельного испытательного сро-
ка? Единственно правильного ответа на этот вопрос не существует, но
все же очень важно определить момент окончания проекта заранее,
чтобы каждый участник ясно понимал, когда готовый результат будет
полностью передан заказчику.
Заинтересованные стороны (дольщики)
Дольщики, как вы уже знаете, --- это люди или группы людей, интересы
которых связаны с данным проектом. Можно выделить четыре катего-
рии дольщиков: потребители, поставщики, участники других проектов
и пр. Потребители --- это те, кто заинтересованы в конечном результа-
те проекта. К ним относится заказчик проекта, так как он получает го-
товый продукт. Но конечный результат проекта, возможно, важен не
только для него, но и для других групп людей. Например, если гото-
вый продукт проекта изменит технологию производства или увели-
чит объем работы, то рабочие профсоюзы, разумеется, окажутся в чис-
ле заинтересованных потребителей проекта.
Вторая категория дольщиков --- это поставщики, т. е. люди или груп-
пы людей, которые не принимают участия в работе над проектом на-
прямую, но поставляют необходимые материалы и средства для его
выполнения.

96
Глава 5. Определение масштаба проекта
Третью категорию составляют участники любых других проектов,
на выполнении которых могут отразиться результаты данного проекта
или результаты которых могут повлиять на ваш проект. Информацию
о них необходимо включить в пункт о пересечении сфер деятельности
проектов в том разделе плана, где рассматривается масштаб проекта.
Наконец, четвертая категория включает все остальные группы людей,
на которых оказывает влияние работа над проектом. Обычно это те, кто
вовлечены в непосредственную работу, например менеджеры по ресурсам,
которые поставляют персонал и/или денежные ресурсы для проекта.
Постройте таблицу, например, такую, как на рис. 5.6. Перечислите
в ней всех дольщиков. Укажите категории, к которым они принадле-
жат, и те их интересы, которые затрагивает данный проект. Остальные
колонки пока оставьте пустыми. Они будут заполнены позднее, когда
мы перейдем к следующему этапу.
Определение масштаба проекта: проверьте себя
Прежде чем перейти к работе над следующим разделом, вернитесь еще
раз к определению масштаба проекта, чтобы убедиться, что вы ничего
не упустили.
Определили ли вы ту проблему, решению которой должен спо-
собствовать конечный результат проекта?
Поможет ли конечный продукт разрешить проблему (проблемы),
стоящие перед заказчиком?
Насколько точно описан конечный продукт в разделе о масштабе
проекта?
Единогласно ли принято решение о том, что именно будет созда-
но в результате проекта?
Заинтересованные стороны (дольщики)
Рис. 5.6. Заинтересованные стороны (дольщики)

Глава 5. Определение масштаба проекта
97
Составлен ли перечень требований потребителя?
Описаны ли критерии по приему продукта, определяемые потре-
бителем? Поддаются ли они измерению?
Четко ли установлен момент окончания проекта?
Выявлены ли все группы людей, интересы которых будут затро-
нуты проектом? Выявлены ли группы, которые могут повлиять
на результаты проекта?
Определены ли точки пересечения вашего проекта с другими про-
ектами?
Активно ли участвует команда в определении масштаба проекта?
Если нет, то почему?
Документ, отражающий план проекта
Наконец вы готовы к тому, чтобы завершить раздел, в котором опре-
деляется масштаб проекта для проектного плана. Проектный план ---
это документ, в котором план выполнения проекта приводится в соот-
ветствие с внешними условиями. Так как разделы плана мы уже рас-
смотрели, то теперь поговорим о том, какие пункты нужно включить
в этот документ.
В раздел о масштабе проекта должны быть включены следующие
пункты:
повторно утвержденное определение потребностей заказчика;
подробное описание конечного продукта, включая свойства и функ-
ции, которыми он должен обладать;
приемные критерии потребителя в измеримом выражении, если
это возможно;
масштаб (границы) проекта;
момент завершения работы над проектом;
перечень заинтересованных сторон (дольщиков) с указанием того,
какие их интересы затрагиваются проектом.
Проектный план не следует публиковать до тех пор, пока не будет
завершен весь этап планирования. При желании раздел, в котором опи-
сывается масштаб проекта, можно обсудить со спонсором, заказчиком
и с основными дольщиками, прежде чем перейти к следующему разде-
лу планирования, так как масштаб --- это основа для дальнейшей рабо-
ты. Будем надеяться, вам подтвердят, что вы находитесь на правиль-
ном пути, или подскажут, что нужно подкорректировать, перед тем,
как приступить к следующему этапу.

Глава 6
Организация проекта
После того как вы четко определили масштаб проекта, наступило вре-
мя подумать о том, как именно будет выполняться работа. Для этого
требуется организовать проект.
Как разделить конечный продукт на отдельные
составляющие
Чтобы организовать работу, первым делом необходимо разделить ко-
нечный результат проекта на управляемые рабочие задания, каждое
из которых будет представлять ту часть работы, с которой может спра-
виться один человек. Когда такое рабочее задание, или, как его еще
называют, технологический процесс, полностью выполнено, появля-
ется определенный продукт. (Технологический процесс --- это ряд опе-
раций, выполнение которых приводит к определенному результату или
конечному продукту.) Например, если вам поручили смонтировать
полки на складе, то результатом этого технологического процесса
будут установленные полки. Промежуточный результат, который при-
нимается потребителем проекта, называется выходом. Каждый про-
межуточный продукт --- это выход определенной технологической опе-
рации, который станет исходным ресурсом для следующего процесса,
в результате которого будет произведен очередной промежуточный
продукт, а он, в свою очередь, послужит ресурсом, и так до тех пор,
пока не будет изготовлен конечный продукт (рис. 6.1). Эта цепочка
взаимосвязанных или взаимозависимых продуктов называется цепоч-
кой входов/выходов. Так, установленные полки --- это лишь ресурс для
создания следующего промежуточного продукта: укомплектованного
склада.
Итак, промежуточный продукт --- это то, что создано при помощи
технологического процесса; он проходит через всю цепочку изготов-
ления промежуточных результатов до получения конечного продукта.
Если рабочая операция не ведет к получению конечного передаваемого

Глава 6. Организация проекта
99
Рис. 6.1. Промежуточный продукт и технологический процесс
продукта, то зачем она нужна? Все, что делается во время работы над
проектом, должно приводить к созданию конечного продукта для по-
требителя.
Представьте себе строительство дома. Конечным продуктом строи-
тельства будет здание. Промежуточные продукты могут включать в себя
разрешение на строительство, вырытый котлован под фундамент, за-
ливку фундамента, каркас здания, внутренние стены и т. д. Каждый из
этих продуктов создается в результате технологического процесса,
выполненного одним или несколькими людьми, и каждый из них яв-
ляется необходимым для получения конечного продукта, типового
здания.
Разбиение всего проекта на промежуточные результаты работы наи-
лучшим образом помогает определить управляемые рабочие задания,
ответственность за выполнение каждого из которых можно возложить
на одного члена команды. Управляемое рабочее задание должно удов-
летворять следующим требованиям:
оно не должно быть слишком большим, его выполнение должно
полностью контролироваться одним человеком;
с ним в состоянии справиться один человек или небольшая группа
людей.
Определение промежуточных продуктов проекта
Лучший способ составить список промежуточных продуктов --- это
использование командой метода «мозгового штурма». Напишите на-
звание конечного продукта на листке липкой бумаги для заметок и при-
клейте его к листу ватмана, повешенному на стену. Затем попросите
членов команды записать названия всех промежуточных продуктов,
которые используются для получения конечного результата. Выпиши-
те все эти названия на липкие листочки и разместите на ватмане.

100
Глава 6. Организация проекта
Подсказка: не беспокойтесь о том, в каком порядке расположить
промежуточные продукты. Вы сможете их систематизировать на сле-
дующем этапе.
Помните, что продукт --- это материальный объект (выраженный
именем существительным) или полностью выполненная задача, дей-
ствие (выраженные причастием прошедшего времени). Полки, уста-
новленные на складе, --- это материальный объект. Организованное
праздничное мероприятие --- это завершенное действие.
Вы можете обнаружить, что некоторые промежуточные продукты
требуют довольно большого объема работы. Попытайтесь разбить такие
технологические процессы еще на несколько этапов (рис. 6.2). Пред-
положим, что вам нужно составить бизнес план, который в вашем про-
екте играет роль промежуточного продукта. Вы можете разбить этот
процесс на создание ряда промежуточных продуктов, например схема
бизнес плана, черновик, окончательный вариант текста и окончатель-
ный вариант с иллюстрациями. Чем проще рабочая операция, тем лег-
че контролировать ее выполнение. Однако если вы сделаете операции
слишком простыми, то ваш проектный план будет чрезмерно перегру-
жен незначительными подробностями. Как же определить правильный
объем каждого рабочего процесса? Этому можно научиться только на опы-
те, но тем, кто столкнулись с такой задачей впервые, лучше предусмот-
реть излишнее количество промежуточных продуктов, чем наоборот.
Создание подпроектов
После того как определены промежуточные продукты, необходимо по-
ручить создание каждого из них (подпроект) одному из подразделений,
Рис. 6.2. Разбиение конечного продукта на промежуточные продукты

Глава 6. Организация проекта
101
работающих над проектом. Напомним, что подпроект --- это часть
основного проекта, за которую отвечает один из членов команды.
Если проект небольшой, то с работой над любым подпроектом в оди-
ночку справится кто либо из членов команды. Если же проект более
крупный, то для выполнения подпроекта может потребоваться группа
людей, а следовательно, для контроля над работой подпроектной
команды назначается лидер. Он руководит подпроектом и одновре-
менно входит в основную команду проекта. Он вправе самостоятель-
но оговорить круг своих обязанностей в рамках задач подпроекта так
же, как лидер проекта определяет свою часть работы над основным
проектом.
Функции лидера подпроектной команды в основном аналогичны
функциям лидера проекта. Лидер подпроектной команды должен сле-
дить за тем, чтобы его команда выполняла свою работу с учетом задач
основной проектной команды.
Команда подпроекта проходит те же этапы и выполняет практически
те же операции, что и команда главного проекта. Ниже представлена
последовательность основных операций планирования проекта, ко-
торые выполняются подпроектной и проектной командами (табл. 6.1).
Таблица 6.1
Планирование подпроекта
Операции
планирования
Планирование
масштаба проекта
Оценка рисков
Календарное
планирование
ресурсов
Бюджетное
планирование
ресурсов
Последовательность планирования для больших
проектов
Определение масштаба проекта --- это первый шаг при
разработке основного проекта. Затем, после того как
проект организован в целом, определяется масштаб
каждого подпроекта
Обычно в первую очередь выполняется оценка рисков
подпроектов, а затем эти результаты используются
главной командой для оценки всего проекта в целом
Сначала разрабатывается черновой вариант графика
основного проекта, а затем составляются графики работы
для каждого подпроекта. Затем эти графики используют-
ся для окончательного определения сроков работы над
основным проектом, при необходимости первоначальный
вариант графика корректируется
Сначала составляется бюджет для выполнения каждого
подпроекта, а затем все полученные бюджеты объединя-
ются и формируется общий бюджет проекта

102
Глава 6. Организация проекта
Определение подпроекта
Как определить, что должен включать в себя каждый подпроект, необ-
ходимый для работы над проектом в целом? Проще всего сделать это,
сгруппировав промежуточные продукты по аналогичным видам опера-
ций или по операциям, требующим схожих навыков (рис. 6.3). В этом вам
очень помогут липкие листки для заметок с написанными на них на-
званиями промежуточных продуктов, которые команда уже подгото-
вила. (Располагайте группы промежуточных продуктов по горизонтали,
а не по вертикали. Впоследствии это позволит вам создать древовидную
схему подпроектов.) Обычно группы, подобранные таким образом,
во многом соответствуют схеме распределения ресурсов в организации
или существующим в ней отделам, например: маркетинговый отдел,
исследовательское и опытно конструкторское бюро и т. д. Каждая из
групп промежуточных продуктов ложится в основу подпроекта.
Подсказка: не стоит беспокоиться, если какие то промежуточные
продукты не вошли ни в одну группу. Вскоре мы разберемся и с ними.
Затем нужно дать название каждой группе или каждому подпроекту.
Оно должно быть коротким, состоять не более чем из двух трех слов
и указывать на то, какой вид работы выполняется в рамках данного
подпроекта. Например, при разработке нового вида продукции в под
проекты, как правило, входят маркетинговые мероприятия, модели-
рование продукта и его создание. Дав названия всем подпроектам, вер-
нитесь к анализу продуктов, не вошедших ни в одну группу, чтобы еще
раз проверить их на соответствие уже определенным подпроектам.
Если они действительно не подходят ни под один из них, то объедини-
те эти продукты в подпроект под названием «Управление проектом».
Рис. 6.3. Группировка промежуточных продуктов по подпроектам

Глава 6. Организация проекта
103
Кроме них в этот подпроект должно войти все, что создается в процес-
се управления проектом, например составление проектного плана или
итогового отчета о завершении проекта. Ответственность за этот под-
проект несет лидер проекта.
Конечный продукт должен относиться к одному из подпроектов.
Часто в случае, если конечный продукт создается лидером проекта, он
включается в подпроект управления проектом, но иногда он может
создаваться и в рамках другого подпроекта.
Проверьте промежуточные продукты всех подпроектов. Не упусти-
ли ли вы что нибудь? Если да, то добавьте недостающие задачи в соот-
ветствующий подпроект. Убедитесь, что они не дублируются в других
подпроектах.
Примечание: один и тот же промежуточный продукт не может быть
целью двух различных подпроектов. Если это все же случилось, то
нужно разбить данный продукт на два меньших и поместить каждый
из них в соответствующий подпроект.
Когда вы закончите определение продуктов, присвойте каждому из
них порядковый номер. Можно начать нумерацию с любого продукта
и продолжить ее в любом порядке; главное, чтобы каждый продукт
имел свой уникальный номер.
Оценка навыков
Теперь, когда подпроекты и связанные с ними промежуточные резуль-
таты работы определены, нужно еще раз просмотреть состав команды,
чтобы убедиться, что ее члены подходят для выполнения работы в под-
проектах. Если проект небольшой и члены главной проектной коман-
ды должны сами выполнить всю работу по созданию промежуточных
продуктов, то нужно сравнить их умение с требуемыми навыками. Вот
несколько вопросов, на которые необходимо ответить:
Есть ли такие промежуточные продукты, которые члены команды
не могут создать своими силами? Если да, то какого рода навыка-
ми должны обладать кандидаты на участие в проекте и нельзя ли
воспользоваться навыками внешнего исполнителя?
Есть ли такой подпроект, для которого, на ваш взгляд, не подходят
те члены команды, которым вы поручили работу над ним, или те,
кого вы назначили ответственными за его выполнение? Есть ли
в организации человек, который мог бы лучше справиться с зада-
чей, решение которой необходимо для выполнения подпроекта?

104
Глава 6. Организация проекта
ЕСЛИ ВЫ хотите успешно завершить проект, то очень важно, чтобы
ваша команда обладала необходимым набором навыков для создания
конечного продукта. Поэтому сейчас самое время определить, нужна
ли вам дополнительная помощь. Нет ничего ужасного, если кто то сам
уйдет из команды, решив, что он выполнит данную работу не самым
лучшим образом. Как раз наоборот, это только докажет, что он готов
на все ради того, чтобы работа увенчалась большим успехом, чем это
позволят сделать его способности. Назначьте каждого члена команды
ответственным за выполнение одного из подпроектов.
Если вы заняты в сравнительно крупном проекте и рассчитываете
выполнить его, привлекая к работе подпроектные команды, то за оцен-
ку навыков должны отвечать лидеры этих команд. Каждому из них
следует понять, какие навыки нужны для выполнения поставлен-
ных задач, и определить, как следует изменить состав команды, чтобы
установить наилучшее соотношение между задачами, которые необ-
ходимо выполнить, и членами команды, которые в состоянии с ними
справиться.
Оценка уровня представительства интересов
дольщиков в проекте
После того как вы убедитесь, что члены вашей команды обладают всеми
навыками, необходимыми для выполнения работы, также необходимо
удостовериться и в том, что в команде представлены интересы всех
дольщиков. Внимательно изучите список заинтересованных сторон
(дольщиков), составленный в специальной форме, которую вы подгото-
вили на этапе планирования масштаба проекта (рис. 6.4). Все ли дольщи-
ки в нем обозначены? Если нет, то обязательно нужно внести их.
Заинтересованные стороны (допьщики)
Труппа
дольщиков Категория
дольщиков
Как они
влияют
на проект?
Является ли
эта группа
ключевым
дольщиком?
Статус
в команде
Связь
группы
с членами
команды
Рис. 6.4. Заинтересованные стороны (дольщики)

Глава 6. Организация проекта
105
Необходимо определить ключевых дольщиков проекта. Ключевые
дольщики проекта --- это люди или группы людей, на которых проект
оказывает значительное влияние. К ним относятся:
заказчик проекта;
основные поставщики ресурсов для проекта;
менеджеры, отвечающие за обеспечение проекта ресурсами (обыч-
но персоналом, но иногда и финансами);
лидеры проектов, сфера деятельности которых пересекается с ва-
шей;
прочие участники, для которых результаты вашего проекта ис-
ключительно важны.
Отметьте в списке всех участников проекта, которых вы считаете
ключевыми дольщиками.
Теперь необходимо решить, как эти стороны должны быть представ-
лены в проекте. Можно выделить три формы представительства.
1. Постоянное членство в команде. Заинтересованного участника
проекта можно включить в команду исполнителей в качестве по-
стоянного члена. Таким образом, он будет обязан присутствовать
на всех собраниях команды и участвовать в полной мере в про-
цессах планирования и мониторинга проекта. Обычно подобный
вид членства используется ключевыми дольщиками.
2. Частичное членство в команде, основанное на участии в работе
в случае необходимости. Команда может специально приглашать
представителей дольщиков для решения определенных задач.
В этом случае они будут посещать собрания только тогда, когда
потребуется их помощь. Таким видом членства пользуются доль-
щики проекта, не являющиеся ключевыми.
3. Некомандное членство. Этот вид членства предполагает, что опре-
деленный член команды будут связываться с дольщиками, участ-
вовать от их имени в обсуждениях и сообщать им о ходе работ по
проекту. Такой процесс называется связью с членом команды.
Подобный вид членства применяют дольщики, которых не устра-
ивают два предыдущих вида.
Часто команды сомневаются, стоит ли им принимать заказчика в по-
стоянные члены команды. Можно назвать по крайней мере несколько
причин, по которым это следует сделать:
участие представителя заказчика в работе команды гарантирует,
что его мнение будет учтено при принятии решений;

106
Глава 6. Организация проекта
заказчик будет лучше понимать, почему в ходе проекта принима-
ются те или иные компромиссные решения;
заказчик обеспечит ценный вклад в проект, сформулировав свои
проблемы и требования к проекту.
Частичное членство в команде, предусматривающее участие в рабо-
те в случае необходимости, полезно, если для деятельности вашей ко-
манды необходимы технические эксперты, но при этом вы не хотите,
чтобы они были ее постоянными членами. Этот вариант подходит для
основных поставщиков и даже для заказчиков, когда нет жесткой не-
обходимости в их постоянном взаимодействии с командой.
В больших проектах с участием подпроектных команд лидерами
подпроектов обычно назначаются менеджеры, отвечающие за обеспе-
чение ресурсами. Это дает лидеру подпроекта возможность оценить
потребности в ресурсах для выполнения своей части работы. Кроме
того, в подобном случае интересы ресурсных отделов также представ-
лены в проекте. Лидеры подпроектов являются постоянными членами
команды. Они отвечают за то, чтобы все конечные продукты, которые
должны появиться в результате выполнения подпроектов, были созда-
ны в соответствии с требованиями, в срок (который мы пока не опре-
делили) и не выходили за рамки бюджета (они также пока не опреде-
лены). Проследите за тем, чтобы у каждого подпроекта было не больше
одного лидера. Запишите имя этого человека под названием подпро-
екта.
Связи с членами команды
Дольщики играют важную роль в судьбе проекта, так как именно они
решают, продолжать ли работу над ним, особенно если проект касает-
ся внедрения какого либо плана или разработки какого либо образца.
Здесь дольщики --- это, как правило, те, кто в дальнейшем будут отве-
чать за выполнение разработанного процесса или за предоставле-
ние задуманной услуги. Сопротивление внедрению вашего плана с их
стороны может означать, что ваша команда потратила впустую все ме-
сяцы работы. Предположим, что вы перепроектировали бизнес про-
цессы, но не пригласили заинтересованные в этом проекте стороны
участвовать в работе команды. Предполагается, что после окончания
проекта менеджеры, ответственные за эти бизнес процессы, станут
внедрять вашу разработку в жизнь. Но ведь они не имеют никакого
отношения к ее созданию! Как вы считаете, насколько восприимчивы

Глава 6. Организация проекта
107
они будут к предложенным вами изменениям? Обычно люди не лю-
бят меняться; особенно же им не нравится, когда другие навязывают
им свое мнение. Поберегите свои нервы и привлеките к работе над
проектом всех дольщиков. Их участие в дальнейшем не раз с лихвой
окупится пониманием, точностью, чувством сопричастности и ответ-
ственностью.
Не каждый дольщик должен входить в команду. Это неправомерно
увеличит размеры команды и сделает ее плохо управляемой. Если член-
ство в команде не обязательно, следует просто установить контакт доль-
щика с одним из членов команды и через него регулярно информиро-
вать заинтересованную сторону о планируемых и текущих событиях,
а также узнавать о ее идеях, необходимых для работы команды. (Кон-
такт нужно устанавливать через постоянного члена команды.)
Отметьте в списке заинтересованных сторон членский статус (по-
стоянный сотрудник, сотрудник в случае необходимости, не входит в
команду) каждого дольщика. Если дольщик не будет входить в состав
команды, то в графе «Связи с членами команды» нужно указать имя
члена команды, ответственного за эту связь.
Внесение изменений в состав команды
Теперь у вас в руках должен находиться полный список постоянных и
специально привлекаемых членов команды. Если этот список отлича-
ется от первоначального состава команды, то нужно утвердить новый
список у спонсора проекта и у всех менеджеров, отвечающих за по-
ставку ресурсов, на работу которых эти изменения могут повлиять.
Если вы продемонстрируете им свои соображения на этот счет (опи-
сание продуктов, которые необходимо произвести, оценку навыков и
список заинтересованных участников), то вам будет легче получить
их поддержку при изменении состава команды и распределении зада-
ний между ее членами.
«Дерево» подпроектов
Следуя всем нашим инструкциям по организации проекта, вы уже прак-
тически заложили основу для составления чартера вашего проекта, ко-
торую мы называем «деревом» подпроектов (рис. 6.5). «Дерево» под-
проектов --- это схематическое представление того, как организован
проект (на какие подпроекты он разбит), какие результаты будут полу-
чены при выполнении каждого из них и кто за что отвечает.

108
Глава 6. Организация проекта
Рис. 6.5. «Дерево» подпроектов
Нарисуйте основной ствол «дерева» и слева от него укажите назва-
ние вашего проекта. Затем нарисуйте «ветвь» для каждого подпроекта
и впишите под ней имя ответственного за этот подпроект лица.
Обозначьте ответвления для каждого результата работы (промежу-
точного или конечного). Перепроверьте схему, чтобы удостовериться,
что вы ничего не упустили и что все продукты упомянуты в схеме не
более одного раза.
Подсказка: причина, по которой каждый продукт должен быть вклю-
чен только в один подпроект, состоит в том, что расположение про-
дукта указывает на лицо, ответственное за его разработку. А основное
правило распределения подотчетности гласит, что за выполнение любо-
го задания или продукта должен отчитываться только один человек,
даже если работа над ним поручена группе.
Ваше «дерево» подпроектов должно напоминать развернутую на 90°
схему структуры организации, которой оно, по сути, и является, --- это
организационная схема проекта. Кроме того, такая схема отражает всю
работу, которая ведется в подпроектах. Иногда ее называют структурой
распределения работ (Work Breakdown Structure, WBS). Однако между
обычной структурой WBS и вашим «деревом» есть одно различие:
структура WBS обычно отображает все действия, которые нужно вы-
полнить, а не только их результаты. Из за этого она иногда становится
слишком подробной и чересчур сложной. Поскольку метод CORE PM
ориентирован на получение результатов, то нам нет необходимости
отображать в «дереве» абсолютно все, чем мы будем заниматься.

Глава 6. Организация проекта
109
Однако в больших проектах, когда работа ведется в командах под
проектов, каждый лидер может создать собственное «дерево» (рис. 6.6).
В этом случае стоит для удобства добавить еще один уровень, на кото-
ром бы перечислялись все операции, необходимые для создания дан-
ного продукта. Заодно здесь можно указать имя ответственного за вы-
полнение каждой из них.
Подсказка: нужно различать понятия «отчетность» и «ответствен-
ность». Если вы должны отчитаться за что то, это означает, что вы
должны контролировать ход данной работы. Если вы несете ответствен-
ность за работу, это означает, что вы выполняете данную задачу само-
стоятельно.
Примечание: важно помнить, что древовидная структура распреде-
ления работ по проекту не отражает последовательность, в которой
производятся продукты, сроки, необходимые для их выполнения, и их
взаимозависимости. О них мы поговорим позднее, когда будет состав-
лен график создания продуктов.
Рис. 6.6. «Дерево» подпроекта

110
Глава 6. Организация проекта
Передача полномочий команде
Организация проекта и распределение ответственности за каждый из
подпроектов и продуктов --- это один из способов, который поможет
вам передать полномочия команде. Преимущество передачи полномо-
чий заключается в том, что выполняемая работа при этом не требует
тщательной проверки всех заданий, над которыми трудятся члены ко-
манды. Делегирование полномочий избавляет вас от необходимости
контролировать каждую мелочь. Однако успешное делегирование не
сводится к тому, чтобы поручить сотрудникам создание продукта, на-
деясь, что все будет сделано правильно. Ниже приводится несколько
условий, выполнение которых необходимо для успешного делегиро-
вания полномочий членам команды:
члены команды должны участвовать в планировании и монито-
ринге проекта;
каждый член команды должен иметь представление о проекте
в целом --- почему проект был начат, какие у него цели;
каждый член команды должен понимать внутренние взаимосвязи
проекта --- то, как все составляющие проекта связаны друг с дру-
гом. (Мы вернемся к этому вопросу, когда будем рассматривать
график выпуска продуктов.);
целью проекта является получение конечного результата и проме-
жуточных продуктов, и за каждый из них должен нести ответствен-
ность один из членов команды. Это позволит участникам само-
стоятельно решать, как лучше произвести тот или иной продукт;
члены команды должны регулярно отчитываться перед командой
о состоянии работы;
команда должна иметь в наличии ресурсы, необходимые для вы-
полнения работы. К ним относятся время, деньги и люди. (Мы
рассмотрим эти вопросы подробнее в следующих главах, когда
речь пойдет о планировании ресурсов.)
Концентрация внимания на получаемых продуктах, а не на выпол-
нении отдельных заданий позволит команде придерживаться допу-
стимого уровня детализации и не даст отдельным членам команды и
лидерам подпроектных команд ограничиться деятельностью в рамках
своих задач. Вот несколько преимуществ работы, ориентированной на
получение продуктов:
созданный продукт/результат работы переходит от одного чело-
века к другому. Это называется передачей. При передаче Рауль

Глава 6. Организация проекта
111
татов работы в первую очередь требуется координация усилий
сотрудников, работающих над проектом, особенно если она про-
исходит между двумя отдельными подпроектами. Ориентация на
продукт позволяет отслеживать такие передачи;
каждый продукт должен быть готов к определенному сроку, следо-
вательно, при таком подходе к работе будет легче определить, во-
время ли он подготовлен;
можно определить себестоимость продукта;
заказчик сможет установить приемные критерии для особенно
важных промежуточных результатов работы.
Эти критерии определяются следующим заказчиком продукта, т. е.
ближайшим соседом в цепочке ресурсов и результатов, которая рас-
сматривалась выше. Внутренний заказчик продукта обычно является
членом команды и сам определяет требования к промежуточному про-
дукту и приемные критерии. Установив приемные критерии, внутрен-
ний заказчик не только вносит свой вклад в создание качественного
конечного продукта, но и избавляет команду от необходимости что то
переделывать.
Организация проекта: проверьте себя
Перед тем как перейти к оценке рисков, вернитесь еще раз к процессу
организации проекта, чтобы убедиться, что вы ничего не забыли.
Есть ли у вас все необходимые сотрудники, которые владеют теми
навыками, которые нужны для создания продуктов?
Определены ли все ключевые дольщики?
Все ли заинтересованные стороны представлены в команде тем
или иным образом (с помощью включения в команду постоянно-
го или специально привлекаемого для определенной цели члена
или посредством связи с одним из членов команды)?
Участвовала ли команда в процессе разбиения проекта на под
проекты?
Не превышает ли число членов головной команды допустимого
уровня --- десяти человек?
Включен ли в работу подпроект, задачей которого является управ-
ление всем проектом в целом?
Все ли промежуточные и конечные продукты проекта закреплены
за соответствующими подпроектами?

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

Глава 7
Оценка рисков
Случалось ли вам оказываться в ситуации, когда непредвиденные со-
бытия приводили к срыву ваших самых тщательно продуманных пла-
нов? Например, наступил тот самый день, когда должен состояться
торжественный обед с танцами по случаю успешного запуска на ры-
нок нового продукта. Поставщик продуктов питания привозит вам за-
казанное, и тут вы замечаете, что этих продуктов хватит только на 100 че-
ловек, а гостей будет не меньше 200. Или, например, во время приема ---
пикника под открытым небом начинается дождь и, выясняется, что никто
из организаторов не подумал о том, чтобы заранее подготовить какой
либо тент или навес. Всех этих рисков можно избежать и вечер прой-
дет гладко, если заранее выделить время и продумать то, как следует
действовать в случае даже самых незначительных отклонений от сце-
нария. Процесс планирования, позволяющий избежать лишних про-
блем, называется оценкой рисков.
Риск --- это проблема, которая может возникнуть. Цель оценки рис-
ков состоит в том, чтобы не дать потенциальным проблемам перера-
сти в реальные трудности. Как, например, можно предотвратить уже
упоминавшуюся проблему с поставкой еды? Нужно проверить реко-
мендации поставщика провизии и убедиться, что он вполне надежен.
Также стоит накануне вечером связаться с ним и удостовериться, что
все для праздничного мероприятия готово. А как быть с дождем, кото-
рый может пойти во время праздника? Как оценка риска может по-
мочь в ситуации, зависящей от такого неконтролируемого фактора, как
погода? Можно заранее заказать тент, а затем уточнить прогноз пого-
ды, чтобы убедиться в необходимости навеса. Или можно перенести
ваше торжество в закрытое помещение. Все это примеры ответных дей-
ствий на возможные риски, т. е. тех способов, которыми можно предот-
вратить те риски, вероятность возникновения которых была выявлена
при планировании.
Оценивать риск необходимо, так как это помогает реализовать про-
ект с наименьшим числом таких проблем, как:

114
Глава 7. Оценка рисков
задержки;
исправления;
дополнительные затраты;
головная боль и язва.
Классификация рисков
Существуют три вида рисков (табл. 7.1).
Риск «масштаба» проекта --- это любая потенциальная проблема, ко-
торая может помешать вам произвести конечный продукт того качества,
который удовлетворит потребителя. Иногда этот риск называют так-
же техническим риском. Он связан с возможными техническими или
технологическими проблемами. В примере с праздничным обедом и тан-
цевальным вечером такой риск может быть связан с возможностью до-
ставки 100 порций угощения вместо 200; 50% приглашенных в этом
случае уйдут голодными и вряд ли останутся довольны мероприятием.
Таблица 7.1
Виды рисков
Вид риска
Риск масштаба,
сферы проекта
Временной риск
Риск издержек
Описание
Риск, связанный с возможностью того, что конечный
продукт проекта не будет соответствовать всем прием-
ным критериям потребителя. Также называется техни-
ческим риском
Риск, связанный с вероятностью того, что работа не будет
выполнена до истечения запланированного срока
Риск превышения лимита затрат
Второй вид риска, временной риск, --- это риск потерь, связанных
с несвоевременной сдачей потребителю конечного продукта. Некото-
рые масштабные или технические риски могут одновременно являть-
ся и временными рисками. Например, если вы собираетесь применить
новые технологии, которые еще не очень хорошо освоены, то рискуете
не только ошибиться при их внедрении (риск масштаба), но и потратить
на изучение новых методов больше времени, чем планировали (вре-
менной риск).
Наконец, существует риск издержек, т. е. риск, связанный с возмож-
ностью того, что вы не уложитесь в бюджет. Например, люди на вашем
торжестве могут выпить больше, чем вы запланировали, или счета на
оплату закусок превысят отпущенные на банкет суммы.

Глава 7. Оценка рисков
115
В процессе оценки рисков, который мы вкратце рассмотрим далее,
вы познакомитесь с тремя видами рисков и поймете, что беспокоиться о
том, к какой категории принадлежит каждый риск, не нужно. Однако
полезно знать различия между этими видами, чтобы убедиться, что вы
выявили потенциальные проблемы каждого из трех видов.
Базовый процесс оценки риска можно разделить на три этапа: опре-
деление рисков, их анализ и разработка контрмер (способов избежа-
ния риска). На собрании, посвященном оценке рисков, необходимо
проработать все эти этапы.
Собрание, посвященное оценке рисков
Очень важно правильно подобрать людей для участия в собрании,
посвященном оценке рисков. Не приглашайте только лишь членов
команды. Пригласите на собрание всех, кто сможет помочь вам опре-
делить или обнаружить потенциальные проблемы. В табл. 7.2 перечис-
лены люди и группы людей, которых следует пригласить на собрание
по определению рисков.
Таблица 7.2
Участники собрания по оценке рисков
Участники собрания
Проектная команда и ее лидер
Спонсор и заказчик проекта
Другие заинтересованные
стороны (дольщики)
Описание
Члены команды могут помочь выявить риски;
кроме того, благодаря непосредственному
участию в этом процессе, они будут чувство-
вать сопричастность с выполняемой работой,
что снизит вероятность возникновения риско-
ванных ситуаций или даже полностью
исключит ее
Для спонсора и заказчика проект имеет огром-
ное значение. Приняв участие в определении
рисков, они будут чувствовать себя более ком-
фортно, поскольку увидят, что для предотвра-
щения рисков делается все возможное
Другие заинтересованные стороны --- это ме-
неджеры по ресурсам или функциональные
менеджеры, основные поставщики и все
остальные, кто заинтересован в проекте. Для
этих людей данный проект важен, поэтому
они наверняка предложат свои идеи и обеспе-
чат его поддержку, если привлечь их к уча-
стию в собрании

116
Глава 7. Оценка рисков
Окончание табл. 7.2
Участники собрания
Противники проекта
Технические эксперты
Люди, имеющие опыт участия
в сходных проектах (проектах,
в которых использовались по-
добные технологические ме-
тоды или обслуживались те
же заказчики, и т. д.)
Описание
Это люди, которые, скорее всего, что то име-
ют против вашего проекта. Пригласив их на
собрание, вы получите представление о том,
каковы, на их взгляд, уязвимые места проекта.
Кроме того, у вас будет возможность убедить
их принять участие в проекте
Пригласите людей, которые обладают какими
либо знаниями о технических аспектах про-
екта. Это поможет вам выявить возможные
технические проблемы
Пригласите людей, которые уже работали над
подобными проектами в прошлом. Их опыт
может оказаться очень полезным --- особенно
если вы плохо осведомлены о том, как
выполнялись эти проекты
Те, кто не являются членами команды, могут внести ценный вклад
в процесс оценки рисков:
став дополнительным источником новых идей;
действуя в качестве рычага, недостающего ресурса (особенно это
касается людей, которые необходимы команде, но не могут быть
ее членами);
взяв на себя обязательства и приняв участие в поиске решения
и принятии мер по снижению риска;
выдвинув свои предположения относительно потенциальных
рисков, чтобы команда могла использовать их для дальнейшего
анализа;
с пользой применяя опыт других людей;
убеждая их перейти от жалоб к участию в поиске решений;
информируя собравшихся о потребностях проекта и существу-
ющих рисках;
разъясняя дольщикам спорные вопросы и трудности проекта;
склоняя членов команды к участию и ответственности за утверж-
денное на собрании решение;
обращая противников в союзников.
Прежде чем проводить собрание, подготовьте помещение, достаточ-
но просторное для того, чтобы все участники смогли в нем комфортно

Глава 7. Оценка рисков
117
расположиться и в то же время легко по нему передвигаться, так как
большая часть работы будет проходить с использованием клейкой бу-
маги для заметок, которую нужно будет приклеивать к флип чарту или
к листу ватмана, прикрепленному к стене. Запаситесь клейкой бума-
гой для заметок и маркерами, и можно начинать собрание.
Первый этап --- выявление рисков
Первый этап --- выявление рисков --- начинается с процесса «мозгово-
го штурма». Попросите группу высказывать все приходящие в голову
идеи по поводу того, какие проблемы могут возникнуть при реализа-
ции проекта. Раздайте всем членам команды блоки клейкой бумаги
для заметок и маркеры, а затем попросите их описать все имеющиеся,
на их взгляд, риски. Прикрепите лист ватмана на стене и позвольте
сотрудникам выкрикивать идеи, записывать их, подходить к ватману
и прилеплять к стене записки на клейкой бумаге --- все одновременно.
Не устанавливайте очередность! Все должны генерировать идеи одно-
временно. Подобный способ «мозгового штурма» называется «Запи-
ши! Скажи! Прилепи!». Это еще один пример приема работы в коман-
де, учитывающий визуальный (клейкие листки), слуховой (скажи!)
и кинестетический (прикрепи!) стили восприятия. (Более подробно
мы рассказывали о стилях восприятия в гл. 3.)
При использовании «мозгового штурма» важно помнить о следу-
ющих простых правилах:
помните, что все идеи --- хорошие идеи;
следите за тем, чтобы все идеи были законченными и раскрытыми;
избегайте однословных определений, так как позже вы не сможе-
те вспомнить, о чем шла речь;
убедитесь, что все идеи записаны или листки с записями при-
креплены к ватману. Лучше всего для этого подойдет клейкая
бумага для заметок, которую затем можно прилепить к флип
чарту или листу ватмана на стене. Такие заметки легко передви-
гать, и во время проведения «мозгового штурма» каждый участ-
ник сможет рассмотреть все идеи;
помните, что идеи могут повторяться (иногда кажется, что пред-
ложенная мысль уже высказывалась ранее, но в ходе обсуждения
обнаруживается, что это совершенно другая идея);
делайте ставку на количество, а не на качество;
выйдите за рамки привычного --- «сойдите с ума», выскажите
самые невероятные и абсурдные идеи;

118
Глава 7. Оценка рисков
никакой критики и замечаний;
не останавливайтесь для того, чтобы обсудить что то;
поддерживайте активность участников.
Когда кажется, что участники уже исчерпали все идеи, попросите
их придумать еще десять идей. Это поможет группе ненадолго обрести
второе дыхание. Затем предложите сотрудникам определить, какие из
выдвинутых ими допущений могут затруднить реализацию проекта,
если не оправдаются. Например, при планировании вы допустили, что
хотя кафе «Magnolia Plantation», где вы собираетесь устроить вечерин-
ку, находится в 50 милях езды от офиса, посетителей это не отпугнет.
Нужно спросить себя, действительно ли это так? Может получиться,
что большая часть приглашенных решит не приезжать, а ведь основ-
ная цель торжества заключается в том, чтобы поблагодарить людей за
работу, которую они проделали, разрабатывая и выпуская на рынок
новую продукцию. Следовательно, риск неявки гостей из за отдален-
ности кафе должен учитываться при разработке проекта.
Запишите все предположения группы на листе бумаги. Затем нуж-
но преобразовать эти предположения в риски с помощью вопроса: что
произойдет, если это предположение оправдается и как следствие со-
здаст проблему для всего проекта. Нужно выписать проблемы или
риски на клейком листочке для заметок и прикрепить его рядом с други-
ми рисками, выявленными благодаря «мозговому штурму».
Второй этап --- анализ рисков
Сформулировав все возможные идеи о том, какие сбои могут произойти
в процессе реализации проекта, можно приступить к определению веро-
ятности того, что какая либо из этих проблем действительно возник-
нет, и ущерба, который она в этом случае причинит проекту. Воз-
можность такого события называется вероятностью риска. Ущерб,
который может быть нанесен в результате, называется влиянием
риска.
Вероятность риска
Для начала необходимо оценить вероятность того, что сбой может про-
изойти, воспользовавшись шкалой: нулевая, низкая, средняя или вы-
сокая вероятность (табл. 7.3).
Достигнув согласия относительно уровня вероятности той или иной
проблемы, запишите его в нижнем левом углу клейкого листочка для
заметок. Риск с нулевой вероятностью --- это событие, о котором точно

Глава 7. Оценка рисков
119
известно, что оно не произойдет. Такие события нужно поместить от-
дельно под заголовком «Нулевой риск».
Таблица 7.3
Оценка вероятности риска
Вероятность
Нулевая
Низкая (Н)
Средняя (С)
Высокая (В)
Значение
Нет ни одного шанса, что данное событие произойдет
Вероятность того, что данное событие произойдет, лежит
в диапазоне от 1 до 40%
Вероятность того, что данное событие произойдет, лежит
в диапазоне от 41 до 70%
Вероятность того, что данное событие произойдет, лежит
в диапазоне от 71 до 99%
Влияние риска
Затем попросите группу определить уровень возможных потерь для
каждого риска, выявленного в результате «мозгового штурма». Запи-
шите этот уровень --- нулевой, низкий, средний или высокий --- в ниж-
нем правом углу листочка для заметок. Например, уровень потерь в
случае, если угощения не хватит на всех гостей, возможно, окажется
высоким, но вероятность такого события очень мала. Риски с нулевым
уровнем потерь --- это события, которые никак не влияют на ход про-
екта. Расположите такие события в стороне под заголовком «Нулевой
риск» (табл. 7.4).
Таблица 7.4
Оценка уровня потерь
Уровень потерь
Нулевой
Низкий (Н)
Средний (С)
Высокий (В)
Значение
Даже если данное событие произойдет, оно не повлечет за
собой никаких потерь, поэтому это вообще не риск
Потери проекта в случае, если данное событие произойдет,
незначительны, но заметны как для заказчика, так и для
спонсора проекта
Потери проекта в случае, если данное событие произойдет,
довольно существенны и могут привести к нарушению
приемных критериев заказчика, выходу за временные или
бюджетные рамки
Потери проекта в случае, если данное событие произойдет,
значительны и могут поставить проект под серьезную
угрозу срыва или полностью провалить его

120
Глава 7. Оценка рисков
Матрица вероятности рисков/потерь
После того как вы оценили все риски, полезно систематизировать их
таким образом, чтобы выявить наиболее опасные. Сделать это можно
с помощью матрицы для анализа рисков, которая называется также
матрицей вероятностей/потерь, или ВП матрицей. Начертите на листе
ватмана сетку из девяти квадратов и откладывайте по вертикальной
оси (оси ординат) вероятности, а по горизонтальной оси (оси абсцисс) ---
потери. Разместите на этой диаграмме риски в соответствии с их низ-
кими, средними и высокими уровнями вероятности или потерь, как
показано на рис. 7.1.
Обратите внимание на то, что в некоторых квадратах стоит пометка
«низкие». Это означает, что сбои, которые попадают в данную область
диаграммы, --- это низкие риски. Такая оценка учитывает как вероят-
ность того, что сбой произойдет, так и уровень потерь при этом. Риски,
которые расположены в промежуточной области и помечены как «сред-
ние», --- это средние риски. Заметьте, что один из квадратов этой области
соответствует рискам с низким уровнем вероятности, но с высоким
уровнем потерь; общая его оценка при этом будет средней.
Пронумеруйте все риски, нанесенные на диаграмму, последователь-
но от верхнего правого угла к нижнему левому углу листа. Точный
порядок рисков не имеет большого значения; главное, чтобы каждому
Рис. 7.1. Диаграмма ВП матрицы

Глава 7. Оценка рисков
121
риску был присвоен отдельный порядковый номер. Это упростит за-
дачу их последующего анализа.
Оценка суммарного риска
Теперь можно вернуться назад и проанализировать расположение всех
рисков на диаграмме, а затем спросить у команды, насколько рискован-
ным является данный проект в целом? Высока ли степень риска? Или
она средняя? А может быть, низкая? Ваши риски в основном оказались
в правой верхней части диаграммы? Если так, то вы имеете дело с очень
рискованным проектом. Риски сосредоточены в левой нижней части диа-
граммы? Тогда это проект с низким уровнем риска. Большая часть рис-
ков попала в среднюю область? В этом случае риск средний (рис. 7.2).
Целью большинства проектов является «низкий» риск, поэтому далее
надо проанализировать, каким образом снизить уровень риска.
Третий этап --- разработка и анализ контрмер
ДЛЯ всех рисков, которые находятся в «средних» или «высоких» сек-
торах матрицы, найдите способы исключить риск или хотя бы снизить
его вероятность и/или уровень потерь. Например, предложения по
снижению риска, связанного с недостаточным количеством продук-
Рис. 7.2. Пример ВП матрицы для проекта со средним уровнем риска

122
Глава 7. Оценка рисков
тов для вечеринки, могут быть следующими: связаться с поставщиком
провизии за 48 часов до начала праздника и тщательно проверить, как
продвигается выполнение вашего заказа (это снизит вероятность дан-
ного риска); организовать работу буфета (это снизит потери); заказать
больше продуктов, чем требуется (это снизит вероятность); подгото-
вить дополнительные напитки (это снизит потери). Не все предложен-
ные идеи окажутся полезными, но целью «мозгового штурма» являет-
ся получение как можно большего количества предложений.
Выпишите все контрмеры на клейкие листочки для заметок и при-
крепите их к заметкам с описанием рисков. Укажите номер риска на
листочках с мерами, предложенными для его снижения. Проанализи-
руйте все риски вместе с потенциальными контрмерами, выработан-
ными в результате «мозгового штурма». Если какая либо контрмера
связана более чем с одним риском, то выпишете на отдельный листок
номера всех этих рисков и прикрепите к одному из них.
Завершив «мозговой штурм», необходимо выбрать те из предложен-
ных контрмер, которые будут включены в проект. Очевидно, что в пер-
вую очередь нужно внести в проект контрмеры, которые не требуют
дополнительных затрат --- не увеличивают продолжительности рабо-
чего времени и не повышают бюджетных расходов. Затем следует об-
ратить внимание на рациональные решения, которые помогают разре-
шить сразу несколько проблем. После этого включите в проект меры,
которые снизят высокие и средние риски до уровня низких.
Подсказка: убедитесь, что выбранные контрмеры не требуют денеж-
ных или временных затрат, превышающих потери, которые вы пытае-
тесь снизить с их помощью. Если дело обстоит именно так, то выгоднее
не решать проблему вовсе, чем использовать данную контрмеру для
снижения риска.
Выбирайте меры по снижению рисков таким образом, чтобы они не
противоречили приоритетным задачам проекта, указанным в чартере.
Такими приоритетами могут быть соответствие целям, срокам или
бюджету проекта. Если наиболее важен график выполнения работ, то
принимаемые меры не должны увеличивать общую продолжитель-
ность проекта. Если главное --- не превысить заявленные издержки, то
очевидно, что меры, требующие дополнительных затрат, не должны
стоять первыми в списке возможных вариантов, хотя для снижения
риска вам, возможно, потребуются именно такие контрмеры.
Включая в проект какую либо контрмеру, тут же назначайте кого
нибудь из команды ответственным за ее разработку. Имя ответствен-
ного лица укажите на листочке с описанием меры.

Глава 7. Оценка рисков
123
Наконец, оцените заново все вероятности и возможные потери от
рисков, которые могли уменьшиться благодаря принятию контрмер,
и надпишите их новые значения над найденными ранее на том же ли-
сточке (используйте для этого маркер красного цвета, чтобы отличать
старые значения рисков от новых). Затем прикрепите все карточки
с описаниями рисков к диаграмме в тех ячейках, которые соответству-
ют новым уровням вероятностей и потерь (рис. 7.3).
Повторная оценка общего риска
Отобрав все необходимые контрмеры и переоценив все вероятности и
потери, вернитесь к вашим приклеенным листочкам и заново оцените
суммарный риск проекта. Остался ли уровень риска данного проекта
высоким или средним? Если да, то необходимо обсудить сложившуюся
ситуацию со спонсором проекта и узнать, как он относится к остав-
шимся рискам. Возможно, проект со средним или даже высоким уров-
нем риска для него приемлем. Может быть, спонсор согласится выде-
лить больше времени и денежных средств на выполнение проекта или
изменит цели проекта для снижения общего риска. Ему придется при-
нять какое то из этих решений, предварительно согласовав его с за-
казчиком.
Рис. 7.3. Перенесение рисков на диаграмму с учетом их новых оценок

124
Глава 7. Оценка рисков
Оценка рисков: проверьте себя
Прежде чем завершить оценку рисков, необходимо убедиться, что вы
ничего не пропустили.
Пригласили ли вы технических экспертов, дольщиков, против-
ников проекта и членов команды на собрание по оценке риска?
Все ли риски выявлены? Пригласили ли вы для оценки рисков
людей со стороны, чтобы гарантировать, что ничего не будет упу-
щено?
Исключили ли вы из рассмотрения те риски, уровень потерь или
вероятность которых равны нулю?
Проводили ли вы «мозговой штурм» до тех пор, пока не получи-
ли все возможные предложения по снижению риска, включая и
те, которые на первый взгляд казались абсурдными?
Согласуются ли выбранные контрмеры с приоритетными задача-
ми проекта?
Назначены ли ответственные за разработку каждой меры по сни-
жению риска?
Является ли суммарный риск проекта низким? Если нет, то по-
лучено ли разрешение спонсора проекта на дополнительные за-
траты ресурсов или на сужение целей проекта с целью снижения
суммарного риска? Или спонсор проекта согласен на высокий
уровень риска?
Документальная форма проектного плана
Ваш последний шаг на этом этапе --- документально оформить собран-
ную информацию. Лучше всего отразит проделанную группой работу
по оценке риска простая таблица (рис. 7.4).
Укажите название проекта и имя лидера проекта. Затем впишите
первоначальную оценку суммарного риска по проекту, которая была
получена до разработки контрмер. После этого приведите окончатель-
ную оценку суммарного риска и разработанные для его снижения меры.
Запишите в таблицу порядковые номера рисков, их описания, пер-
воначальные уровни вероятности и потерь. Перечислите все контрме-
ры, которые были предложены в процессе «мозгового штурма» для сни-
жения каждого из рисков, включая и не вошедшие в проект. Затем
поставьте контрольную отметку напротив тех, которые будут исполь-
зоваться в проекте, и впишите имя ответственного за применение этой

Глава 7. Оценка рисков
125
Рис. 7.4. Форма для оценки рисков
меры лица. Наконец, укажите новые оценки уровней вероятности
и потерь рисков, которые были получены с учетом применения контр-
мер.
Поздравляем! Вы благополучно завершили процесс оценки рисков.

Глава 8
Составление графика работ
График работ определяет, что и к какому времени должно быть сдела-
но. При работе над большинством проектов требуются два вида гра-
фиков: этапный график и график сдачи конечных продуктов. Этапный
график --- это календарная схема проекта «с высоты в 10 тыс. футов».
В нем отражают 10 12 ключевых событий, вех в работе над проектом
и устанавливают сроки их завершения. График сдачи конечных про-
дуктов --- это детальное представление проекта «с расстояния в 100 фу-
тов». В нем отражены все продукты, сроки их выполнения и взаимоза-
висимости между подпроектами.
Этапный график нужен для того, чтобы осветить основные моменты
работы и обсудить их с заинтересованными сторонами (дольщиками).
График сдачи конечных продуктов служит целому ряду целей. Он:
отражает срок сдачи каждого из продуктов, а также информацию
о том, в каком подпроекте ведется работа над этим продуктом;
определяет взаимозависимость между продуктами;
показывает даты этапного графика;
обеспечивает мониторинг хода работ на этапе выполнения про-
екта;
отражает последовательность технологических операций, от произ-
водства первого продукта до получения конечного продукта.
Последовательность технологических операций --- это некая после-
довательность шагов (продуктов), необходимых для производства
конечного продукта. Этот процесс состоит из ряда передач промежу-
точных продуктов от одного человека к другому (цепочка ресурсов
результатов рассматривалась выше). График сдачи конечных продук-
тов --- это, в сущности, схема технологических операций, дающая
представление о том, когда будет создан продукт и кто получит его
для производства последующего продукта в цепи. Так как график сда-
чи конечных продуктов отображает связанные между собой трудовые
процессы и предполагаемые сроки сдачи каждого продукта, то он яв-
ляется одним из наиболее важных элементов проектного плана.

Глава 8. Составление графика работ
127
Примечание: даже если вы считаете, что члены вашей команды уже
знакомы со схемой технологических операций, проверьте это еще раз.
Существует вероятность того, что при составлении графика сдачи ко-
нечных продуктов будут сделаны настоящие «открытия». Даже очень
опытные сотрудники часто удивляются некоторым из них, когда ви-
дят, как их работа связана с проектом в целом.
Первый шаг, который вы должны сделать для составления этапного
графика и графика сдачи конечных продуктов, заключается в том, что-
бы выделить в вашем проекте вехи, основные события.
Выделение вех в проекте
Первые три вехи, которые необходимо включить в график работы, ---
это «этапные ворота» проекта. Они свидетельствуют о завершении
основных этапов управления проектом. Первые «этапные ворота», со-
ставление чартера, не включаются в этапный график работы, так как
к началу планирования проекта эта стадия уже завершена. Остальные
этапы --- утверждение проектного плана (что указывает на завершение
этапа планирования), передача конечного продукта потребителю (что
указывает на завершение этапа выполнения) и отчет о завершении
проекта (что указывает на окончание этапа завершения проекта) ---
должны быть включены в этапный график работы.
Кроме того, стоит добавить от шести до десяти промежуточных вех
на этапе воплощения проекта. Если ваш проект включает в себя «этап-
ные ворота», используйте и их. («Этапные ворота» --- это ключевые ре-
зультаты в технологическом процессе. Обычно они используются
организацией для принятия решений типа продолжать/не продолжать
работу по проекту.) Если вы не используете «этапные ворота», то вам
потребуется выбрать 6 10 ключевых продуктов, каждый из которых
означает завершение какого либо большого сегмента работы по проек-
ту. Выбранные продукты могут производиться как в процессе вопло-
щения главного проекта, так и в одном из подпроектов: важно, чтобы
полученный продукт имел значение для проекта в целом. Если спонсор
или заказчик проекта определил крайние сроки получения каких либо
результатов или продуктов, то их тоже необходимо включить в этап-
ный график, так как, наметив эти крайние сроки, заказчик или спонсор
указал на их важность, а этапный график как раз должен отражать наи-
более значимые конечные результаты. Обдумывая график работы, рас-
сматривайте его с точки зрения документа, который будут изучать люди,
не входящие в вашу команду. Спросите себя: «Какие результаты работы
имеют значение для спонсора, заказчика и других участников проекта?»

128
Глава 8. Составление графика работ
Постарайтесь подобрать вехи таким образом, чтобы охватить весь
этап воплощения проекта. Когда все даты сосредоточены в самом начале
или, наоборот, в конце этапа претворения проекта в жизнь, то дольщикам
проекта трудно определить, идет ли выполнение проекта по графику.
Это создает опасное положение, которое может привести к нежелатель-
ным беспокойствам и стрессу. Равномерное распределение ключевых
вех (рис. 8.1) поможет убедить все заинтересованные стороны, что вы
успешно справляетесь с работой; они будут благодарны вам, и у них не
останется поводов для паники и вмешательства в вашу работу.
После того как вы определили все вехи, запишите название каждой
из них в центре клейкого листочка для заметок. Если спонсор или за-
казчик установили крайние сроки достижения этих вех (например,
крайний срок получения конечного продукта), то напишите эти даты
красным фломастером в правом нижнем углу листочка. (Вы будете
использовать эти листочки в процессе создания графика выполнения
продукта, составление которого будет следующим вашим действием.)
Если подобные крайние сроки не были установлены, оставьте пока это
место на листочках пустым.
Теперь члены команды должны подготовиться к собранию, где будет
обсуждаться график производства продукта. В процессе подготовки
к этой встрече каждый член команды должен подготовить для своих
продуктов клейкие листочки, включая все контрмеры, которые были
определены для этих продуктов на собрании по оценке риска. Далее
члены команды должны оценить, как много времени им потребуется
для получения каждого продукта или для принятия контрмер.
Рис. 8.1. Распределение вех в процессе воплощения проекта

Глава 8. Составление графика работ
129
Оценка занятости персонала при получении продукта
Фактическое рабочее время в часах или неделях, необходимое для
получения конечного продукта, называется временными затратами пер-
сонала или просто занятостью. В примере с организацией праздничного
обеда с танцами то время, которое потребуется для составления списка
приглашенных, --- это временные затраты на получение данного продук-
та. Давайте предположим, что временные затраты оценены в 12 часов,
или в полтора рабочих дня. Когда мы говорим о временных затратах на
создание продукта, мы имеем в виду чистое время, которое необходимо
для его производства. Другими словами, это не количество дней, в те-
чение которых вы должны выполнить эту работу, параллельно выпол-
няя с десяток дел или просто ожидая информации от других людей;
это фактическое время, которое вы посвящаете производству продукта.
Большинство людей работает над проектом лишь часть своего ра-
бочего дня, а следовательно, календарное время, необходимое для про-
изводства продукта, оказывается больше, чем временные затраты на
работу. Если, к примеру, вы одновременно занимаетесь еще двумя про-
ектами, то вы сможете уделить производству вашего продукта, скажем,
20% своего рабочего времени. Календарное время работы, или период
времени, за который вы сможете составить список приглашенных,
в этом случае составит 7,5 дней (12 часов, или 1,5 дня, деленных на
20% = 7,5 дней на получение конечного продукта).
Исключая те случаи, когда вы 100% своего рабочего времени посвя-
щаете получению конечного продукта и ваша работа не требует полу-
чения какой либо информации от кого бы то ни было, календарный
период времени всегда оказывается длиннее, чем чистые временные
затраты. Чем больше проектов и другой работы вам нужно сделать,
тем больше календарного времени вам потребуется для получения
конечного продукта.
Примечание: календарный период времени должен выражаться в ко-
личестве рабочих дней, календарных недель или календарных меся-
цев, требующихся для получения конечного продукта. Пять рабочих
дней обычно считаются календарной неделей.
Календарный период времени, необходимый для работы, должен
определяться и оцениваться человеком, который отвечает за произ-
водство продукта, основываясь на своем личном опыте, опыте других
и данных, полученные из отчетов об уже завершенных проектах. Если
вы имеете дело с большим проектом, требующим разбиения на под
проекты, то менеджер каждого из подпроектов должен попросить чле-
нов своей команды оценить календарный период времени, который

130
Глава 8. Составление графика работ
потребуется для производства их продуктов. Как и в случае любых
других оценок, вы получаете лишь более или менее реальные предпо-
ложения. Когда вы оцениваете календарную продолжительность из-
готовления отдельных продуктов, не стоит учитывать так называемый
закон подлости Мерфи. Этот закон подразумевает появление непред-
виденных обстоятельств в процессе воплощения проекта, и будет луч-
ше, если вы добавите поправку на этот закон при расчете длительности
всего проекта, а не работы над каждым продуктом в отдельности. Мож-
но назвать две основные причины, по которым непредвиденные об-
стоятельства лучше включить в общий план:
1. Если делать поправку на закон Мерфи при оценке временных
затрат на каждый продукт, то в результате вы получите больше
непредвиденных обстоятельств, чем нужно. Вы, конечно, знаете
о том, что закон Мерфи обязательно внесет свои коррективы, но вы
не знаете, где и когда он может сработать, а значит, делая поправки
всюду, неоправданно увеличиваете объем временных затрат.
2. Время, которое добавлено к общей длительности работы на случай
непредвиденных обстоятельств, обычно тратится попусту. Так как
сотрудники всегда чем нибудь заняты, то стараются потянуть
время и не начинают работу точно в срок и даже, более того, тя-
нут до последней минуты, чтобы только только успеть к запла-
нированному сроку выполнения работы. Если поправку на не-
предвиденные обстоятельства добавлять к временным затратам
на каждый продукт, то работа над ними просто начнется позднее
и время, которое было отпущено на случай непредвиденных об-
стоятельств, уже будет бесполезно растрачено из за запоздалого
старта. И если теперь вдруг сработает закон Мерфи, то вы не успее-
те выполнить работу в срок, так как дополнительного времени
для решения возникших проблем уже не будет. Лучше всего оце-
нить время, которое потребуется для работы над продуктом, безо
всяких поправок, а затем добавить запас времени в общий гра-
фик. Если возникнет проблемная ситуация, то это время можно
будет перераспределить между сотрудниками.
Попросите членов команды записать все временные затраты и ка-
лендарную продолжительность работ в нижней части листочков с дан-
ными по каждому из продуктов. В центре листочков укажите наиме-
нование и номер продукта согласно «дереву» подпроектов (рис. 8.2).
Подсказка: используйте для подпроектов липкие листочки разных
цветов. Это поможет вам визуально различать продукты во время со-
здания графика работ.

Глава 8. Составление графика работ
131
Рис. 8.2. Клейкие листочки с информацией о конечных продуктах
После того как временные затраты и календарное время оценены,
вы готовы к собранию по разработке графика сдачи продуктов.
Создание сетки графика
Для подготовки к собранию по созданию графика сдачи продуктов
нужно зарезервировать просторное помещение с пустыми стенами.
Прикрепите к стене лист ватмана длиной как минимум 3 метра. На-
чертите на нем большую сетку. Вдоль нижней горизонтальной линии
сетки нанесите временную шкалу проекта (разбив ее на недели, меся-
цы или кварталы в зависимости от продолжительности проекта).
Вдоль левой вертикальной оси сетки нанесите названия подпроектов.
Если график большой, то при желании можно указать названия также
и с правой стороны. Начертите горизонтальные линии (наподобие до-
рожек в бассейне), разделяющие соседние подпроекты (рис. 8.3).
Подсказка: оставьте между подпроектами свободное место, доста-
точное по меньшей мере для двух рядов липких листочков.
Разместите все листочки, изготовленные при составлении поэтап-
ного графика, на временной шкале (вдоль нижней горизонтальной оси),
приблизительно в тех точках, где, по вашему мнению, должна завер-
шиться данная работа. Если для этих вех установлены крайние сроки, то
укажите их красным цветом в нижней части листочка и поместите их
на шкале точно там, где указана эта дата. Если вам известны причины, по
которым был определен именно такой срок, то их нужно тоже указать
на листочке.
Примечание: если крайний срок получения вехи отмечен красным
цветом, то вы помните, что эта дата установлена спонсором или заказ-
чиком проекта и что ее нельзя изменить без предварительного согласо-
вания. Если же сроки намечены членами или руководителем команды,
то отмечайте их карандашом. Это будет означать, что даты установле-

132
Глава 8, Составление графика работ
Рис. 8.3. Сетка графика
ны вами; следовательно, пока проектный план не будет утвержден, их
можно изменять без предварительного согласования.
Попросите членов команды наклеить все листочки на дорожку, на-
черченную для их подпроекта, приблизительно над той датой на
временной шкале, к которой планируется закончить данную работу.
Но выписывать сроки на сам листочек пока не нужно.
Определение взаимозависимостей
Перед тем как вы сможете определить сроки сдачи конечных про-
дуктов, нужно определить взаимозависимости отдельных продуктов,
одни из которых служат основой для получения других. Предшеству-
ющий продукт --- это продукт, который служит ресурсом для последу-
ющих продуктов, или продукт, от которого тем или иным образом
зависит производство последующих продуктов. В примере с органи-
зацией нашего праздничного обеда с танцами для того, чтобы начать
рассылку приглашений, их нужно сначала напечатать; следовательно,
печать приглашений и рассылка приглашений --- это два связанных
между собой продукта, причем печать предшествует рассылке. Рассыл-
ка приглашений, напрямую зависящая от процесса печати, является
последующим продуктом. У одного продукта может быть несколько
предшествующих и последующих продуктов (рис. 8.4).

Глава 8. Составление графика работ
133
Рис, 8.4. Предшествующие и последующие продукты
Перенос данных о взаимозависимостях на график
Чтобы определить срок сдачи продукта, сначала необходимо про-
считать его предшествующие продукты. Начните с листочков, рас-
положенных слева; именно эти продукты будут получены в первую
очередь. Для каждого продукта установите, нужно ли подготовить
какие либо продукты до того, как можно будет приступить к работе
над ним. Если вы обнаружите продукт, для которого не требуется пред-
шествующих продуктов, то определите для него дату получения сле-
дующим образом:
напишите дату, когда вы планируете приступить к работе над
продуктом, в нижнем левом углу на листочке для заметок. Это
будет дата начала производства продукта (лучше всего записать
ее карандашом, так как, возможно, вам придется изменить дату,
составляя окончательный график работ);
прибавьте продолжительность выполнения работ к дате начала
производства (продолжительность работ должна быть уже записа-
на посередине нижней части листочка). Продолжительность долж-
на выражаться в рабочих днях, неделях или месяцах. Начальная
дата плюс продолжительность работ --- это дата сдачи готового
продукта;
напишите карандашом дату сдачи готового продукта в нижнем
правом углу.
После того как вы спланировали сроки изготовления продуктов, не
требующих предварительного получения других продуктов, можно
перейти к последующим, создание которых зависит исключительно от
уже полученных продуктов (предшествующих). Рассчитайте дату на-
чала и окончания работ по получению того или иного последующего

134
Глава 8. Составление графика работ
продукта. Начало работ обычно назначается на день, следующий за
наиболее поздней возможной датой сдачи предшествующего продукта.
Для расчета даты начала изготовления продуктов, которые связаны бо-
лее чем с одним предшествующим продуктом, используется дата оконча-
ния работ по получению самого последнего из всех продуктов (рис. 8.5).
Переходите от одного продукта к другому в такой последовательности:
определите все предшествующие продукты;
определите наиболее позднюю возможную дату получения того
или иного предшествующего продукта;
определите дату начала работ по созданию последующего про-
дукта. Если это возможно, то дата начала работ должна прихо-
диться на следующий день после самого позднего срока сдачи
самого последнего продукта. Уточните у членов команды, не свя-
зан ли кто либо из них личными обязательствами, например по
выполнению других проектов, командировками и т. д., которые
могут помешать своевременному началу работ;
прибавьте продолжительность работ к дате их начала --- это дата
окончания работ;
прикрепите листочек для заметок с информацией о продукте на-
против деления на временной шкале, соответствующего дате сда-
чи работ;
запишите дату сдачи работ в нижней части листочка в правом углу;
начертите стрелки от предшествующего продукта к последующему
(последующим).
Спланировав получение всех продуктов, вернитесь назад и проана-
лизируйте весь график работ в целом (рис. 8.6). Найдите продукты, на
которых цепочка обрывается и которые не связаны с последующими
Рис. 8.5. Подсчет дат получения продуктов

Глава 8. Составление графика работ
135
Рис. 8.6. График выполнения работ
продуктами. Если этот продукт не поставляется потребителю, то, зна-
чит, вы что то перепутали: либо этот продукт не нужен для проекта,
либо вы упустили из виду какой то значимый для технологического
процесса последующий продукт.
Обозначьте даты тех ключевых вех, для которых не были назначены
крайние сроки завершения работ. Если обнаружились вехи, которые
невозможно завершить к назначенному крайнему сроку, то нужно:
» узнать у спонсора проекта, есть ли возможность перенести край-
ний срок сдачи данной работы;
пересмотреть график работ, если крайний срок сдачи работы из-
менить нельзя. (Мы рассмотрим это более подробно чуть позже.)
Преимущества метода разработки графика работ
вручную
Составление графика работ с помощью листа ватмана и клейких ли-
сточков имеет ряд преимуществ по сравнению со способом, когда лидер

136
Глава 8. Составление графика работ
проекта сидит за своим компьютером и разрабатывает график работ
с помощью какой либо компьютерной программы:
все члены команды принимают участие в создании графика ра-
бот;
конфликтные ситуации, вызванные неудобством графика работ,
в командной среде немедленно устраняются;
каждый член команды понимает, от кого зависит его работа и кто
будет зависеть от результатов его работы;
члены команды лучше знают свои собственные графики работы
и могут изменять сроки начала и сдачи работ по созданию под
продуктов таким образом, чтобы наиболее эффективно сочетать
данную работу с другими своим обязанностями;
каждый член команды представляет полную картину работы и то,
каким образом связаны все ее составляющие.
Однако листочки для заметок имеют существенный недостаток: их
размер стандартен, и поэтому при разработке графика продолжитель-
ность работ не отображается визуально. Этот недостаток легко испра-
вить, если нарисовать график с учетом продолжительности работ. Что-
бы показать продолжительность работ для каждого продукта, можно
начертить вокруг листочка прямоугольник, начинающийся датой на-
чала работ и заканчивающийся на дате сдачи работ. Таким образом,
вы получите так называемый график Ганта (рис. 8.7). Используйте для
изготовления прямоугольников цветные маркеры и постарайтесь об-
вести листочки как можно точнее.
Рис. 8.7. График Ганта

Глава 8. Составление графика работ
137
Резервное время
Начертив график Ганта, вы, вероятно, заметите, что между некоторы-
ми парами продуктов на графике нет пустого места. Между другими
парами продуктов вы обнаружите незанятые промежутки времени.
Такие промежутки называются резервным временем. Резервное вре-
мя --- это дополнительное время между сроком сдачи продукта и сро-
ком начала работы над следующим продуктом. Обычно оно возника-
ет, когда для производства продукта требуется закончить несколько
предшествующих продуктов, а работу над последующим продуктом
нельзя начинать, пока не будет готов последний из предшествующих.
В результате между последующим и одним или несколькими предше-
ствующими продуктами образуется резервное время (рис. 8.8).
Резервное время означает, что если получение предшествующего
продукта (с резервным временем после срока его сдачи) будет задержа-
но на время, меньшее или равное резервному, то работу над последу-
ющим продуктом все же можно будет начать вовремя. Если же такого
резерва нет, то сдача предыдущего продукта с опозданием приведет
к задержке начала работ над следующим продуктом.
Для каждой пары предыдущих/последующих продуктов нужно
обвести в кружок те, которые не имеют резервного времени. Если гра-
фик нарисован без учета продолжительности работ, то определить про-
дукты без резервного времени можно, попарно рассмотрев все пре-
дыдущие и последующие продукты и обведя кружком те из них, у которых
нет запаса времени между завершением работы над предыдущим про-
дуктом и началом работы над последующим продуктом.
Рис. 8.8. Резервное время

138
Глава 8. Составление графика работ
Определение критического пути
Линия, проходящая через весь график и соединяющая продукты, между
которыми отсутствует резервное время, называется критическим путем.
Критический путь --- это самая длинная линия на графике; именно она
определяет дату сдачи конечного результата работы. Ведь если какой
то из продуктов сдать позже назначенного срока, то конечный продукт
также будет получен с задержкой. А быстрее проект нельзя выполнить,
поскольку на критическом пути нет резервного времени (если только
не ускорить работу над продуктами, которые включены в критический
путь).
Когда необходимо сократить график выполнения работ, то сначала
нужно определить критический путь. Если график выполнения работ
не слишком запутан, то можно соединить обведенные кружками про-
дукты без резерва времени и проследить критический путь на графике
(рис. 8.9). Это напоминает ориентирование в лабиринте.
Однако если из за слишком большого количества продуктов очень
трудно визуально определить критический путь, то в этом случае
следует воспользоваться компьютерной программой для календарно-
го планирования. Почти каждая программа для планирования проек-
тов позволяет определить критический путь. Вам нужно лишь ввести
в компьютер данные из составленного вами графика производства про-
дуктов. Потребуется указать наименование каждого продукта (обыч-
но этот раздел называется в программе «Операция»), длительность
работ, дату начала и сдачи работ и предшествующие продукты. (В настоя-
щее время большинство компьютерных программ сами рассчитывают
даты начала и сдачи работ, если вы сообщите им продолжительность
работ и данные о предшествующих продуктах. Вы увидите, что в итоге
получатся те же даты, что и в результате расчетов на собрании по со-
ставлению графика работ.) После того как в программу будет введена
вся информация о продуктах, на графике появится критический путь.
Включение в график дополнительного «страхового»
времени
Проблема, возникающая при планировании любых проектов, заклю-
чается в том, что предсказать или полностью проконтролировать то,
что произойдет в будущем, нельзя. Все, что мы можем сделать, --- это
спланировать будущие события с большей или меньшей точностью.
Чем лучше вы информированы о примерной продолжительности работ

Глава 8. Составление графика работ
139
Рис. 8.9. Определение критического пути
над подпроектами и о связанных с ними рисках, тем точнее будет ваш
график.
Кроме того, чем долгосрочнее планы, которые мы составляем, тем хуже
нам удается прогнозировать будущее. Следовательно, графики менее
длительных проектов, как правило, точнее, чем более протяженные.
Так как будущие события всегда связаны с неопределенностью, то
при их планировании, как и при оценке продолжительности работ,
необходимо в конце общего графика делать поправку на непредвиден-
ные обстоятельства, чтобы застраховаться от неожиданностей. Поправ-
ка на непредвиденные обстоятельства играет в данном случае роль стра-
хового полиса. Она может и не понадобиться, но лучше ее иметь, чем
работать без нее, так как если подлый закон Мерфи сработает, то страхо-
вой запас времени поможет выполнить работу в соответствии с уста-
новленными крайними сроками.
Магической формулы для определения объема необходимого стра-
хового времени не существует. Это время зависит от следующих фак-
торов:
сложность проекта. Чем сложнее проект, тем больше «страхового»
времени вам понадобится;
уровень риска проекта. Чем рискованнее проект, тем больше «стра-
ховки» вам нужно;
продолжительность проекта. Более долгие проекты требуют боль-
ше «страхового» времени, так как с ростом продолжительности
становится сложнее предсказать будущее;
ваш опыт выполнения подобных проектов. При его наличии вам
потребуется учитывать фактор случайностей в меньшей степени,
чем в случае, если вы впервые выполняете проект;

140
Глава 8. Составление графика работ
опыт команды. Чем опытнее команда, тем меньше будет поправ-
ка на непредвиденные обстоятельства, так как оценка команды
окажется более точной;
объем и точность данных, полученных на основе уже выполненных
в прошлом подобных проектов. Если вы располагаете точными
статистическими данными, то ваша оценка будет ближе к реаль-
ности. Следовательно, потребуется меньше «страхового» времени;
надежность поставщиков. Чем менее надежны поставщики, тем
больше «страховки» нужно;
степень, в которой имеющиеся ресурсы приходится распределять
между различными проектами. Это фактор создает значительную
неопределенность при оценке и увеличивает риск того, что ре-
сурсов на выполнение данного проекта не хватит, потому что они
будут оттянуты для работы над другими проектами.
Какого запаса «страхового» времени на случай непредвиденных
обстоятельств будет достаточно? Об этом можно только догадывать-
ся. До тех пор, пока у вас нет достоверных данных, лучше всего
перестраховаться и запланировать даже больший запас, чем вы счита-
ете нужным.
Сокращение графика работ
Если ваш график с учетом «страхового» времени не позволяет соблю-
сти крайние сроки поучения продуктов, то необходимо рассмотреть
возможность сокращения некоторых сроков. Это не означает, что нужно
отказаться от «страхового» времени. Если вы не предусмотрите время
для защиты от рисков, то тактическое планирование стопроцентно га-
рантирует, что вы сорвете сроки выполнения, так как закон Мерфи
непременно сработает в тот или иной момент. Вот несколько вопро-
сов, на которые нужно ответить, чтобы выяснить, за счет чего можно
сократить график:
Предусмотрен ли «страховой» запас времени для каждого из оце-
ниваемых периодов работы? Можно ли объединить эти резерв-
ные «страховки» в конце графика? Если запас времени на случай
непредвиденных обстоятельств перенести в конец графика, а не
добавлять к сроку выполнения работ для каждого продукта, то
в общей сложности времени потребуется меньше.
Можно ли параллельно производить продукты, которые в дан-
ном графике создаются последовательно?

Глава 8, Составление графика работ
141
Можно ли начать работать над последующим продуктом до того,
как последний предшествующий продукт будет полностью за-
вершен, используя уже готовые составляющие продукты?
Можно ли привлечь к работе дополнительные людские и прочие
ресурсы, чтобы сократить общую продолжительность выполне-
ния продукта?
Можно ли выполнять обзоры результатов по телефону или по-
средством видеоконференции, вместо того чтобы делать это лично
или по почте? (Для обзоров результатов потребуется значитель-
ное время, поэтому уменьшение их продолжительности на кри-
тическом пути сократит график в целом.)
Если нужно заказать оборудование, то можно ли сделать это за-
ранее, чтобы зарезервировать товар в магазине поставщика?
Можно ли сократить время поставки товара с помощью курьера,
работающего ночью, или услуг перевозки, предоставляемых за
дополнительную плату?
Может ли спонсор проекта помочь высвободить основные ресурсы
настолько, чтобы работа над проектом пошла быстрее?
Не стесняйтесь обращаться к спонсору проекта за поддержкой или
за советом. Покажите ему график получения продуктов и узнайте, за
счет чего, на его взгляд, можно сократить время работы. Однако не
пытайтесь сократить график производства продуктов без достаточных
на то оснований. В итоге вы наверняка получите нереалистичный
график работ, в который не сможете уложиться, опоздав к крайнему
сроку сдачи тех или иных важных продуктов.
Возможности выбора при составлении графика работ
Как быть, если вы не успеваете выполнить работу в срок, предусмо-
тренный графиком? Если в списке приоритетов вашего проекта указа-
но, что уложиться в сроки важнее, чем сохранить запланированный
объем затрат, то нужно позаботиться о возможности «покупки време-
ни». Это можно сделать, включив в график дополнительные ресурсы,
например помощь со стороны внешних консультантов. Если сроки важ-
нее, чем достижение всех целей проекта, то в качестве одного из вари-
антов можно уменьшить объем работ. С помощью метода «мозгового
штурма» можно найти несколько вариантов того, как именно сузить
масштаб работ (при условии, что в крайние сроки и в ограничения по
затратам необходимо уложиться), а затем предложить рассмотреть эти

142
Глава 8. Составление графика работ
возможности спонсору и заказчику проекта. Пусть выбирают, как луч-
ше распорядиться ресурсами проекта --- временем и деньгами.
Сделав выбор между крайними сроками, затратами и целями проек-
та, можно окончательно утвердить оба графика работ. Проанализируйте
ключевые события и определите их сроки с учетом дат, указанных в гра-
фике сдачи продуктов. Обведите даты начала и окончания работ на всех
листочках с информацией о продуктах. Начертите маркером стрелки,
определяющие взаимозависимости между продуктами. График рабо-
ты составлен! Теперь можно приступить к разработке бюджета проекта.
Составление графика работ: проверьте себя
Теперь самое время для критической оценки и анализа. Ниже пред-
ставлены контрольные вопросы для проверки проделанной работы:
Включили ли вы в ваш график контрмеры для снижения риска?
Все ли продукты либо используются для создания последующего
продукта, либо поставляются потребителю проекта? На графике
не должно быть продуктов, на которых цепочка обрывается, хотя
они не поставляются при этом потребителю.
Реалистичен ли этот график? Считает ли команда его выпол-
нимым?
Перенесли ли вы «страховое» время на случай непредвиденных
обстоятельств в конец графика? Не добавили ли вы его к срокам
изготовления каждого продукта?
Отражает ли «страховое» время уровень риска, который опреде-
лен в графике?
Все ли указанные в графике крайние сроки вы сможете соблюсти?
Если нет, то обсудили ли вы этот график со спонсором проекта?
Довели ли вы до конца поэтапный график работ?
Документальная форма проектного плана
При желании вы можете включить поэтапный график и график сдачи
продуктов в ваш проектный план. Для того чтобы создать воспроизводи-
мый график выполнения продуктов, можно внести данные в компью-
терную программу для календарного планирования и затем по частям
распечатать график.

Глава 9
Разработка бюджета
Вы почти закончили процесс планирования. Уже определен масштаб
проекта, выполнена оценка рисков и составлен график работ. Вы орга-
низовали этот проект, т. е. знаете, кто, чем и когда будет заниматься.
Теперь пора приступить к разработке бюджета, а затем к составлению
итогового проектного плана.
Обычно в бюджет включают два вида затрат: внутренние затраты
организации, такие как рабочее время сотрудников, перекрестные рас-
ходы между отделами, и затраты внешние, такие как покупка оборудо-
вания или услуг.
Затраты на работу персонала
Все проекты требуют вложения денежных ресурсов, даже если за пре-
делами организации средства не расходуются. Расходы внутри орга-
низации необходимы, так как люди, вовлеченные в проект, работают
над ним не бесплатно. Силы, вкладываемые сотрудниками в проект,
называемые рабочим вкладом или трудовыми издержками, требуют
от организации затрат в форме заработной платы, премий и наклад-
ных издержек. Затраты на деятельность персонала --- это и есть основ-
ные внутренние затраты проекта.
Многие организации не учитывают стоимость рабочего времени, так
как проекты выполняются для внутренних потребителей и организа-
ция списывает подобные расходы как часть затрат на ведение бизнеса.
Временные затраты обычно игнорируются, так как это невозвратные
издержки. Но пренебрегать затратами на работу персонала не стоит,
так как необходимо ознакомить руководство с суммарной оценкой за-
трат по проекту, прежде чем приступить к дальнейшей работе. Если не
поставить руководство в известность, то оно может одобрить проект,
потенциальная прибыль от которого не покроет понесенных затрат.
Однако оценивать затраты на содержание персонала --- это не ваша
обязанность; эта задача находится в компетенции спонсора проекта.

144
Глава 9. Разработка бюджета
Организации, которые получают плату за выполнение проекта от
внешних потребителей, обычно рассчитывают трудовые затраты, так
как они заинтересованы в получении прибыли для оплаты труда сво-
их служащих. Независимо от того, внешним или внутренним будет
потребитель проекта, расчет трудовых затрат выполняется по одной и
той же схеме. Давайте рассмотрим ее подробнее.
Трудовые затраты
Трудовые затраты --- это затраты, связанные с работой сотрудников
над проектом. Чтобы рассчитать их, необходимо оценить время, которое
каждый человек затратит на выполнение своих заданий. Эта оценка
трудовых затрат уже указана на клеюшихся листочках с информацией
о продуктах, которая использовалась во время составления графика
сдачи продуктов. Затем, сложив общее время работы всех сотрудни-
ков, мы получим суммарные трудовые затраты на производство про-
дукта.
Большая часть времени выполнения проекта обычно расходуется
на производство продукта, но часть времени уходит на подготовку со-
браний, решение проблем, написание отчетов и т. д. Такие затраты на-
зываются трудовыми затратами на управление проектом.
Трудовые затраты на управление проектом
Трудовые затраты на управление проектом --- это время, которое требу-
ется для планирования и управления проектом. Попросите каждого
члена команды оценить время, которое он тратит на действия по управ-
лению проектом, например на составление отчета о состоянии работы,
организацию собраний команды, встречи с заинтересованными сторо-
нами и т. д. Таким образом вы узнаете суммарную оценку трудовых
затрат для каждого человека или для подпроекта. Сложив суммарные
оценки трудовых затрат на изготовление продукта и на управление
проектом, вы получите совокупную оценку затрат для человека или
подпроекта.
Одно из преимуществ оценки трудовых затрат состоит в том, что,
даже если в ней нет насущной необходимости, она помогает менедже-
рам по ресурсам определить, сколько времени людям потребуется для
работы. Когда менеджеры по ресурсам подписывают проектный план,
они обязуются предоставить все те ресурсы, которые оговорены в до-
кументе. Это также дает им возможность распределить ресурсы соглас-

Глава 9. Разработка бюджета
145
но потребностям. По крайней мере они знают, на что согласились, и не
смогут придержать те ресурсы, которые письменно обязались предо-
ставить.
После того как вы собрали сведения о трудовых затратах всех со-
трудников, вам потребуется рассчитать повременную ставку оплаты
на человека за час, день, неделю или месяц. Иногда размер оплаты опре-
деляется в зависимости от функций сотрудника, а иногда назначается
единая ставка для всего отдела. Получите точные данные о ставках у ме-
неджера кадрового отдела или в бухгалтерии.
Перемножьте повременные ставки и суммарный показатель трудовых
затрат для каждого человека, и вы получите общие трудовые издержки.
Завершение оценки затрат
Помимо оценки трудовых затрат вам, возможно, придется оценить
и другие внутренние затраты:
любые перекрестные расчеты между отделами;
любые накладные издержки проекта.
Кроме внутренних затрат в большинстве проектов также преду-
смотрены и внешние затраты, такие как оплата услуг людей или по-
купки за пределами организации. Даже если вы не станете оценивать
внутренние затраты, то без оценки внешних затрат в большинстве про-
ектов вам не обойтись.
Проанализируйте перечень продуктов проекта и для каждого из них
ответьте на вопрос: «Какие ресурсы нужно будет приобрести за предела-
ми организации, чтобы создать этот продукт?» Затем следует записать
все необходимые внешние покупки и оценить затраты на них. Внешние
затраты включают следующие статьи:
приобретенное оборудование;
услуги сторонних организаций, например консультационные
услуги;
снабжение;
командировки;
» транспортные расходы.
Сложив все внешние затраты, вы получите их суммарный объем.
Затем, если вы рассчитали внутренние затраты, прибавьте их к внеш-
ним затратам, чтобы определить общую сумму издержек. Это и будет
ваш бюджет, или оценка затрат. Затем вам потребуется оценить точ-
ность ваших расчетов.

146
Глава 9. Разработка бюджета
Точность оценки
Оценка --- это только оценка, не более того. Какая то более точна, а ка-
кая то --- менее, поэтому вы должны определить точность оценки и до-
вести ее до сведения спонсора и других дольщиков проекта. Сделать
это можно, указав не только оценочную сумму затрат, но и уровень ее
точности, а также диапазон возможных отклонений. Например, если
бы вы были спонсором проекта и вам бы сообщили, что затраты на
обед с танцами составят $19 524, какую сумму вы бы рассчитывали
уплатить? $19 524. Утверждение, что я собираюсь потратить именно
$ 19 524, создает впечатление, будто затраты оценены очень точно; одна-
ко на самом деле это предположение может оказаться ошибочным.
Тем не менее, на основе имеющихся данных можно сделать довольно
точную оценку. У заинтересованных участников проекта нет возмож-
ности определить, насколько точно оценены затраты, пока вы не сооб-
щите им уровень ее точности.
Вот некоторые из факторов, от которых зависит точность оценки:
квалификация членов команды;
ваш опыт создания подобных продуктов в прошлом;
точность статистических данных о трудовых затратах (при усло-
вии, что такие данные существуют) и их применимость к вашему
проекту;
продолжительность проекта (чем продолжительнее проект, тем
меньше точность оценки).
Исходя из этих факторов нужно определить точность сделанной
оценки как высокую (В), среднюю (С) или низкую (Н).
После того как вы определите степень точности, к уже сделанной
оценке общих затрат добавьте диапазон возможных отклонений --- плюс
или минус определенное значение, которое будет отражать достовер-
ность оценки. Диапазон отклонений показывает, что из за неточности
оценки затраты могут оказаться как выше, так и ниже рассчитанного
уровня, но в то же время мы убеждены, что окончательный объем за-
трат находится в пределах установленного диапазона.
Вот несколько предложений по определению диапазона вашей
оценки:
если точность оценки определена как высокая, то можно использо-
вать разброс ±10%. (Это означает, что вы должны вычесть и при-
бавить к основному значению 10% для получения общего диа-
пазона.);

Глава 9. Разработка бюджета
147
при средней точности разброс может составлять ±25%;
для низкой точности разброс будет равен ±50% и более.
Не обязательно строго придерживаться этих значений; они приве-
дены здесь, чтобы дать примерное представление о возможной шири-
не диапазона.
Вернемся к оценке затрат на организацию обеда с танцами; мы оцени-
ли их в $19 524 и присвоили этой оценке средний уровень точности.
С учетом диапазона точности мы получим предположительный объем
затрат между $17 500 и $21 500. Поможет ли это нам лучше предста-
вить себе, сколько денег может потребоваться? Конечно, да. Будет ли
такая оценка ближе к действительности, чем простое значение $ 19 524?
Несомненно.
Выразив оценку затрат как диапазон значений, вы:
точнее опишете реально возможные затраты на проект;
исключите вероятность неожиданностей впоследствии, во время
выполнения работы;
сможете управлять ожиданиями дольщиков, касающимися буду-
щих затрат;
предусмотрите резерв на случай непредвиденных обстоятельств.
Разница между фактическими затратами и наибольшим значением
диапазона оцениваемых затрат представляет собой средства, которые
можно потратить на непредвиденные расходы. Другими словами, она
позволяет застраховаться от действия закона Мерфи и привести факти-
ческие затраты в соответствие с бюджетом. Вспомните, как важно было
предусмотреть дополнительный резерв времени в графике работ. Точно
так же необходимо учесть средства на непредвиденные расходы в бюд-
жете. Предсказать будущее со 100% ной точностью невозможно, и при
оценке следует об этом помнить.
После того как вы рассчитали диапазон возможных затрат, вам сле-
дует сравнить наибольшее значение диапазона с пределом расходов,
который зафиксирован в программе проекта. Если наибольшее значе-
ние диапазона расходов не превышает предела, то можно считать, что
на этом оценка ваших расходов закончена. Однако если это значение
выше указанного в программе, то необходимо:
проверить расчеты, чтобы убедиться, что в ваши предположения
и вычисления не закралась ошибка;
пересчитать бюджет вместе со спонсором проекта, чтобы убедить-
ся, что в установленном лимите расходов существуют резервы для
непредвиденных затрат. Если затраты имеют для проекта перво-

148
Глава 9. Разработка бюджета
степенное значение, то переговоры по пересмотру предела рас-
ходов вряд ли помогут. Однако если затраты не на первом месте
в списке приоритетов, то, возможно, вам повезет;
найти другие способы, чтобы снизить издержки, если лимит рас-
ходов изменить нельзя. Как правило, для этого существуют три
возможности: использование деятельности персонала вместо
внешних услуг (если внешние затраты значительны); увеличение
уровня риска проекта за счет исключения контрмер, требующих
денежных затрат; сужение круга задач проекта. Выясните у спон-
сора проекта, использование какого варианта его больше всего
устроит, или предложите ему несколько вариантов на выбор. На-
пример: «Мы можем снизить объем итоговой продукции до X,
или можем принять на себя больший риск, отказавшись от не-
которых контрмер, что позволит нам сэкономить $ Y, или же мы
можем увеличить на Z время работы персонала над проектом,
чтобы сэкономить $Y на внешних затратах».
Прежде чем включать в план проекта полученные результаты, вер-
нитесь еще раз к проделанной работе, чтобы убедиться, что вы ничего
не забыли.
Разработка бюджета: проверьте себя
Спросили ли вы спонсора о необходимости оценки внутренних
издержек?
Включили ли вы временные затраты на управление проектом
в оценку трудовых затрат?
Оценили ли вы все внешние издержки, связанные с вашим про-
ектом?
Определили ли вы точность оценки затрат и рассчитали ли ее
диапазон?
Согласна ли команда с полученными результатами?
Превосходит ли наибольшее значение диапазона установленный
лимит затрат? Если превосходит, то одобрил ли спонсор проекта
продолжение работ или он повысил лимит расходов?
Форма проектного плана
Для того чтобы документально оформить оценку затрат, вам, возмож-
но, понадобится заполнить соответствующую форму, приведенную на

Глава 9, Разработка бюджета
149
рис. 9.1. Внесите в форму значения затрат, точность и диапазон оцен-
ки, обоснуйте выбранный уровень точности. Это поможет остальным
участникам проекта понять, как вы получили эти значения и почему
фактическое значение затрат, которые могут потребоваться, отлича-
ется от запланированного. Кроме того, этот документ во время завер-
шения проекта напомнит вам о том, из каких предпосылок вы исходи-
ли при оценке затрат.
Если не требуется оценка внутренних издержек, то верхнюю часть
таблицы оставьте незаполненной. Эта форма --- один из документов,
которые вам потребуются для составления проектного плана.
Рис. 9.1. Форма для оценки затрат

Глава 10
Составление окончательного проектного
плана
Поздравляем! Вы завершили процесс планирования! Настало время
составить окончательный план. План проекта --- это продукт этапа пла-
нирования. Он содержит всю собранную вами и вашей командой ин-
формацию относительно того, как должен выполняться проект. Если
чартер проекта отражает и ожидания от проекта, и пожелания к нему,
то план вполне реален. Поэтому именно он будет служить вам ориен-
тиром во время выполнения проекта.
Если вы следовали нашим указаниям на этапе планирования и во-
влекли команду и основные заинтересованные стороны в процесс пла-
нирования, то вряд ли вы столкнетесь с неприятными сюрпризами,
отдав ваш план на одобрение высшему руководству. Если же вы со-
ставляли план в одиночку, то на данном этапе проекта у вас появится
гораздо больше проблем.
Перед тем как перейти к подготовке документальной формы проект-
ного плана, давайте обратимся к методу CORE PM, чтобы проследить,
каким образом все отдельные части согласуются друг с другом.
Описание масштаба проекта
Определим, какой продукт произведут для потребителя. Вы начинали
с описания конечного продукта, включая все его особенности и функ-
ции. Затем вы вместе с заказчиком определяли критерии приемки.
Приемные критерии продукта (САС --- Customer Acceptance Criteria)
являются целью вашего проекта. САС --- это определение того, каким
заказчик представляет себе успешный результат; САС позволяет ко-
манде проекта следить за тем, в правильном ли направлении она двига-
ется для того, чтобы достичь успеха. Конечный продукт должен помочь
заказчику решить его проблемы или удовлетворить его потребности,
которые и являются движущей силой проекта.

Глава 10. Составление окончательного проектного плана
151
Рамки проекта вы также определили: что в него входит, а что нет,
какие существуют пересечения вашей сферы деятельности с другими
проектами и когда проект считается завершенным (рис. 10.1). Вы так-
же составили список дольщиков, или заинтересованных лиц.
Рис. 10.1. Описание масштаба проекта
Организация проекта
Для того чтобы произвести конечный продукт, пришлось сначала орга-
низовать работу над проектом. Вы разбили конечный результат работы
на несколько промежуточных результатов, а затем возложили ответ-
ственность за получение каждого из них на конкретного члена команды.
Затем вы выделили подпроекты и каждый продукт (промежуточный
или окончательный) закрепили за каким либо из подпроектов.
Кроме того, необходимо было удостовериться, что в состав команды
входят именно те люди, которые вам нужны. Вы оценили навыки, не-
обходимые для создания конечного продукта, и проверили список доль-
щиков, чтобы удостовериться в том, что кто либо из членов команды
либо представляет их интересы, либо выступает как посредник, под-
держивая связь с заинтересованными лицами и вовлекая последних
в работу над проектом. После этого вы внесли в состав команды все
изменения, необходимые для того, чтобы она наилучшим образом под-
ходила для успешного выполнения проекта (рис. 10.2). Для каждого
подпроекта был назначен лидер из числа членов команды.
Риск
В ходе оценки рисков вы и ваша команда, исследуя конечный и проме-
жуточные продукты проекта, задавали себе вопрос: «Что может пойти
не так, как запланировано?» Были определены и проанализированы
риски проекта (рис. 10.3). Затем вы запланировали контрмеры для
предотвращения этих рисков. Контрмеры были внесены в график работ.

152
Глава 10. Составление окончательного проектного плана
Рис. 10.2. Организация проекта
Трудозатраты, требующиеся для предотвращения рисков, добавляют-
ся к суммарному рабочему времени, которое, по вашим оценкам, по-
требуется для выполнения проекта. Все затраты, связанные с контр-
мерами, вы включили в предположительную сумму расходов.
Планирование ресурсов
Последний вопрос, который вы себе задали: «Сколько времени, уси-
лий и денег потребуется для выполнения проекта?» Вы разработали
Рис. 10.3. Оценка рисков

Глава 10. Составление окончательного проектного плана
153
поэтапный график, который необходимо обсудить с людьми, не вхо-
дящими в состав команды. Затем вы создали график сдачи продуктов,
отражающий сроки, в которые должен быть готов тот или иной проме-
жуточный продукт, а также демонстрирующий взаимосвязь продук-
тов. Наконец, вы включили в график дополнительное время на случай
каких либо непредвиденных обстоятельств или проблем.
Рабочее время, которое потребуется для создания каждого проме-
жуточного продукта, определено. Затем вы добавляете к временным
затратам на создание продуктов те затраты, которые необходимы для
управления проектом, и оцениваете суммарные трудозатраты. Затра-
ты рабочего времени переведены в денежные затраты на оплату труда,
одну из составляющих внутренних издержек проекта. После этого вы
перечисляете все внутренние и внешние издержки проекта, рассчиты-
ваете суммарный объем расходов, оценивая уровень точности расче-
тов (рис. 10.4).
Вот и все. Все части собраны вместе согласно логике. Вам осталось
составить последний документ, и вы готовы к написанию плана про-
екта. Этот документ --- план по управлению изменениями.
Рис. 10.4. Планирование ресурсов

154
Глава 10. Составление окончательного проектного плана
Планирование процесса управления изменениями
Поскольку в уже утвержденный план проекта, возможно, понадобит-
ся внести некоторые изменения, то вам потребуется спланировать про-
цесс управления изменениями. Без формального процесса управления
изменениями вы, скорее всего, столкнетесь с проблемой постепенного
отклонения проекта от намеченного курса, которая возникает, когда
заказчик или другие лица продолжают добавлять что то в проект после
того, как план уже одобрен. «Раз уж вы разрабатываете данные свойства,
не могли бы вы также устроить, чтобы программа делала...?» Это при-
мер того, как может начаться деформация проекта. Но даже если не
учитывать деформацию проекта, в процессе работы часто приходится
вносить изменения в проект, связанные с его масштабом, графиками
или бюджетом. Это происходит не только потому, что мы не можем
предсказать будущее наверняка, но и из за того, что в ходе выполне-
ния проекта могут измениться условия и нам необходимо будет под-
корректировать проект, чтобы продолжать его далее.
Процесс управления изменениями:
заставляет оценивать каждое новое требование, поэтому измене-
ния не вносятся автоматически;
. держит масштаб, график и бюджет проекта под постоянным конт-
ролем;
помогает команде различать необходимые и несущественные из-
менения;
требует оценить эффект от каждого изменения;
поддерживает соответствие плана проекта и текущего состояния
дел.
Процесс управления изменениями должен включать:
описание процесса управления изменениями. Оно отражает те
шаги, которые необходимо предпринять при внесении измене-
ния;
форму запроса на внесение изменения. Она заполняется челове-
ком, который желает внести изменение в проектный план. Этим
человеком может быть заказчик проекта или член команды ис-
полнителей, если, например, очевидно, что нельзя выполнить
проект к установленному крайнему сроку или наделить конеч-
ный продукт определенными свойствами.
Помимо этого, лидеру проекта придется вести журнал изменений,
чтобы отслеживать состояние каждого из запрошенных изменений.

Глава 10. Составление окончательного проектного плана
155
Процесс управления изменениями
Существуют два основных способа управления изменениями: с помощью
блок схемы и/или с помощью описания предпринимаемых шагов.
Шаги, типичные для процесса управления изменениями, приведе-
ны в табл. 10.1.
Таблица 10.1
Управление изменениями
Шаг
1. Запрос
2. Воздействие
3 .Одобрение/отказ
Действие
Кто то из членов команды или другое лицо предлагает
внести изменение. Он заполняет раздел формы запроса
на внесение изменений, где разъясняет необходимость
данного изменения. Команда определяет, стоит ли это
делать. Если стоит, то команда переходит ко второму
шагу. Если изменение бессмысленно, то данный вопрос
следует внести в список рассматриваемых проблем
и обсудить со спонсором проекта и с человеком, предло-
жившим внести изменения
Команда анализирует требуемое изменение и оценивает,
как оно скажется на проекте. Данный анализ проводится
вместе с инициатором изменения, заказчиком и спонсо-
ром проекта
Спонсор и заказчик проекта одобряют или отвергают из-
менение. Если изменение отклонено, то его инициатор
уведомляется об этом. Если изменение одобрено, то
инициатор изменения и команда проекта уведомляются
о том, что в план проекта вносятся поправки
Примерная блок схема для процесса управления изменениями по-
казана на рис. 10.5.
Как правило, чтобы сделать эти три шага, пользуются формой запро-
са об изменении, которая состоит из трех частей: запроса на внесение
изменения, куда входит объяснение необходимости данного измене-
ния (часть обоснования), анализа того, как изменение повлияет на
проект (анализ последствий), и утверждения изменения (одобрение)
(рис. 10.6). Раздел обоснования заполняется лицом, настаивающим на
внесении изменения. Это может быть спонсор проекта, заказчик, ко-
манда исполнителей или другое заинтересованное лицо. В случае, если
требование получено по электронной почте или по телефону, раздел
обоснования может заполнить лидер проекта, который затем уже пере-
даст форму на подпись тому, кто предложил данное изменение. Команда

156
Глава 10. Составление окончательного проектного плана
Рис. 10.5. Блок схема процесса управления изменениями

Глава 10. Составление окончательного проектного плана
157
Рис. 10.6. Форма запроса на внесение изменений
исполнителей заполняет часть, посвященную анализу последствий
изменения. Часть, которая отведена для одобрения изменений в про-
ектном плане, заполняется теми, кто должны утвердить данное изме-
нение в плане проекта.

158
Глава 10. Составление окончательного проектного плана
Шаг первый --- запрос на внесение изменения
ЕСЛИ вам или кому нибудь еще понадобилось внести изменения в про-
ектный план, то первое, что нужно сделать, --- заполнить верхнюю часть
формы запроса на внесение изменений.
Часть формы, связанная с обоснованием, требует ответа на следую-
щие вопросы:
Что инициатор запроса хочет изменить?
Почему он хочет внести данное изменение (какую проблему он
пытается разрешить)?
Как инициатор предлагает внести данное изменение в проектный
план?
Насколько срочно данное изменение?
Шаг второй --- анализ воздействия
Теперь, предположив, что данное изменение полезно, команде надо его
проанализировать. Это действие подразумевает, что команда вернется
назад и снова пройдет через все этапы планирования для того, чтобы
оценить то воздействие, которое данное изменение окажет на проект-
ный план. Команде следует оценить, как изменение повлияет на мас-
штаб проекта, риск и ресурсы. Например, запрос на перенесение даты
проведения торжественного обеда с танцами на месяц вперед необходи-
мо проанализировать с точки зрения изменения масштаба (возможно,
понадобится изменить место проведения или найти новую музыкаль-
ную группу); новых рисков, вытекающих из этого; изменения бюджета,
включая точность оценки. Информация о последствиях вносится в со-
ответствующую часть формы запроса на внесение изменения.
Шаг третий --- одобрение
Если мы собираемся изменять проектный план, то после того, как мы
оценили воздействие предлагаемого изменения на проект, запрос нуж-
но утвердить. В различных компаниях существуют различные прави-
ла относительно того, кто должен одобрить вносимые изменения, но
чаще всего это инициатор изменения, лидер проекта, спонсор и заказ-
чик проекта. Если вы должны получить одобрение других людей, удо-
стоверьтесь, что вы указали их в форме.
Форму запроса на внесение изменений, включая инструкцию по ее
заполнению, следует включить в план проекта.

Глава 10. Составление окончательного проектного плана
159
Журнал изменений
Лидеру проекта необходимо как то следить за работой по каждому за-
просу на изменение. Для тех проектов, где число изменений невелико,
это не представляет особой трудности. Однако некоторые проекты посто-
янно требуют внесения каких то изменений, и для них нужна формаль-
ная система контроля. Подобный контроль можно проводить при по-
мощи журнала изменений. Пример такого журнала показан на рис. 10.7.
Каждому запросу присваивается номер. Записывается инициатор
изменения, и оно подробно описывается. Также указываются дата по-
лучения запроса об изменении и срок, к которому нужно принять ре-
шение о внесении изменения. Можно также добавить колонку, в кото-
рой будет указываться срочность изменения.
Затем фиксируются результаты анализа последствий. Описываются
изменения, которые нужно будет внести в масштаб проекта. Влияние
на график проекта будет выражено в количестве дней, недель или ме-
сяцев, которые придется добавить или исключить из графика. Влия-
ние на расходы следует представить в виде денежной суммы, на кото-
рую изменится бюджет. В конце укажите дату, когда изменение было
одобрено или отклонено.
Примечание: на основании даты получения запроса на данное из-
менение и даты, когда он был одобрен, вы можете вычислить продолжи-
тельность цикла обработки каждого запроса об изменении --- время,
которое пройдет с момента получения запроса до момента, когда ре-
шение о том, вносить ли это изменение, будет принято.
Рис. 10.7. Журнал проектных изменений

160
Глава 10. Составление окончательного проектного плана
На этом раздел управления изменениями в проектном плане завер-
шается, и вы готовы идти дальше, к конечному утвержденному проект-
ному плану.
Составление проектного плана
Теперь у вас есть все документы, необходимые для того, чтобы соста-
вить основную часть плана проекта. Изучите табл. 10.2 и проверьте, не
упустили ли вы что нибудь.
Вам нужно будет добавить к плану руководящее резюме.
Таблица 10.2
Документальный план проекта
Раздел
Запуск
Команда
Масштаб
Масштаб
Масштаб
Масштаб
Организация
Риск
Документ или форма
Чартер проекта
Контракт, заключенный
с командой
Описание масштаба
проекта
Приемные критерии
продукта для заказчика
Границы работы над
проектом
Форма для определения
дольщиков проекта
«Дерево» подпроектов
Формы рисков
Пояснение
Одобрен спонсором проекта
Командное соглашение одобрено
командой
Детальное описание того продукта,
который будет предоставлен в итоге
заказчику проекта
Критерии, которые заказчик будет
использовать для того, чтобы опре-
делить, доволен ли он конечным
продуктом проекта
Описание тех задач, которые входят
в проект, и тех, которые выходят за
его рамки
Описание того, как данный проект
влияет на каждую из групп заинте-
ресованных лиц; статус каждого из
заинтересованных участников
в команде исполнителей и имя по-
средника, если он требуется
Диаграмма, на которой изображены
все подпроекты, ответственные лица
и продукты каждого из подпроектов
Определение рисков, контрмеры,
люди, ответственные за каждую
контрмеру

Глава 10. Составление окончательного проектного плана
161
Окончание табл. 10.2
Раздел
Ресурсы
Ресурсы
Ресурсы
Управление
изменениями
Документ или форма
Поэтапный график
График сдачи
продуктов
Оценка расходов
Процесс управления
изменениями
Пояснение
Общий график работ над проектом
для заказчика проекта, спонсора
проекта и других заинтересован-
ных лиц
График для членов команды, отра-
жающий взаимосвязи промежуточ-
ных продуктов проекта
Внутренние и внешние издержки,
связанные с проектом
Схема, на основании которой в план
проекта будут вноситься изменения
Руководящее резюме
Руководящее резюме не должно по объему превышать одной страни-
цы. Основные моменты резюме приведены в табл. 10.3.
После того как вы составили руководящее резюме, ваш план готов
для утверждения.
Утверждение проектного плана
Теперь необходимо обсудить со спонсором проекта подписи, необ-
ходимые для утверждения проектного плана. Разумеется, одобрение
спонсора проекта необходимо получить в первую очередь, но если у вас
имеется внутренний заказчик, он также должен одобрить план проек-
та в числе первых. Полезно бывает получить и подписи менеджеров
по ресурсам или функциональных менеджеров.
Перед тем как объявить, что процесс планирования завершен, про-
верьте еще раз содержание плана проекта и все соответствующие
процессы.
Составление проектного плана: проверьте себя
Составили ли вы руководящее резюме для проектного плана?
Составили ли вы все документы, связанные с проектным пла-
ном?

162
Глава 10. Составление окончательного проектного плана
Таблица 10.3
Руководящее время
Раздел
Цели проекта
Заказчик проекта
Основные дольщики
Конечный продукт
Приемные критерии
продукта для заказчика
Риски
Дата сдачи конечного
продукта
Оценка затрат
Приоритеты проекта
Действие
Возьмите их из чартера проекта, если только они не
изменились в ходе составления проектного плана
Укажите заказчика проекта
Перечислите основных заинтересованных лиц (за
исключением спонсора и заказчика проекта)
Опишите конечный продукт
Перечислите приемные критерии продукта
Перечислите основные риски и контрмеры, которые
вы выбрали для того, чтобы устранить эти риски
Документально подтвердите общий уровень рисков
проекта
Документально подтвердите все основные допуще-
ния, связанные с проектом, --- особенно те, что
относятся к технологии и ноу хау
Укажите срок сдачи конечного продукта проекта
Оцените объем финансовых расходов и точность их
оценки. Укажите лимиты расходов
Укажите приоритеты проекта: цели, график,
издержки
Включили ли вы в проектный план схему управления изменения-
ми? Всем ли участникам проекта (члены команды, заказчик, спон-
сор проекта) она понятна?
Одобрен ли ваш план?
План проекта составлен! Теперь пришло время воплотить его в жизнь.
Если вы хорошо поработали над планом, то у вас имеется отличный
фундамент для дальнейшей работы.

Глава 11
Приемы работы с командой
Вы уже познакомились с рядом приемов работы с командой при управ-
лении проектами, например с «деревом» подпроектов, оценкой рис-
ков и графиком выполнения проектов. Есть и другие приемы, пред-
назначенные для решения широкого круга проблем, которые могут
пригодиться на этапах планирования и выполнения проекта.
Такие приемы помогут вам принять любое решение, если вы вос-
пользуетесь схемой ОСАВ (IOАСTM):
О --- определение идей или проблем;
С --- систематизация идей;
А --- анализ идей;
В --- выбор одного или нескольких вариантов решения.
Существует множество приемов, которые можно применить на каж-
дом этапе схемы ОСАВ. Здесь мы рассмотрим четыре приема, которые
должны быть в арсенале каждого лидера проекта. Эти приемы можно
использовать на различных этапах процесса ОСАВ. Например, по-
строение диаграммы по сходству параметров, которое уже вкратце упо-
миналось в гл. 4 при составлении командного соглашения, может ис-
пользоваться как на этапе определения идей (О), так и на этапе их
систематизации (С).
Принятие решений сначала требует широкого обобщения проблем-
ной ситуации для исследования имеющихся возможностей, а затем ее
сужения для поиска решений. Процесс обобщения можно сравнить
с воронкой, в широкую часть которой заливается огромное количество
идей. Сужение проблемы достигается путем ограничения круга ва-
риантов для выбора. Его можно сравнить с узким концом воронки
(рис. 11.1). На пути от одного конца воронки к другому идеи подвер-
гаются систематизации и анализу, что помогает отобрать те из них, ко-
торые не только выполнимы, но и решают существующую проблему
наилучшим образом.

164
Глава 11. Приемы работы с командой
Рис. 11.1. «Воронка» принятия решения по схеме ОСАВ
Процесс принятия решений ОСАВ лучше всего использовать в тех
ситуациях, когда:
существует большое количество разнообразных идей или подхо-
дов к решению проблемы;
данной проблемой затронуты интересы большого количества
людей. (Если проблема касается только двоих, то вы можете вос-
пользоваться методом преодоления конфликтов; если же заинте-
ресованных сторон больше и все они преследуют различные
цели, то в этом случае вам поможет схема ОСАВ.)
Как вы уже знаете из гл. 3, работу в команде необходимо организо-
вать таким образом, чтобы задействовать все три сенсорных стиля вос-
приятия: визуальный, слуховой и кинестетический. Это позволяет
гарантировать, что в процессе принятия решения примет участие каж-
дый из членов команды. Кроме того, только так группе удастся найти
приемлемое для всех ее членов решение.
Рассмотрим первый прием, помогающий принять решение: постро-
ение диаграммы по сходству параметров.

Глава 11. Приемы работы с командой
165
Построение диаграммы по сходству параметров
(O,C)
Диаграмма по сходству параметров отлично подходит для определе-
ния и систематизации идей и проблем. Используйте ее в случаях, когда
нужно:
применить метод «мозгового штурма» в большой группе;
систематизировать большое количество идей, полученных с по-
мощью метода «мозгового штурма», таким образом, чтобы их было
удобно использовать для работы над проблемой;
стимулировать образование новых связей между существующи-
ми идеями;
направить работу над проблемой в другое русло, если старые спо-
собы работы оказались неэффективными, а новые идеи выдви-
нуть практически нереально.
Прежде чем начать построение диаграммы, прикрепите большой
лист ватмана к стене и раздайте всем членам команды по пачке клей-
кой бумаги для заметок и по маркеру.
Шаг 1
Процесс построения диаграммы по сходству параметров начинается
с четкого определения проблемы, которую вы собираетесь решать. Затем
переформулируйте проблему так, чтобы стало ясно, какого результата
вы хотели бы добиться. Например, вы работаете над проектом слия-
ния двух структур и вас беспокоит возможный упадок боевого духа
сотрудников. Переформулировать проблему, указав на результат, мож-
но так: «Какие максимальные усилия мы можем предпринять, чтобы
поддержать боевой дух работников во время слияния?»
Шаг 2
На следующем этапе найдите все мыслимые решения проблемы с по-
мощью метода «мозгового штурма». Это замечательный способ заста-
вить людей нестандартно мыслить и выдвигать новые идеи. Однако в
поисках новых идей не стоит забывать о следующих принципах:
все идеи хороши;
записывайте каждую идею на отдельном листочке клейкой бумаги;
идеи могут повторяться;
количество важнее качества;
выйдите за рамки рациональности --- пусть идеи будут безумными;

166
Глава 11. Приемы работы с командой
никакой критики;
не останавливайтесь, продолжайте обсуждение;
не теряйте темпа.
Используйте метод проведения «мозгового штурма» «Запиши! Ска-
жи! Прикрепи!», описанный в гл. 7. Каждый из участников должен за-
писать все свои идеи на клейких листочках, произнести их вслух и,
наконец, прикрепить заметки к листу ватмана, висящего на стене. Чем
больше идей вы получите в результате, тем лучше. Приветствуйте даже
самые сумасбродные и абсурдные решения. Этот поможет группе на-
строиться на творческий мыслительный процесс.
Все записи должны:
содержать существительное и глагол;
быть написаны маркером;
быть написаны достаточно большими буквами, чтобы их можно
было прочесть с расстояния нескольких метров.
Не прекращайте «мозгового штурма» до тех пор, пока не иссякнут
все очевидные идеи. Вот несколько подсказок, которые помогут вам
избежать принятия банальных решений:
если у группы не так много идей, то, скорее всего, это очень высо-
коклассные решения. Используйте их в качестве отдельных идей
для «мозгового штурма». Переформулируйте их так, чтобы ори-
ентировать членов группы на поиск решения, а затем с помощью
«мозгового штурма» определите идеи, направленные на реализа-
цию каждого из решений высокого уровня. Разместите все замет-
ки под соответствующими названиями разделов;
попросите группу высказывать самые неожиданные, безумные
идеи, чтобы выйти за рамки обычного мышления группы. Прово-
цируйте их вопросами, например такими: «Если бы это решение
было луковицей, то как бы оно выглядело?»;
«поднимайте планку» для группы. Если кажется, что у участни-
ков кончились идеи, то попросите их найти еще 10 20. Это заста-
вит их рассуждать нетрадиционным образом.
Шаг З
Следующий шаг при построении диаграммы по сходству параметров
требует упорядочить или систематизировать идеи. Организуйте актив-
ную работу членов команды, попросив их подойти к листу ватмана на
стене для сортировки идей. (Лучше всего выполнять сортировку, раз

Глава 11. Приемы работы с командой
167
бившись на группы не более шести человек.) Затем команда молча
переходит к процессу систематизации идей, который:
снижает степень значимости существующей в группе иерархии;
дает людям возможность задуматься об идеях, а не о записавших
их людях;
заставляет участников процесса вчитываться в каждую идею и
связывать ее с другими предложениями. Это объединяет все идеи
в единую картину, позволяя людям почувствовать себя соприча-
стными всем идеям, а не только своим собственным;
уничтожает желание анализировать и критиковать идеи;
ускоряет выполнение работы.
Правило относительно того, что вся работа должна выполняться
в тишине, может быть нарушено, если имеет место недопонимание ка-
кой то необычной идеи. В этом случае попросите члена команды вкратце
объяснить данную идею, но развернутого ее обсуждения не допускайте.
Продолжайте сортировать идеи до тех пор, пока группа не закончит
переклеивать листки для заметок с места на место. Все идеи должны
быть сгруппированы на листе ватмана. Вот еще несколько подсказок,
которые помогут при сортировке идей:
если два члена команды никак не могут решить, в какой раздел
лучше приклеить листок с записью, то создайте еще один точно
такой же и поместите их в оба раздела;
если в каком либо из разделов количество листков превысит 15,
то нужно разбить его на подгруппы;
если остались листки, которые не вошли ни в один из разделов,
то ничего страшного в этом нет. Для каждого из них нужно завести
отдельный раздел.
Процесс систематизации идей не должен занимать более 15 20 ми-
нут, если, конечно, у вас не более 100 клейких листочков.
Шаг 4
Как только сходные листочки объединены в группы, можно присту-
пать к обсуждению заголовков для каждого из разделов и подгрупп.
Лучший способ определения названий для категорий строится по сле-
дующей схеме:
Во первых, бегло просмотрите все группы и придумайте пример-
ные заголовки, описывающие одним словом основную концеп-
цию данного раздела.

168
Глава 11. Приемы работы с командой
Подсказка: используйте для заголовков листочки разных цветов или
больших размеров, так как они будут располагаться над всеми осталь-
ными листочками с идеями и должны выделяться на их фоне.
Во вторых, повторно просмотрите примерные заголовки и напи-
шите окончательные формулировки, которые бы наилучшим об-
разом соответствовали принципу разбиения на группы. Заголо-
вок должен состоять из 5 10 слов, и его содержание должно быть
ясным без прочтения всех листков, вошедших в этот раздел идей.
Создайте заголовки для всех подгрупп.
Проанализируйте заголовки и соответствующие им идеи. Обсуди-
те, требуется ли создать дополнительные подгруппы. Решите, вводить
ли отдельные заголовки для идей, не вошедших ни в одну группу, или
лучше включить их в одну из уже существующих (рис. 11.2).
Все этапы определения сходных идей показаны в табл. 11.1.
На этом процесс построения диаграммы по сходству параметров
завершен. Вы выдвинули идеи, систематизировали их и пришли к
устраивающему всех решению относительно основных разделов.
На следующем этапе схемы ОСАВ следует проанализировать идеи
и выработать совместно с командой единодушное решение. Рассмот-
рим основные приемы, которые могут помочь вам в этом. Первый из
них называется диграфом взаимосвязей.
Диграф взаимосвязей (Л В)
Диграф взаимосвязей (ДВ) поможет вам наглядно представить при-
чинно следственные связи между схожими группами идей или потен-
циальными решениями проблемы (их должно быть не более 10). Ис-
пользуйте метод ДВ в случаях, когда вам нужно:
отделить симптомы от истинных причин проблемы;
Рис. 11.2. Диаграмма по сходству параметров

Глава 11. Приемы работы с командой
169
Таблица 11.1
Диаграмма по сходству параметров
Шаги
12
3
4
Действие
Формулирование проблемы, ориентированное на поиск решения
Поиск идей с помощью метода «мозгового штурма». Запись их на
листочках для заметок
Сортировка идей участниками, которые не должны при этом разгова-
ривать друг с другом
Создание заголовков
определить движущие силы изменений;
определить коренные причины возникновения проблем или раз-
ногласий.
Диграф взаимосвязей --- это оптимальный способ для выявления
истоков проблемы. При оценке возможных решений возникает есте-
ственное стремление остановиться на очевидном выходе или на сред-
ствах, которые помогут устранить лишь внешние проявления пробле-
мы. Метод ДВ помогает увидеть скрытые за внешними проявлениями
истоки проблемы и подход к ее решению.
Прикрепите к стене лист ватмана и предложите группе (состоящей
не более чем из шести человек) построить на нем схему взаимосвязей
с помощью цветных маркеров и клейких листков для заметок.
Шаг 1
Запишите задачу или проблему на клейком листочке, а затем прикре-
пите его в верхней части ватмана. Ее формулировка должна немного
отличаться от тех, которые вы использовали для поиска решений про-
блем при построении диаграммы по сходству параметров. В методе ДВ
поставленный вопрос должен указывать на источник проблемы или
ключ к решению. Например: «Какие именно движущие силы помогут
нам избежать проблем в процессе слияния двух структур?»
Шаг 2
Сформулируйте утверждения о причинах проблем, которые будут изо-
бражены на диаграмме. Эти утверждения можно получить с помощью:
разделов диаграммы по сходству параметров;
метода «мозгового штурма»;
сбора информации о причинах проблем.
Лучше, если общее число утверждений не превышает 10. Если их
больше, то постарайтесь объединить сходные утверждения в группы,

170
Глава 11. Приемы работы с командой
общее количество которых также не превосходит 10. Все утверждения
(или их группы) нужно обозначить на листочках клейкой бумаги и
расположить их по кругу на листе ватмана (рис. 11.3).
Шаг З
Теперь нужно рассмотреть все утверждения попарно, каждый раз за-
давая себе вопрос: «Приводит ли одно из этих утверждений к возник-
новению другого?». Если какое то из них является причиной второго, то
между ними существует причинно следственная связь. Отметьте ее на
диаграмме, начертив стрелку от причины к следствию. Не рисуйте дву-
сторонних стрелок. Если вы не можете четко установить взаимосвязь
двух утверждений, то не нужно ставить стрелку вообще.
Продолжайте перебирать пары утверждений, выявляя связи между
ними, до тех пор, пока не будет проанализирована каждая из них.
Шаг 4
Подсчитайте количество стрелок, отходящих от каждого из листочков,
и стрелок, указывающих на каждый из них, и запишите результаты на
листочках. Например, результат 4/2 означает, что для одного из ли-
сточков насчитывается 4 отходящие от него стрелки и 2 на него указы-
вающие (рис. 11.4). На тех листочках, от которых отходит наибольшее
количество стрелок, указаны истоки проблемы. Те же из них, на кото-
рые указывает большое количество стрелок, содержат основные след-
ствия или симптомы проблемы.
Шаг 5
Те листочки, на которых описаны истоки проблемы (большое количе-
ство стрелок направлено от них), передвиньте налево, а те из них, на
Рис. 11.3. Второй шаг построения диграфа взаимосвязей

Глава 11. Приемы работы с командой
171
Рис. 11.4. Четвертый шаг построения диграфа взаимосвязей
которых указаны основные следствия (большое количество стрелок
направлено к ним), --- направо. Оставшиеся листочки оставьте посере-
дине. Затем перерисуйте стрелки, показывающие связи между причи-
нами проблемы (рис. 11.5). Не нужно копировать все стрелки, кото-
рые были нарисованы на третьем шаге. Достаточно будет показать
основное направление причинно следственной связи.
Как правило, лучше всего сначала разобраться с главными истока-
ми проблем и лишь затем перейти к промежуточным причинам. По
всей видимости, после того как вы проработаете все причины проблем,
вы получите уже готовый диграф взаимосвязей основных следствий
проблемы. Краткое описание процесса построения диграфа взаимосвя-
зей представлено в табл.11.2.
Если возникает вопрос о том, над какими из причин следует рабо-
тать в дальнейшем для устранения проблем, то можно применить два
следующих инструмента принятия решения: матрицу принятия реше-
ния МТ или многозначное голосование.
Рис. 11.5. Окончательный вариант ДВ

172
Глава 11. Приемы работы с командой
Таблица 11.2
Диграф взаимосвязей
Шаги
1
2
3
4
5
Операции
Запишите формулировку проблемы
Определите возможные причины
Сопоставьте все пары листков и выявите причинно следственные
связи между ними
Подсчитайте количество стрелок, направленных к каждому листку
и от него
Перерисуйте ДВ таким образом, чтобы истоки проблем были
расположены слева, а основные следствия --- справа
Матрица принятия решения МТ(А, В)
Когда необходимо сделать выбор между несколькими различными ре-
шениями (или если в основе вашей проблемы лежит несколько причин),
то очень важно определить критерии, с помощью которых можно до-
вольно точно оценить решение. Для этого авторами было разработано
специальное средство --- матрица принятия решения MartinTate (МТ).
Используйте такую матрицу в случаях, если:
вам нужно принять очень значимое или сложное решение;
« вам нужно проанализировать различные варианты на основе ряда
критериев;
нет единого мнения о том, какое решение лучше;
некоторые члены команды сомневаются в том, что данное реше-
ние оптимально;
вы хотите подойти к процессу принятия решения как можно объ-
ективнее.
Шаг 1
Нужно построить на листе ватмана сетку матрицы принятия решения.
Озаглавьте две колонки, расположенные слева, и верхний ряд, как по-
казано на рис. 11.6. Затем сверху на листе ватмана запишите ту цель,
которой вы собираетесь достичь в результате.
Шаг 2
Теперь все варианты решений нужно перечислить в верхней части
матрицы. В качестве вариантов решений могут выступать названия
разделов диаграммы по сходству параметров или основные истоки

Глава 11. Приемы работы с командой
173
Рис. 11.6. Составление матрицы принятия решения МТ--- шаг первый
проблем, определенные на основании диграфа взаимосвязей. Возмож-
но, группа получит эти варианты с помощью метода, «мозгового штур-
ма». Обсудите и запишите четкие определения для каждого варианта,
а затем удостоверьтесь, что каждый член группы их понимает.
Предположим, что вас интересует, какой метод обучения в области
управления проектами окажется наилучшим для вашей организации.
Вы построили диаграмму по сходству параметров и получили три ва-
рианта решений:
1. Обучение в классе, набор в который осуществляется случайным
образом. Сотрудники по своему желанию записываются на зара-
нее подготовленные учебные курсы.
2. Обучение в классе, организованное для проектных команд. Члены
проектной команды вместе посещают заранее подготовленные
семинары.
3. Обучение проектной команды по мере выполнения ею работы над
проектом (принцип «точно в срок»). Программа обучения разби-
вается на части, каждую из которых команда изучает тогда, когда
перед ней в процессе управления проектом возникает подобная
задача.
Шаг З
При помощи метода «мозгового штурма» составьте перечень критери-
ев, которые будут использоваться для принятия правильного решения.

174
Глава 11. Приемы работы с командой
Выбранные критерии должны помочь вам провести границу между аль-
тернативными решениями. Например, такой критерий, как освоение
методологии управления проектом всеми студентами, бесполезен, если
ему удовлетворяют все три варианта решения.
Ниже приведены примеры критериев решений:
низкие затраты;
простота реализации;
малочисленные препятствия при реализации;
короткие сроки реализации.
Каждый вариант решения необходимо проверить на соответствие
всем выбранным критериям. Число критериев по возможности не долж-
но превышать 6. Используйте для принятия решения все подходящие
критерии. Для каждого из них напишите рабочее определение того,
что этот критерий означает, чтобы все однозначно понимали его.
Шаг 4
Если какие либо из выбранных критериев требуют ответа «да» или
«нет» (например, такие вопросы, как: «Выполнимо ли решение?» или:
«Превышает ли стоимость обучения $Х?»), то нужно дать ответы на
них для каждого альтернативного решения и исключить те, на которые
даются отрицательные ответы. Затем запишите оставшиеся критерии
сверху вниз в левой колонке таблицы, построенной для матрицы при-
нятия решений (рис. 11.7).
Шаг 5
Установите весовые коэффициенты для каждого из критериев. Исполь-
зуйте при этом шкалу оценки от 1 до 9:
весовой коэффициент 1 3 --- желательно;
весовой коэффициент 4 6 --- крайне желательно
весовой коэффициент 7 9 --- обязательно.
Лучше всего, если у всех критериев будут разные весовые коэффи-
циенты. Например, если для вас крайне желательны два критерия, то
назначьте одному из них значение весового коэффициента, равное 4,
а другому --- 6 (рис. 11.8). Если команда не может прийти к единому
мнению относительно того, как распределить весовые коэффициенты,
то пусть каждый участник самостоятельно взвесит каждый критерий,
а вы затем объедините их значения и найдете средний результат. Убеди-
тесь, что это среднее значение устраивает всех членов группы. Прежде
чем переходить к следующему шагу, необходимо убедиться в том, что
все члены команды пришли к согласию.

Глава 11. Приемы работы с командой
175
Рис. 11.7. Составление матрицы принятия решения МТ --- шаг четвертый
Шаг 6
Закройте все только что записанные весовые коэффициенты листочка-
ми клейкой бумаги для заметок, а затем оцените все варианты решения
по каждому из критериев. Используйте при этом следующую шкалу
для оценки:
1 --- решение, не удовлетворяющее критерию;
3 --- решение, частично удовлетворяющее критерию;
Рис. 11.8. Составление матрицы принятия решения МТ --- шаг пятый

176
Глава 11. Приемы работы с командой
9 --- решение, практически полностью удовлетворяющее критерию.
Такая шкала оценки (1, 3, 9) поможет провести черту между вари-
антами, которые в значительной степени удовлетворяют критериям
выбора, и теми, которые совершенно не удовлетворяют им или удов-
летворяют лишь частично.
Запишите эти оценки в верхних левых углах ячеек, в которых пере-
секаются колонка варианта решения и строка критерия (рис. 11.9).
Члены команды должны оценивать все варианты решений совместно.
Если они не достигли согласия во время обсуждения оценок, то пред-
ложите участникам оценить все варианты решений по каждому крите-
рию в одиночку, а затем найдите среднее значение. Когда вы закончите
оценивать решения, проверьте еще раз, все ли согласны с получившим-
ся рейтингом.
Шаг 7
Умножьте балл, назначенный при оценке решений (число в верхнем
левом углу ячейки), на весовой коэффициент (число во второй слева
колонке), а затем запишите полученное значение в нижнем правом углу
ячейки (рис. 11.10).
Для каждого варианта решения сложите все числа, стоящие в пра-
вых углах ячеек, и запишите полученное итоговое значение в нижней
строке колонки. Самое высокое итоговое значение и укажет на реше-
ние, которое наилучшим образом соответствует выбранным командой
критериям выбора. Обсудите полученные результаты всей командой
и решите, действительно ли это наилучшее решение с точки зрения
Рис. 11.9. Составления матрицы принятия решения МТ --- шаг шестой

Глава 11. Приемы работы с командой
177
Рис. 11.10. Составление матрицы принятия решения МТ --- шаг седьмой
определенной ранее цели, записанной в верхней части листа. Если это
не так, то нужно пересмотреть критерии выбора, назначенные весовые
коэффициенты и баллы. Краткое описание последовательности шагов,
нужных для составления матрицы принятия решений МТ, показано
в табл. 11.3.
Если необходимости в применении аналитического подхода к приня-
тию решения нет, то не исключено, что вы предпочтете более быстрый
и простой инструмент принятия решения, называемый многозначным
голосованием.
Таблица 11.3
Матрица принятия решения МТ"
Шаги
1
2
3
4
5
6
7
Действия
Создайте сетку матрицы принятия решений
Перечислите варианты решений
Составьте перечень критериев решений при помощи метода
«мозгового штурма»
Отфильтруйте варианты на основании критериев «да/нет»
Определите весовые значения для всех критериев
Оцените соответствие вариантов решений каждому из критериев
Умножьте баллы, назначенные при оценке решений, на весовой коэф-
фициент и просуммируйте полученные числа для каждого варианта
решения
Решение с самым высоким итоговым баллом является оптимальным

178
Глава 11. Приемы работы с командой
Многозначное голосование (А, В)
Многозначное голосование --- это прием, который позволяет сузить ряд
вариантов решения, поскольку вы просите каждого человека выбрать
один из них, наиболее для него предпочтительный. Когда бы вы ни пред-
ложили людям сделать этот выбор, они будут осознанно или неосо-
знанно использовать свои собственные критерии выбора и взвешивать
значимость каждого критерия для принимаемого решения. Обычно
люди не осознают этот внутренний процесс анализа, и в целом он оста-
ется невидимым для группы, каждый член которой принимает реше-
ние самостоятельно.
На практике проведение анализа путем использования матрицы
принятия решения требуется далеко не всегда. Вы можете использо-
вать метод многозначного голосования в случаях, если:
вам нужно быстро принять единодушное решение для всей группы;
решение не настолько значимое, чтобы тратить время на прове-
дение тщательного анализа;
вам необходимо удостовериться, что все согласны с принимае-
мым решением;
критерии принятия решения хорошо известны и устраивают всех
членов команды;
вам необходимо уменьшить длинный список идей, отобрав лишь
некоторые из них, а затем применить к ним другие инструменты
анализа, например схему взаимосвязей или матрицу решения МТ.
Шаг 1
Раздайте всем членам команды клейкие листки. Если у вас более 10 ва-
риантов решения, то каждому участнику голосования нужно выдать по
5 листков. Если же вариантов меньше 10, то у каждого должно быть ко-
личество листков, в два раза меньшее, чем число вариантов решений.
Шаг 2
Попросите участников сформулировать для себя критерии, которые
они будут использовать при принятии решения. Затем предложите
каждому из них проголосовать за те решения, которые, по его мнению,
являются наилучшими. Один листок соответствует одному голосу. За
один вариант решения нельзя отдавать более одного листка.
Шаг З
Когда голосование будет завершено, посчитайте количество листков,
прикрепленных возле каждого варианта решения. Расположите все

Глава 11. Приемы работы с командой
179
Таблица 11.4
Многозначное голосование
Шаги
1
2
3
Действия
Обеспечить всех участников голосования клейкими листками
Участники голосуют за варианты, которые, на их взгляд, являются
наилучшими
Подсчитать голоса
варианты по порядку от наибольшего количества голосов к наимень-
шему. Убедитесь, что такая классификация понятна группе.
Прежде чем принять окончательное решение, можно:
отметить решения с наиболее высокой оценкой как решения, вы-
бранные всей группой;
взвесить все сильные и слабые стороны для двух трех первых ва-
риантов решения из полученного списка и затем выбрать одно из
них;
обработать наиболее высоко оцененные решения с помощью дру-
гих инструментов анализа, например построив схему взаимосвя-
зей или матрицу принятия решения МТ.
Инструменты для процесса ОСАВ
В этой главе были рассмотрены четыре основных приема работы в ко-
манде --- построение диаграммы по сходству параметров, диграф при-
чинно следственных взаимосвязей, матрица принятия решений МТ
и многозначное голосование. Вместе они составляют набор базовых
инструментов, который поможет команде принять оптимальные реше-
ния как на этапе планирования, так и на этапе воплощения проекта
в жизнь. Что ж, теперь пора перейти к непосредственному производ-
ству конечных продуктов проекта!
Примечание
Более подробно о таких инструментах, как диаграмма по сходству па-
раметров, диграф причинно следственных взаимосвязей и голосование
с множественным выбором, можно узнать из книги «Memory Jogger II»,
опубликованной издательством GOAL/QPC.

Глава 12
Претворение плана в жизнь
После того как проектный план одобрен, пора приступать к созданию
конечного продукта. Чаще всего члены основной команды или команды,
работающей над подпроектом, расходятся и приступают к работе по
созданию своих собственных продуктов. Большая часть этапа выпол-
нения проекта уходит на это, так что будем надеяться, что вы разрабо-
тали хороший проектный план --- ведь процесс выполнения проекта
является не только самым протяженным, но и требующим наиболь-
шего количества ресурсов: времени, трудовых затрат и денег. Если вы
следовали всем рекомендациям, изложенным в предыдущих главах, то
вы готовы перейти к этапу выполнения проекта.
Выполняя работу, не забывайте об управлении проектом, которое
на этом этапе сводится к четырем основным задачам:
следить за окружающей обстановкой;
управлять изменениями;
быть в курсе хода работ;
обсуждать то, как протекает работа.
Как правило, все эти четыре операции выполняются во время со-
браний команды исполнителей, которые время от времени нужно про-
водить, чтобы убедиться, что все идет хорошо. Частота собраний зави-
сит от продолжительности проекта и от объема выполняемой работы.
Вот несколько советов, которые помогут определить частоту проведе-
ния командных собраний:
если продолжительность проекта составляет менее шести месяцев,
то стоит проводить собрания еженедельно или раз в две недели;
если проект рассчитан на срок больше шести недель, но менее
одного года, то нужно проводить собрания раз в две недели;
если проект будет длиться больше года, то собрания следует про-
водить раз в две недели или даже раз в месяц.
На каждом собрании команды вы должны провести обзор продуктов,
которые были созданы за время, прошедшее с последнего собрания,

Глава 12. Претворение плана в жизнь
181
и подумать о продуктах, которые по графику должны быть готовы
к следующему собранию. Основное правило: на период между двумя
командными собраниями не следует планировать завершение работы
больше чем над шестью продуктами. Если, согласно графику, до следу-
ющего собрания команды будет готово большее количество продук-
тов, то нужно провести дополнительное собрание.
Строгих правил относительно частоты проведения командных со-
браний не существует. Лучше всего в начале работы запланировать
побольше собраний, а к концу работы постепенно снизить их частоту,
если в этом не будет большой необходимости.
Кто должен присутствовать на собраниях?
На собраниях команды должны присутствовать лидер проекта, члены
основной команды и любые другие участники, приглашаемые на со-
брания с определенной целью. Если ваш проект невелик, то члены
основной проектной команды заняты непосредственно выполнением
работы. Если же проект большой, то основная проектная команда
будет состоять из лидеров подпроектных команд. Лидеры подпроек
тов должны проводить собрания со своими командами и обсуждать на
них те же самые вопросы до того, как отправиться на общее собрание
основной проектной команды.
Перед собранием члены проектной команды подготавливают обнов-
ленную информацию о состоянии дел по своей части работы над про-
ектом. Таким образом, все члены проектной команды должны быть
готовы доложить о результатах, достигнутых их командами, о суще-
ствующих рисках, графике работы, бюджете и т. д. Прежде чем расска-
зать о том, что должно войти в отчет о состоянии работы над проек-
том, рассмотрим типичную повестку дня для собрания проектной или
подпроектной команды.
Повестка дня для собрания команды
Каждый раз, встречаясь с командой на собрании, вы будете в той или
иной мере касаться одних и тех же вопросов. Ниже приведен пример
повестки дня для собраний команды на этапе выполнения проекта:
обзор текущего состояния проекта --- члены команды докладыва-
ют о ходе работ по своей части проекта. От вас требуется внести
эти данные в форму отчетности о состоянии дел;
обсуждение потенциальных проблем --- проведите мониторинг
окружающей обстановки для обнаружения новых потенциальных

182
Глава 12. Претворение плана в жизнь
проблем, которые не были учтены при оценке рисков. Нужно ре-
шить, как действовать, чтобы предотвратить эти проблемы. Надо
внести полученные данные в форму отчетности о состоянии дел;
обзор запросов по изменению плана --- определите, насколько
обоснован каждый из запросов, а также внесите полученные дан-
ные в форму отчетности о состоянии дел;
обзор и обновление списка рассматриваемых проблем --- обсуди-
те возможные решения поставленных ранее проблем. Добавьте
в уже созданный список новые вопросы и проблемы. Внесите по-
лученные данные в форму отчетности о состоянии дел;
просмотр содержимого «доски объявлений» --- для вопросов, ко-
торые записаны на листочках, прикрепленных к листу ватмана,
решения либо находятся, либо заносятся в список рассматрива-
емых проблем;
признание достижений --- поблагодарите членов команды за уже
выполненную работу. Не забудьте отдать должное их успехам;
оценка результатов собрания --- проводится беглый анализ собра-
ния, чтобы в следующий раз учесть ошибки и внести необходи-
мые коррективы.
Теперь рассмотрим подробнее выполнение всех этих пунктов повест-
ки дня. (Они представлены не в той последовательности, в которой вы
будете сталкиваться с ними при командной встрече.)
Мониторинг потенциальных проблем
Хотя вы и постарались спрогнозировать этап выполнения проекта, но
вряд ли вы обладаете экстрасенсорными способностями, следователь-
но, вам потребуется непрерывно отслеживать как внутренние, так и
внешние условия работы над проектом, чтобы определить, не возник-
ли ли какие либо обстоятельства, которые могут отразиться на рисках
всего проекта. Возможно, изменения произойдут в организации заказ-
чика проекта, а может быть, конкуренты выпустят новый продукт,
очень похожий на тот, который вы еще только разрабатываете. Не-
обходимо составить мнение о любых новых обстоятельствах и о тех
условиях работы, которые отличаются от ваших ожиданий.
Мониторинг потенциальных проблем нужно проводить не только
во время собраний команды, но и на обзорных собраниях с дольщика-
ми проекта, например с заказчиком и спонсором. Следует выяснить
у всех дольщиков проекта, какие значимые, на их взгляд, изменения
могут оказать влияние на проект. Будьте очень внимательны, чтобы

Глава 12. Претворение плана в жизнь
183
не упустить необходимую информацию. Если что то изменится в ра-
бочей среде, нужно вместе с командой исполнителей выяснить, как это
может сказаться на проекте:
если последствия уже отразились на работе, то нужно оценить
характер и степень воздействия. Определите, не нужно ли что
либо изменить в проектном плане. Если изменения действитель-
но необходимы, то внесите их с помощью методов управления
изменениями;
если изменения могут повлиять на работу в будущем, то их нуж-
но включить в процесс оценки риска. Если для снижения новых
рисков требуется введение контрмер, то следует внести измене-
ния в план с помощью методов управления изменениями.
Обзор отчета о состоянии работы
Анализ текущего состояния работы над проектом дает возможность
установить, насколько результаты работы соответствуют проектному
плану. Это означает, что вы должны сравнить результаты, получен-
ные на данный момент, с теми, которые были запланированы, а затем
определить меры, которые следует предпринять в случае, если проект
«отклонится от намеченного курса».
Цель контроля над результатами --- обеспечить именно такое завер-
шение проекта, как было обещано: чтобы конечный продукт проекта
удовлетворял критериям заказчика, а сам проект был бы выполнен в
срок и в рамках бюджетных ограничений. Если проводить мониторинг
результатов регулярно, то вы своевременно узнаете о несоответствии
хода работ плану; благодаря этому можно принять меры, чтобы вер-
нуться к запланированному графику до того, как ситуация выйдет из
под контроля.
Различают шесть областей, за изменениями в которых необходимо
следить:
риск;
соответствие масштабу;
график работ;
трудовые затраты;
расходы;
изменения в плане.
Обратите внимание на то, что все эти разделы входят в план проекта.
Для каждого из них необходимо проводить мониторинг текущего со

184
Глава 12. Претворение плана в жизнь
стояния, сравнивая его с указанным в плане, а затем определять, что
нужно сделать для ликвидации отклонений от плана.
Примечание: за организацией проекта следить не нужно, поскольку
она остается практически постоянной до тех пор, пока не изменятся
цели проекта или пока в компании не произойдут изменения, отража-
ющиеся на составе команды.
Риск
Как мы уже упоминали, мониторинг обстановки нужно проводить для
того, чтобы обнаружить появившиеся риски и корректировать состав-
ленные ранее прогнозы относительно того, какие риски могут возник-
нуть при работе над проектом. В случае, если первоначальная оценка
риска изменится или если обнаружатся новые риски, необходимо ввести
контрмеры (возможно, понадобится составить запрос на изменение
проектного плана), аннулировать запланированные контрмеры (если
вероятность рисков снизится и потребность в этих контрмерах отпа-
дет) или добавить новые риски к уже выявленным (для этого тоже
может понадобиться запрос на изменение проектного плана). Любые
изменения в оценке рисков проекта должны отмечаться в отчете о со-
стоянии работы (рис. 12.1).
График работ
При мониторинге графика работ нужно ответить на следующие во-
просы: «Было ли выполнено вовремя все то, что предполагалось за-
вершить к этому моменту? Считаете ли вы, что сможете выполнить
в срок оставшуюся работу?» Нужно держать под контролем не только
основные этапы выполнения проекта, но и отдельные стадии работы
над продуктами в прошлом и в обозримом будущем. Оглядываясь на-
зад, выясните, все ли сроки завершения основных этапов работы были
соблюдены? Соответствуют ли фактические сроки запланированным?
Рис. 12.1. Риски в отчете о состоянии работы

Глава 12. Претворение плана в жизнь
185
БЫЛИ ЛИ изготовлены в срок все промежуточные продукты? Не рас-
ходятся ли фактические сроки завершения работы с планируемыми?
Заглядывая вперед, скажите, рассчитываете ли вы выполнить основ-
ные задания в сроки, указанные в плане? Если нет, то когда предпола-
гается закончить работу? Есть ли такие промежуточные продукты, даты
завершения которых лежат в промежутке между текущим и следующим
собраниями команды?
Все данные по вашему графику работы нужно внести в отчет (рис. 12.2).
Примечание: не заполняйте последнюю колонку в отчете о состоя-
нии работ, озаглавленную «Продукты, завершенные после послед-
него обновления информации», пока не проанализируете соответствие
масштабу.
Рис. 12.2. График работ отчета о состоянии работы

186
Глава 12. Претворение плана в жизнь
ЕСЛИ ВЫ поймете, что не успеваете закончить работу в установлен-
ные графиком сроки, то нужно вместе с командой определить, в чем
причины этой задержки. А затем пусть члены команды с помощью ме-
тода «мозгового штурма» найдут способ «втиснуть» проект в желаемые
сроки. Не все фактические отклонения от графика отражаются на край-
них сроках завершения проекта в целом, поэтому сосредоточьтесь на
тех потенциальных изменениях, которые угрожают непосредственно
крайним срокам выполнения проекта, т. е. связанных с продуктами,
которые находятся на критическом пути. Нужно уделить внимание
всем отклонениям от графика, которые могут привести к нарушению
запланированных сроков.
Чем раньше вы обнаружите возможные отклонения, тем легче будет
предотвратить смещение сроков выполнения работы.
Соответствие масштабу
Эта часть отчета о состоянии работы представляет собой план, в соот-
ветствии с которым команда будет работать над конечным продуктом,
чтобы удовлетворить приемным критериям потребителя. Эффектив-
ное управление проектом означает, что вы не будете ждать до послед-
него момента, когда ваш заказчик получит конечный продукт и вдруг
обнаружит, что продукт не соответствует его запросам. Если это про-
изойдет, то заказчик будет разочарован и вам придется переделывать
уже выполненную работу. Доработка не только потребует больших
средств, но и увеличит общий срок выполнения проекта. Следователь-
но, рациональнее убедиться в том, что готовый продукт приемлем для
заказчика; а это значит, что все промежуточные продукты в цепочке
должны устраивать тех, кто выступают в роли их потребителей. Сде-
лать это можно, составив план масштаба, а затем, проводя мониторинг
их качества по мере завершения работы над продуктами.
Каждый раз, когда вы заканчиваете работу над промежуточным про-
дуктом и передаете его промежуточному потребителю, спрашивайте
у него, удовлетворен ли он качеством продукта.
Если промежуточный потребитель доволен результатом, это следу-
ет отметить в отчете контрольной «галочкой». Если промежуточный
продукт не соответствует критериям, то пусть ответственное за него
лицо внесет все необходимые изменения, чтобы привести качество
продукта в соответствие с необходимыми стандартами. При этом в от-
чете о состоянии работы нужно указать меры, которые будут приняты
для улучшения качества.

Глава 19. Претворение плана в жизнь
187
Подсказка: очень важно договориться об уровне качества или о при-
емных критериях для промежуточных продуктов еще до того, как нач-
нется их производство. Это можно сделать на этапе планирования.
Нужно обязательно определить уровень качества или приемные крите-
рии для продуктов, которые раньше не производились, а также для тех,
которыми промежуточные потребители в прошлом были недовольны.
Трудовые затраты и финансовые расходы
Если вы включили в проектный план трудовые затраты и финансовые
расходы, то вам потребуется регулярно сравнивать реальные затраты
рабочего времени и финансовые расходы с плановыми показателями.
Но даже если перечисленные данные не вошли в план, то все равно
полезно проводить их мониторинг, так как это поможет вам собрать
статистические данные о том, какие затраты потребуются для выпол-
нения определенного вида проекта. Зафиксируйте в отчете фактиче-
ские трудовые затраты, т. е. совокупный объем времени, израсходо-
ванного на проект. Сравните также фактические и запланированные
расходы. Фактические данные дают представление о сумме, которую
вы уже потратили к настоящему моменту, но не показывают, уложи-
тесь ли вы в заданные бюджетные рамки, не прибегая к регулярному
пересмотру суммы, которая вам еще потребуется на завершение рабо-
ты. Предположим, что ваш бюджет составляет $400, а продолжитель-
ность проекта --- 4 месяца. За первый месяц вы потратили $125. Как
определить, уложитесь ли вы в указанную сумму? Превысите ли вы
ее? Потратите меньше? Скорее всего, если основная часть расходов по
проекту приходится на начало работ, то вы уложитесь в бюджетные
рамки. Однако, если серьезные расходы еще впереди, то, по всей види-
мости, бюджетных средств вам не хватит. Один из способов прояснить
ситуацию с бюджетом --- попросить команду сделать прогноз предсто-
ящих расходов с учетом уже сделанных затрат. Пусть, к примеру, ваша
команда оценивает оставшиеся расходы на выполнение проекта в $275
(при среднем уровне точности). Тогда диапазон проектируемых рас-
ходов составляет примерно $250 $300. Сложив прогнозируемые расхо-
ды ($300) и уже потраченные средства ($125), мы получим общую сум-
му предполагаемых затрат, которая превысит размер бюджета на $25.
Вряд ли это вас устроит. Если вы обнаружите, что вам угрожает пре-
вышение бюджета, то действуйте по одному из приведенных ниже ва-
риантов:
после обсуждения ситуации со спонсором сделайте запрос о вне-
сении изменений для увеличения финансирования;

188
Глава 12. Претворение плана в жизнь
» если работа над проектом только еще началась, то не спешите что
либо предпринимать, однако продолжайте контролировать уро-
вень расходов --- не исключено, что фактические расходы меньше
прогнозируемых;
выясните, за счет чего можно снизить расходы или сократить
масштабы работ.
Если вы обнаружите, что все таки превысите бюджет, то нужно как
можно быстрее сообщить об этом спонсору проекта. Вряд ли его обраду-
ет эта новость, но он, возможно, подскажет вам, как привести расходы
к запланированному уровню.
' Укажите все фактические трудовые затраты и финансовые расходы
в отчете (рис. 12.3).
Обзор запросов на внесение изменений
Если вы установили, что не в состоянии выполнить все, что наметили
в проектном плане, или если один из ключевых дольщиков проекта
требует внести в план изменения, например добавить новые особен-
ности или функции к характеристикам конечного продукта, ввести
новый продукт, сократить график работ или уменьшить бюджет, то
необходимо действовать по схеме управления изменениями.
Во первых, требуется заполнить форму запроса на внесение измене-
ний. Тот, кто подал запрос на внесение изменения, должен заполнить
верхнюю часть этой формы (см. гл. 10). Получив запрос на изменение,
вы должны присвоить ему порядковый номер и записать его в журнал
изменений. Как вы помните, в этот журнал вносятся данные о каждом
полученном запросе на изменение, а также статус запроса. Предполо-
жим, что вы получили запрос на изменение плана вашего проекта по
Рис. 12.3. Трудовые затраты и финансовые расходы в отчете
о состоянии работ

Глава 12. Претворение плана в жизнь
189
организации торжественного обеда с танцами и в нем сказано, что в
список приглашенных необходимо добавить еще 50 персон. Обосно-
ван такой запрос тем, что один из вице президентов счел необходи-
мым пригласить еще несколько людей, работавших над проектом, так
как, по его мнению, они тоже должны принять участие в торжестве.
Во вторых, попросите команду проанализировать, насколько оправ-
дано предложенное изменение. Если команда сочтет, что данное изме-
нение недостаточно обосновано, то нужно вернуться назад и выяснить
мнение спонсора об этом запросе. Если спонсор решит, что изменение
бесполезно, то нужно обсудить запрос с человеком, подавшим его. Воз-
можно, что он владеет информацией, которая делает изменение зна-
чимым настолько, что его необходимо реализовать. Далее нужно оце-
нить воздействие предложенных изменений на проект, определить
ресурсы, которые потребуются для его реализации --- по крайней мере
время и трудовые затраты, --- вряд ли вы захотите тратить ресурсы на
бессмысленные запросы. Итак, прежде чем приниматься за анализ по-
следствий изменения, нужно убедиться, что оно небесполезно.
И наконец, нужно оценить последствия изменений для утвержден-
ного проектного плана. К примеру, что повлечет за собой увеличение
числа приглашенных на 50 персон? Чтобы узнать это, нужно оценить
воздействие изменений на:
масштаб (может потребоваться более просторная площадка для
проведения праздника);
риск (из за большего числа приглашенных может повыситься уро-
вень рисков или, возможно, появятся новые риски);
планирование ресурсов (повлияют ли изменения на график ра-
бот, трудовые затраты, финансовые расходы?).
Рассмотрим еще один пример. Предположим, что спонсор хочет сни-
зить бюджет проекта на $2500. Анализируя последствия, вы должны
найти способы снижения затрат --- например, можно провести прием
в помещении, чтобы сэкономить на стоимости тента, или вместо сто-
роннего персонала использовать внутренний персонал (найти добро-
вольцев). Можно снизить издержки, если аннулировать некоторые за-
планированные контрмеры для снижения риска или предложить
несколько способов уменьшения масштаба работы для корректиров-
ки размера бюджета, например организовать фуршет вместо банкета.
Для анализа последствий вам потребуется пригласить основную
команду на собрание по мини планированию проекта для повторной
проработки всех этапов планирования, чтобы найти ответ на вопрос:

190
Глава 12. Претворение плана в жизнь
«Каковы будут последствия предложенных изменений для существу-
ющего плана?» После того как вы заполните раздел формы о влиянии
изменений на план в целом, спонсор и заказчик должны ее утвердить.
Если изменения будут одобрены, то внесите их в проектный план,
и, исправленный, он станет новым официальным планом. В дальней-
шем вы должны отслеживать все результаты работы уже по новому
плану.
Если же изменения были признаны несущественными, то тогда нуж-
но связаться с человеком, подавшим запрос, и объяснить причины от-
каза. Лучше всего это сделать лично, или по крайней мере по телефону,
чтобы вы могли ответить на все вопросы, которые возникнут у оппо-
нента. Если этот человек занимает более высокую должность в орга-
низации, чем вы, то, возможно, вам потребуется поддержка, чтобы со-
общить ему об отказе. Вы можете попросить спонсора проекта помочь
вам в этом. В конце концов, это одна из его обязанностей.
Заполните в отчете о состоянии работы раздел «Изменения в пла-
не», ясно показав, какие изменения предлагалось внести, когда они
были предложены, были ли изменения одобрены и если да, то какие
поправки внесены в существующий план (рис. 12.4).
Обзор и обновление списка рассматриваемых
проблем
Проанализируйте список рассматриваемых проблем вместе с членами
команды. Обсудите решения проблем, которые по графику должны
быть рассмотрены на данном собрании команды. Запишите все дан-
ные о том, как и когда должны быть разрешены эти вопросы. Обсудите
вопросы, ответы на которые не были найдены, и разработайте страте-
гию, с помощью которой можно все же ответить на них. Если нужно
более тщательно проанализировать какой либо вопрос, то включите
его в отчет о состоянии проекта (рис. 12.5). Затем проанализируйте те
Рис. 12.4. Запросы на внесение изменений в отчете о состоянии работ

Глава 12. Претворение плана в жизнь
191
Рис. 12.5. Анализ проблем в отчете о состоянии работ
вопросы, ответы на которые нужно будет получить к очередному со-
бранию команды.
Завершение отчета о состоянии работ
Вы сможете закончить отчет о состоянии работ над проектом сразу же,
как только обсудите результаты работы совместно с командой. К это-
му моменту ваш отчет будет уже почти завершен. Последний раздел
отчета включает сводную таблицу или краткое описание состояния дел
в целом (рис. 12.6). Здесь нужно оценить качество масштаба, соблюде-
ние графика, трудовые затраты и материальные расходы.
После собрания нужно опубликовать отчет, чтобы все члены коман-
ды, спонсор, заказчик и другие участники проекта могли с ним озна-
комиться. Этот документ также может выступать в роли протокола
собрания команды исполнителей. Отчет --- это один из основных спо-
собов проинформировать всех участников проекта о достигнутых ре-
зультатах.
Рис. 12.6. Сводная таблица о состоянии работ

192
Глава 12. Претворение плана в жизнь
Просмотр всех листочков на доске объявлений
В конце собрания нужно вернуться к доске объявлений и посмотреть,
остались ли еще вопросы, которых вы до сих пор не коснулись. Если
они существуют, то действуйте согласно одному из вариантов:
обсудите вопросы и ответьте на них, а идеи рассмотрите до того,
как закончить собрание;
включите вопросы в список рассматриваемых проблем, назначив
лиц, ответственных за их разрешение;
исключите проблемы, которые уже обсуждались, и вопросы, кото-
рые уже не интересуют тех, кто их поставил. Обычно это вопросы,
которые были заданы в начале собрания и обсуждались на нем
позднее или потеряли свою значимость в процессе обсуждения.
Перед тем как снимать какой либо вопрос, уточните у человека,
который его задал, согласен ли он с этим;
внесите серьезные вопросы в повестку дня следующего собрания
проектной команды.
Признание достижений
Поблагодарить членов команды за работу, которую они проделали,
никогда не вредно. Большинство людей задействовано в нескольких
проектах одновременно. Простая благодарность имеет огромное зна-
чение, так как позволяет людям почувствовать, что их высоко ценят,
а командам --- дойти до наивысшей стадии сотрудничества команды,
о чем мы уже говорили ранее.
Кроме того, всякий раз, когда вы достигнете очередного ключевого
момента, нелишне будет организовать нечто особенное, чтобы отме-
тить успехи команды. По крайней мере нужно просто выразить при-
знательность за выполненную работу. На собрание можно принести
фрукты или выпечку, чтобы создать благожелательную атмосферу.
Даже самое скупое признание заслуг придает сил тем, кто трудится
над проектом, на всех этапах работы.
Оценка результатов собрания
Прежде чем закрыть собрание, нужно вкратце оценить то, что прошло
успешно, и то, что на последующих собраниях можно сделать лучше.
Проще всего сделать это, раздав всем участникам клейкую бумагу для

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

194
Глава 12. Претворение плана в жизнь
предоставляйте спонсору и заказчику объективную информацию
в таком объеме, чтобы они могли принимать решения осознанно.
Не следует задавать вопросы типа: «Чего вы от нас хотите?» Лучше
сказать: «Если мы выполним следующую задачу, то она потребу-
ет столько то затрат X, она даст такие то преимущества/выгоды Y,
на ее выполнение потребуется Z дней/недель». Другими слова-
ми, их выбор должен быть достаточно обоснованным;
если вы просите у них помощи, сделайте ситуацию предельно
ясной для них. Определите ваши требования достаточно четко,
чтобы избежать любой возможной двусмысленности. Получить
не ту помощь, о которой вы просили, --- это все равно что поте-
рять козырь в карточной игре;
предлагайте им различные варианты решений, но не принимайте
решения за них.
В конце обзорного собрания с заказчиком или спонсором проекта
уточните, удовлетворены ли они и не возникли ли у них какие нибудь
вопросы. Эти вопросы могут помочь вам раскрыть то, чего еще не за-
метила команда, а также выявить проблемы, пока они еще не стали
слишком значительными. Возможно, это будут вопросы, возникшие
в результате недопонимания ситуации. В таком случае необходимо
сразу разъяснить все неясные моменты.
Наконец, не забывайте поблагодарить их за оказанную поддержку.
Передача конечного продукта заказчику
Продолжайте мониторинг результатов работы вместе с командой и сле-
дите за прогрессом вместе со спонсором и заказчиком до тех пор, пока
конечный продукт не будет полностью готов и передан заказчику.
С этого момента этап выполнения проекта можно считать завершен-
ным. Пора переходить к завершающему этапу работы.
Претворение плана в жизнь: проверьте себя
Ниже приведены контрольные вопросы, ответив на которые, вы удо-
стоверитесь, что ничего не упустили в процессе выполнения работы:
Проводите ли вы мониторинг обстановки (конкурентов, потре-
бителей, технологий и т. д.), чтобы своевременно выявлять все
изменения, которые могут повлиять на ход проекта?
Узнаете ли вы у спонсора и заказчика проекта о том, как, по их
мнению, изменились условия работы?

Глава 12. Претворение плана в жизнь
195
Регулярно ли вы проводите обзор потенциальных проблем на со-
браниях команды исполнителей?
Используете ли вы процесс управления изменениями, описан-
ный в проектном плане?
Заносите ли вы в журнал изменений все запросы на внесение из-
менений?
Принимает ли команда участие в процессе оценки воздействия
изменений на проектный план?
Все ли члены команды приходят на собрания с подготовленными
отчетами о состоянии дел?
Активно ли члены команды участвуют в оценке правильности
выполнения проекта?
Чувствуют ли себя члены команды совладельцами результатов
проекта?
Выпускаются ли регулярные отчеты о состоянии работы над про-
ектом?
Регулярно ли проводятся обзорные собрания с заказчиком и спон-
сором проекта?
Обеспечиваете ли вы обратную связь со спонсором и заказчиком
проекта, чтобы узнать, как они воспринимают результаты работы
над проектом?

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

Глава 13. Завершение проекта
197
Оценка проекта заказчиком
После того как готовый продукт будет передан заказчикам, можно пред-
ложить им дать оценку проекта. Для этого удобно использовать спе-
циально разработанную форму оценки. Она должна содержать утверж-
дения, которые потребитель будет оценивать по шкале от 1 до 6 (или
от 1 до 10), где минимальное значение --- это «абсолютно не согласен»,
а максимальное --- «абсолютно согласен». (Максимальное значение
шкалы оценки лучше сделать четным, чтобы у заказчика не возникало
соблазна выбирать значения, находящиеся посередине шкалы. Это
позволит вам не просто получить оценки заказчика, а определить, по-
ложительное у него сложилось отношение к проекту или отрицатель-
ное.) Чтобы выяснить, как заказчик относится к результатам работы
над проектом, можно использовать следующие простые утверждения:
» конечный продукт удовлетворяет моим приемным критериям;
конечный продукт соответствует моим ожиданиям;
сроки сдачи продукта отвечают моим требованиям;
затраты не превышают приемлемого уровня;
в целом я доволен результатами проекта.
При желании вы можете также включить утверждения для оценки
процесса управления проектом, например:
проектный план был полностью выполнен и оказался эффектив-
ным;
цели и задачи проекта были определены правильно;
процесс управления изменениями был эффективным;
мой уровень участия в проекте удовлетворяет меня;
отчеты о состоянии дел были ясными и полными;
меня регулярно информировали о ходе работ;
в целом я доволен процессом управления проектом.
Добавьте к этому списку те утверждения, которые подходят именно
для вашего проекта. Например, если вы занимались внедрением про-
граммного обеспечения, то вам стоит уточнить, устраивает ли служащих
обучающая программа и не нужно ли что либо улучшить или дорабо-
тать.
Беседа с заказчиком
После того как форма оценки будет заполнена заказчиком, можно при-
гласить его на очное интервью. Присутствие спонсора проекта на этой

198
Глава 13. Завершение проекта
встрече тоже не будет лишним. Во время беседы нужно обязательно
получить ответы на два вопроса: что удалось «на все сто» (положи-
тельные результаты), а что в следующий раз можно будет сделать эф-
фективнее (дельта --- изменения для улучшения)? Полученные отве-
ты занесите в форму плюс/дельта (рис. 13.1).
Как можно увидеть из разделов формы, они все напоминают вопро-
сы из письменной оценки. Но интервью позволяет получить развер-
нутые ответы. Например, если потребитель оценивает утверждение
«Цели и задачи проекта были определены правильно» в три из шести
баллов, то спросите у него, что при определении целей и задач проекта
ему понравилось, а что, по его мнению, в следующий раз нужно сде-
лать иначе. Все ответы запишите в форму.
Ни в коем случае не стоит занимать при этом оборонительную по-
зицию и пытаться оправдываться, объясняя, почему что то было сдела-
но или не сделано во время проекта. Ваша задача сейчас состоит в том,
чтобы задать интересующие вас вопросы и записать ответы заказчика,
Рис. 13.1. Итоговый отчет о результатах работы

Глава 13. Завершение проекта
199
Рис. 13.2. Итоговый отчет о результатах работы
а не отстоять результаты своей работы. Представьте себе, что вы жур-
налист и вам нужно только получить необходимую информацию. Если
же вы хотите объяснить, что произошло при выполнении проекта, то
устройте дополнительное собрание для обсуждения итогов проекта.

200
Глава 13. Завершение проекта
Итоговый отчет о результатах работы
Получив от заказчика оценку проекта, вы можете приступить к составле-
нию итогового отчета о результатах проекта (рис. 13.2). Он строится
по той же схеме, что и промежуточные отчеты о состоянии работ, но:
добавляется раздел о целях и задачах проекта, чтобы дать пред-
ставление о том, насколько точно были соблюдены приемные
критерии заказчика;
в разделе, посвященном графику работы, перечисляются все основ-
ные этапы работы с указанием планируемых и фактических сро-
ков. Если ни один из перечисленных этапов не был связан с ко-
нечным продуктом, то он добавляется в конец списка;
в разделе, касающемся трудовых затрат и финансовых расходов,
подводятся итоги и фактические данные сравниваются с теми,
что были указаны в утвержденном плане;
в разделе изменений плана перечисляются все изменения, которые
были внесены в исходный план. Раздел «Окончательный план»
должен содержать данные из окончательного плана, касающиеся
целей работы (изменений в критериях приема продукта), край-
них сроков сдачи, трудовых затрат и расходов;
в самом низу таблицы нужно дать объяснение всем несоответ-
ствиям между запланированными и итоговыми фактическими
величинами. Несоответствия --- это любые отклонения от плановых
результатов работы. Несоответствия могут быть как положитель-
ными (выполнение работы раньше графика), так и отрицатель-
ными. Очень важно объяснить и положительные и отрицательные
итоги, так как нужно, чтобы причины всех успехов и неудач были
понятными.
Оценка проекта спонсором
Предложите спонсору оценить проект с помощью тех же методов, ко-
торые вы применяли для получения оценки заказчика. Для начала
попросите его заполнить форму для оценки проекта, а затем проведи-
те с ним интервью. Перед тем как приступить к оценке проекта, дайте
спонсору возможность ознакомиться с итоговым отчетом о результа-
тах проекта.
При опросе спонсора важно использовать те же утверждения, что
и для заказчика (в этом случае вы сможете сопоставить их ответы).

Глава 13. Завершение проекта
201
В разделе «Результаты проекта» необходимо немного изменить фор-
мулировку. Например, вместо фразы: «Конечный продукт соответству-
ет моим ожиданиям» лучше написать: «Конечный продукт удовлетво-
ряет ожиданиям заказчика». Можно добавить следующее утверждение:
«Конечный продукт удовлетворяет потребностям организации».
При желании вы можете более тщательно проанализировать и про-
цесс управления проектом. Вот несколько дополнительных утвержде-
ний, которые могут пригодиться при опросе:
проект был тщательно спланирован;
проект был эффективно спланирован;
дольщики эффективно участвовали в управлении проектом;
ресурсы проекта использовались рационально;
в процессе планирования нельзя было предугадать, что впослед-
ствии потребуется скорректировать некоторые задачи проекта;
лидер проекта превосходно справился со своей работой;
вопросы, которые передавались для решения спонсору проекта,
в полной мере соответствовали его доле участия в работе.
Добавьте сюда утверждения, которые помогут вам получить требу-
емую информацию. После того как вы получите ответы, можно перейти
к беседе со спонсором проекта, как вы уже делали в случае с потреби-
телем. Подготовьте для этого форму плюс/дельта и внесите в нее все
ответы спонсора проекта.
Оценка проекта другими заинтересованными
сторонами
Полезно установить обратную связь и с другими дольщиками проекта,
например с менеджерами, отвечающими за обеспечение ресурсами.
Чтобы не беседовать с каждым из них, объедините форму плюс/дель-
та с формой для оценки проекта, попросите их заполнить ее, а затем
проанализируйте ответы.
Для получения объединенной формы нужно просто добавить к утверж-
дениям из формы для оценки проекта две колонки, озаглавив их «По-
ложительные результаты» и «Идеи для улучшения работы в будущем».
Образец такой формы показан на рис. 13.3.
В основном этот опрос должен касаться процесса управления про-
ектом. Используйте тот же набор вопросов, которые вы задавали спон-
сору и заказчику проекта. Можно добавить и несколько утверждений,
которые имеют отношение только к данной группе участников проекта:

202
Глава 13. Завершение проекта
Рис. 13.3. Форма для оценки проекта заинтересованными участниками
меня правильно информировали о том, какое количество ресурсов
требуется для проекта;
меня регулярно информировали о ходе работ по проекту;
я согласен с объемом ресурсов, которые мне пришлось поставить
для выполнения проекта;

Глава 13. Завершение проекта
203
мои представители в команде регулярно информировали меня
о результатах работы.
Если у вас есть какие то вопросы, требующие более конкретных от-
ветов, то свяжитесь с интересующим вас лицом и обсудите их. Полу-
чив все ответы, сведите их в единую таблицу, а затем представьте ее
команде для анализа.
Оценка проекта членами команды
Попросите членов команды оценить проект. Вопросы, которые вы для
них подготовите, должны касаться следующих аспектов работы:
особенности руководства проектом. (Этот вопрос позволяет ли-
деру проекта выяснить мнение группы о том, как он справился со
своей работой.);
процесс управления проектом, включая результативность плани-
рования, мониторинг и контроль над изменениями;
взаимодействие команды --- эффективно ли она работала, были
ли продуктивными собрания команды;
организационная поддержка проекта.
Форму для опроса членов команды сделайте по образцу формы для
дольщиков проекта, чтобы у них была возможность написать, что им
понравилось в работе, а что, на их взгляд, следует доработать.
Усвоенные уроки
Опросив всех участников проекта, переходите к собранию, на котором
расскажите о том, какие уроки были получены в процессе работы. Ис-
пользуйте список выводов, сделанных на протяжении всего проекта,
итоговый отчет о результатах работы, оценки участников и формы
плюс/дельта. Проанализировав итоговый отчет и формы для обратной
связи, заполненные участниками, выпишите все новые данные на лист
ватмана, чтобы каждый мог присоединиться к их обсуждению.
Примечание: не забывайте, что цель этого собрания --- обучение и
усвоение полученного опыта; ни в коем случае не допускайте, чтобы
обсуждение превращалось в поиск виновных. Кроме того, помните, что
анализировать следует не только неудачи, но и успехи, так как из них
также можно сделать выводы, которые пригодятся в дальнейшем. Чаще
всего мы слишком много внимания уделяем ошибкам и тому, как их
исправить.

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

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

Глава 14
Подведение итогов
Мы с вами проделали долгий путь, и если вы следовали за путеводной
нитью метода CORE PM, то наверняка перед вами уже сияют башни
Изумрудного города. Настало время оглянуться назад и проанализи-
ровать то, чему вы научились за время пути. Вот семь ключей к успеш-
ному осуществлению проекта.
Семь ключей к успеху
Семь секретов успешной работы над проектом --- это то, что отдельная
проектная команда может и должна сделать. Вот эти ключи к успеху:
1. Использовать эффективные методы работы.
2. Не жалеть времени на планирование проекта.
3. Привлечь к работе заказчика.
4. Сделать проект управляемым.
5. Сформировать единую команду.
6. Организовать эффективный обмен информацией.
7. Учиться на своих ошибках.
Теперь расскажем об этих секретах более подробно.
Секрет 1 --- использовать эффективные методы
работы
Эффективный метод работы (например, рассмотренный в этой книге
метод СОРЕ РМ) предоставляет вам алгоритмы и инструменты, необхо-
димые для успешного выполнения проекта. Изобретать новые методы
работы вряд ли разумно, если только вы не являетесь опытным экспер-
том по части управления проектами. Лучше всего использовать испы-
танные методы и вести команду к цели, руководствуясь именно ими.
Самое главное в секрете успеха --- это слово применение. Ни один
метод не принесет плодов, пока вы его не используете. Применение

Глава 14. Подведение итогов
207
метода означает, что он должен приводить к определенным результа-
там. Если вы прочитаете о методе, но не примените его на практике,
вряд ли он вам существенно поможет. Применяйте на практике те при-
емы и методы, о которых вы только что прочитали. Предложите осталь-
ным членам команды изучить какой либо метод, а затем испытайте его
все вместе. Вам не обязательно с самого начала использовать весь
метод целиком. Попробуйте составить чартер проекта или выпол-
нить оценку рисков. Постройте вместе с командой график работы
или заключите командное соглашение. Какие бы составляющие ме-
тода вы не использовали в работе, ваши проекты от этого только вы-
играют.
Секрет 2 --- не жалеть времени на планирование
проекта
Большинство команд, трудящихся над проектами, приступает к этапу
выполнения, не составив ни чартера, ни плана работы над проектом.
Они считают, что, начав сразу с создания продукта, они быстрее по-
кончат с выполнением проекта в целом. Однако если уделить доста-
точно времени процессу планирования проекта, то это:
поможет гарантировать то, что конечный продукт будет отвечать
потребностям заказчика проекта;
избавит от многих проблем и сведет к минимуму количество ра-
боты, которую придется переделывать;
позволит удостовериться, что вы движетесь в правильном на-
правлении, прежде чем вы приступите к этапу выполнения;
даст возможность убедиться, что руководство поддерживает раз-
работанный план действий;
сократит общее время, требуемое для выполнения проекта.
Не жалейте времени на планирование проекта! Особое внимание
уделите следующим вопросам:
1. Исследуйте потребности заказчика проекта. Убедитесь, что вы
правильно поняли проблему и что решение, которое вы собира-
етесь внедрить, будет наилучшим из возможных решений. Нуж-
но постоянно проверять, поможет ли конечный продукт решить
проблему, которая стоит перед заказчиком.
2. Никогда не начинайте проект без чартера. Этот документ помога-
ет очертить ожидания руководства --- направление работы над про-
ектом и любые существующие ограничения по ресурсам. Рабо

208
Глава 14. Подведение итогов
тать над проектом без чартера --- это все равно что отправиться
в отпуск, так и не решив, куда именно, вы едете. Хорошо, если вас
не ждут в определенном месте к заранее оговоренному сроку;
если кто то вас ожидает, то это уже гораздо хуже. Руководство
рассчитывает, что вы, проделав работу, достигнете определенно-
го «места назначения». Поэтому вам стоит узнать, каким должен
быть конечный пункт вашей работы над проектом.
3. Составляйте проектный план при участии команды. Убедитесь,
что вы досконально определили цели и задачи работы, всех доль-
щиков, риски, график работы и бюджет проекта. Затем отдайте
план на утверждение спонсору, заказчику, менеджерам по ресурсам
и другим заинтересованным сторонам. Проектный план --- это
карта, по которой вы добираетесь до конечного пункта назначе-
ния вашей работы. Нужно только определить, куда вы направля-
етесь, сколько понадобится сделать остановок для пополнения
ресурсов и анализа результатов, а также составить раскладку всех
требуемых ресурсов --- т. е. все, что может понадобиться, чтобы
благополучно добраться до места назначения.
Секрет 3 --- привлечь к работе заказчики
Проект создается для того, чтобы удовлетворить потребности заказ-
чика. Команда исполнителей часто испытывает затруднения, пытаясь
четко сформулировать потребности и желания заказчика, а затем со-
ставить на их основе список требований, которые понятны ему и при-
емлемы для него. Лучший способ убедиться, что окончательный про-
дукт соответствует потребностям и пожеланиям заказчика, --- это
привлечь его к участию в работе над проектом, особенно на ранних
стадиях, когда определяются цели и задачи проекта. В этом случае за-
казчик вряд ли окажется неудовлетворенным, цели и задачи, указан-
ные в плане, будут соблюдены и вам не придется постоянно что то
менять по ходу работы. Кроме того, заказчик станет активным участ-
ником проекта, почувствует причастность к результатам проекта и от-
ветственность за них.
Даже после того, как вся информация о требованиях заказчика (при
его участии) будет собрана, не стоит отстранять его от работы над про-
ектом. Если возможно, включите в команду представителя его интере-
сов. В этом случае вы сможете постоянно получать от заказчика необ-
ходимые ресурсы и информацию. Его представитель в команде также
будет исполнять роль посредника.

Глава 14. Подведение итогов
209
На этапе воплощения проекта в жизнь лидер проекта должен регу-
лярно встречаться с заказчиком, предоставляя ему отчеты о положе-
нии дел и получая его отзывы и информацию, которая может иметь
большое значение для проекта. При возникновении проблем нужно
сообщить заказчику, что вы собираетесь предпринять для их решения.
Если эта проблема касается заказчика напрямую, то нужно сначала
выяснить его мнение о том, как следует поступить в сложившейся си-
туации. Предложите ему несколько вариантов решения на выбор. А за-
тем ознакомьте его с отчетами о том, как было реализовано выбранное
им решение.
Когда заказчику будет передан конечный продукт, попросите его
оценить не только результаты, но и сам процесс выполнения проекта,
который привел к получению данных результатов.
Заказчики могут стать вашими надежнейшими союзниками. Нуж-
но только мудро использовать их возможности.
Секрет 4 --- сделать проект управляемым
Вы близки к отчаянию. Перед вами стоит цель, которая кажется недо-
стижимой. Ваши ресурсы ограничены. Вы работаете с группой людей,
которые не знают, что им делать. Однако не стоит волноваться. Для
начала четко определите цель --- конечный продукт проекта, затем раз-
бейте ее на более мелкие цели, т. е. промежуточные продукты проекта,
а затем организуйте все это в подпроекты. Для каждого подпроекта
нужно назначить ответственное лицо.
Сделать проект управляемым --- значит сделать его выполнимым,
а если он будет таким, то вы легко сможете его осуществить.
В методе CORE PM мы делаем упор на продукты проекта (полу-
ченные результаты или произведенная продукция), а не на операции.
Работа, ориентированная на продукт проекта, имеет ряд преимуществ:
вы можете ясно определить область подотчетности по каждому
продукту: кто будет работать над этим продуктом, к какому сро-
ку продукт будет готов, сколько потребуется денежных средств,
каковы требования к итоговому качеству;
выполнение продукта легко контролировать. Либо продукт вы-
полняется в срок, в рамках бюджетных ограничений и удовлет-
воряет критериям потребителя либо нет;
вы не запутаетесь в лишних деталях. Большие проекты могут со-
стоять из такого огромного количество операций, что определить

210
Глава 14. Подведение итогов
взаимосвязи отдельных операций практически невозможно. Если
основная проектная команда сосредоточивается на продуктах
и определяет детали отдельно для каждого подпроекта, то взаи-
мосвязи проясняются и управлять проектом становится гораздо
легче.
Секрет 5 --- сформировать единую команду
Одной из основных функций лидера проекта является формирование
команды. Рассмотрим ряд важных элементов этого процесса.
Привлекайте команду к планированию проекта
Создание эффективной команды необходимо начать еще на стадии
запуска проекта. Определите, какие навыки понадобятся команде и как
в ней должны быть представлены интересы дольщиков, а затем исполь-
зуйте потенциал команды для разработки проектного плана. Переходя
к этапу выполнения проекта, нужно привлечь команду к контролю
состояния работы по проекту. Если члены команды почувствуют себя
хозяевами проекта на этапе его выполнения, они будут более опера-
тивно и эффективно справляться с возникающими в ходе работы труд-
ностями. Они сохранят это чувство собственности, и решение проблем
из персональной обязанности лидера превратится в дело всей команды.
Пользуйтесь визуальными методами и приемами работы
в команде
Приемы работы в команде помогут вовлечь в работу над проектом всю
команду. Если вы участвуете в организации собрания, то нужно с по-
мощью инструментов для командной работы рассадить участников и
организовать между ними беседу с учетом всех трех стилей восприя-
тия; при этом сначала участники могут ощутить некий дискомфорт.
Но стоит только раз попробовать, и вы уже не захотите возвращаться
к собраниям старого образца, на которых все безучастно слушали до-
кладчика. Во время собрания встаньте и возьмите маркер. Запишите
все идеи и проблемы на клейкой бумаге для заметок и прикрепите ее
к листу ватмана на стене. Еще лучше, если члены команды сами запишут
свои идеи, затем произнесут их вслух прикрепят листки к плакату.
Используйте диаграммы по сходству параметров в случае, если у вас
накопилось много идей и нужно как можно быстрее рассортировать их
и привести в порядок. Вы ищете первопричины проблем? Попробуйте
построить диграф причинно следственных взаимосвязей. Вам нужно

Глава 14. Подведение итогов
211
сократить список идей? Примените метод многозначного голосования.
Вы хотите рассмотреть все идеи и отобрать лучшие из них? В этом
случае вам поможет матрица решений МТ. Благодаря рассмотренным
приемам работы в команде, основанным на использовании знания и опы-
та ее членов, каждый из них примет активное участие в работе и резуль-
таты работы над проектом окажутся наилучшими из возможных.
Будьте помощником, а не начальником
Раньше руководитель проекта действовал как диктатор, в одиночку
решая, что нужно делать, а затем распределяя обязанности между чле-
нами команды. В новой модели взаимоотношений с командой руково-
дителю отводится роль помощника. В этой роли от него требуется:
(1) уважать индивидуальные различия; (2) создавать и поддерживать
безопасную рабочую среду; (3) обеспечивать ход процесса, не вникая
в детали. Если вы должным образом организуете процесс и убедитесь,
что в вашей команде работают нужные люди, вы тем самым позаботи-
тесь и о содержании работы.
Управляйте процессами внутри команды
Все команды развиваются по одной и той же схеме, проходя через не-
сколько стадий формирования, но не все из них достигают наивысшей
ступени развития --- стадии единения. От лидера проекта требуется
так управлять процессами внутри команды, чтобы привести ее к выс-
шей точке развития, когда люди удовлетворены работой, продуктивно
сотрудничают и получают от этого удовольствие. Управление команд-
ными процессами начинается с момента запуска проекта и продолжа-
ется до самого конца. Применение в управлении проектом приемов
работы в команде, с помощью которых к участию привлекаются все
члены команды, помогает сплотить рабочий коллектив.
Управление процессами внутри команды, как и руководство про-
цессом управления проектом, требует от лидера целого ряда новых
навыков. К ним относятся:
навыки сотрудничества;
навыки помощника;
навыки и приемы для разрешения конфликтных ситуаций;
навыки получения конструктивной обратной связи;
приемы решения проблем;
приемы метода «мозгового штурма»;
навыки общения;
навыки управления проектом.

212
Глава 14. Подведение итогов
Секрет 6 --- организовать эффективный обмен
информацией
Организовать обмен информацией --- это непростая задача для любой
организации, но еще труднее этого добиться, когда вы работаете над
проектом. Проект можно сравнить с открытием новой фирмы. Он вы-
полняется на заказ, так как его цель состоит либо в разработке чего то
нового, либо в усовершенствовании чего то уже существующего. На-
бирается команда, определяются заказчик и дольщики проекта. Воз-
никает необходимость в каналах обмена информацией. Нужно раз-
работать процедуры коммуникации и для внутренних, и для внешних
целей.
Обмен информацией внутри команды в основном осуществляется
на собраниях, а также посредством систем голосовой и электронной
почты. Лидер проекта должен составить график собраний команды.
Их следует проводить с помощью эффективных инструментов управ-
ления собраниями. Эффективное собрание имеет большое значение
для образования продуктивных каналов обмена информацией. Кроме
того, нужно определить формальные потоки информации между члена-
ми команды, а также между руководителем проекта и членами команды.
Например, обновляется ли информация после проведения командных
собраний? Если да, то когда?
Наиболее важным внешним каналом информации является связь
между руководителем, спонсором и заказчиком проекта. Помимо их
взаимодействия во время разработки и утверждения проекта органи-
затор и заказчик должны непрерывно обновлять информацию о со-
стоянии дел и запросах об изменениях.
Кроме того, другие участники, например менеджеры по ресурсам,
также должны постоянно получать информацию о ходе работ и тре-
буемых ресурсах. Для этого члены команды исполнителей назначают-
ся ответственными за информирование определенных участников
проекта.
Организация обмена информацией часто кажется слишком трудо-
емкой, но она необходима, так как информации никогда не бывает
слишком много, особенно при работе над проектом, цель которого ---
изменить структуру организации или разработать инновационный
продукт. Подготовка сторон, заинтересованных в проекте, к его резуль-
татам не менее важна для успеха проекта, чем основная задача проек-
та --- достижение поставленных целей.

Глава 14. Подведение итогов
213
Секрет 7 --- учиться на своих ошибках
Возможно, наиболее значимый ключ к успеху заключается в том, что-
бы не закрывать глаза на собственные ошибки, так как это поможет
вам избежать подобных промахов в будущем. Успешный опыт тоже
заслуживает внимания: только зная, как вы достигли успеха, вы смо-
жете повторить его.
Необходимо делать выводы и фиксировать их документально на
протяжении всего выполнения проекта. Кроме того, в конце проекта
следует посвятить некоторое время пересмотру всего того, что про-
изошло во время работы. Нужно, чтобы проект оценили заказчик, спон-
сор и дольщики. Что было сделано правильно? Что можно улучшить?
Попросите также оценить проект членов команды. Что прошло удач-
но? Что нужно взять на заметку?
Собрав все факты, проанализируйте основные причины проблем,
которые возникли во время работы (постройте схему причинно след-
ственных взаимосвязей). Это поможет определить, что в следующий
раз нужно делать иначе, чтобы избежать проблем.
Во время проекта важно быть в курсе того, какими аспектами работы
недовольны команда и другие заинтересованные стороны. Чем раньше
вы узнаете о существовании проблемы, тем быстрее сможете ее устра-
нить.
Весь опыт, полученный при выполнении проекта, можно преобра-
зовать в шаблоны работы или списки контрольных вопросов для по-
следующих проектных команд. Каждая команда должна учитывать
опыт предшественников, совершенствуя тем самым мастерство успеш-
ного выполнения проектов в организации в целом.
Заключение
ЕСЛИ ВЫ используете в работе все семь ключей к успеху, как и предпи-
сывает метод CORE PM, то, несомненно, работа над большинством
проектов приведет вас к долгожданной цели --- к вашему Изумрудно-
му городу. Однако, несмотря на все старания, некоторые проекты все
же будут терпеть крах. Такова их природа, ведь при создании чего то
нового или улучшенного используемые технологии иногда оказыва-
ются неэффективными, а стратегия вашей организации --- недально-
видной. Применение приемов, подсказок и методик, описанных в этой
книге, значительно повысит ваши шансы на успех. Дерзайте! И чем
дальше, тем более успешным будет ваш путь.

Приложение А
Тест для самооценки способностей
руководителя проекта
Оцените ваши лидерские способности с помощью следующего теста
для самопроверки. Используйте шкалу для ответов на вопрос от 1 до 6:
1 --- почти никогда;
2 --- время от времени;
6 --- менее половины всего времени;
4 --- более половины всего времени;
5 --- большую часть времени;
6 --- всегда.
Утверждение
1. Я удостоверяюсь в том, как команда создает командное
соглашение и насколько она его в дальнейшем
соблюдает
2. Моя команда использует для принятия решения инстру-
менты, основанные на командной работе, благодаря
чему решения принимаются оперативно и эффективно
3. Я удостоверяюсь в том, что команда ясно понимает,
принятие каких решений находится в области ее компе-
тенции, а какие нет
4. Я фиксирую всю информацию, которой члены команды
обмениваются на собраниях и которую записывают на
лекционных плакатах или листах ватмана
5. Я создаю командную среду, в которой нет места страху
и чувству вины
6. Я отношусь к каждому члену команды с уважением
7. Я удостоверяюсь в том, что каждый может на равных
правах принимать участие в работе
8. При использовании метода «мозгового штурма»
я удостоверяюсь в том, что фиксируются все идеи
и что никто не критикует высказываемые гипотезы
Балл
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
4
4
4
4
4
4
4
4
5
5
5
5
5
5
5
5
6
6
6
6
6
6
6
6

Приложение А. Тест для самооценки способностей руководителя проекта 215
Утверждение
9. Я лично обеспечиваю конструктивную обратную связь
(информацию как о положительных, так и об отрица-
тельных реакциях) со всеми членами команды при
необходимости
10. Я формирую командный процесс, в котором учитыва-
ются различия в стилях мышления, обработке инфор-
мации и стилях восприятия
11. Я умею эффективно слушать других, так как должен
быть уверен, что правильно понимаю высказывания/
переживания других
12. Я слежу, чтобы все конфликты полностью разрешались
посредством принятия выигрышных решений
13. Я персонально признаю успехи членов команды
14. Я не боюсь, что мои идеи будут оспорены
15. Я умею и действительно учусь на опыте командной
работы
16. Я знаю, как управлять всеми стадиями формирования
команды (формирование, возмущение, стабилизация,
выполнение работы и расставание)
17. Я регулирую работу команды на всех четырех этапах
процесса управления проектом
18. Все члены команды принимают участие в процессах
планирования и мониторинга проекта
19. Все члены команды ясно понимают, за какую часть
работы они несут ответственность
20. Я поддерживаю хорошие отношения с организатором
и потребителем проекта
21. Все члены команды оценивают положительные резуль-
таты и возможности для улучшения работы на каждом
командном собрании
22. Мы периодически отмечаем наши успехи
23. Я сам помогаю членам команды решать проблемы,
прежде чем обратиться за помощью к организатору
или потребителю проекта
24. Я регулярно информирую организатора и потребителя
проекта о состоянии дел
25. Я удостоверяюсь в том, что этап завершения проекта
проводится без поиска или указания виновных, а един-
ственно с целью выявления полученного опыта
Балл
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5
6
6
6
6
6
6
6
6
6
6
6
6
6
6
6
6
6

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

Приложение В. Стили мышления
217
Существует 16 индивидуальных стилей в рамках данных 4 катего-
рий. Сильные стороны мышления некоторых людей сконцентрирова-
ны только в одной из категорий. Другим же людям присущ смешан-
ный стиль мышления.
В командном окружении важно понять сильные и слабые стороны
мышления как каждого индивидуального сотрудника, так и команды
в целом. Например, если в команде не хватает людей с аналитическим
типом мышления, то руководителю команды проекта придется рабо-
тать интенсивнее, проверяя, приняты ли решении в соответствии с ре-
альными фактами и данными, а не просто интуитивно. Инструменты
принятия решений МТ, которые обсуждались в гл. 11, могут служить
хорошими аналитическими инструментами для того, чтобы упрочить
аналитический подход к работе внутри группы.
Стили мышления каждого человека в отдельности и команды в це-
лом можно определить и изобразить, используя «Игру на определение
различий», созданную группой Ned Hermann Group. Ее можно приобрести,
обратившись на web сайт Мартин Тейт по адресу www.projectresults.com.

Приложение С
Пример командного договора
A. Обязательства
Мы как команда проекта будем:
1. Соглашаться только на ту работу, в которой мы компетентны и ко-
торую способны выполнить.
2. Честны и реалистичны при планировании масштабов, графиков,
обеспечения персоналом и издержек проекта, а также в отчетах
о проекте.
3. Работать в предупреждающей манере, предвидя потенциальные
проблемы и предотвращая их до того, как они проявились.
4. Сразу оповещать нашего потребителя (потребителей) и органи-
затора проекта обо всех изменениях, которые могут затронуть их
интересы.
5. Извещать других членов команды о ходе проекта и всех измене-
ниях.
6. Хранить конфиденциальную информацию о наших потребителях
в строжайшей тайне.
7. Фокусировать свое внимание на том, что улучшит проект в целом.
8. Доводить данный проект до конца.
B. Собрания команды. Основные правила: участие в работе
Мы будем:
1. Сохранять в тайне вопросы, обсуждаемые командой на собрани-
ях, если иное не оговорено.
2. Честными и открытыми в ходе собраний.
3. Поощрять различные точки зрения на все темы.
4. Предоставлять каждому члену команды возможность равного уча-
стия.
5. Открыты для новых подходов и готовы слушать новые идеи.

Приложение С. Пример командного договора
219
6. Избегать обвинений, когда что то не ладится. Вместо этого мы
будем обсуждать происходящее и искать способы улучшения си-
туации.
C. Собрание команды. Основные правила: обмен информацией
Мы будем:
1. Стремиться понять и только затем быть понятыми.
2. Говорить четко и по существу.
3. Активно и эффективно слушать.
4. Поддерживать ход обсуждений.
5. Использовать визуальные средства, такие как рисунки, графики
и таблицы, для того чтобы облегчить обсуждение.
D. Собрание команды. Основные правила: решение проблем
Мы будем:
1. Поощрять участие каждого.
2. Поощрять все идеи (не критиковать), поскольку новые концеп-
ции выходят за рамки нашего обычного восприятия.
3. Основываться на идеях друг друга.
4. Использовать инструменты работы в команде для того, чтобы
облегчить решение проблем.
5. Когда это возможно, использовать данные, которые могут по-
мочь в решении проблемы.
6. Помнить, что решение проблем --- это творческий процесс и в ре-
зультате часто приходят новые идеи и новое понимание.
E. Собрание команды. Основные правила: принятие решений
Мы будем:
1. Принимать решения, основанные на фактах, если это возможно.
2. Искать необходимую информацию.
3. Обсуждать критерии (издержки, время, воздействие и т. д.) при-
нятия решений перед тем, как выбрать какой то вариант.
4. Поощрять и анализировать различные интерпретации сведений
и данных.
5. Получать вклад в виде идей и мнений от каждого участника, пе-
ред тем как принять решение.
6. Обсуждать дела и интересы с другими участниками команды во
время собраний или частным образом, а не с посторонними и в не-
подходящей манере.

220
Приложение С. Пример командного договора
7. Спрашивать всех участников команды, могут ли они поддержать
решение, перед тем как это решение будет принято.
F. Собрание команды. Основные правила: разрешение
конфликтов
Мы будем:
1. Рассматривать конфликты как естественный процесс и как воз-
можность для роста.
2. Пытаться понять интересы и пожелания каждой вовлеченной сто-
роны перед тем, как найти ответ или решение.
3. Выбирать подходящее время и место для обсуждения и решения
конфликта.
4. Внимательно слушать чужие точки зрения.
5. Повторять то, что мы поняли, и спрашивать другую сторону, пра-
вильно ли мы поняли ее точку зрения.
6. Признавать веские и обоснованные замечания, сделанные другой
стороной.
7. Представлять нашу точку зрения и наши интересы в беспристра-
стной манере, не нападая на оппонента.
8. Стараться найти общее основание для решения.
G. Нормативы для собраний
1. Собрания будут проводиться каждые дней/недель/месяцев.
2. Собрания будут созываться
.
3. Повестки дня будут издаваться каждые дней/недель, заранее,
за
вперед.
4. Собранию будут содействовать
.
5. Через каждые
собрания будет проводиться оценка проведен-
ных собраний.
6. Секретарь будет составлять протокол собраний каждые дней
проведения собраний.
Н. Процедуры, связанные с собранием
1. Собрания будут начинаться и заканчиваться вовремя.
2. Команда будет приходить на собрания подготовленной.
3. Во время собраний пейджеры и телефоны будут отключены.
4. В конце каждого собрания будет обсуждаться повестка дня сле-
дующего собрания.

Приложение С. Пример командного договора
221
5. ДЛЯ ТОГО чтобы перехватывать идеи и вопросы, не касающиеся
сути дела, будет использоваться специальное место для заметок.
6. Нерешенные проблемы будут вноситься в список решаемых проб-
лем.
7. Если какой то член команды не может присутствовать на собра-
нии, он должен послать от себя представителя с правом приня-
тия решений.
8. Задания, связанные с проведением собраний, будут выполняться
членами команды по очереди.
Подписи: (члены команды).

Приложение D
Методология решения проблем
MartinTate {MT)
Методология решения проблем MartinTate (МГ)/называется ОАВ/ВО.
Первые три этапа этого метода (ОАВ) включают определение пробле-
мы (стадия определения), анализ проблемы (стадия анализа) и затем
выбор решения (стадия выбора). Стадии ВО используются для внед-
рения решения.
Первые три стадии должны быть отработаны, прежде чем можно
будет приступить к началу реализаций решений в проектах.
Стадия 1 --- определение проблемы (О). На первой стадии команда
изучает проблему и среду, в которой эта проблема возникла. Изучают-
ся любые имеющиеся данные о проблеме и разрабатываются в пись-
менном виде формулировки задачи.
Стадия 2 --- анализ проблемы (А). На второй стадии собираются дан-
ные для разъяснения проблемы; это процесс, в ходе которого опреде-
ляются место возникновения существующей проблемы и ее основные
причины. Наконец, составляется письменная формулировка причин
проблемы.
Стадия 3 --- выбор решения (В). На третьей стадии команда с помо-
щью метода «мозгового штурма» определяет возможные пути разре-
шения проблем и создает несколько потенциальных вариантов. Из них
выбирается оптимальный. Затем нужно составить описание решения.
Этот трехэтапный процесс должен быть завершен до того, как будет
начат проект. Нужно убедиться, что вы определили точные причины
возникновения проблемы и приняли самое лучшее из возможных ре-
шений, прежде чем приступить к реализации решений в проекте. Ког-
да определение проблемы и отбор решения требуют командной рабо-
ты, то трехэтапный процесс решения проблемы становится уже сам по
себе отдельным проектом. Он также требует запуска, планирования,
выполнения и завершения.
Последние два этапа методологии, внедрение и обзор результатов,
также можно считать отдельным проектом. На этапе внедрения команда

Приложение Р. Методология решения проблем MartinTate (MT) 223
разрабатывает решение и затем следит за его выполнением. Если этот
этап проходит успешно, то решение реализуется в полном объеме. На
этапе обзора результатов сравниваются данные о реализации решения
с имеющимися данными о проблеме, чтобы удостовериться в том, что
решение было принято правильно и оно помогло устранить основные
причины возникновения проблемы. При необходимости нужно вне-
сти поправки в решение, а затем передать его менеджеру, занимающе-
муся бизнес процессами, который отвечает за непрерывную поддерж-
ку процесса реализации решения.

Паула Мартин, Карен Тейт
УПРАВЛЕНИЕ ПРОЕКТАМИ
Серия «Практика менеджмента»
Перевод с английского О. А. Страховой, О. П. Табеловой
Главный редактор
Е. Строганова
Заведующий редакцией
С. Жильцов
Руководитель проекта
Е. Базанов
Выпускающий редактор
Е. Маслова
Научные редакторы
В. Галенко, О. Страхова
Редактор
Н. Перевезенцева
Художественный редактор
С. Маликова
Корректоры
М. Одинокова, Н. Сулейманова
Верстка
А. Полянский
Лицензия ИД No 05784 от 07.09.01.
ООО «Питер Принт», 194044, Санкт Петербург, пр. Б. Сампсониевский, дом 29а.
Налоговая льгота --- общероссийский классификатор продукции ОК 005 93,
том 2; 95 3005--- литература учебная.
Подписано в печать 12.08,05. Формат 60*90/16. Усл. п. л. 14.
Тираж 2500. Заказ No 1815.
Отпечатано с готовых диапозитивов в ООО «Типография Правда 1906».
195299, С. Петербург, Киришская ул., 2.
Тел,: (812) 531 20 00, (812) 531 25 55