Набор инструментов для управления проектами читать онлайн - Драган Милошевич

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

Драган З. Милошевич

Профессор Портлендского университета (Орегон, США) Драган Милошевич, написавший эту монографию, обобщил свой многолетний опыт управления крупными проектами и открыто поделился своими наработками и достижениями в систематизации бизнес-процессов по управлению проектами.

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

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

Драган З. Милошевич

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

Инструменты и приемы для практикующего project-менеджера

Под общей редакцией С.И. Неизвестного

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

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

All Rights Reserved. Authorized translation from the English language edition published by by John Wiley & Sons, Inc.

Предисловие к русскому изданию

Когда-то, в тяжелые времена, Джон Кеннеди сказал: «У меня есть тысячи специалистов, могущих построить пирамиду. Но нет ни одного, который сказал бы, стоит ли ее строить»!

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

Профессор Портлендского университета (Орегон, США) Драган Милошевич, написавший эту монографию, широко известен в западных кругах в сфере управления проектами.

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

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

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

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

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

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

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

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

Сергей Неизвестный,

научный редактор книги,

член Project Management Institute,

член International Project Management Association,

член Российской Ассоциации Управления Проектами СОВНЕТ

Теория, упакованная в набор инструментов управления проектами

Возможности управления проектами (PM) на сегодняшний день достигли пика своего исторического развития. Дело в том, что управление проектами стало предпочтительной стратегией ведения бизнеса, и тому есть множество свидетельств. Крупные корпорации, локомотивы американской экономики, провели широкомасштабные акции по корпоративному управлению проектами и основали центры управления проектами, которые предназначены для создания среды, способствующей успеху PM. Чтобы повысить свою конкурентоспособность, журнал «Fortune 500»[1 - Журнал «Fortune» (США) ведет ежегодно обновляющийся список 500 крупнейших компаний США, ранжированных по объему продаж. – Прим. ред.] организовал новый форум по определению сравнительной эффективности (бенчмаркинг) управления проектами, задачей которого стало выявление лучших практик PM. Небольшие фирмы тоже стараются не отстать в этой гонке за лидерами. Интересно то, что данное явление носит всеохватный характер. К областям, в которых использование управления проектами стало традиционным, присоединяются такие представители новой экономики, как высокие технологии и телекоммуникации.

Результатом подобной популярности стал экспоненциальный рост как количества членов Института управления проектами (PMI) – крупнейшей в мире ассоциации менеджеров проектов, – так и количества сертифицированных профессионалов управления проектами (PMP). Более того, авторитет корифеев управления проектами повысился и за пределами этой сферы. Том Петерс (Tom Peters) называет работу менеджера проекта работой номер один в XXI веке. Элиахия Голдратт (Eliahy Goldratt), пионер теории ограничений, рассматривает управление проектами как следующий фронтир непрерывного совершенствования бизнеса. Выражая доверие к утверждениям этих гуру менеджмента, компании уже сделали миллиардные вложения в обучение персонала управлению

проектами.

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

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

Способы подачи материала

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

Отметим вкратце, что в главе 1 рассматривается построение набора инструментов, поддерживающего конкурентную стратегию компании, а главы 2 – 15 представляют собой хранилище более чем 50 инструментов, причем упоминание каждого из этих инструментов сопровождается объяснением, как его использовать, – данным аспектом традиционная литература часто пренебрегает. Инструменты, необходимые для инициации проектов и перестройки организации с целью обеспечения их выживания, рассмотрены в части I. Часть II посвящена инструментам планирования проектов, позволяющим разработать реалистичный сетевой график, запланировать развитие проекта в будущем и реализовать его бизнес-цели. Инструменты исполнения, контроля и закрытия проектов анализируются в части III. И наконец, используя эти инструменты как основные строительные блоки, в части IV показано, как можно построить «инструментальный ящик» управления проектами, а также приведено несколько практических примеров. Ниже представлено более детальное описание этих шагов.

Рис. 1. Структура книги

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

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

В главах 11 – 15 части III рассматриваются несколько групп инструментов практической реализации, предназначенных для осуществления плана, который разработан с помощью инструментов, описанных в части II. В этих главах предлагаются способы выполнения проектов путем синхронизации развертывания рабочей силы и материальных ресурсов, то есть способы претворения планов проектов в жизнь. Инструменты контроля фокусируются на мониторинге и измерении хода исполнения и выполнении надлежащих действий для достижения бизнес-целей проектов. Роль инструментов закрытия состоит в том, чтобы планомерно завершить проект и обеспечить приемку его результатов. При выборе инструментов реализации мы внимательно прислушивались к словам менеджеров, полагающих, что главная задача практического выполнения состоит в том, чтобы опираться на факты, носить упреждающий характер и непрерывно прогнозировать путь, по которому пойдет развитие проекта. Как следствие описываемые инструменты показывают и объясняют, как обеспечивать упреждающую отчетность и контроль содержания, расписания, стоимости и качества, как осуществлять упреждающий контроль процессов выполнения в части реагирования на риски и создания команды, и наконец, как реализовать надлежащее завершение проекта.

Разработке каркаса для выбора инструментов и их подстройки под потребности пользователя посвящена часть IV. Действительно, теперь, когда известно, какие инструменты нам доступны, пора переходить к главе 16, где показано, как отобрать

инструменты для включения в «инструментальный ящик». Это достигается посредством уникального ситуативного (рассчитанного на различные непредвиденные случаи) каркаса, почти не представленного в традиционной литературе. Он призван помочь отобрать те инструменты, которые наилучшим образом отвечают конкретной ситуации. Чтобы сделать применение инструментов в реальных условиях более наглядным, книга сопровождается несколькими приложениями, содержащими примеры «инструментальных ящиков» для ряда ситуаций, которые встречаются при выполнении проектов. Эти ситуации затрагивают проекты различных размеров и сложности и относятся к разным предметным областям. Следует также добавить, что устанавливается четкая взаимосвязь между инструментами, рассматриваемыми в данной книге, и популярным изданием Института управления проектами «A Guide to Project Management Body of Knowledge».

Структура глав

В части рассмотрения отдельных инструментов управления проектами главы 2 – 15 имеют однотипную структуру и ход изложения (рис. 2).

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

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

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

Рис. 2. План главы

Структура описания инструментов

Описания всех инструментов, рассматриваемых в главах 2 – 15, имеют единообразную структуру (рис. 3).

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

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

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

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

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

• советы;

• контрольные списки;

• детальные примеры;

• кейсы;

• базовая информация.

Рис. 3. Структура описания инструментов

Как читать эту книгу

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

• читателю, интересующемуся каким-либо инструментом управления проектами, рекомендуется в деталях изучить данный инструмент;

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

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

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

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

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

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

• владельцам/командам процессов. Отдельные менеджеры

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

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

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

Часть 1

Инструменты инициации проекта

Глава 1

Стратегическая роль «инструментального ящика» управления проектами

Человек – это животное, использующее инструменты. Без инструментов он – ничто, с инструментами он – все.

    Томас Карлайл

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

• прояснить новую роль;

• объяснить ее стратегическую важность.

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

Новая роль «инструментального ящика» управления проектами

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

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

Рис. 1.1. Пример процесса стандартизованного управления проектами с соответствующим «инструментальным ящиком»

Рис. 1.2. Пирамида, опирающаяся на «инструментальный ящик» управления проектами

Стратегия управления проектами поддерживает конкурентную стратегию

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

Суть конкурентной стратегии состоит в создании преимущества, которое позволит компании обогнать своих конкурентов [1]. Чтобы обеспечить такое преимущество, компании задействуют свои организационные ресурсы [2]. Представим себе, например, управление проектами как организационный ресурс. Для такого представления полезным может оказаться блок общих конкурентных стратегий (далее просто конкурентных стратегий), показанный на рис. 1.3 [3].

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

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

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

Компании, выбирающие стратегии минимальной стоимости, нацеливаются на достижение устойчивого ценового преимущества по отношению к конкурентам (квадрант, соответствующий низкой дифференциации/низкой стоимости на рис. 1.3). Идея состоит в том, чтобы использовать фактор низкой стоимости для создания ценового отрыва от конкурентов и тем самым отобрать у них определенную долю рынка. Еще один способ – получать более высокую прибыль, продавая продукт по текущей рыночной цене [5]. Этот способ хорош при наличии твердого базового продукта, снабженного небольшими дополнениями, и при одновременном поиске новых путей снижения цены без ухудшения качества и отказа от основных характеристик.

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

Воспользуемся описанным блоком конкурентных стратегий, чтобы понять, как управление проектами помогает создавать конкурентные преимущества. Рассмотрим три компании: Intel, Armstrong World Industries (AWI) и Oregon Anesthesiology Group (OAG). Конкурентная стратегия фирмы Intel ориентирована на достижение отличий (см. рис. 1.3). Она нацелена на технологические инновации и минимизацию времени выхода на рынок, рассматривая эти параметры как конкурентные преимущества. В данной стратегии значительная роль принадлежит проектам разработки продуктов, задача которых – быстрее и быстрее выдавать «на-гора» новые кристаллы процессоров. Именно здесь вступает в игру управление проектами, позволяющее сжать цикл разработки нового кристалла и вывести продукт на рынок раньше конкурентов. Сокращение расписаний проектов коснулось и других, не связанных с разработкой процессоров областей деятельности фирмы Intel – от крупных проектов сооружения новой фабрики до небольших проектов улучшения качества. Разумеется, это не случайность. Таков выбор руководства – развернуть управление проектами, чтобы обеспечить конкурентное преимущество за счет сокращения жизненных циклов проектов во всей компании.

Другие компании, использующие стратегии достижения отличий, также активно работают над созданием конкурентного преимущества путем сокращения длительности проектных циклов. Такие фирмы, как General Electric, NEC, Northern Telecom и AT&T, сумели сократить длительность проектного цикла в среднем на 20 – 50% [5]. Смысл сокращения цикла проекта заключается в его последствиях. Например, применительно к разработке продуктов компания, которая выходит на рынок раньше конкурентов, часто получает продажи по высокой цене, более продолжительный срок продаж, большую прибыль и более крупную долю рынка [6 – 8].

Конкурентная стратегия фирмы AWI абсолютно иная. Вместо того чтобы акцентировать внимание на отличительных чертах продукта и времени выхода на рынок (подход, столь ревностно проводимый фирмой Intel), AWI намеревается занять позиции ценового лидера в соответствующей отрасли (квадрант, соответствующий низкой дифференциации/низкой стоимости на рис. 1.3). Один из менеджеров AWI сказал: «Мы работаем в сфере производства строительных материалов уже более 70 лет. Технологические изменения не являются главным фактором в нашей отрасли – в отличие от способности предложить продукцию по более низкой цене. Чтобы развить эту способность и стать лидером в данной отрасли, нам пришлось рационализировать все производственные процессы, постоянно опуская целевую планку стоимости производства. Часть наших усилий была направлена на обеспечение управления снижением стоимости и разработку проектов развития производственных процессов». Подобное стремление к снижению стоимости заметно и в других, непроизводственных проектах фирмы AWI. Управление проектами как в производственной, так и в непроизводственной сфере ставит своей целью снижение их стоимости, что в конечном счете направлено на достижение ценового конкурентного преимущества.

Это не является секретом и для других фирм, использующих управление проектами для поддержки той же стратегии минимальной стоимости. Причина такого положения – в увеличившейся стоимости проектов и финансовых затруднениях, с которыми сталкиваются многие ведущие компании. В условиях, когда проект планирования ресурсов в масштабе предприятия может стоить 300 миллионов долларов [9], а новая фабрика – 4 миллиарда [10], компаниям, чтобы создать ценовое конкурентное преимущество [11], приходится уменьшать стоимость и финансовое бремя. Следовательно, поддержка со стороны управления проектами помогает компаниям захватить большую долю рынка и получить более высокие прибыли [2].

Конкурентное преимущество фирм Intel и AWI обеспечивается за счет такого управления проектами, которое ориентировано на минимизацию сроков и стоимости соответственно. В противоположность этим фирмам OAG (Oregon Anesthesiology Group) стремится получить наилучшую стоимость (квадрант, соответствующий высокой дифференциации/низкой стоимости на рис. 1.3). Цель этой корпорации, в которой работают более 190 врачей, состоит в предоставлении услуг здравоохранения по наилучшей цене в сравнении с конкурентами, предлагающими услуги аналогичного качества [4]. Соответственно и управление проектами здесь нацелено на решение стоимостных и качественных задач. Вице-президент ОАО говорит: «Рынок, подобный нашему, – это беспощадный рынок. Организации по управлению здравоохранением постоянно давят на всех медиков, принуждая их к уменьшению стоимости услуг. Чтобы остаться на плаву, мы стандартизировали все протоколы управления, применяемые нами во всех проектах информационных систем и проектах постоянного повышения качества. Это позволило выполнять проекты в соответствии с целевыми установками по части качества и стоимости. В противном случае наши клиенты предпочтут иметь дело с кем-то другим». Используя свое конкурентное

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

Другие эксперты подтверждают, что соотношение «цена – качество» рассматривается в ряде фирм как цель проектов [12]. Дело в том, что компании, которые ориентируются на стратегию достижения наилучшего показателя «цена – качество» и вытекающие из нее конкурентные преимущества, нуждаются в таком управлении проектами, которое данную стратегию поддерживает.

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

• компании выбирают свои конкурентные стратегии;

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

Во-первых, компании выбирают конкурентные стратегии как средства борьбы со своими соперниками по рынку. Хотя конкурентная стратегия любого типа имеет в конечном счете одну и ту же цель – создание конкурентного преимущества, способы ее достижения различаются. Одни строят преимущество на основе дифференциации (отличия от других), другие – на основе низкой стоимости, а третьи – на основе показателя «цена – качество». Во-вторых, компании используют управление проектами в соответствии со своими стратегиями. Поэтому в Intel, AWI и OAG по-разному представляют показатель, на котором должно быть сфокусировано управление проектами: на сроках (Intel), на стоимости (AWI), на соотношении «цена – качество» (ОАО). И нет ничего удивительного в том, что некоторые видные исследователи рассматривают управление проектами как одну из величайших опасностей, равно как и благоприятную возможность, с которой сталкиваются менеджеры в своей конкурентной борьбе [13].

Хотя стратегия управления проектами играет значительную роль, она никоим образом не является единственной движущей силой создания конкурентной стратегии. Напротив, для того чтобы создать работоспособную конкурентную стратегию, необходимы и другие бизнес-стратегии, обычно называемые функциональными [2]. В частности, определенный вклад обеспечивают стратегии НИОКР, маркетинга, производства, работы с кадрами и т. д.

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

Процесс стандартизированного управления проектами поддерживает стратегию управления проектами

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

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

• элементы процесса стандартизованного управления проектами, посредством которых осуществляется такая поддержка;

• значение слова «стандартизованные»;

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

Начнем с примеров, являющихся эмпирическими свидетельствами. В недавнем отчете форума по бенчмаркингу управления проектами Fortune 500 утверждается, что 85% его членов используют при управлении проектами стандартизованные подходы и процедуры [14]. Аналогично многие организации, работающие в сфере программного обеспечения, применяют модель зрелости возможностей, также стремясь к выполнению проектов с помощью стандартизованного процесса. Ведомые идеей стандартизации процессов, некоторые организации пытаются сертифицировать свое управление проектами по стандарту ISO 9000. И наконец, многие компании внедряют модели зрелости управления проектами, чтобы постоянно улучшать управление проектами посредством стандартизованного процесса [15].

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

• фазы жизненного цикла проекта;

• управленческие и технические операции;

• результаты;

• контрольные события.

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

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

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

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

Если слово «стандартизованные» не объяснить применительно к процессу стандартизованного управления проектами, оно

может вызвать путаницу. Каков в действительности его смысл? Если мы определяем процесс стандартизованного управления проектами как стандартизованную последовательность операций проекта (которая приводит к получению результатов), то стандартизация означает степень отсутствия отклонений при выполнении таких операций [18]. Полная изменчивость процесса управления проектами – это крайний случай. Иначе говоря, процесс управления проектом каждый раз выполняется по-другому, не так, как раньше. Совершенно очевидно, что 100%-ная изменчивость означает нулевую стандартизацию. Этот подход часто называется подходом ad hoc. Другой крайний случай – 100%-ная стандартизация конкретного процесса: данный процесс всегда выполняется одним и тем же способом. В этом случае изменчивость составляет 0%. Между этими двумя крайностями лежит область реальных процессов управления проектами с различными значениями стандартизации и изменчивости.

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

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

Решение о том, насколько сильно должен быть стандартизован процесс управления проектами, – это установление отношения между стандартизацией и изменчивостью, называемого обычно гибкостью. Оно определяется стратегией управления проектами, точнее типами пропетой, с которыми имеет дело эта стратегия. В целом стратегия для проектов с высокой степенью определенности будет стремиться к более высокому уровню стандартизации и меньшему уровню гибкости. Согласно мнению экспертов, большая часть проектов в организациях принадлежит к данной группе [20]. Стратегия же для проектов, которые характеризуются высокой степенью неопределенности, требует меньшей стандартизации и большей гибкости (см. главу 16). Когда мы используем термин «процесс стандартизованного управления проектами» в этой книге, мы подразумеваем, что этот процесс стандартизован более чем на 50%.

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

«Инструментальный ящик» поддерживает процесс стандартизированного управления проектами

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

• определим инструменты управления проектами и «инструментальный ящик»;

• опишем два способа использования «инструментального ящика»;

• объясним, как процесс стандартизованного управления проектами обеспечивает соответствие (согласование) с «инструментальным ящиком»;

• сравним выгоды, обеспечиваемые методом «один инструмент за один раз» и методом «инструментального ящика»;

• разъясним вопросы стандартизации «инструментального ящика» управления проектами.

Определение инструментов управления проектами и «инструментального ящика». К инструментам управления проектами относятся процедуры и техники, посредством которых достигаются управленческие результаты. «А Guide to the Project Management Body of Knowledge» [21, 22] и другие источники используют термин «инструменты и техники» вместо того, что мы определяем как инструменты управления проектами. Два примера таких инструментов – это устав команды и анализ Монте-Карло. Они отличаются друг от друга обрабатываемой информацией. Устав команды – это систематическая процедура обработки качественной информации, которая касается даваемой команде авторизации (разрешения) на выполнение проекта. С другой стороны, анализ Монте-Карло представляет собой инструмент планирования рисков, который также устанавливает систематическую процедуру, но на этот раз выполняемую посредством алгоритма численного определения рисков. Иными словами, это количественный инструмент. Ключевым элементом как группы качественных, так и группы количественных инструментов – а все инструменты управления проектами принадлежат к одной из названных групп – является систематическая процедура. Мы не будем говорить о программном обеспечении управления проектами, хотя совершенно очевидно, что многие обсуждаемые в книге инструменты существуют и в формате программных пакетов. Однако мы делаем акцент на сути инструментов управления проектами – на их систематической процедуре.

Два способа использования «инструментального ящика». Мы определяем «инструментальный ящик» как набор предварительно выбранных инструментов, которые менеджер способен задействовать в процессе стандартизованного управления проектами. При использовании такого набора возможны два варианта. В первом случае каждый инструмент набора поддерживает конкретные результаты процессов управления. Например, два инструмента, обозначенные на рис. 1.1 как S.1, – это СДР (структурная декомпозиция работ) и описание содержания. Они поддерживают получение такого результата управления, как определенное содержание, названное S.1 (на этом рисунке все инструменты из «инструментального ящика» и поддерживаемые ими результаты управления пронумерованы соответственно). Кроме того, «ящик» разработан таким образом, чтобы включить в себя все инструменты, которые могут понадобиться для практической реализации процесса стандартизованного управления проектами и получения совокупности его результатов.

Во втором случае идея состоит в том, чтобы заменить результаты управления

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

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

Сравнение выгод, обеспечиваемых методом «один инструмент за один раз» и методом «инструментального ящика». Вне зависимости от избранной стратегии те компании, которые являются исполнителями проектов, сталкиваются с реальностью конкуренции – в дело включаются их заказчики. Заказчики говорят компаниям, что они хотят, когда они хотят это (как можно быстрее – требование высокой скорости), в каком качестве они хотят это (как можно лучше – требование более высокого качества и удовлетворения заказчика) и сколько они готовы за это заплатить (как можно меньше – требование низкой стоимости) [20]. И менеджеры прислушиваются к этим требованиям, поскольку удовлетворенные заказчики чрезвычайно важны для экономического успеха компании. В 1997 г. стоимость акций компаний, работой которых заказчики были особенно довольны, была более чем на 100% больше, чем стоимость акций остальных фирм [24]. Можно сказать, что такого понятия, как «заказчик», не существует. Есть понятие «этот заказчик» – то есть такой заказчик, который (в данный конкретный момент) использует свою власть и способность требовать. Чтобы выполнить предъявленные требования, ведущие компании стремятся создать такой процесс стандартизованного управления, который способен обеспечивать для выполняемых проектов:

• скорость;

• повторяемость;

• параллелизм.

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

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

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

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

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

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

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

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

Заключительные замечания

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

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

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

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

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

Литература

1. Hamel, G. and С. К. Prahalad 1989 «Strategic Intent» Harvard Mush Business Review 67(3): 92 – 101.

2. Harrison, J. S. and C. H. S. John 1998 «Strategic Management of organizations and Stakeholders» St. Paul, Minn.: South-Western College Publishing.

3. Porter, M. E. 1985 «Competitive Advantage» New York: The Free Press.

4. Thompson, A. A. and A. J. I. Strickland 1995 «Crafting and Implementing Strategy» Chicago: Irwin.

5. Adler, P. S., et al 1996 «Getting the Most out of Your Product Development Process» Harvard Business Review» 74(2): 134 – 152.

6. Calatone, R. J. and C. A. D. Benedetto 2000 «Perfomanse and Time to Market: Accelerating Cycle Time with Overlapping Stages» IEEE Transactions of Engineering Management 47(2): 232 – 244.

7. Nevens, T. M., G. L. Summe and B. Uttal 1990 «Commercializing Technology: What the Best Companies Do» Harvard Business Review 68(3): 154 – 163.

8. Smith, P. and D. Reinertsen 1990 «Developing Priducts in Half the Time» New York: Van Nostrand Rienhold.

9. Mclemore, I. 1999 «High Stake Games» Business Finance (5) 30 – 33.

10. Iansiti, M. and J. West 1997 «Technology Integration Turning Great Research into Great Products» Harvard Business Review 75(3): 69 – 79.

11. Wheelwringht, S. С/ and К. В. Clark 1992 «Revolutionizing Product Development» New York: The Free Press.

12. Clark, К. В. And T. Fujimoto 1991 «Product Development Performance» Boston: Harvard Business School Press.

13. Cusumano, M. and K. Nobeoka 1998 «Thinking Beyond Lean» New York: The Free Press.

14. Tony, F. and R. Powers 1997 «Best Practices of Project Management Groups in Large Functional Organizations» Drexel Hill, Pa.: Project Management Institute.

15. Kerzner, H. 2001 «Strategic Planning for Project Management» New York: John Wiley & Sons.

16. Kerzner, H. 2000 «Applied Project Management» New York: John Wiley & Sons.

17. Kemerer, C. F. 1997 «Software Project Management» Boston: McGrow-Hill.

18. Stevenson, W. J. 1993 «Production and Operation Management» Boston: Irwin.

19. Sobek, D. J. Liker and A. Ward 1998 «Another Look at How Tojota Integrates Product Development» Harvard Business Review 76(4): 39 – 49.

20. Hammer, M. and J. Champy 1993 «Reengineeringthe Corporation» New York: Harper Business.

21. Project Management Institute 2000 «A Guide to the Project Management Body of Knowledge» Newton Square, Pa: Project Management Institute.

22. Thamhain, H. J. 1999 «Emerging Project Management Techniques: A Managerial Assessment» Portland International Conference jn Management of Engineering and Technology. Portland, Oregon.

23. Coombs, R., A. McMeekin and R. Pybus 1998 «Toward Development of Benchmarking Tools for R&D Project Management R&D Management 28(3): 175 – 186.

24. University of Michigan Business School and American Society for Quality 1998 «American Customer Satisfaction Index»: 1994 – 1998 Ann Arbor: University of Micigan Press.

25. Pinto, J. K. and J. E. Prescott 1990 «Planning and Tactical Factors in the Project Implementation Process» Jornal of Managament Studies 27(3): 305 – 327.

26. Might, R. 1989 «How Northern Telecom Competes on Time» Harvard Business Review 67(4): 108 – 114.

27. Eisenhardt, K. and S. L. Brown 1998 «Time Pacing: Competing in Marketing That Won’t Stand Still» Harvard Business Review 76(2): 56 – 69.

Глава 2

Отбор проектов

В написании данной главы принимал участие доктор Джозеф П. Мартино.

Когда в ходе нашего исследования мы уходим вперед, горизонт отодвигается… и исследование всегда остается незавершенным.

    Марк Паттисон, Айзек Касубон

В полном соответствии со словами эпиграфа менеджерам все еще

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

• модель оценки ранга проекта;

• аналитический иерархический процесс;

• экономические методы (срок окупаемости, чистая приведенная стоимость, внутренняя норма прибыли);

• выбор портфеля;

• метод реальных вариантов выбора.

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

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

• научиться использовать различные инструменты выбора проектов;

• находить инструменты отбора проектов, соответствующие конкретной проектной ситуации;

• адаптировать инструменты в соответствии со своими нуждами.

Оттачивание этих навыков играет главную роль в инициации проектов и построении процесса стандартизованного управления (рис. 2.1).

Рис. 2.1. Роль инструментов отбора проектов в процессе стандартизованного управления

Модели ранжирования проектов

Что такое модели ранжирования проектов?

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

Применение моделей ранжирования проектов

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

• проектное предложение;

• стратегические и тактические планы;

• историческая информация.

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

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

Построение модели ранжирования проектов. Чтобы построить модель, нужно определить следующее:

• форму модели с указанием конкретных категорий критериев или факторов;

• величину и важность критериев;

• способы измерения критериев.

Первым делом установим форму модели. «Обобщенная» модель ранжирования проектов может выглядеть так:

В данной модели символы A, B, C, D, E, F, G представляют собой критерии, которые должны быть включены в определение ранжирования проектов. Величина каждого критерия для данного проекта подставляется в форму. Символы a, b, c, d, e, f, g – весовые коэффициенты, присвоенные каждому критерию. Согласно данной модели критерии, находящиеся в числителе, – это преимущества, в то время как критерии, стоящие в знаменателе, – недостатки. Критерии и соответствующие весовые коэффициенты устанавливаются руководством, значения критериев определяются спецификой проекта и обычно присваиваются командой проекта.

ФУНДАМЕНТАЛЬНЫЙ ПРОЦЕСС ВЫБОРА ПРОЕКТОВ

Какие типы проектов являются проектами/кандидатами (например, проекты разработки продуктов, выхода на рынок, капитального строительства, непрерывного совершенствования и т. д.)? Этот вопрос задается на начальных шагах процесса отбора проектов (рис. 2.2). Затем создается «меню» проектов/кандидатов, после чего начинается процесс выработки адекватных критериев. Цель данного процесса – включить факторы, которые помогают максимизировать ценность портфеля проектов для компании.

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

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

КРИТЕРИИ, КОТОРЫЕ ДОЛЖНЫ БЫТЬ УЧТЕНЫ ПРИ ОТБОРЕ ПРОЕКТОВ

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

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

Данная модель использует три категории критериев:

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

• взаимозаменяемые критерии (B, C, D, E) – факторы, которые способны заменять друг друга при выполнении следующего условия: уменьшение по одному критерию является приемлемым, если оно сопровождается достаточным увеличением по другому критерию. Например, проектировщик может выбирать между надежностью и ремонтопригодностью до тех пор, пока «стоимость владения» остается постоянной. В этом случае весовые коэффициенты должны отражать относительную стоимость увеличения надежности и упрощения обслуживания. Расходы F показаны как отдельный критерий, который уместен по отношению к любым проектам. Данный критерий может быть далее подразделен на категории расходов: заработная плата, материалы, коммунальные услуги, отгрузка и транспортировка – если между этими категориями существует взаимозаменяемость (допустим, использование более дорогих материалов с целью экономии расходов на оплату труда). В противном случае компоненты расходов должны просто суммироваться и рассматриваться как единый фактор;

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

Второй вопрос – величина и важность критериев. Как только формула модели определена, разработчикам следует разграничить величину и весовой коэффициент критерия. В предыдущей формуле B, C, D – величины соответствующих факторов конкретного проекта, в то время как b, c, d – весовые коэффициенты, назначенные этим факторам, которые отражают важность, присвоенную им принимающим решение лицом. В случае взаимозаменяемых факторов отношение b/c представляет собой показатель взаимозаменяемости между факторами B и C. Если B уменьшается на единицу, то C должен возрасти как минимум на величину b/c, чтобы сумма данных факторов осталась постоянной или возросла. Иными словами, менеджер, принимающий решение, волен жертвовать одним фактором в пользу другого в соответствии с их весами до тех пор, пока полная сумма остается постоянной или возрастает.

Для определения ранжирования проектов в табл. 2.2 (столбец «Элемент») использована простая модель, описываемая формулой:

Общий балл = B + C + D.

Здесь общий балл равен сумме B, C и D, то есть сумме значений таких соответствующих им критериев, как уникальные функциональные характеристики продукта или техническая сложность (см. табл. 2.2).

Наконец, третий вопрос, требующий решения, – это вопрос измерения критериев. Некоторые критерии (такие как расходы и прибыли) поддаются объективному измерению, другие (такие как вероятность успеха и стратегическая важность) не поддаются и потому должны быть получены на основе суждения. Модели ранжирования могут легко включать в себя объективные и субъективные (определяемые на основе суждения) критерии. Хорошо, если субъективные критерии оцениваются по шкале, «проградуированной» в ключевых фразах, – это обеспечит единообразную оценку данного фактора для каждого из проектов. Оценки следует выполнять в пределах какой-либо удобной шкалы, например 10-балльной (см. врезку «Пример шкалы для измерения величины критерия “Доступность носителей навыков”»). Такая шкала должна быть разработана для каждого критерия, требующего субъективной оценки (см. табл. 2.2). Объективные факторы (в частности, стоимость) могут быть измерены непосредственно, что избавляет от необходимости использования подобной шкалы.

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

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

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

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

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

ПРИМЕР ШКАЛЫ ДЛЯ ИЗМЕРЕНИЯ ВЕЛИЧИНЫ КРИТЕРИЯ «ДОСТУПНОСТЬ НОСИТЕЛЕЙ НАВЫКОВ»

10. Все навыки имеются в достаточном объеме (с запасом).

9. Все навыки доступны в необходимом объеме (без запаса).

8. Все технические навыки доступны.

7. Большинство профессиональных навыков доступно.

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

5. Необходима некоторая переподготовка носителей профессиональных навыков.

4. Необходима существенная переподготовка носителей технических навыков.

3. Необходима существенная переподготовка носителей профессиональных навыков.

2. Все носители технических навыков должны быть наняты.

1. Все носители технических навыков и некоторые носители профессиональных навыков должны быть наняты.

0. Все носители технических и профессиональных навыков должны быть наняты.

Предположив, что значения критериев, относящиеся к конкретным проектам, имеют приблизительно нормальное распределение, можно ожидать, что результатом такой операции будет стандартизованная величина, распределенная в диапазоне от – 3 до +3. Этот диапазон следует преобразовать в диапазон положительных величин. Если какое-либо из значений в таблице изначально равно нулю, стандартизованное значение также должно быть равно нулю. Для соблюдения данного требования необходимо ко всем значениям критерия в столбце прибавить абсолютную величину наиболее отрицательного значения данного критерия, получившегося после вышеописанной процедуры вычитания и деления. В результате будут получены стандартизованные величины, находящиеся в диапазоне от 0 приблизительно до +6. Если ни одно из первоначальных значений не равнялось нулю, к каждому значению нужно сначала прибавить 1, а затем – абсолютную величину наиболее отрицательного значения данного критерия. Это даст нам набор стандартизованных величин, укладывающихся в диапазон приблизительно от +1 до +7. Затем данные стандартизованные величины должны быть подставлены в формулу модели. Далее каждый проект получает балльную оценку, основанную на относительных весах, которые установлены руководством, и проектно-специфических данных, которые предоставлены теми, кто предлагает этот проект (и, возможно, другими подразделениями).

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

Использование моделей ранжирования проектов

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

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

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

Сравнение модели ранжирования проектов и аналитического иерархического процесса (AHP) – двух рассматриваемых нами инструментов ранжирования проектов – представлено в разделе «Аналитический иерархический процесс».

Время использования. Хотя принципы, лежащие в основе моделей ранжирования проектов, сравнительно просты, разработка эффективной модели может стать очень времяемким

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

Выгоды. Ценность модели ранжирования проектов состоит в возможности ее адаптации к конкретной ситуации, в которой принимается решение, с учетом многочисленных целей и критериев, имеющих характер как объективных данных, так и суждений, которые считаются важными [2]. Это позволяет избежать чрезмерного акцентирования на финансовых критериях, которые, как правило, не отличаются высокой надежностью на ранних этапах жизни проекта. При таком подходе принятие решений вынужденно базируется на тщательном рассмотрении каждого проекта с точки зрения единой совокупности критериев; особое внимание здесь уделяется критически важным критериям, поскольку одни критерии более важны, чем другие (что устанавливается путем присвоения весов). И наконец, модели ранжирования проектов могут быть подвергнуты анализу чувствительности – определению того, какое изменение весовых коэффициентов требуется для получения значительного изменения приоритетов.

Преимущества и недостатки. Существует множество точек зрения на преимущества и недостатки модели ранжирования проектов. Рассмотрим, в частности, следующие преимущества:

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

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

• похоже, она работает. Несколько проведенных исследований показали, что модель способствует принятию верных решений. Представители Procter & Gamble утверждают, что их компьютерные модели ранжирования проектов имеют 85%-ную предсказательную способность [1];

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

СОВЕТЫ ПО ИСПОЛЬЗОВАНИЮ МОДЕЛЕЙ РАНЖИРОВАНИЯ ПРОЕКТОВ

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

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

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

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

Если говорить о недостатках моделей ранжирования проектов, можно отметить следующее [2]:

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

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

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

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

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

КОНТРОЛЬ МОДЕЛЕЙ РАНЖИРОВАНИЯ ПРОЕКТОВ

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

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

• включать в себя уместные в данной ситуации критерии с весовыми коэффициентами и градуированными шкалами для оценки;

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

• выдавать одиночную оценку для каждого проекта;

• обеспечивать возможность ранжирования проектов.

Резюме

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

ранних фазах жизненного цикла проекта, когда принимаются основные решения и расставляются приоритеты, и, во-вторых, когда принимаются решения о продолжении/прекращении выполнения проекта.

Аналитический иерархический процесс

Что такое аналитический иерархический процесс?

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

Рис. 2.3. Пример иерархии решений AHP

Применение аналитического иерархического процесса

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

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

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

• проектное предложение;

• стратегические и тактические планы;

• историческая информация.

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

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

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

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

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

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

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

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

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

столбца, формируя значения, отражающие предпочтительность фактора для строки над фактором для столбца (23).

И снова мы имеем определенные значения, с которыми можно начинать работать, и снова расчет матрицы тривиален, если использовать электронную таблицу. Однако во многих случаях матрицу приходится заполнять на основе рассуждений и здравого смысла. Поскольку эта матрица имеет размер 16 ? 16, необходимо выполнить n (n – 1) / 2 или (16 ? 15) / 2 = 120 суждений (значения под диагональю должны быть обратны зеркально симметричным значениям над диагональю, а сама диагональ должна состоять из единиц). Такие вычисления могут потребовать значительных усилий от людей, ответственных за ранжирование проектов по какому-либо критерию.

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

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

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

Использование аналитического иерархического процесса

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

Следует отметить, что аналитический иерархический процесс обычно задействуется применительно к крупным и достаточно важным проектам для принятия решений о выборе новых проектов к выполнению и о продолжении/прекращении уже существующих проектов [4]. Определенную помощь здесь способно оказать специализированное программное обеспечение, например Expert Choice, Automan, Excel. И хотя по отношению к малым проектам AHP может использоваться одним лицом, его истинная ценность лежит в сфере группового принятия решений (см. врезку «Советы по использованию аналитического иерархического процесса»). Это особенно важно в том случае, когда данные для различных подкритериев генерируются различными группами. Вместо формирования единой группы людей, являющихся специалистами в совершенно разных дисциплинах и пытающихся прийти к консенсусу, эксперты заполняют соответствующие матрицы, опираясь на свои профессиональные знания, а затем результаты их работы объединяются с помощью AHP.

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

СРАВНЕНИЕ МОДЕЛЕЙ РАНЖИРОВАНИЯ ПРОЕКТОВ И АНАЛИТИЧЕСКОГО ИЕРАРХИЧЕСКОГО ПРОЦЕССА

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

Хотя во многих случаях результаты работы двух рассмотренных методов хорошо согласуются друг с другом, в нашем примере этого нет. Согласование наблюдается для проектов с рейтингами 1 и 2. Начиная с проектов, имеющих рейтинг 3, наступает значительное рассогласование. Коэффициент корреляции между двумя наборами рейтингов составляет всего 0,14. Какой метод правилен? Определить это невозможно. Если бы имелась некая объективная мера достоинств проекта, не было бы нужды использовать описанные методы, каждый из которых имеет свои сильные и слабые стороны. Модель

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

Выгоды. Аналитический иерархический процесс представляет собой ценный инструмент на различных уровнях, поскольку сочетает простоту и сложность. Путем разбиения сложных задач, к каковым относится ранжирование проектов, на несколько уровней AHP помогает сфокусироваться на определенных аспектах проблемы, рассматривая один или два критерия за раз. Согласно общеизвестному закону Миллера, человек способен сравнивать 7 ± 2 элементов (сущностей) одновременно. Ориентация AHP на последовательные сравнения критериев (например, «один с одним») с последующим синтезом (общего результата) повышает качество принимаемого решения. Подобный подход не только дает менеджеру возможность получить наилучшее решение, но и позволяет обосновать сделанный выбор. Способность AHP работать со сложными ситуациями базируется на использовании множественных критериев, часть из которых представляет собой субъективные, а часть – объективные аспекты решения. Субъективные аспекты могут включать в себя качественные суждения, основанные как на чувствах и эмоциях менеджера, так и на его размышлениях. С другой стороны, объективные аспекты могут адресоваться к количественным критериям, например численным значениям рентабельности. Гибкость AHP в случае одновременного применения объективных и субъективных, количественных и качественных критериев не имеет себе равных. Он действительно обеспечивает систематическое опирающееся на различные точки зрения ранжирование проектов, или, если говорить более обобщенно, уменьшение рисков при принятии решений.

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

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

• наглядные иерархии. Сложные проблемы в области принятия решений по ранжированию проектов легко отобразить с помощью графических иерархических конструкций. Даже достаточно разветвленные, детализированные конструкции делают проблему визуально представимой, упрощая рассмотрение потенциальных рисков и конфликтов [5]; (26)

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

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

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

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

• затруднения при квантификации. Некоторые пользователи время от времени испытывают затруднения при квантификации (выражении в численном виде) важности определенного критерия.

Вариации. Подход, используемый в AHP, очень похож на тот, что применяется в инструменте MOGSA (Mission, Objectives, Goals, Stra tegies, Actions – Миссия, Целевые установки, Задачи, Стратегии, Действия), пример которого приведен на рис. 2.4 [6]. В MOGSA также присутствует иерархическое разбиение задачи принятия решения для построения сети отношений между тремя основными уровнями иерархии: уровнем воздействий (Миссия, Целевые установки), уровнем целей (Задачи) и операционным уровнем (Стратегии, Действия). Отличия MOGSA от AHP проявляются в некоторых вычислительных аспектах.

СОВЕТЫ ПО ИСПОЛЬЗОВАНИЮ АНАЛИТИЧЕСКОГО ИЕРАРХИЧЕСКОГО ПРОЦЕССА

Нижеследующие подходы могут оказаться полезными при использовании AHP:

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

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

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

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

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

Резюме

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

Экономические методы

Что такое экономические методы?

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

Ниже мы рассмотрим три различных экономических метода: время окупаемости, чистая приведенная стоимость (NPV) и внутренняя норма прибыли (IRR). В табл. 2.5 представлены три гипотетических

проекта-кандидата с соответствующими значениями потоков стоимости и прибыли (расходов и доходов). Эти проекты будут оценены с помощью каждого из названных методов.

КОНТРОЛЬ AHP

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

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

• структурировать иерархию: высший уровень (выбор наилучших проектов) – промежуточный уровень (критерии и подкритерии выбора) – низший уровень (проекты-кандидаты);

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

• выполнять относительную оценку в пределах каждого иерархического уровня;

• выдавать единственную оценку для каждого проекта на каждом уровне, а также общую оценку;

• обеспечивать возможность ранжирования проектов в соответствии с окончательной оценкой.

Время окупаемости

Время (срок, период) окупаемости – это просто промежуток времени между моментом инициации проекта и моментом, когда кумулятивный поток денежной наличности (доходы минус расходы) становится положительным и происходит возврат всех средств, инвестированных в проект. Как показано в табл. 2.5, (кумулятивный) поток наличности для проекта 1 становится положительным через шесть лет, для проекта 2 – через пять, а для проекта 3 – через восемь. Если смотреть по данному критерию, то проект 2 является наилучшим выбором.

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

Чистая приведенная стоимость (NPV)

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

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

Excel и другие электронные таблицы позволяют непосредственно вычислять NPV: достаточно ввести в функцию вычисления NPV значения ставки дисконтирования и денежных сумм (либо указать совокупность ячеек для обработки). Результат отображается в той ячейке, в которой находится функция. Используя функцию NPV, можно выполнить расчет чистой приведенной стоимости для каждого из трех проектов при значениях ставки дисконтирования 5, 10 и 15%. Результаты расчета приведены в следующей таблице.

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

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

Внутренняя норма прибыли (IRR)

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

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

ВЫБОР ЭКОНОМИЧЕСКОГО МЕТОДА

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

СОВЕТЫ ПО ИСПОЛЬЗОВАНИЮ ЭКОНОМИЧЕСКИХ МЕТОДОВ

Использование экономических методов

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

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

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

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

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

Резюме

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

КОНТРОЛЬ ЭКОНОМИЧЕСКИХ МЕТОДОВ

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

Методы выбора портфеля

Что такое методы выбора портфеля?

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

Применение методов выбора портфеля

Сначала необходимо собрать исходную информацию:

• данные о проектах-кандидатах;

• политики компании.

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

Конструирование модели портфеля. Проанализируем меню проектов, представленное в табл. 2.6. В дополнение к критериям выбора, использованным в примерах модели ранжирования проектов или аналитического иерархического процесса, примем во внимание взаимодействие проектов, чтобы получить портфель без конфликтов. Предположим, что бюджет ограничен величиной 600 тысяч долларов, максимально доступное время опытного производства составляет 4500 часов, а максимально доступное машинное время – 700 часов. Исходя из этих сведений, нужно составить такой портфель проектов, который обеспечит максимальную отдачу.

Электронные таблицы, например Excel, могут выполнить подобную «оптимизацию» в случае проблемы небольшого масштаба. В табл. 2.7 показана таблица Excel, предназначенная для отбора проектов в портфель и обеспечивающая максимальную отдачу при отсутствии нарушения какого-либо ограничения. Значение «1» в столбце «Выбран» означает, что данный проект был отобран для включения в портфель, значение «0» – наоборот. Запись в ячейке «Общая стоимость» представляет собой встроенную в Excel функцию SUMPRODUCT, примененную к столбцам «Выбран» и «Стоимость». Аналогичная операция проведена и для ячеек «Время опытного производства» и «Машинное время».

Как только проблема сформулирована, с помощью Excel SOLVER (или эквивалентного модуля в случае другой таблицы) легко рассчитать оптимальный портфель. Очевидно, что значения «Общая стоимость», «Время опытного производства» и «Машинное время» здесь удовлетворяют наложенным ограничениям. Оставшиеся ограничения нуждаются в объяснении. В частности, мы не хотим, чтобы программа пыталась «купить» ресурсы, выбирая «отрицательный проект». Следовательно, значения в столбце «Выбран» не должны превышать 1. И наконец, мы не вправе выполнить только половину проекта, следовательно, значения в столбце «Выбран» должны быть целыми. Три названных ограничения, действующие совместно, приводят к тому, что ячейки в столбце «Выбран» могут принимать два значения: 0 и 1. Другими словами, отбираться могут только целые проекты и не более чем по одному за раз (28).

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

X + Y ? 1,

где X и Y – ячейки столбца «Выбран», соответствующие двум версиям одного и того же проекта.

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

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

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

Использование метода выбора портфеля

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

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

Общая отдача 7434

Ограничения: 0 ? B2?B17 ? 1, B2?B17 – целое

Общая стоимость: 583 ? 600; Время моделирования: 3772 ? 4500; Машинное время: 534 ? 700.

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

СОВЕТЫ ПО ИСПОЛЬЗОВАНИЮ МЕТОДА ВЫБОРА ПОРТФЕЛЯ

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

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

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

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

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

КОНТРОЛЬ МЕТОДА ВЫБОРА ПОРТФЕЛЯ

Контроль позволяет убедиться в том, что выбор портфеля осуществляется надлежащим образом. Вы должны:

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

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

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

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

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

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

Резюме

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

Метод реальных вариантов выбора (опционов)

Что такое метод реальных вариантов выбора (опционов)?

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

Аналогия с финансовыми опционами. Метод реальных вариантов выбора (опционов) – это относительно новый метод отбора проектов, который использует аналогии с финансовыми опционами. Итак, в сфере бизнеса опцион – это финансовый

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

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

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

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

Применение метода реальных вариантов выбора (опционов)

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

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

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

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

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

Компенсация рисков: аналогия с опционами с обратной и предварительной премией. Опцион с обратной премией – это способ ограничения downside-риска. Опцион с предварительной премией – способ извлечения выгоды из upside-риска. Если рассматривать проект как опцион, нужно поискать аналогии с финансовыми опционами (с обратной и предварительной премией) для уменьшения downside– и upside-рисков. Ниже приводятся некоторые меры, аналогичные опционам с обратной премией:

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

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

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

• исследование. Выполнение пилотного проекта или проекта-прототипа с последующим его расширением, если дела пойдут хорошо;

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

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

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

Каждая из

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

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

• хеджирование. Незначительные инвестиции в дополнительные средства производства, чтобы сделать их доступными в том случае, если дела пойдут лучше, чем ожидалось;

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

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

Структурирование проекта для управления рисками. Меры, которые должен принять менеджер по части управления рисками, приведены ниже:

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

• определить теневые (33) варианты (то есть варианты, которыми компания могла бы воспользоваться) для уменьшения каждого из специфических рисков, идентифицированных на предыдущем шаге;

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

• установить сочетания вариантов, которые приводят к созданию наиболее ценной (34) структуры проекта;

• преобразовать один из специфических наборов теневых вариантов в опцион.

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

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

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

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

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

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

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

Рис. 2.5. Деление пространства вариантов выбора на области[2 - Timothy A. Luehrman, “Strategy As A Portfolio of Options”, Harvard Business Review, September-October 1998. Copyright © Harvard Business School Publishing. Перепечатано с разрешения Harvard Business School Publishing.]

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

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

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

В области 2 отношение «отдача/стоимость» превышает 1, а неопределенность в сравнении с ним мала, хотя и существует. Выполнение проекта допустимо отложить до получения дальнейшей информации (которая, возможно, снизит неопределенность), но если

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

В области 3 отношение «отдача/стоимость» превышает 1, но не определенность в сравнении с ним очень высока. Проект нужно отложить в ожидании дальнейшей информации, которая, быть может, уменьшит неопределенность.

В области 4 отношение «отдача/стоимость» меньше 1. Это говорит против проекта. Однако неопределенность здесь очень высока, и, если выяснится, что отдача этого проекта достаточно велика, проект рекомендуется переместить в область 3 или 2.

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

Ниже мы рассмотрим пример того, как концепция вариантов выбора (опционов) может быть применена к проекту.

Пример

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

Ценность проекта. Степень востребованности продукта потребителями неизвестна. Ежегодные продажи другого продукта, ориентированного на тот же сегмент рынка, составляют 90 миллионов долларов. Это наиболее правдоподобная оценка общего объема рынка для нового продукта. Если компания X выйдет на рынок первой, она сумеет захватить как минимум 2/3 рынка до появления продукта-конкурента.

Имеющийся в настоящее время персонал способен выполнить инженерные работы в течение трех лет. Если предположить, что разработка продукта займет еще два года, полный объем продаж составит 90 миллионов долларов в год (при отсутствии конкурентов), величина прибыли будет равна 10%, ставка дисконтирования составит 15% и продажи будут продолжаться еще шесть месяцев после выхода на рынок, потенциальную стоимость проекта можно оценить в 17 миллионов долларов (текущее значение NPV).

Идентификация рисков. В предлагаемом проекте были выявлены нижеперечисленные риски.

Риск, свойственный фирме:

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

Риск конкуренции:

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

• известно, что иностранная компания Z работает над альтернативным подходом, который требует развития науки и технологии, но способен снизить стоимость производства. Для того чтобы выдержать конкуренцию с компанией Z, придется уменьшить прибыль до 5%. Если фирма X выйдет на рынок первой, значение NPV проекта составит 8 миллионов долларов.

Рыночный риск:

• сегмент рынка может не отреагировать на новый продукт. Максимальный объем продаж в этом случае составит 40 миллионов долларов. При отсутствии конкурентов величина NPV проекта оценивается в 8 миллионов (downside-риск);

• если будут привлечены дополнительные сегменты рынка и реализованы продажи за рубежом, величина NPV проекта может достичь 25 миллионов долларов (upside-риск).

Ожидаемые расходы:

• инженерные работы: трое инженеров по 100 тысяч долларов в год на каждого плюс накладные расходы за первые три года: NPV составляет 685 тысяч долларов;.

• разработка продукта: четверо инженеров по 100 тысяч долларов в год на каждого плюс накладные расходы за четвертый и пятый годы: NPV составляет 428 тысяч долларов;.

• новые производственные мощности: 4 миллиона долларов за пятый год: NPV составляет 2 миллиона долларов;

• итоговое значение NPV расходов: 3113 тысяч долларов.

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

Идентификация возможных вариантов выбора (опционов). Данный пункт включает в себя следующие действия:

A. Нанять еще троих специалистов для инженерных работ, уменьшив их длительность до 18 месяцев. NPV дополнительных зарплат, накладных расходов и расходов по найму составляет 575 тысяч долларов. NPV зарплат уже занятых в проекте инженеров уменьшается до 487 тысяч , а NPV общих расходов на инженерные работы составит 1062 тысяч. Дополнительные 18 месяцев продаж принесут прибыль, NPV которой составит 24 миллиона долларов при отсутствии конкурентов или 20 миллионов в случае выхода фирмы на рынок первой.

B. Использовать аутсорсинг (прибегнуть к услугам третьей стороны) для разработки некритических элементов, создавая своими силами только критические элементы. Таким образом время инженерных работ уменьшается до двух лет. Значение NPV для стоимости аутсорсинга равно 476 тысяч долларов, а для инженерных работ, выполняемых самостоятельно, уменьшается до 487 тысяч долларов. Более ранние продажи увеличивают NPV прибыли до 21 миллиона долларов при отсутствии конкурентов и до 16 миллионов при выходе на рынок первыми.

C. Параллельное выполнение инженерных и производственных работ. Увеличивает стоимость работ, но сокращает время выхода на рынок. NPV инженерных работ возрастает до 794 тысяч долларов. Значение NPV прибыли составит 21 миллионов долларов при отсутствии конкурентов и 17 миллионов при выходе на рынок первыми.

D. Подготовка документации для лизинга производственных мощностей вместо строительства собственных. Значение NPV подготовки документации составляет 25 тысяч долларов. Лизинг уменьшает размер прибыли до 8%, поэтому NPV прибыли составит 14 миллионов долларов при отсутствии конкурентов и 10 миллионов при выходе на рынок первыми. Штрафные санкции за лизинг производственных мощностей при преждевременном прекращении проекта имеют NPV 1 миллион долларов.

E. Инициирование исследовательского проекта в той же сфере, что и иностранная компания Z, с целью выставить достойный конкурирующий (в случае их успеха) или собственный продукт. Предположим, что на исследования потребуется четыре года, на инженерные работы – три, на разработку продукта – два, а продажи продукта будут продолжаться еще шесть лет. Размер прибыли составит 15%, если компанию Z постигнет неудача, 10%, если компания Х первой представит на рынке новую технологию, и еще шесть лет продаж после появления новой технологии. Если исследовательский проект провалится, его NPV составит 1,05

миллиона долларов, в противном случае – 1,2 миллиона. NPV суммарной прибыли от предложенного продукта и продукта высоких технологий будет равняться 27 миллионам при отсутствии конкурентов и 19 миллионам, если компания Z достигнет успеха в те же сроки.

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

• A + C + D + E (неудачен): NPV расходов = 3,07 миллиона долларов, NPV прибыли = 4,05 миллиона, итоговая NPV = 0,98 миллиона;

• B + C + D + E (неудачен): NPV расходов = 3,2 миллиона долларов, NPV прибыли = 4,05 миллиона, итоговая NPV = 0,85 миллиона;

• A + C + D: NPV расходов = 2,02 миллиона долларов, NPV прибыли = 4,05 миллиона, итоговая NPV = 2,03 миллиона;

• B + C + D: NPV расходов = 2,17 миллиона долларов, NPV прибыли = 4,05 миллиона, итоговая NPV = 1,75 миллиона;

• опционы отсутствуют: NPV расходов = 927 тысяч долларов, NPV прибыли = 2,8 миллиона, итоговая NPV = 1,873 миллиона;

• A + C + D + E (успешен): NPV расходов = 3,226 миллиона долларов, NPV прибыли = 2,5 миллиона, итоговая NPV = – 0,73 миллиона.

В наихудшем из возможных случаев комбинация вариантов A + C + D обеспечивает наилучший результат. Если какой-либо из рисков не осуществляется, чистая прибыль будет намного выше. Ясно, что вариант E не заслуживает выполнения в предположении неудачи исследовательского проекта. И даже если вариант E окажется успешным, но все остальное пойдет плохо, его все равно не следует реализовывать. Если же все остальное пойдет хорошо, вариант E – потенциально выигрышный.

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

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

Использование метода реальных вариантов выбора (опционов)

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

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

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

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

СОВЕТЫ ПО ИСПОЛЬЗОВАНИЮ МЕТОДА РЕАЛЬНЫХ ВАРИАНТОВ ВЫБОРА (ОПЦИОНОВ)

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

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

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

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

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

КОНТРОЛЬ МЕТОДА РЕАЛЬНЫХ ВАРИАНТОВ ВЫБОРА (ОПЦИОНОВ)

Контроль позволяет убедиться в том, что метод реальных вариантов выбора (опционов) применяется надлежащим образом. Вы должны:

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

Выявить риск, свойственный фирме, риск конкуренции и рыночный риск;

• идентифицировать теневые варианты для компенсации каждого вида риска. Для каждого риска найти по крайней мере один теневой вариант, способный его скомпенсировать;

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

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

• обновлять оценки по мере необходимости. Периодически обновлять оценки стоимости проекта;

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

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

Резюме

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

Заключительные замечания

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

Литература

1. Cooper R. G., S. J. Edgett and E.J. Kleinschmidt 1998 “Best Practices for Managing R&D Portfolios: Lessons from the Leaders – II” Research Technology Management 41(4): 20 – 33.

2. Henrickson, A. D. and A. J. Traynor 1999 “A Practical Project – Selection Scoring Tool” IEEE Transactions on Engineering Management 46(2): 158 – 170.

3. Saaty, T. L. 1983 “Priority Setting in Complex Problems” IEEE Transactions on Engineering Management 30(2):140 – 155.

4. Liberatore, M. 1987 “An Extantion of the Analitic Hierarchy Procedure for Industrial R&D Project Selection and Resource Allocation” IEEE Transactions on Engineering Management 34(1): 12 – 21.

5. Saaty, T. L. 1980 “The analytic Hierarchy Process” New York McGrow – Hill.

6. Kocaoglu, D. F. 1983 “ A Participative Approach to Program Evaluation” IEEE Transactions on Engineering Management 30(3): 112 – 118.

7. Gear, A. E. 1974 “Review of Some Recent Developments in Portfolio Modeling in Applied Research and Development” IEEE Transactions on Engineering Management 21(4):119 – 125.

8. Dickenson, M. W., A. C. Thornton and S. Graves 2001 “Technology Portfolio Management Optimizing Interdependent Projects over Multiple Periods” IEEE Transactions on Engineering Management 48(4): 518 – 527.

9. Luehrman, T. 1998 “Strategy as a Portfolio of Real Options” Harvard Business Review 76(5).

Глава 3

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

Баланс прекрасен.

    Мийоко Охно

Основные темы настоящей главы – это инструменты составления портфеля проектов:

• традиционные диаграммы;

• пузырьковые диаграммы.

Рис. 3.1. Роль инструментов картографирования портфеля в процессе стандартизованного управления проектами

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

Данная глава призвана помочь менеджерам проектов:

• научиться использовать различные инструменты картографирования портфелей проектов;

• выбирать инструменты, которые соответствуют реальной проектной ситуации;

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

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

Традиционные диаграммы для управления портфелями проектов

Что такое традиционные диаграммы для управления портфелями проектов?

Традиционные диаграммы для управления портфелями – это

гистограммы, ленточные и секторные диаграммы (рис. 3.2), с успехом применяемые для отображения баланса портфеля. При гибком подходе к разработке они не налагают ограничений на аспекты/параметры проекта, которые должны быть отображены [2]. Напротив, с помощью диаграмм можно показать различные параметры проекта: его размер, распределение ресурсов, выполненную стоимость, сроки, что позволяет менеджерам балансировать их нужным образом.

Рис. 3.2. Круговая диаграмма распределения расходов между проектами различных типов

Построение традиционных диаграмм

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

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

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

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

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

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

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

• большая часть ресурсов (63%) выделяется в проекты обслуживания и поддержки производства;

• меньшая часть ресурсов (37%) потребляется проектами разработки приложений.

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

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

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

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

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

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

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

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

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

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

• простота. Рисование традиционных диаграмм или их чтение практически не представляет проблемы для пользователей. Как следствие простота концепции и внешнего вида позволяют использовать такие диаграммы без какой-либо подготовки;

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

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

НАЧИНАЙТЕ ТАМ, ГДЕ РАСХОДЫ ВЫШЕ

Многие менеджеры не задумываются о том, что такое правильный баланс для их портфеля проектов. Если вы – один из них, то спросите себя: «Знаю ли я текущее разбиение моих проектов или расходов?» Так, руководительница группы разработки приложений не смогла сказать, какой процент финансирования идет на находящиеся в ее ведении типы/категории проектов, а именно на проекты разработки новых приложений, в сравнении с проектами обновления существующего программного обеспечения и поддержки существующих продуктов. Один из способов приступить к балансированию портфеля проектов – оценить текущее разбиение расходов, ответив на два вопроса:

1. Каковы общие расходы на проекты сейчас?

2. Какой процент расходов соответствует каждой категории проектов?

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

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

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

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

Еще один вид традиционной диаграммы – ленточная диаграмма – приведен на рис. 3.4. И снова акцент сделан на распределении ресурсов

с отображением четырех параметров: перечня проектов, запланированного и фактически израсходованного количества ресурсов, а также выполненной стоимости. Эта схема позволяет выявить проекты, которые расходуют ресурсы медленнее или быстрее, чем планировалось, чтобы соответственно изъять лишнее или добавить недостающее. Например, проект Z испытывает перерасход и, возможно, нуждается в большем количестве ресурсов. Напротив, проект X использует меньшее количество ресурсов, чем предполагалось, что позволяет перераспределить ресурсы из проекта X в проект Z[3 - Для проектов, реализуемых в России, этот подход не вполне приемлем. Как правило, у нас перерасход ресурсов характеризует не истинное положение дел в проекте, а личностные качества его руководителей. Включать здесь положительную обратную связь (выделять больше ресурсов по мере увеличения перерасхода) означает стимулировать непрофессионализм, халатность, расточительность и хищения. – Прим. ред.]. На диаграмме это показано в отношении длины ленты, отображающей выполненную стоимость[4 - Здесь – освоенный объем. – Прим. ред.], к длине ленты, отображающей фактическую стоимость (это отношение также называется индексом выполнения стоимости, см. главу 13).

Рис. 3.3. Гистограмма времени завершения проектов[5 - PORTFOLIO MANAGEMENT FOR NEW PRODUCTS, ROBERT G. COOPER, SCOTT J. EDGETT and ELKO J. KLEINSHMIDT. Copyright © 1998, Robert G. Cooper, Scott J. Edgett and E. J. Kleinshmidt. Перепечатано с разрешения Perseus Books Publishers, члена Perseus Books, L.L.C.]

Рис. 3.4. Гистограмма выделения ресурсов

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

ИСПОЛЬЗОВАНИЕ ТРАДИЦИОННЫХ ДИАГРАММ

Убедитесь, что вы подготавливаете традиционные диаграммы надлежащим образом. Они должны отражать:

• выбранные аспекты или параметры проекта;

• шкалу измерения этих аспектов или параметров.

Резюме

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

Пузырьковые диаграммы

Что такое пузырьковые диаграммы?

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

Построение пузырьковой диаграммы

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

• стратегических и тактических планов;

• критериев отбора проектов;

• списка проектов с их численными оценками.

Рис. 3.5. Пузырьковая диаграмма в пространстве «легкость исполнения / важность проекта»[6 - PORTFOLIO MANAGEMENT FOR NEW PRODUCTS, ROBERT G. COOPER, SCOTT J. EDGETT and ELKO J. KLEINSHMIDT. Copyright © 1998, Robert G. Cooper, Scott J. Edgett and E. J. Kleinshmidt. Перепечатано с разрешения Perseus Books Publishers, члена Perseus Books, L.L.C.]

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

Выбор типа диаграммы. Определение типа диаграммы начинается с четкого понимания параметров, которые будут представлены осями пузырьковой диаграммы (см. врезку «Это не старая матрица BCG[7 - Матрица Boston Consulting Group. – Прим. ред.]»). Вариантов здесь множество [3, 4]:

• отдача (финансовая, основанная на большом количестве критериев);

• фазы жизненного цикла (концепция, планирование, исполнение, закрытие);

• дата завершения (месяцы, годы);

• стратегическое соответствие или важность (низкая, средняя, высокая);

• качество ресурсов (низкое, среднее, высокое);

• стоимость проекта (доллары, часы работы ресурсов);

• вероятность технического или коммерческого успеха (проценты);

• легкость исполнения (диапазон от «трудно» до «легко»);

• категории проектов (НИОКР, инжиниринг, производство, маркетинг, обслуживание / техническая поддержка и т. д.);

• типы проектов (например, в разработке продуктов – платформы, вторичные (производные) продукты, расширение, совместные предприятия и т. д.);

• сегменты рынка (рынок A, рынок B и т. д.).

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

• диаграммы, основанные на моделях балльной оценки (например, важность проекта в сопоставлении с легкостью исполнения);

• диаграммы риска/отдачи (например, скорректированное значение NPV в сопоставлении с вероятностью технического успеха);

• прочие пузырьковые диаграммы (например, расходы проекта в сопоставлении с фазами жизненного цикла).

ЭТО НЕ СТАРАЯ МАТРИЦА BCG

Впервые столкнувшись с пузырьковыми диаграммами, многие поспешили отметить их сходство с матрицей BCG (а также матрицей GE или матрицей МакКинси), представленной в 1970-х годах [1]. В действительности же это не так. Старые матрицы использовались для отображения существующих стратегических бизнес-единиц в координатах матрицы «привлекательность рынка / конкурентная позиция (положение по отношению к конкурентам)» и являлись слепком текущего состояния бизнес-единиц. Пузырьковые диаграммы проекта

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

СОГЛАСНЫ ЛИ ВЫ С ПРИГОВОРОМ, ВЫНЕСЕННЫМ ЭТОМУ ПОРТФЕЛЮ?

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

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

• в общем и целом наш портфель отвратителен;

• наш портфель не сфокусирован;

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

• слишком много слабых проектов;

• наш портфель плохо сбалансирован;

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

Вы согласны?

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

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

• типы проектов в сопоставлении с сегментами рынка;

• даты завершения в сопоставлении с фазами жизненного цикла;

• риск (вероятность успеха) в сопоставлении с отдачей.

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

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

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

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

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

• другая проблема – слишком большое количество (шесть) проектов, находящихся в правом нижнем квадранте. Это самое не удачное место для проекта. Рассмотрите вопрос об удалении части проектов;

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

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

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

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

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

• отменить исполнение трех проектов, имеющих наименьшую важность;

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

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

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

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

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

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

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

ИСПОЛЬЗУЙТЕ ОЦЕНКИ, ПОЛУЧЕННЫЕ НА СТАДИИ ОТБОРА ПРОЕКТОВ

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

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

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

Несмотря на выгоды, обеспечиваемые применением пузырьковых диаграмм, некоторые пользователи отмечают их серьезные несовершенства [5, 6]. Эти диаграммы выступают в качестве средства информационного представления портфеля проектов, а не в качестве модели принятия решений. Как следствие, они не содержат механизма, помогающего принимать решения. В частности, модели балльной оценки могут служить моделью принятия решений при ранжировании проектов, в то время как пузырьковые диаграммы не позволяют балансировать портфель. Они скорее создают стартовую точку, отталкиваясь от которой руководители будут предпринимать необходимые действия. Пузырьковые диаграммы не показывают правильный баланс. Менеджер сам должен определить такой баланс и сравнить его с балансом, фактически имеющим место, а также решить, когда изменять баланс, прекращать те или иные проекты или добавлять новые. Однако, в то время как одни пользователи рассматривают указанные несовершенства как изъяны, присущие самой идее данного инструмента, другие заявляют, что свою задачу – отображение информации о балансе портфеля – этот инструмент выполняет хорошо.

Преимущества и недостатки. Пузырьковые диаграммы характеризуются рядом серьезных преимуществ:

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

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

Возникновение проблем при использовании пузырьковых диаграмм возможно, если есть:

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

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

Рис. 3.6. Пузырьковая диаграмма в координатах «риск/отдача»[8 - Marheson, D., Matheson, J. E. and Menke, M. M., “Making Excellent R&D Decisions”, Reserch_Technology Management, November_December 1994. Copyright © Industrial Research Institute. Перепечатано с разрешения Industrial Re search

Institute.]

Вариации. Пузырьковых диаграмм (карт портфеля или матриц портфеля) существует множество [7, 9]. На рис. 3.6 представлена диаграмма в координатах «риск/отдача», которая очень популярна в НИОКР-проектах. Изучение этой диаграммы показывает, что:

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

• присутствует достаточное количество проектов типа «жемчужина». Это потенциально судьбоносные проекты, имеющие высокую вероятность успеха и способные принести большую прибыль;

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

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

Еще один популярный вид пузырьковой диаграммы – диаграмма в координатах «дата завершения / фаза жизненного цикла» (рис. 3.7). Она показывает следующее:

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

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

Рис. 3.7. Пузырьковая диаграмма в координатах «дата завершения / фаза жизненного цикла»

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

Резюме

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

ПРОВЕРКА ПУЗЫРЬКОВЫХ ДИАГРАММ

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

• выбранные параметры размерности проекта;

• шкалу измерения этих аспектов или параметров;

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

Заключительные замечания

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

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

Литература

1. Harrison, J. S. and C. St. John 1998 “Strategic Management of Organizations and Stakeholders” 2d ed. Cincinnati: South – Western College Publishing.

2. Brenner, M. S. 1994 “Practical R&D Project Prioritization” Research Technology management 37(5): 38 – 42.

3. Buss, M. D. J. 1983 “How to Rank Computer Project” Harvard Business Review 1(71): 145.

4. Cooper, R. G., S. J. Edgett, and E. J. Kleinshmidt 1998 “Best Practices for Managing R&D Portfolios: Lessons from the leaders – Part II” Research Technology Management 41(4): 20 – 33.

5. Cooper, R. G., S. J. Edgett, and E. J. Kleinshmidt 1997 “Portfolio Management in New Product Development: Lessons from the leaders – Part I” Research Technology Management 41(4): 20 – 33.

6. Cooper, R. G., S. J. Edgett, and E. J. Kleinshmidt 1997 “Portfolio Management in New Product Development: Lessons from the leaders – Part II” Research Technology Management 40(6): 43 – 52.

7. Archer, N. P. and F. Ghazemzaden 1999 “An Integrated Framework for project Portfolio Selection” International Journal of Project Management 17(4): 207 – 216.

8. Marheson, D., J. E. Matheson and M. M. Menke 1995 “Making Excellent R&D Decisions” Research Technology Management 37(6) 21 – 24.

9. Marheson, D., J. E. Matheson and M. M. Menke 1994 “Using Decision Quality Principles to Balansce Your R&D Portfolio” Research Technology Management 37(3) 38 – 43.

Часть 2

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

Глава 4

Требования заказчика проекта

Глава написана при участии Джоза Кампоса (Jose Campos).

В этой главе рассказывается об основных инструментах выявления и преобразования требований заказчика проекта, таких как:

• сетевой график заказчика;

• целевой план;

• выборка;

• рекомендации для переговоров;

• использование функции качества (Quality Function Deployment – QFD).

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

В этой главе менеджеры проектов научатся:

• использовать разные методы при работе с заказчиком;

• выбирать методы, которые соответствуют реальной проектной ситуации;

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

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

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

Рис. 4.1. Роль метода определения требований заказчика в процессе управления проектом

Сетевой график заказчика

Что такое сетевой график заказчика?

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

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

Составление сетевого графика заказчика

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

Рис. 4.2. Сетевой график заказчика

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

• план проекта;

• список членов команды.

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

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

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

• Почему необходимо сотрудничество с заказчиками проекта?

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

• Каким образом использовать полученную в ходе взаимодействия информацию?

ОСНОВНОЕ ТРЕБОВАНИЕ ЗАКАЗЧИКА – ЭФФЕКТИВНЫЕ ВЛОЖЕНИЯ

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

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

Подготовка выборки[9 - Обычно под этим в управлении проектами подразумевается часть работ, относящихся к формированию так называемого профиля заказчика, где среди прочего определяются ключевые фигуры заказчика, его миссия, декларированная и истинная мотивации участия в проекте и прочее. – Прим. ред.]. После определения цели взаимодействия с заказчиком нужно выявить представителя заказчика, с которым предстоит общаться (см. врезку «У каждого проекта есть заказчик»). Это обычно происходит на собрании команды или всех участников фактического взаимодействия по проекту. Для создания профиля необходимо ответить на следующие вопросы:

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

• Где находятся эти доверенные лица?

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

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

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

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

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

• Является ли ответ на вопрос значимой информацией для проекта?

У КАЖДОГО ПРОЕКТА ЕСТЬ ЗАКАЗЧИК

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

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

основе собственных нужд, наборов целей или выдвигаемых на данный момент требований. Ошибочным является предположение о том, что все работают на одну организацию и стремления каждого понятны. Иными словами, внутренние заказчики проявляют все свойства внешних. Менеджер проекта должен учитывать мнение заказчика проекта, к какой бы категории тот ни принадлежал[10 - Термины участник (stakeholder) и заказчик (customer) проекта часто являются взаимозаменяемыми. – Примечание авт.].

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

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

Основными здесь являются следующие вопросы:

• Кто из команды наиболее подготовлен для ведения переговоров?

• Хватит ли выбранным сотрудникам времени для общения и обработки информации?

• Запланировано ли обучение сотрудников для более эффективного общения?

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

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

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

• Продумана ли логистика проекта для обеспечения успеха контакта?

• Был ли заказчик уведомлен о предстоящих контактах?

• Был ли определен и согласован способ фиксации информации?

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

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

• Была ли собрана воедино вся информация по всем контактам?

• Будет ли конечный отчет написан и разослан членам команды проекта?

• Зафиксирован ли накопленный опыт для улучшения работы на следующих этапах взаимодействия с заказчиком?

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

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

• Определены ли факторы ценности для заказчика?

• Усвоила ли команда проекта эти факторы?

• Были ли факторы ценности интегрированы в процессы и проектные продукты?

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

Использование сетевого графика заказчика

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

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

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

шести-восьми недель (хотя в маленьких проектах затраченное время сокращается до часа).

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

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

Преимущества и недостатки. Ниже приведены два основных преимущества сетевого графика заказчика:

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

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

Практика указывает и на недостатки сетевой модели:

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

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

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

Резюме

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

Целевой план

Что такое целевой план?

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

ПРОВЕРКА СЕТЕВОГО ГРАФИКА ЗАКАЗЧИКА

Структура сетевого графика должна включать следующие этапы:

• разработка целевого плана;

• подготовка выборки;

• составление плана обсуждения;

• определение состава команды;

• встреча с заказчиками;

• обработка данных;

• встраивание информации в рамки проекта.

Рис. 4.3. Целевой план

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

Соберите необходимую информацию. Качественный целевой план основан на детализации следующей информации:

• план проекта;

• состав команды проекта.

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

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

• Каким должен быть результат проекта?

• Каковы цели проекта?

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

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

• Каковы деловые причины встреч?

• Зачем устраивать эту последовательность встреч?

• Какова задача команды для встреч?

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

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

Здесь основное внимание обращается на цели визита (для примера см. врезку «От разочарования до восхищения: модель Кано»). Другими словами, ставя задачи проекта, укажите цели посещения заказчиков (см. рис. 4.3). Это позволит команде понять, почему, чтобы достигнуть поставленных целей, нужно встречаться с заказчиком. Хорошим вопросом здесь будет: «Что мы хотим узнать от заказчика?»

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

• Какие области проекта будут затронуты этими встречами?

• Какие особые области проекта следует изучить перед встречей?

• Какие особые области проекта не будут затронуты встречами?

ОТ РАЗОЧАРОВАНИЯ ДО ВОСХИЩЕНИЯ: МОДЕЛЬ КАНО[11 - См. приложение Б. – Прим. ред.]

Японский профессор Нориаки Кано (Noriaki Kano) предложил следующую классификацию требований:

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

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

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

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

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

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

• ожидаемое время начала и завершения встреч;

• узловые точки (milestone), такие как завершение работы над рекомендацией для переговоров, выборкой, презентацией итогового отчета и т. д.

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

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

• Кто несет ответственность за принятие или отклонение конечного отчета?

• Кто руководит командой, проводящей встречи?

• Каков состав команды?

• Кто станет общаться с заказчиком?

• Кто займется обработкой собранной информации?

• Кто будет составлять итоговый отчет?

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

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

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

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

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

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

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

Преимущества и недостатки. К преимуществам целевого плана относятся:

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

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

В числе недостатков можно назвать:

• запутанность. Формат инструмента иногда провоцирует путаницу: из-за ограничения времени общения объем информации может существенно сократиться, и пропадут важные сведения;

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

Вариации. Вариантами целевого плана будут дополнительные цели или намерения вашего проекта [2], таблица намерений.

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

Резюме

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

Выборка

Что такое выборка?

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

количественной по своей природе.

Рис. 4.4. Выборка

Составление выборки

Сбор необходимой информации. На качество выборки влияют два источника информации:

• целевой план;

• организационная схема заказчика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

ПРОВЕРКА ВЫБОРКИ

Убедитесь, что выборка имеет необходимую структуру, то есть включает в себя:

срез 1 – сегмент или группа главных заказчиков;

срез 2 – подсегмент или подгруппа;

срез 3 – функции, должность или имя представителя.

Рекомендации для переговоров

Что такое рекомендации для переговоров?

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

Составление рекомендации для переговоров

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

Рис. 4.5. Рекомендации для переговоров

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

Составьте основу рекомендации для

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

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

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

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

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

Использование рекомендаций для переговоров

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

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

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

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

ИСКУССТВО ЗАДАВАТЬ ВОПРОСЫ

Источник большинства ошибок – неправильная манера задавать вопросы на интервью с заказчиком. Чтобы избежать проблем:

• не включайте в вопрос собственные предубеждения;

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

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

Ниже приведен список вопросов, наиболее полезных при проведении интервью с заказчиком:

• не ограниченные временем вопросы. Такие вопросы позволяют заказчику высказать все свои требования. Если спросить, например: «Каковы три основные проблемы, встречающиеся в процессе сдачи проекта?» – заказчик сможет рассказать о проблемах, основываясь на своем восприятии и с учетом собственных приоритетов;

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

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

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

Резюме

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

Использование функции качества

Что такое функции качества?

Функция качества – это инструмент заказчика, который позволяет встроить его требования

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

Рис. 4.6. Функция качества

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

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

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

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

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

Рис. 4.7. Функции качества проекта

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

• ограничить количество страниц в документе методологии;

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

• использовать корпоративную терминологию при написании документа;

• писать в четком и понятном стиле;

• рассматривать этапы методологии через этапы жизненного цикла проекта.

КОШМАР 2500-Й ЯЧЕЙКИ

Пат: Что произошло с вашей функцией качества? Такое впечатление, что ей еще далеко до завершения.

Джим: Моя команда ушла, а я отказался от роли менеджера проекта. Потому она и не завершена.

Пат: Но ведь все члены твоей команды пользовались функцией качества раньше? А потом ушли? В чем дело?

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

Пат: Много работы приходится делать впустую.

Джим: Мы уже потратили 16 часов. Возможно, потребуется еще 24. Команда говорит, что наша функция качества слишком большая и на ее составление уходит очень много времени.

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

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

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

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

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

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

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

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

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

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

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

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

Остановка или продолжение. Многие проекты используют только функции качества: это позволяет встроить требования заказчика в процесс планирования. Забегая вперед, скажем, что в крупных проектах приветствуется уточнение нужд заказчика на протяжении всей работы над проектом. С этой целью стоятся еще три дома качества (рис. 4.8). Здесь требования проекта (как сделать) из первого дома перемещаются на место требований заказчика (что сделать) во втором и т. д. Основная цель данной процедуры – соотнести требования заказчика с последовательными низкоуровневыми сокращениями проектных работ, полностью переведя их на операционный уровень. Логика тут похожа на иерархическую структуру (WBS): нужно дойти до уровня совокупности работ – уровня, на котором работа выполнена. Такой подход гарантирует, что требования заказчика будут встроены в самое основание блоков, образующих проект. По мере построения четырех домов качества их необходимо анализировать и корректировать.

Рис. 4.8. Четыре функции качества

Использование функции качества

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

Время использования. Время, необходимое для построения дома качества, зависит от его размеров и числа людей, вовлеченных в этот процесс. Небольшой дом (см. рис. 4.7) могут создать три человека в течение 45 минут. Для построения большого (10 ? 10) дома качества потребуются усилия пяти-шести членов команды и пять-шесть часов работы.

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

Преимущества и недостатки. Преимущества дома качества таковы:

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

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

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

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

• затраты времени. Некоторые члены команды воспринимают работу по созданию дома качества как интерфейсную (Frontend) для проекта.

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

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

ПРОВЕРКА ФУНКЦИИ КАЧЕСТВА

Проверьте правильность структуры функций качества. В нее должны входить:

• требования заказчика (что нужно сделать);

• требования проекта (как это нужно сделать);

• крыша дома качества (матрица взаимосвязей);

• матрица соотношений;

• сравнительный анализ проектов конкурентов;

• конечные цели.

Резюме

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

Заключительные заметки

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

При раздельном применении каждый инструмент имеет свое

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

Литература

1. Shillito, M. L. 2001 “Voice of the Customer” Boca Raton, Fla.: St. Lucie Press.

2. McQuarrie, E. R. 1998 “CustomerVhits” Vol. 2. Thousand Oaks, Ca.: Sage Publications.

3. Goetsch, D. L. and S. B. Davis 2000 “Introduction to Total Quaitiy” 3d ed. Upper Saddle River, NJ: Prentice Hall.

4. Hammer, M. and J. Champy 1993 “Reengineering the Corporation” JewYork: Harper Business.

5. McKenna, R. 1995 “Real – Time Marketing” Harvard Business Review 73(4): 87 – 95.

6. Scholtes, P. R. 1996 “The Team Handbook” 2d ed. Madison, Wis.: Joiner Associates.

7. University of Michigan Business School and American Society for Quality 1998 “American Customer Satisfaction Index: 1994 – 1998” Ann Arbor: University of Michigan Press.

8. Thompson, A. T. and A. J. Strickland 1995 “Crafting and Implementing Strategy” Boston: Irwin.

9. Hoch, D. J., ?. R. Roeding, G. Purkert, and K. S. Lindner 2000 “The Secrets of Software Success” Boston, Harvard Business School Press.

10. Norman, D. A. 1998 “The Invisible Computer” Cambridge, Mass.: The MIT Press.

11. Shillito, M. L. 1994 “Advanced QFD” New York: John Wiley & Sons.

12. Evans, R. J. and M. W. Lindsay 1999 “The Management and Control of Quality” St. Paul, Minn.: South – Wesiern College Publishing.

Глава 5

Планирование содержания

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

    Вильям Шекспир

Основные темы настоящей главы – это инструменты планирования содержания:

• устав проекта;

• SWOT-анализ[12 - Анализ сильных и слабых сторон проекта, возможностей и угроз. Весьма продуктивный инструмент, позволяющий повысить эффективность планирования, организации и исполнения проекта. – Прим. ред.] проекта;

• описание содержания;

• иерархическая структура работ.

Рис. 5.1. Роль инструментов планирования содержания в процессе управления проектами

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

Данная глава призвана помочь менеджерам проектов:

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

• выбрать те инструменты, которые отвечают проектным потребностям;

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

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

Устав проекта

Что такое устав проекта?

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

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

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

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

• стратегические и тактические планы;

• голос заказчика[13 - Удачный термин. В русскоязычной литературе по управлению проектами он может соответствовать техническому требованию, техническому заданию, списку требований заказчика, запросу заказчика на проект. – Прим. ред.];

• проектное предложение;

• процесс отбора проектов.

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

Определение миссии проекта. Точность и ясность – два ключевых условия, которым должно отвечать определение цели проекта [2, 7], как показано на рис. 5.2. Не имеет значения, прописана миссия для новой модификации существующего продукта или для огромной фабрики по производству полупроводников с многомиллиардным оборотом, – и в том, и в другом случае достаточно нескольких слов. Это утверждение может определять основные задачи, например проектирование, прототипирование, программирование, а может быть предельно простым и директивным, допустим «разработать новую платформу продуктов».

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

ПРЕДЕЛЬНЫЕ ЦЕЛИ: СТАВИТЬ ИЛИ НЕ СТАВИТЬ?

Насколько легко достижимыми должны быть цели проекта, сформулированные в уставе? Можно ли считать нормальным написание устава, в

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

Определение бизнес-цели. Что является силой, побуждающей к выполнению проекта? Целью может быть повышение удовлетворения заказчиков (как в примере на рис. 5.12), что упрощает их привлечение и удержание, а в конечном счете повышает устойчивость бизнеса и увеличивает приносимую им прибыль. Целью также может стать прорыв на новый рынок, стремление увеличить свою долю на существующем рынке, получить новые источники доходов и т. д. На стратегическом уровне выделяют несколько причин реализации проекта. Главное – не забывать о существовании таких причин и знать их суть.

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

Определение целей проекта. Термины «миссия проекта» и «бизнес-цель» допускают широкое толкование. Чтобы дать команде более конкретные указания, устав должен определить конкретные цели проекта (см. врезку «Предельные цели: ставить или не ставить?»), как минимум задать временные, стоимостные и качественные цели.

Временная цель – это желаемая дата завершения проекта, в нашем случае (см. рис. 5.2) 1 ноября 2002 г. Соблюдения этого срока нужно добиться, израсходовав не более 600 часов работы ресурсов при уровне качества, указанном в спецификации. Например, один из элементов качества, определяемых спецификацией, относится к способу представления информации для руководства, а именно к ежемесячному отчету о ходе исполнения более 20 проектов разработки новых продуктов. Данный элемент качества требует, чтобы чтение и интерпретация отчета отнимали у руководителя не более трех минут. Постановка более трех целей достаточно распространена, как показано на рис. 5.2, где такая цель призвана удовлетворить заказчика.

Отбор участников команды и назначение куратора[14 - В оригинале автор употребляет термин спонсор. Однако контекстуальное содержание данного понятия соответствует принятому в англоязычной литературе термину gatekeeper – куратор проекта. Поскольку в русском языке слово «спонсор» имеет явно иное смысловое наполнение, чем в данной монографии, мы не будем его использовать в русской версии книги. – Прим. ред.]проекта. Одна из целей издания устава – официально объявить имена менеджера проекта и, возможно, членов команды. Однако сразу называть всех участников необязательно. В последнем случае предполагается, что функциональные руководители выделят в проект своих подчиненных после издания устава.

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

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

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

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

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

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

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

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

Когда использовать. Применительно к крупным проектам устав применяется с начала формального управления проектами, то есть с начала 1950-х годов. Поскольку крупные проекты потребляют значительные организационные ресурсы, которые берутся из различных функциональных групп, такой подход вполне оправдан. По той же причине устав удобен и в отношении малых кросс-функциональных[15 - Довольно удачный термин. В русскоязычной литературе в таких случаях применяется термин многофункциональный, который в меньшей степени отражает существо данного типа проектов. – Прим. ред.] проектов. Однако для других, не кросс-функциональных малых проектов издание устава – редкость (исключением является ситуация, когда члены функциональных подразделений географически рассредоточены, что случается все чаще). Пример использования устава проекта в работе корпораций представлен во врезке «Необходимость устава».

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

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

НЕОБХОДИМОСТЬ УСТАВА

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

ПРОВЕРКА УСТАВА ПРОЕКТА

Убедитесь, что вы разработали надлежащий устав проекта. Этот устав должен:

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

• включать в себя все элементы, определяемые форматом устава;

• обеспечивать согласованность элементов.

Преимущества и недостатки. Устав проекта характеризуется следующими преимуществами:

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

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

Основной недостаток устава проекта:

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

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

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

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

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

Резюме

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

SWOT-анализ проекта

Что такое SWOT-анализ проекта?

SWOT-анализ – расширенная версия классического анализа «сильные стороны, слабые стороны, благоприятные возможности, угрозы» на уровне проекта (не на уровне компании). Цель его проведения – оценить потенциал и окружение проекта и действовать в соответствии с ними [10]. Потенциал проекта, выраженный в виде его сильных и слабых сторон, говорит о том, что данный проект может выполнять правильно, а чего не может. Оценка окружения проекта показывает, какие благоприятные возможности представляет и какими опасностями грозит внешний мир. Информация об окружении проекта вкупе со знанием его потенциала дает командам возможность идентифицировать критические факторы успеха (CSF), определяющие удовлетворение нужд клиента (рис. 5.3). Измерение текущего состояния проекта по этим критическим факторам предупреждает о наличии стратегических разрывов и о необходимости продумать стратегию для реагирования на эти разрывы. Осведомленность о наличии разрывов и четко определенный способ реагирования на них позволяют команде сформировать реалистичное содержание проекта и разработать стратегии, необходимые для достижения цели. Говоря кратко, SWOT-анализ должен лежать в основе планирования содержания и способа выполнения проекта.

Проведение SWOT-анализа проекта

Сбор исходной информации. Для того чтобы SWOT-анализ с самого начала взял хороший старт, необходимо наличие следующей ключевой информации:

• устав проекта и обусловившие его документы;

• голос заказчика.

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

Рис. 5.3. Пример SWOT-анализа проекта

Определение требований заказчика. Проекты выполняются для того, чтобы помочь заказчикам удовлетворить требования по части создания продукта или услуги для их потребителей. Как следствие, процесс восприятия голоса заказчика разработан для того, чтобы предоставить менеджеру информацию о нуждах клиента (см. главу 4). При SWOT-анализе количество требований должно быть ограничено только наиболее важными – теми, которые могут спасти или провалить проект. В нашем примере (см. рис. 5.3) заказчик ясно дал понять, что время выхода на рынок является для него очень важным параметром, и потребовал, чтобы срок выполнения данного проекта был сокращен на 30% по сравнению с обычным для проектов такого типа. Это серьезная проблема для компании и команды, имеющей ограниченный опыт реализации проектов разработки нового продукта в режиме быстрого прохода. Поскольку руководство рассматривает проект как возможность выхода компании на новый рынок краткосрочных контрактов, необходимо, чтобы он увенчался успехом. Но что для этого требуется? Ответ заключается в критических факторах успеха.

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

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

ИССЛЕДОВАНИЕ ОКРУЖЕНИЯ НА ПРЕДМЕТ ВОЗМОЖНЫХ КРИТИЧЕСКИХ ФАКТОРОВ УСПЕХА И РАЗРЫВОВ

Ниже приводится краткий контрольный список общего характера, в котором перечислены области возможного нахождения критических факторов успеха и связанных с ними стратегических разрывов [1, 3]:

• акционеры;

• клиенты (заказчики, потребители);

• правительства;

• конкуренты;

• общественное мнение;

• кредиторы;

• поставщики/продавцы;

• профсоюзы;

• местные сообщества

ИРОНИЯ СУДЬБЫ: ДАЖЕ ПРОДАВЕЦ САЛАТ-ЛАТУКА МОЖЕТ СТАТЬ КРИТИЧЕСКИМ ФАКТОРОМ УСПЕХА

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

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

Параллельный инжиниринг – это совмещение операций проекта с целью ускорения его выполнения [12, 13]. Краеугольный камень параллельного инжиниринга – взаимно-обратные зависимости между операциями [14], обменивающимися неполной информацией [2], что делает их выполнение более сложным, но и более быстрым. В случае создания новых продуктов такой обмен становится более эффективным, если осуществляется посредством программного обеспечения для распределенного проектирования, в ведении которого находятся ресурсы (в достаточном количестве и надлежащего качества). Быстрая разработка продуктов также требует формирования подвижных кросс-функциональных команд, которые должны владеть навыками межличностного общения, позволяющими справляться с конфликтами, уметь вести переговоры, необходимость в которых неизбежно возникает при выполнении проектов в режиме быстрого прохода, и работать с неполной информацией [15]. В довершение ко всему календарное планирование такого проекта немыслимо без умения разрешать критические ситуации, которые могут составлять 30 – 40% всех операций проекта, и все это – при необходимости завершения проекта в предельно сжатые сроки. Иначе говоря, необходимо всестороннее знание всех составляющих каждого критического фактора успеха.

Рассмотрев пространство возможностей проекта, снова обратимся к требованиям заказчика. В каких областях окружения проекта нужно действовать успешно, чтобы выполнить или превзойти такие требования? Вам может понадобиться включить в команду по разработке нового продукта поставщика первого уровня – это проверенный способ ускорения проекта [16]. Разумеется, внешних критических факторов существует множество, однако контрольный список, приведенный во врезке «Исследование окружения на предмет возможных критических факторов успеха и разрывов», подскажет вам, где их следует искать.

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

Измерение разрывов[16 - В русскоязычной литературе такой процесс называют мониторингом отклонений от целей проекта. Причем это может быть как процесс планирования, так и процесс исполнения проекта. – Прим. ред.]. Следующим шагом после определения критических факторов должно стать измерение разрывов. Разрыв – это различие между идеальным и фактическим значениями фактора. Идеальному фактору успеха «быстрая разработка продукта» в нашем примере на рис. 5.3 соответствуют отличные оценки по всем его составляющим (параллельный инжиниринг, программное обеспечение для распределенного проектирования, межличностные навыки и календарное планирование). В таком случае критический фактор успеха как целое и все четыре его составляющие находятся на идеальном для удовлетворения требований заказчика уровне. Фактический уровень отражает вашу оценку точки, в которой вы находитесь по отношению к данному фактору и его составляющим.

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

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

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

Принятие решения о способе реагирования на разрывы. Идентификация разрывов приводит вас к следующей проблеме – что с ними делать? Здесь есть три варианта: оставить как есть, уменьшить разрыв, устранить разрыв [17].

Как показано на рис. 5.4, когда проект имеет небольшие разрывы в критических факторах успеха в обоих пространствах или не имеет их вовсе (левый верхний угол), наилучшим выбором будет первый вариант – оставить все как

есть.

Рис. 5.4. SWOT-анализ проекта и стратегии реагирования на разрывы

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

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

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

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

Использование SWOT-анализа проекта

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

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

ВАМ ХВАТИТ 10 МИНУТ

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

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

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

• вскрывает те сильные стороны, которые еще не использованы в полной мере, и те слабые стороны, которые могут быть скорректированы;

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

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

Преимущества и недостатки. К основным

преимуществам SWOT-анализа относятся:

• акцентирование. Анализ показывает стратегические разрывы, тем самым обеспечивая реализацию принципа «предупрежден – значит вооружен»;

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

Что касается недостатков SWOT-анализа, то часть из них перечислена ниже:

• затраты времени. Найти время на проведение анализа иногда может быть проблематично;

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

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

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

Резюме

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

КОНТРОЛЬ SWOT-АНАЛИЗА ПРОЕКТА

Убедитесь, что SWOT-анализ проекта:

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

• включает в себя стратегические требования клиента;

• определяет стратегические разрывы по отношению к ключевым факторам успеха;

• позволяет выбрать стратегию реагирования на разрывы: оставить как есть, уменьшить или устранить;

• формулирует действия по проведению стратегии в жизнь;

• обеспечивает согласованность всех элементов.

Описание содержания

Что такое описание содержания?

Описание содержания[17 - В данном случае имеется в виду содержание предметной части проекта. Кроме этого, в любом проекте есть содержание именно управления проектом – части, являющейся приоритетной для непосредственной работы менеджера. – Прим. ред.] представляет собой письменное изложение целей, этапов и продуктов проекта (рис. 5.5). Описание содержания отвечает на вопрос, имеющий основополагающе значение: «Что мы производим в данном проекте?» Это позволяет оценить желаемый результат и составить базовый план содержания, которому необходимо следовать при выполнении всех работ проекта. В известном смысле базовый план содержания можно сравнить с границами проекта – он говорит о том, что выход за границы не допускается без санкции руководителя и что все, находящееся в этих границах, представляет собой пространство решений, в котором разрешается действовать команде проекта. Хотя существует множество версий описания содержания, формат, представленный ниже, основан на утверждении, что проект – это бизнес-предприятие.

Составление описания содержания

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

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

• голос заказчика;

• устав проекта;

• SWOT-анализ проекта.

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

Рис. 5.5. Простой пример описания содержания

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию (http://www.litres.ru/dragan-z-miloshevich/nabor-instrumentov-dlya-upravleniya-proektami/?lfrom=931425718) на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

notes

Примечания

1

Журнал «Fortune» (США) ведет ежегодно обновляющийся список 500 крупнейших компаний США, ранжированных по объему продаж. – Прим. ред.

2

Timothy A. Luehrman, “Strategy As A Portfolio of Options”, Harvard Business Review, September-October 1998. Copyright © Harvard Business School Publishing. Перепечатано с разрешения Harvard Business School Publishing.

3

Для проектов, реализуемых в России, этот подход не вполне приемлем. Как правило, у нас перерасход ресурсов характеризует не истинное положение дел в

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

4

Здесь – освоенный объем. – Прим. ред.

5

PORTFOLIO MANAGEMENT FOR NEW PRODUCTS, ROBERT G. COOPER, SCOTT J. EDGETT and ELKO J. KLEINSHMIDT. Copyright © 1998, Robert G. Cooper, Scott J. Edgett and E. J. Kleinshmidt. Перепечатано с разрешения Perseus Books Publishers, члена Perseus Books, L.L.C.

6

PORTFOLIO MANAGEMENT FOR NEW PRODUCTS, ROBERT G. COOPER, SCOTT J. EDGETT and ELKO J. KLEINSHMIDT. Copyright © 1998, Robert G. Cooper, Scott J. Edgett and E. J. Kleinshmidt. Перепечатано с разрешения Perseus Books Publishers, члена Perseus Books, L.L.C.

7

Матрица Boston Consulting Group. – Прим. ред.

8

Marheson, D., Matheson, J. E. and Menke, M. M., “Making Excellent R&D Decisions”, Reserch_Technology Management, November_December 1994. Copyright © Industrial Research Institute. Перепечатано с разрешения Industrial Re search Institute.

9

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

10

Термины участник (stakeholder) и заказчик (customer) проекта часто являются взаимозаменяемыми. – Примечание авт.

11

См. приложение Б. – Прим. ред.

12

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

13

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

14

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

15

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

16

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

17

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