Выгоды. Трудно оспорить фундаментальную ценность диаграмм и их способность выступать в качестве средств наглядного представления информации – именно это, с точки зрения многих специалистов, делает их популярными. Пузырьковая диаграмма отображает проекты, находящиеся в наиболее предпочтительных квадрантах, например в квадранте, соответствующем большой важности и низкой сложности, и помогает выявить проекты, находящиеся в менее благоприятных квадрантах, например в квадранте малой важности и высокой сложности. Кроме того, они явно и недвусмысленно демонстрируют чрезвычайную важность балансирования проектов по желаемым квадрантам диаграммы. Столь наглядное отображение портфеля проектов невозможно при использовании таких инструментов, как, например, экономические методы или модели балльной оценки.
Несмотря на выгоды, обеспечиваемые применением пузырьковых диаграмм, некоторые пользователи отмечают их серьезные несовершенства [5, 6]. Эти диаграммы выступают в качестве средства информационного представления портфеля проектов, а не в качестве модели принятия решений. Как следствие, они не содержат механизма, помогающего принимать решения. В частности, модели балльной оценки могут служить моделью принятия решений при ранжировании проектов, в то время как пузырьковые диаграммы не позволяют балансировать портфель. Они скорее создают стартовую точку, отталкиваясь от которой руководители будут предпринимать необходимые действия. Пузырьковые диаграммы не показывают правильный баланс. Менеджер сам должен определить такой баланс и сравнить его с балансом, фактически имеющим место, а также решить, когда изменять баланс, прекращать те или иные проекты или добавлять новые. Однако, в то время как одни пользователи рассматривают указанные несовершенства как изъяны, присущие самой идее данного инструмента, другие заявляют, что свою задачу – отображение информации о балансе портфеля – этот инструмент выполняет хорошо.
Преимущества и недостатки. Пузырьковые диаграммы характеризуются рядом серьезных преимуществ:
• простота. Их дружественность по отношению к пользователю и легкость применения столь высоки, что люди, работающие с ними впервые, нуждаются в минимальной предварительной подготовке или вовсе не нуждаются в ней;
• точка зрения, основанная на фактических данных. Пузырьковые диаграммы обеспечивают непредвзятое представление информации, не окрашенное чьим-либо мнением.
Возникновение проблем при использовании пузырьковых диаграмм возможно, если есть:
• информационная перегрузка. Поскольку существует огромное количество пузырьковых диаграмм, многие диаграммы могут использоваться одновременно, тем самым увеличивая, а не уменьшая сложность балансирования;
• неадекватные данные. Если данные, использованные для построения диаграммы, выбраны неверно, результирующая диаграмма может оказаться ошибочной.
Рис. 3.6. Пузырьковая диаграмма в координатах «риск/отдача»[8]
Вариации. Пузырьковых диаграмм (карт портфеля или матриц портфеля) существует множество [7, 9]. На рис. 3.6 представлена диаграмма в координатах «риск/отдача», которая очень популярна в НИОКР-проектах. Изучение этой диаграммы показывает, что:
• слишком много усилий и средств затрачивается на тривиальные проекты типа «бутерброд». Это должны быть простые небольшие проекты, характеризующиеся высокой вероятностью успеха и малой прибылью;
• присутствует достаточное количество проектов типа «жемчужина». Это потенциально судьбоносные проекты, имеющие высокую вероятность успеха и способные принести большую прибыль;
• имеются два проекта типа «устрица» – это нормально, если рассматривать их как долгосрочные (проекты общего, фонового плана), способные принести высокие прибыли, но характеризующиеся низкой вероятностью успеха;
• квадрант проектов типа «белый слон» содержит только один проект – и это хорошо. Такие проекты имеют низкую прибыль и низкую вероятность успеха.
Еще один популярный вид пузырьковой диаграммы – диаграмма в координатах «дата завершения / фаза жизненного цикла» (рис. 3.7). Она показывает следующее:
• все небольшие проекты будут завершены незадолго до конца первого года работы, все большие – незадолго до конца второго года. Это очень плохой баланс, требующий принятия мер по разнесению сроков завершения проектов. Желательно также выполнить балансирование проектов различного размера;
• наблюдается надежный баланс как для малых, так и для больших проектов по фазам жизненного цикла.
Рис. 3.7. Пузырьковая диаграмма в координатах «дата завершения / фаза жизненного цикла»
Адаптация пузырьковых диаграмм. Мы описали лишь несколько общих типов пузырьковых диаграмм. Рекомендуем изучить общие модели, а затем адаптировать их к конкретной проектной ситуации. Ниже мы перечислим некоторые способы такой адаптации.
Резюме
Заключительные замечания
Литература
Часть 2
Глава 4
В этой главе рассказывается об основных инструментах выявления и преобразования требований заказчика проекта, таких как:
• сетевой график заказчика;
• целевой план;
• выборка;
• рекомендации для переговоров;
• использование функции качества (Quality Function Deployment – QFD).
Перечисленные инструменты, часто называемые инструментами досконального изучения заказчика, позволяют гармонично сочетать выявление необходимой информации от заказчика, с одной стороны, и непосредственное ее получение – с другой. Более того, эти инструменты обеспечивают контакт команды проекта с подходящим представителем заказчика и помогают планировать взаимодействие с ним. После того как информация о требованиях заказчика собрана, с помощью структурного подхода она интерпретируется в границах проекта. По ходу выполнения проекта требуются более точные данные, предоставляемые посредством инструментов планирования и управления затратами, использование которых является частью планирования объема работ (рис. 4.1).
В этой главе менеджеры проектов научатся:
• использовать разные методы при работе с заказчиком;
• выбирать методы, которые соответствуют реальной проектной ситуации;
• адаптировать выбранные методы к собственным нуждам.
Изучение данных инструментов позволит вам понимать требования заказчика для их включения в проекты. Следовательно, это умение является приоритетным при планировании и построении стандартного процесса управления проектом.
Рис. 4.1. Роль метода определения требований заказчика в процессе управления проектом
Сетевой график заказчика
Что такое сетевой график заказчика?
Составление сетевого графика заказчика
Использование сетевого графика заказчика
Несмотря на выгоды, обеспечиваемые применением пузырьковых диаграмм, некоторые пользователи отмечают их серьезные несовершенства [5, 6]. Эти диаграммы выступают в качестве средства информационного представления портфеля проектов, а не в качестве модели принятия решений. Как следствие, они не содержат механизма, помогающего принимать решения. В частности, модели балльной оценки могут служить моделью принятия решений при ранжировании проектов, в то время как пузырьковые диаграммы не позволяют балансировать портфель. Они скорее создают стартовую точку, отталкиваясь от которой руководители будут предпринимать необходимые действия. Пузырьковые диаграммы не показывают правильный баланс. Менеджер сам должен определить такой баланс и сравнить его с балансом, фактически имеющим место, а также решить, когда изменять баланс, прекращать те или иные проекты или добавлять новые. Однако, в то время как одни пользователи рассматривают указанные несовершенства как изъяны, присущие самой идее данного инструмента, другие заявляют, что свою задачу – отображение информации о балансе портфеля – этот инструмент выполняет хорошо.
Преимущества и недостатки. Пузырьковые диаграммы характеризуются рядом серьезных преимуществ:
• простота. Их дружественность по отношению к пользователю и легкость применения столь высоки, что люди, работающие с ними впервые, нуждаются в минимальной предварительной подготовке или вовсе не нуждаются в ней;
• точка зрения, основанная на фактических данных. Пузырьковые диаграммы обеспечивают непредвзятое представление информации, не окрашенное чьим-либо мнением.
Возникновение проблем при использовании пузырьковых диаграмм возможно, если есть:
• информационная перегрузка. Поскольку существует огромное количество пузырьковых диаграмм, многие диаграммы могут использоваться одновременно, тем самым увеличивая, а не уменьшая сложность балансирования;
• неадекватные данные. Если данные, использованные для построения диаграммы, выбраны неверно, результирующая диаграмма может оказаться ошибочной.
Вариации. Пузырьковых диаграмм (карт портфеля или матриц портфеля) существует множество [7, 9]. На рис. 3.6 представлена диаграмма в координатах «риск/отдача», которая очень популярна в НИОКР-проектах. Изучение этой диаграммы показывает, что:
• слишком много усилий и средств затрачивается на тривиальные проекты типа «бутерброд». Это должны быть простые небольшие проекты, характеризующиеся высокой вероятностью успеха и малой прибылью;
• присутствует достаточное количество проектов типа «жемчужина». Это потенциально судьбоносные проекты, имеющие высокую вероятность успеха и способные принести большую прибыль;
• имеются два проекта типа «устрица» – это нормально, если рассматривать их как долгосрочные (проекты общего, фонового плана), способные принести высокие прибыли, но характеризующиеся низкой вероятностью успеха;
• квадрант проектов типа «белый слон» содержит только один проект – и это хорошо. Такие проекты имеют низкую прибыль и низкую вероятность успеха.
Еще один популярный вид пузырьковой диаграммы – диаграмма в координатах «дата завершения / фаза жизненного цикла» (рис. 3.7). Она показывает следующее:
• все небольшие проекты будут завершены незадолго до конца первого года работы, все большие – незадолго до конца второго года. Это очень плохой баланс, требующий принятия мер по разнесению сроков завершения проектов. Желательно также выполнить балансирование проектов различного размера;
• наблюдается надежный баланс как для малых, так и для больших проектов по фазам жизненного цикла.
Резюме
В настоящем разделе были рассмотрены пузырьковые диаграммы – средства представления информации, которые наглядно показывают ключевые параметры проекта, необходимые для успешного балансирования портфеля проектов. Такие диаграммы могут быть полезны при проведении итоговых обзоров фаз проекта, когда принимается решение о продолжении проекта или его прекращении. Как и в случае с традиционными диаграммами, пузырьковые диаграммы не способны предложить какие-либо меры по балансированию несбалансированного портфеля, однако могут указать на важность распределения проектов по желаемым квадрантам. Наиболее эффективный способ использования диаграмм – их адаптация под конкретные ситуации. Во врезке «Проверка пузырьковых диаграмм» приводится контрольный список, который поможет вам при их построении.
ПРОВЕРКА ПУЗЫРЬКОВЫХ ДИАГРАММ
Убедитесь, что вы подготавливаете пузырьковые диаграммы надлежащим образом. Они должны отражать:
• выбранные параметры размерности проекта;
• шкалу измерения этих аспектов или параметров;
• проекты в виде пузырьков, расположенные в различных квадрантах и сбалансированные в соответствии с указаниями руководства.
Заключительные замечания
В настоящей главе мы рассмотрели два различных семейства инструментов картографирования проектов – традиционные и пузырьковые диаграммы. Каждый из этих инструментов характеризуется многообразием форм. Когда нужно отобразить два-три параметра, традиционные диаграммы могут использоваться параллельно с пузырьковыми, например круговая диаграмма, подобная изображенной на рис. 3.2, и пузырьковая, как на рис. 3.5. В данном случае малая информационная насыщенность круговой диаграммы хорошо отражает общую картину распределения ресурсов по типам проектов. Эти данные превосходно дополняются более высокой информационной насыщенностью пузырьковой диаграммы, детализирующей вклад отдельных проектов в общий баланс, выраженный в координатах «важность / легкость реализации».
Если требуется более высокая информационная насыщенность, пузырьковые и традиционные диаграммы перестают быть совместимыми и начинают конфликтовать. Например, информация, представленная в гистограмме (см. рис. 3.3), легко может быть отображена пузырьковой диаграммой. В этом случае пузырьковая диаграмма привлечет внимание к отдельным проектам, показывая их как пузырьки различных размеров. С другой стороны, гистограмма превосходит пузырьковую диаграмму по части отображения сводных значений ресурсов, выделенных в течение квартала. В целом традиционные диаграммы более просты и лучше известны менеджерам, а значит, при необходимости балансировать портфель они будут предпочтительнее. В таблице приводится итоговое сравнение, которое поможет вам в выборе инструмента в конкретной проектной ситуации.
Если требуется более высокая информационная насыщенность, пузырьковые и традиционные диаграммы перестают быть совместимыми и начинают конфликтовать. Например, информация, представленная в гистограмме (см. рис. 3.3), легко может быть отображена пузырьковой диаграммой. В этом случае пузырьковая диаграмма привлечет внимание к отдельным проектам, показывая их как пузырьки различных размеров. С другой стороны, гистограмма превосходит пузырьковую диаграмму по части отображения сводных значений ресурсов, выделенных в течение квартала. В целом традиционные диаграммы более просты и лучше известны менеджерам, а значит, при необходимости балансировать портфель они будут предпочтительнее. В таблице приводится итоговое сравнение, которое поможет вам в выборе инструмента в конкретной проектной ситуации.
Литература
1. Harrison, J. S. and C. St. John 1998 “Strategic Management of Organizations and Stakeholders” 2d ed. Cincinnati: South – Western College Publishing.
2. Brenner, M. S. 1994 “Practical R&D Project Prioritization” Research Technology management 37(5): 38 – 42.
3. Buss, M. D. J. 1983 “How to Rank Computer Project” Harvard Business Review 1(71): 145.
4. Cooper, R. G., S. J. Edgett, and E. J. Kleinshmidt 1998 “Best Practices for Managing R&D Portfolios: Lessons from the leaders – Part II” Research Technology Management 41(4): 20 – 33.
5. Cooper, R. G., S. J. Edgett, and E. J. Kleinshmidt 1997 “Portfolio Management in New Product Development: Lessons from the leaders – Part I” Research Technology Management 41(4): 20 – 33.
6. Cooper, R. G., S. J. Edgett, and E. J. Kleinshmidt 1997 “Portfolio Management in New Product Development: Lessons from the leaders – Part II” Research Technology Management 40(6): 43 – 52.
7. Archer, N. P. and F. Ghazemzaden 1999 “An Integrated Framework for project Portfolio Selection” International Journal of Project Management 17(4): 207 – 216.
8. Marheson, D., J. E. Matheson and M. M. Menke 1995 “Making Excellent R&D Decisions” Research Technology Management 37(6) 21 – 24.
9. Marheson, D., J. E. Matheson and M. M. Menke 1994 “Using Decision Quality Principles to Balansce Your R&D Portfolio” Research Technology Management 37(3) 38 – 43.
2. Brenner, M. S. 1994 “Practical R&D Project Prioritization” Research Technology management 37(5): 38 – 42.
3. Buss, M. D. J. 1983 “How to Rank Computer Project” Harvard Business Review 1(71): 145.
4. Cooper, R. G., S. J. Edgett, and E. J. Kleinshmidt 1998 “Best Practices for Managing R&D Portfolios: Lessons from the leaders – Part II” Research Technology Management 41(4): 20 – 33.
5. Cooper, R. G., S. J. Edgett, and E. J. Kleinshmidt 1997 “Portfolio Management in New Product Development: Lessons from the leaders – Part I” Research Technology Management 41(4): 20 – 33.
6. Cooper, R. G., S. J. Edgett, and E. J. Kleinshmidt 1997 “Portfolio Management in New Product Development: Lessons from the leaders – Part II” Research Technology Management 40(6): 43 – 52.
7. Archer, N. P. and F. Ghazemzaden 1999 “An Integrated Framework for project Portfolio Selection” International Journal of Project Management 17(4): 207 – 216.
8. Marheson, D., J. E. Matheson and M. M. Menke 1995 “Making Excellent R&D Decisions” Research Technology Management 37(6) 21 – 24.
9. Marheson, D., J. E. Matheson and M. M. Menke 1994 “Using Decision Quality Principles to Balansce Your R&D Portfolio” Research Technology Management 37(3) 38 – 43.
Часть 2
Инструменты планирования проекта
Глава 4
Требования заказчика проекта
Глава написана при участии Джоза Кампоса (Jose Campos).
В этой главе рассказывается об основных инструментах выявления и преобразования требований заказчика проекта, таких как:
• сетевой график заказчика;
• целевой план;
• выборка;
• рекомендации для переговоров;
• использование функции качества (Quality Function Deployment – QFD).
Перечисленные инструменты, часто называемые инструментами досконального изучения заказчика, позволяют гармонично сочетать выявление необходимой информации от заказчика, с одной стороны, и непосредственное ее получение – с другой. Более того, эти инструменты обеспечивают контакт команды проекта с подходящим представителем заказчика и помогают планировать взаимодействие с ним. После того как информация о требованиях заказчика собрана, с помощью структурного подхода она интерпретируется в границах проекта. По ходу выполнения проекта требуются более точные данные, предоставляемые посредством инструментов планирования и управления затратами, использование которых является частью планирования объема работ (рис. 4.1).
В этой главе менеджеры проектов научатся:
• использовать разные методы при работе с заказчиком;
• выбирать методы, которые соответствуют реальной проектной ситуации;
• адаптировать выбранные методы к собственным нуждам.
Изучение данных инструментов позволит вам понимать требования заказчика для их включения в проекты. Следовательно, это умение является приоритетным при планировании и построении стандартного процесса управления проектом.
Сетевой график заказчика
Что такое сетевой график заказчика?
Сетевой график заказчика – это инструмент, позволяющий разработать системный подход для учета требований заказчика (рис. 4.2). Чтобы выполнить поставленную задачу, на сетевом графике указаны последовательность этапов и их сроки, которые обрисовывают процесс получения документов и использование данных заказчика. Хорошо отлаженный и последовательно выполняемый процесс повышает степень вовлеченности заказчика в процесс планирования и реализации проекта.
Логика применения сетевого графика заказчика в этом случае является четким и надежным инструментом. Процесс получения входной информации от заказчика, как любая другая группа проектных работ, требует планирования. Менеджер проекта должен иметь достаточно времени для общения с заказчиком и эффективного применения полученной информации. Проще говоря, сетевой график заказчика – это схема использования инструментов, представленных в этой главе, и их временные рамки.
Логика применения сетевого графика заказчика в этом случае является четким и надежным инструментом. Процесс получения входной информации от заказчика, как любая другая группа проектных работ, требует планирования. Менеджер проекта должен иметь достаточно времени для общения с заказчиком и эффективного применения полученной информации. Проще говоря, сетевой график заказчика – это схема использования инструментов, представленных в этой главе, и их временные рамки.
Составление сетевого графика заказчика
Разработка и применение сетевого графика заказчика – достаточно новое явление в проектных организациях. Отсутствие опыта повышает риск ошибки. Чтобы не допустить оплошности, следует обратить внимание на методическую разработку и построение сетевого графика с четко определенной последовательностью этапов (см. рис. 4.2).
Рис. 4.2. Сетевой график заказчика
Подготовка входной информации. Значительное влияние на успешное создание сетевого графика оказывают следующие данные:
• план проекта;
• список членов команды.
План проекта, обычно подготавливаемый на начальном этапе, содержит информацию о целях, масштабе и стратегии осуществления проекта. Это позволяет выявить основных заказчиков и определить способы получения и использования необходимой информации. Если члены команды уже известны, их также можно привлекать для формирования сетевого графика. Они получают право на закрытие сделки при условии обязательного использования графика такого типа.
Встреча команды проекта с заказчиком. Существует точка зрения, что команда проекта владеет всей информацией, требуемой для завершения проекта. Другими словами, со стороны команды можно ожидать сопротивления, обусловленного их чрезмерной уверенностью или сложившимися традициями (если они никогда ранее не встречались с заказчиками). Менеджер проекта должен знать о возможности подобного сопротивления и объяснить людям, что многие сведения еще предстоит выяснить. Кто заказчики проекта? Знаем ли мы все требования заказчиков? Знаем ли мы нечетко сформулированные требования заказчиков? Ответы на эти вопросы докажут необходимость посещения заказчика и позволят лучше понять его условия. Кроме того, понимание требований заказчика станет хорошим подспорьем для увеличения стоимости проекта (см. врезку «Основное требование заказчика – эффективные вложения»).
Составление целевого плана. На данном этапе нужно сформулировать основные идеи, которые определяют цель визита к заказчику. Готовясь к встрече, представляющей собой часть этапа по налаживанию контактов с заказчиком, участники команды должны получить исчерпывающие ответы на следующие вопросы:
• Почему необходимо сотрудничество с заказчиками проекта?
• Когда нужно начать взаимодействие с заказчиком, чтобы оно стало наиболее эффективным для проекта?
• Каким образом использовать полученную в ходе взаимодействия информацию?
• С кем общаться для получения достоверной информации?
• Где находятся эти доверенные лица?
• Сколько доверенных лиц требуется для построения надежной модели?
Данная информация описывает представителей заказчика, с которыми нужно взаимодействовать.
Разработка рекомендаций для обсуждения. На следующем этапе члены команды должны составить вопросы или выбрать темы для обсуждения с заказчиком проекта. Здесь основными будут вопросы:
• Какая информация действительно нужна?
• Каким образом составить вопросы для получения необходимой информации?
• Является ли ответ на вопрос значимой информацией для проекта?
Определение состава команды. На этом этапе необходимо определить членов команды, которые будут общаться с заказчиком.
Основными здесь являются следующие вопросы:
• Кто из команды наиболее подготовлен для ведения переговоров?
• Хватит ли выбранным сотрудникам времени для общения и обработки информации?
• Запланировано ли обучение сотрудников для более эффективного общения?
На практике в состав команды обычно входят два человека. Например, для общения с восемью заказчиками создаются две команды по два человека, и каждая команда проводит по четыре встречи. Присутствие на встрече более двух человек способно испортить дискуссию. Кроме того, если участников двое, они могут разделить функции: один задает вопросы, а другой делает заметки. Необходимое условие при зачислении в команду – наличие времени для сбора и обработки информации, а также соответствующая подготовка. (По словам одного эксперта, участники команды проекта, как правило, недостаточно подготовлены для проведения интервью. Возможно, это является основной причиной выпуска продуктов, в которых не учтены требования заказчика.) [10]
И наконец, в бюджете следует предусмотреть статью для покрытия транспортных расходов интервьюеров. Это особенно важно при необходимости поездок в другие города или страны.
Общение с заказчиком. На основе подготовленных рекомендаций для обсуждения избранные члены команды проводят встречу с заказчиком проекта. Подготовка к интервью должна включать ответы на следующие вопросы:
• Продумана ли логистика проекта для обеспечения успеха контакта?
• Был ли заказчик уведомлен о предстоящих контактах?
• Был ли определен и согласован способ фиксации информации?
Организовать встречу следует так, чтобы ничто не помешало проведению интервью. Время и место встречи, присутствие заказчика и т. п. заслуживают пристального внимания. К тому же безусловным требованием является ведение записей, поскольку это единственный способ сохранить полезную информацию. Представьте себе, например, обсуждение восьми интервью, записи на которых не делались, особенно если они прошли несколько недель назад.
Обработка информации. После завершения всех встреч нужно собрать полученную информацию в единый отчет, который будет полезен проекту. Обычно это реализуется при тесном взаимодействии всех участников интервью. Цель такого взаимодействия – убедиться в том, что ответы на нижеследующие вопросы являются утвердительными:
• Была ли собрана воедино вся информация по всем контактам?
• Будет ли конечный отчет написан и разослан членам команды проекта?
• Зафиксирован ли накопленный опыт для улучшения работы на следующих этапах взаимодействия с заказчиком?
Типичный сценарий встречи может выглядеть следующим образом. Принимая во внимание общие рекомендации для обсуждения, начните с наиболее важных вопросов. Каждый участник изложит полученные данные, сделает необходимые заявления, расспросит о потребностях заказчика и систематизирует информацию по определенным категориям – к примеру, нужды заказчика и его разочарования. Используйте целевой план для выявления критериев оценки потребностей заказчика. Требования заказчика, ранжированные с учетом приоритетов, становятся так называемыми факторами ценности. В конце встречи нужно вычленить от трех до пяти категорий с потребностями, расставленными в порядке убывания их приоритетов. Последним шагом должно стать принятие на себя ответственности за применение информации, а затем составление письменного отчета.
«Встраивание» информации в границы проекта. Именно на этом этапе можно получить отдачу от учета требований заказчика. Помните, что вся собранная информация бесполезна до тех пор, пока она не включена в границы проекта. К примеру, один из вариантов – встреча членов команды для анализа итогового отчета, определенных последствий или действий, необходимых как результат обсуждения. Также целесообразно рассмотреть отчет с менеджерами. Проверьте, что требования заказчика непосредственно встроены в границы проекта. Следующие вопросы помогут вам понять, завершен ли данный этап:
• Определены ли факторы ценности для заказчика?
• Усвоила ли команда проекта эти факторы?
• Были ли факторы ценности интегрированы в процессы и проектные продукты?
Один из структурных подходов к интерпретации требований заказчика в границах проекта реализуется при помощи функции качества, подробно описанной в конце этой главы. Если работа начинается с факторов ценности для заказчика (Чего хотелось бы заказчику и в каком порядке?), то функции качества служат ее продолжением («Как в проекте учитываются пожелания заказчика?»), что выражается в переносе требований в рамки проекта и даже изменении деталей проекта.
Подготовка входной информации. Значительное влияние на успешное создание сетевого графика оказывают следующие данные:
• план проекта;
• список членов команды.
План проекта, обычно подготавливаемый на начальном этапе, содержит информацию о целях, масштабе и стратегии осуществления проекта. Это позволяет выявить основных заказчиков и определить способы получения и использования необходимой информации. Если члены команды уже известны, их также можно привлекать для формирования сетевого графика. Они получают право на закрытие сделки при условии обязательного использования графика такого типа.
Встреча команды проекта с заказчиком. Существует точка зрения, что команда проекта владеет всей информацией, требуемой для завершения проекта. Другими словами, со стороны команды можно ожидать сопротивления, обусловленного их чрезмерной уверенностью или сложившимися традициями (если они никогда ранее не встречались с заказчиками). Менеджер проекта должен знать о возможности подобного сопротивления и объяснить людям, что многие сведения еще предстоит выяснить. Кто заказчики проекта? Знаем ли мы все требования заказчиков? Знаем ли мы нечетко сформулированные требования заказчиков? Ответы на эти вопросы докажут необходимость посещения заказчика и позволят лучше понять его условия. Кроме того, понимание требований заказчика станет хорошим подспорьем для увеличения стоимости проекта (см. врезку «Основное требование заказчика – эффективные вложения»).
Составление целевого плана. На данном этапе нужно сформулировать основные идеи, которые определяют цель визита к заказчику. Готовясь к встрече, представляющей собой часть этапа по налаживанию контактов с заказчиком, участники команды должны получить исчерпывающие ответы на следующие вопросы:
• Почему необходимо сотрудничество с заказчиками проекта?
• Когда нужно начать взаимодействие с заказчиком, чтобы оно стало наиболее эффективным для проекта?
• Каким образом использовать полученную в ходе взаимодействия информацию?
ОСНОВНОЕ ТРЕБОВАНИЕ ЗАКАЗЧИКА – ЭФФЕКТИВНЫЕ ВЛОЖЕНИЯПодготовка выборки[9]. После определения цели взаимодействия с заказчиком нужно выявить представителя заказчика, с которым предстоит общаться (см. врезку «У каждого проекта есть заказчик»). Это обычно происходит на собрании команды или всех участников фактического взаимодействия по проекту. Для создания профиля необходимо ответить на следующие вопросы:
Заказчик проекта является главной фигурой в нем. Из-за конкуренции процесс определения требований заказчика приобретает все большую важность. Именно заказчики диктуют условия своим поставщикам и называют сумму, которую они готовы заплатить. Ведущие организации предоставляют ресурсную информацию по проектам, товарам и услугам, чтобы удовлетворить заказчика.
Рассмотрим пример. Сервисная служба компании Apple Computers обзванивает клиентов и каждую неделю публикует список, включающий 10 наиболее часто возникающих проблем. На основе этого списка разработчики улучшают процессы производства продуктов или начинают выпуск новых с учетом имеющихся пожеланий клиентов. Довольные клиенты нужны для поддержания стабильного экономического положения компании. Так, в 1997 году фирмы, преуспевшие в удовлетворении своих клиентов, удвоили акционерный капитал. Не секрет, что наиболее успешные мировые производители программного обеспечения считают вовлеченность заказчиков в производственный процесс одним из наиболее важных факторов выполнения проекта в целом: удовлетворение клиентов начинается с их участия в проекте. Таким образом, игнорирование требований заказчика – плохое решение для бизнеса.
• С кем общаться для получения достоверной информации?
• Где находятся эти доверенные лица?
• Сколько доверенных лиц требуется для построения надежной модели?
Данная информация описывает представителей заказчика, с которыми нужно взаимодействовать.
Разработка рекомендаций для обсуждения. На следующем этапе члены команды должны составить вопросы или выбрать темы для обсуждения с заказчиком проекта. Здесь основными будут вопросы:
• Какая информация действительно нужна?
• Каким образом составить вопросы для получения необходимой информации?
• Является ли ответ на вопрос значимой информацией для проекта?
У КАЖДОГО ПРОЕКТА ЕСТЬ ЗАКАЗЧИКПредположим, что встреча с заказчиком проекта не может длиться более одного часа. В этом случае нужно подготовить три-четыре ключевых вопроса или темы для обсуждения. Каждый участвующий в процессе общения с заказчиком должен оперировать одним и тем же набором вопросов в одинаковой последовательности, чтобы обеспечить порядок проведения переговоров. Следует помнить, что после завершения встречи информация должна быть сведена в общий отчет, поэтому во время обсуждения нужно делать заметки.
Поскольку мы привыкли видеть в заказчиках проекта основных получателей его выгод, они будут определять результаты проекта. Обычно заказчики делятся на две группы: внешние и внутренние. Внешние заказчики покупают проект, финансируя организацию. Здесь основной задачей будет удовлетворение их потребностей и сохранение денежных поступлений. Когда выгоды проекта получают другие работники, они обычно называются внутренними заказчиками. Внутри компании работы по проекту передаются от одной команды другой. Команда может получить работу от других сотрудников компании – внутренних заказчиков. Внешними поставщиками выступают продавцы, находящиеся вне организации и предлагающие продукты, услуги, материалы и т. п. проектной команде. Поэтому каждый проект, с одной стороны, является заказчиком, а с другой – источником работ.
Внешние и внутренние заказчики демонстрируют схожие модели поведения. Например, их определение выгоды складывается на основе собственных нужд, наборов целей или выдвигаемых на данный момент требований. Ошибочным является предположение о том, что все работают на одну организацию и стремления каждого понятны. Иными словами, внутренние заказчики проявляют все свойства внешних. Менеджер проекта должен учитывать мнение заказчика проекта, к какой бы категории тот ни принадлежал[10].
Определение состава команды. На этом этапе необходимо определить членов команды, которые будут общаться с заказчиком.
Основными здесь являются следующие вопросы:
• Кто из команды наиболее подготовлен для ведения переговоров?
• Хватит ли выбранным сотрудникам времени для общения и обработки информации?
• Запланировано ли обучение сотрудников для более эффективного общения?
На практике в состав команды обычно входят два человека. Например, для общения с восемью заказчиками создаются две команды по два человека, и каждая команда проводит по четыре встречи. Присутствие на встрече более двух человек способно испортить дискуссию. Кроме того, если участников двое, они могут разделить функции: один задает вопросы, а другой делает заметки. Необходимое условие при зачислении в команду – наличие времени для сбора и обработки информации, а также соответствующая подготовка. (По словам одного эксперта, участники команды проекта, как правило, недостаточно подготовлены для проведения интервью. Возможно, это является основной причиной выпуска продуктов, в которых не учтены требования заказчика.) [10]
И наконец, в бюджете следует предусмотреть статью для покрытия транспортных расходов интервьюеров. Это особенно важно при необходимости поездок в другие города или страны.
Общение с заказчиком. На основе подготовленных рекомендаций для обсуждения избранные члены команды проводят встречу с заказчиком проекта. Подготовка к интервью должна включать ответы на следующие вопросы:
• Продумана ли логистика проекта для обеспечения успеха контакта?
• Был ли заказчик уведомлен о предстоящих контактах?
• Был ли определен и согласован способ фиксации информации?
Организовать встречу следует так, чтобы ничто не помешало проведению интервью. Время и место встречи, присутствие заказчика и т. п. заслуживают пристального внимания. К тому же безусловным требованием является ведение записей, поскольку это единственный способ сохранить полезную информацию. Представьте себе, например, обсуждение восьми интервью, записи на которых не делались, особенно если они прошли несколько недель назад.
Обработка информации. После завершения всех встреч нужно собрать полученную информацию в единый отчет, который будет полезен проекту. Обычно это реализуется при тесном взаимодействии всех участников интервью. Цель такого взаимодействия – убедиться в том, что ответы на нижеследующие вопросы являются утвердительными:
• Была ли собрана воедино вся информация по всем контактам?
• Будет ли конечный отчет написан и разослан членам команды проекта?
• Зафиксирован ли накопленный опыт для улучшения работы на следующих этапах взаимодействия с заказчиком?
Типичный сценарий встречи может выглядеть следующим образом. Принимая во внимание общие рекомендации для обсуждения, начните с наиболее важных вопросов. Каждый участник изложит полученные данные, сделает необходимые заявления, расспросит о потребностях заказчика и систематизирует информацию по определенным категориям – к примеру, нужды заказчика и его разочарования. Используйте целевой план для выявления критериев оценки потребностей заказчика. Требования заказчика, ранжированные с учетом приоритетов, становятся так называемыми факторами ценности. В конце встречи нужно вычленить от трех до пяти категорий с потребностями, расставленными в порядке убывания их приоритетов. Последним шагом должно стать принятие на себя ответственности за применение информации, а затем составление письменного отчета.
«Встраивание» информации в границы проекта. Именно на этом этапе можно получить отдачу от учета требований заказчика. Помните, что вся собранная информация бесполезна до тех пор, пока она не включена в границы проекта. К примеру, один из вариантов – встреча членов команды для анализа итогового отчета, определенных последствий или действий, необходимых как результат обсуждения. Также целесообразно рассмотреть отчет с менеджерами. Проверьте, что требования заказчика непосредственно встроены в границы проекта. Следующие вопросы помогут вам понять, завершен ли данный этап:
• Определены ли факторы ценности для заказчика?
• Усвоила ли команда проекта эти факторы?
• Были ли факторы ценности интегрированы в процессы и проектные продукты?
Один из структурных подходов к интерпретации требований заказчика в границах проекта реализуется при помощи функции качества, подробно описанной в конце этой главы. Если работа начинается с факторов ценности для заказчика (Чего хотелось бы заказчику и в каком порядке?), то функции качества служат ее продолжением («Как в проекте учитываются пожелания заказчика?»), что выражается в переносе требований в рамки проекта и даже изменении деталей проекта.
Использование сетевого графика заказчика
Когда использовать. Сетевой график заказчика требуется в больших проектах, обычно на этапе определения границ. Многие команды начинают его формирование еще на этапе подготовки предложения и в процессе выбора проекта: это дает возможность оценить проект и включить необходимые ресурсы в план. В некоторых случаях именно на этом этапе начинается общение с заказчиками. У каждого заказчика должен быть собственный сетевой график.