Набор инструментов для управления проектами. Часть 2. Инструменты планирования проекта (Д. З. Милошевич, 2003)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПРОВЕРКА ФУНКЦИИ КАЧЕСТВА

Проверьте правильность структуры функций качества. В нее должны входить:

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

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

• крыша дома качества (матрица взаимосвязей);

• матрица соотношений;

• сравнительный анализ проектов конкурентов;

• конечные цели.

Резюме

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

Что такое устав проекта?

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

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

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

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

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

• голос заказчика[13];

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

• процесс отбора проектов.

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

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

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

ПРЕДЕЛЬНЫЕ ЦЕЛИ: СТАВИТЬ ИЛИ НЕ СТАВИТЬ?

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

Определение бизнес-цели. Что является силой, побуждающей к выполнению проекта? Целью может быть повышение удовлетворения заказчиков (как в примере на рис. 5.12), что упрощает их привлечение и удержание, а в конечном счете повышает устойчивость бизнеса и увеличивает приносимую им прибыль. Целью также может стать прорыв на новый рынок, стремление увеличить свою долю на существующем рынке, получить новые источники доходов и т. д. На стратегическом уровне выделяют несколько причин реализации проекта. Главное – не забывать о существовании таких причин и знать их суть.

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

Определение целей проекта. Термины «миссия проекта» и «бизнес-цель» допускают широкое толкование. Чтобы дать команде более конкретные указания, устав должен определить конкретные цели проекта (см. врезку «Предельные цели: ставить или не ставить?»), как минимум задать временные, стоимостные и качественные цели.

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

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

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

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

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

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

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

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

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

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

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

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

НЕОБХОДИМОСТЬ УСТАВА

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

ПРОВЕРКА УСТАВА ПРОЕКТА

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

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

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

• обеспечивать согласованность элементов.

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

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

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

Основной недостаток устава проекта:

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

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

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

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

Резюме

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

Что такое 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-анализ проекта. Очевидно, что описание содержания и его логика должны учитывать данные о сильных и слабых сторонах, благоприятных возможностях и угрозах проекта, полученные в ходе анализа разрывов. Прежде чем приступить к определению содержания проекта, подумайте, не разумнее ли описывать содержание параллельно с разработкой СДР: такой подход позволяет достичь согласования ответов на вопросы «Что мы производим в данном проекте?» (содержание) и «Как мы это производим?» (СДР).

Конец ознакомительного фрагмента.