2.1
Структуризация инновационного проекта
Будем понимать под структурой проекта совокупность взаимосвязанных элементов и процессов проекта, представленных с различной степенью детализации.
Структура проекта представляет собой стройную иерархическую декомпозицию проекта на составные части (элементы, модули), необходимые и достаточные для планирования и контроля осуществления проекта для различных участников проекта. В соответствии с определением PMI, декомпозиция – это метод планирования, предполагающий разбиение содержания проекта и результатов поставки проекта на более мелкие и легко определяемые элементы до тех пор, пока работы по проекту, связанные с выполнением содержания проекта и обеспечением результатов поставки, не определены достаточно подробно для исполнения, отслеживания и мониторинга этих работ.
Понимание проекта как структурированного (информационного) объекта, подчиняющегося логическим суждениям и формальным правилам, является основой профессиональных методов реализации и управления проектом.
Умение построить структуру проекта означает умение выделить и сформулировать отдельные подзадачи, а значит, поставить четкую задачу перед исполнителем и добиться ее выполнения. Задача должна быть четко сформулированной и посильной для исполнителя. Необходимость добиваться исполнения требует наличия навыков общего менеджмента.
Одним из признаков проекта является его разграничение, т. е. обособление, от других задач, осуществляемых в организации. Обособление проекта является важным фактором уменьшения рисков недостаточно профессионального управления, поскольку дает возможность лучше спланировать работы проекта, четко назначить ресурсы на работы проекта, распределить ответственность. Для этого необходимо использовать специальные подходы, направленные на выявление процессов, структур, работ проекта, которые позволяют этот проект структурировать, а в конце проекта взвесить и оценить его результат.
Цель управления проектами как методологии – путем структуризации упростить проект и тем самым снизить требования к квалификации менеджеров, участвующих в проекте. Для инновационных проектов это тем более важно, что в них сильна неопределенность, связанная зачастую с нечеткостью конечной цели, изначальной неопределенностью используемых методов и ресурсов.
Как же добиться того, чтобы менеджер совершал меньше ошибок или по крайней мере чтобы они не были катастрофическими для проекта? Важно построить такую систему управления проектом, которая помогала бы менеджеру предвидеть проблемы проекта (риски). Технология управления проектами в силу четкой структуризации и систематизации действий сама по себе обеспечивает существенное снижение рисков проекта.
В самом деле, структуризация проекта, упрощение его за счет разбиения на составные элементы (этапы, работы, процессы) позволяет организовать управление проектом по единым правилам. В этом случае менеджер, руководитель проекта, руководствуясь правилами структуризации проекта, избежит ошибок, вызванных неумением спланировать проект, нечеткостью действий, неспособностью справиться с большим количеством информации. Выделение отдельных этапов, а в рамках этапов – работ дает возможность существенно упростить исходную задачу, поручить более простую задачу менеджеру не такой высокой квалификации. С помощью грамотно построенного плана проекта можно контролировать развитие проекта по времени. Система контроля и мониторинга обеспечивает руководителя проекта и куратора (вышестоящего менеджера) актуальной информацией. То есть само построение проекта в соответствии с некими правилами ведет к существенному снижению рисков проекта.
Формируемая в рамках системы управления проектами подсистема управления рисками существенно зависит от характера проекта: для каждого проекта конкретный набор рисков и реагирования на них может быть свой, отличающийся от других. Стандарт PMI выделяет девять областей знаний, в рамках которых происходит формирование систем управления проектом: интеграционная система, управление содержанием проекта, сроками, стоимостью, качеством, человеческими ресурсами, коммуникациями, рисками, поставками проекта. Более подробно эти подсистемы описаны ниже. Подсистема управления рисками является лишь одной из них, однако важность ее, особенно для инновационных проектов, весьма велика.
В методологию управления проектами заложена четкая логика, связывающая между собой различные области знаний и процессы управления проектами. Любой проект ориентирован на успех, значит, должны быть сформулированы четкие критерии успеха. Как правило, критерии успеха относятся к четырем основным группам. Прежде всего это касается предметной области – достижения главной цели проекта. Проект должен быть реализован с заданным качеством, в требуемые сроки и без превышения установленной сметы. Кроме того, заданные цель проекта, сроки, качество, стоимость являются факторами, ограничивающими возможности руководителя проекта.
В процессе реализации проекта его менеджер применяет тот способ структуризации проекта, который позволяет наилучшим образом организовать управление проектом для обеспечения успеха проекта (рис. 2.1).
Проводя структуризацию проекта, менеджер имеет возможность выделить этапы (фазы) проекта, в рамках каждого этапа осуществить декомпозицию результата этапа на более мелкие задачи (работы), выделить функции проекта и возложить их реализацию на подсистемы управления проектом, описать эти подсистемы через процессы управления. В этом случае, например, план проекта разрабатывается для каждого этапа, а функция разработки плана проекта (этапа) реализуется через группу процессов планирования, что позволяет распределить реализацию процессов между членами команды проекта.
Рис. 2.1. Структуризация проекта
Разбиение на временные этапы дает возможность выделить относительно независимые блоки работ (например, этап разработки технического предложения, эскизного проектирования и т. п.). Разбиение по работам и задачам в рамках конкретного этапа помогает детализировать и взаимоувязывать выполняемые работы.
Разбиение (декомпозиция) главной цели проекта на более простые частные подзадачи и представление работ по реализации проекта в виде процессов является основой методологии PMI. За счет этого удается снизить последствия таких общих рисков, как недостаточная квалификация управленческого персонала, отсутствие опыта реализации проектов данного типа, высокая сложность проекта. Надо помнить о том, что каждый этап проекта структурируется как отдельный проект, поэтому декомпозиция целей проводится для каждого этапа.
Выделение процессов позволяет выстроить прогнозируемую последовательность действий. Многообразие реализуемых в рамках проекта функций заставляет разграничить их между собой с целью детального описания и распределения ответственности между участниками.
Наконец, введение понятия «подсистема управления» обеспечивает необходимую интеграцию, комплексность управленческих воздействий, объединение различных по характеру факторов для концентрации на достижении целей проекта. Это позволяет, как и в технических системах, строить подсистему управления, которая должна быть замкнутой через систему получения информации (т. е. иметь обратную связь) и воздействовать на объект управления, уменьшая соответствующее рассогласование.
Поскольку объект (или объекты) и регулируемые параметры известны (необходимо придерживаться графика, не допускать отклонения по срокам, финансам, ресурсам, поддерживать эффективное функционирование команды проекта), то задача подсистемы управления заключается в измерении отклонений параметров, минимизации отклонений от заданных значений. Эти параметры в каждом проекте могут отличаться, иногда значительно, поэтому на этапе планирования следует четко формулировать и фиксировать те из них, которые должны регулироваться.
Далее, в процессе управления проектом эти параметры измеряются и в случае отклонения или появления негативного воздействия (риска) включается компенсирующее воздействие. Вот эта последовательность действий и составляет суть второго аспекта управления рисками проекта.
Приступая к изучению структуризации проекта, введем некие постулаты проектного управления.
1. Каждый этап проекта является самостоятельным проектом. Выделяя этапы, мы обязаны к каждому этапу применить весь арсенал проектного управления как к отдельному проекту.
2. За каждым нашим действием или бездействием необходимо видеть последствия. Все действия менеджера вызывают последствия. Эти последствия надо видеть и предугадывать, для того чтобы вовремя среагировать в случае нежелательных последствий.
3. Чем больше этапов проекта – тем больше объем планирования. Выделяя большое количество этапов с целью упрощения проекта, мы должны быть готовы к большему объему планирования, что заставляет менеджера искать разумный компромисс между сложностью проекта и объемом работы по организации управления проектом.
4. Недостаточно выявить проблемы (риски) проекта, необходимо разработать реагирование. Менеджеру проекта недостаточно фиксировать проблему, необходимо разработать меры по ее устранению или по крайней мере по существенному снижению потерь вследствие ее наступления.
5. В проекте не должно быть элементов, которые в дальнейшем не используются («висящее ружье должно выстрелить»). Все действия должны иметь продолжение. Единственный случай, когда сделанная работа может оказаться выполненной впустую, – меры по защите от рисковых событий. Если событие не состоялось, то и защитные меры не понадобятся, однако эти затраты оправдываются тем, что в противном случае потери были бы недопустимо велики.
2.2
Этапы инновационного проекта
Одним из методов структуризации инновационного проекта является выделение фаз (этапов) проекта. Под фазой понимается ряд логически связанных операций проекта, обычно завершающихся достижением одного из основных результатов поставки. Этап – это промежуток времени, отмеченный каким-либо событием, или отдельная стадия какой-либо проделанной работы. В дальнейшем эти два понятия будем рассматривать как синонимы. Этап проекта необходим для фиксации промежуточных результатов, выделения группы работ, относящихся к одному типу. Обычно этап проекта выделяется в том случае, когда проект в своем развитии проходит ряд временных интервалов, которые имеют свои качественные особенности. Этапы проекта связаны между собой результатами.
В случае выделения этапов проекта каждый из них должен рассматриваться в качестве отдельного проекта. Каждый этап работы, как и план проекта в целом, планируется, согласовывается и утверждается одним из руководителей организации, курирующим данное направление работ. На каждом этапе работы может назначаться отдельный ответственный исполнитель (руководитель).
Следует, однако, помнить, что при слишком мелком дроблении проекта на этапы может значительно увеличиться общий объем работ по планированию, поскольку к каждому этапу необходимо подходить как к самостоятельному проекту.
Некоторые этапы проекта существуют в большинстве проектов и имеют особое значение. Так, работы, связанные с подготовкой обоснования проекта, обычно выделяют в самостоятельный этап. После принятия решения по результатам, достигнутым в ходе этапа подготовки обоснования, начинается следующий этап проекта – разработка плана проекта, после которого следует исполнительный этап. Его работы позволяют создать продукт проекта и передать его заказчику. Исполнительный этап в свою очередь может разбиваться на подэтапы в зависимости от величины, сложности, продолжительности проекта.
После достижения целей проекта начинается этап (подэтап) завершения проекта, в ходе которого подводятся итоги, уточняются результаты проекта, происходит разбор работы, обеспечивается сохранение полученного опыта реализации проекта, оценивается вклад участников, производится выплата вознаграждения и осуществляется его документальное оформление. Иногда работы такого рода в отдельный этап не выделяют, а выполняют их в рамках исполнительного этапа.
Однако могут быть и другие способы разбиения проекта на этапы. Так, при разработке нового изделия, прибора или установки в состав этапа подготовки обоснования могут быть включены этапы предпроектных исследований, подготовки технического задания и технического предложения. В проектах реструктуризации предприятий выделяют следующие большие этапы: анализ ситуации, выработка предложений, реализация предложений. В любом случае у руководителя проекта имеется свобода действий, позволяющая – с учетом типа проекта и конкретной ситуации – наилучшим для целей управления образом провести разбиение на этапы исходного проекта.
Довольно часто с началом реализации проекта возникает ряд проблем. Вдруг оказывается, что заказчик имел в виду совсем не тот результат, который получается. Команда проекта не очень четко поняла цели проекта и начала двигаться не в том направлении. Руководитель проекта не понимает видение процесса реализации проекта, имеющееся у вышестоящего руководства, и в итоге делает не так, как это предполагалось руководством.
Когда проект начинает выполняться, оказывается, что множество факторов не учтено. Обычное объяснение этому: а разве можно все учесть при планировании? Все эти неприятности чрезвычайно отравляют жизнь руководителя проекта, приводят к большому перерасходу средств и времени, компания теряет репутацию перед клиентом, а сам проект зачастую оказывается на грани провала. Именно поэтому в рамках подготовки обоснования проекта и разработки плана проекта необходимо выполнить ряд обязательных действий (процессов), которые обеспечивают повышение качества обоснования и плана проекта. Эти действия рассматриваются в следующих главах. План проекта и его исполнение у разных менеджеров могут значительно различаться. Как уже отмечалось, это связано с многообразием инструментов управления, различием опыта и квалификации менеджеров, умением учесть множество факторов, воздействующих на проект.
При создании новой техники и технологий обязательно реализуются следующие фазы:
• фундаментальные исследования. Направлены на получение новых научных знаний и выявление наиболее существенных закономерностей. Результат фундаментальных исследований – научные открытия, обоснование новых понятий, создание новых теорий, открытие новых принципов создания изделий и технологий, новых свойств материалов и способов их получения;
• прикладные исследования. Направлены на исследование путей практического применения открытых ранее явлений и процессов. Целью научно-исследовательских работ (НИР) прикладного характера является решение технической проблемы, получение конкретных научных результатов, которые будут использованы в опытно-конструкторских работах;
• опытно-конструкторские работы (ОКР). Применяются для создания, модернизации, усовершенствования образцов новой техники, материала, технологии. ОКР является завершающей стадией научных исследований;
• освоение промышленного производства новых изделий. На этой стадии выполняются опытные, экспериментальные работы для изготовления и отработки опытных образцов;
• промышленное производство.
Для каждой конкретной работы по созданию нового изделия можно использовать понятие жизненного цикла, которое определяет последовательность прохождения инновационного проекта по отдельным стадиям и этапам, т. е. инновационный процесс.
Любой проект проходит фазы развития (жизненный цикл). Обычно выделяются четыре фазы: начальная фаза, фаза разработки, реализации и фаза завершения (рис. 2.2). Если любую из этих фаз представить в качестве самостоятельного проекта, то каждый такой проект в свою очередь будет иметь те же четыре фазы. Такое разбиение позволяет выделить самостоятельные задачи, имеющие временные рамки, ограниченные финансовыми и материальными ресурсами. Руководитель проекта должен хорошо понимать цели, достигаемые на каждой из этих фаз.
Так, в начальной фазе разрабатывается концепция проекта, осуществляется сбор исходных данных, уточняются цели работы, ограничения, определяются необходимые ресурсы, проводится сравнение альтернатив.
Рис. 2.2. Фазы жизненного цикла проекта
В фазе разработки проект готовится к реализации: назначается руководитель проекта, формируется команда проекта, разрабатывается структура проекта, планируются основные работы, определяются требуемые ресурсы, готовятся календарные планы, смета и бюджет проекта, организуется выполнение базовых проектных и опытно-конструкторских работ по проекту.
В фазе реализации, как следует из названия, выполняются основные работы проекта.
В завершающей фазе обеспечивается закрытие проекта.
Содержание фаз жизненного цикла приведено ниже.
Начальная фаза
Разработка концепции проекта:
• сбор исходных данных и анализ существующего состояния (предварительное обследование);
• выявление потребности в изменениях (проекте);
• формирование целей, задач, результатов проекта;
• определение основных требований, ограничительных условий, критериев оценки проекта;
• оценка уровня риска;
• описание окружения проекта, потенциальных участников;
• оценка требуемых времени и ресурсов на реализацию проекта;
• определение и сравнительная оценка альтернатив;
• экспертиза предложенных вариантов;
• утверждение концепции и получение одобрения для следующей фазы.
Фаза разработки
Разработка основных компонент проекта и подготовка к его реализации:
• назначение руководителя проекта и формирование команды проекта;
• установление деловых контактов и изучение целей, мотивации и требований заказчика и владельцев проекта, других ключевых участников;
• развитие концепции и разработка основного содержания проекта:
– конечные результаты и продукты,
– стандарты качества,
– структура проекта,
– основные работы,
– требуемые ресурсы;
• структурное планирование:
– декомпозиция проекта,
– календарные планы и укрупненные графики работ и обеспечения,
– смета и бюджет проекта,
– потребность в ресурсах,
– процедуры управления проектами и система контроля и мониторинга,
– идентификация рисков и разработка мер противодействия;
• организация и проведение торгов, заключение субконтрактов с основными исполнителями;
• организация выполнения базовых проектных и опытно-конструкторских работ по проекту;
• получение одобрения на продолжение работ.
Фаза реализации проекта
Выполнение основных работ проекта, необходимых для достижения целей проекта:
• организация и проведение торгов, заключение контрактов;
• полный ввод в действие разработанной системы управления проектами;
• организация выполнения работ;
• ввод в действие средств и способов коммуникации и связи участников проекта;
• ввод в действие системы мотивации и стимулирования команды проекта;
• детальное проектирование и технические спецификации;
• оперативное планирование работ;
• установление системы информационного контроля за ходом работ;
• организация материально-технического обеспечения работ и управление им;
• выполнение работ, предусмотренных проектом;
• руководство, координация работ, согласование темпов, мониторинг прогресса, прогноз состояния, оперативный контроль и регулирование основных показателей проекта:
– хода работ, прогноза развития проекта,
– качества работ и проекта,
– продолжительности и сроков,
– стоимости и других показателей;
• решение возникающих проблем и задач.
Завершающая фаза
Осуществляются подведение итогов, разрешение конфликтов и закрытие проекта:
• планирование процесса завершения проекта;
• эксплуатационные испытания окончательного продукта проекта;
• подготовка кадров для эксплуатации создаваемого объекта;
• подготовка документации, сдача объекта заказчику и ввод в эксплуатацию;
• оценка результатов проекта и подведение итогов;
• подготовка итоговых документов.
Следует отметить, что представление проекта в виде фаз жизненного цикла на практике используется редко. Чаще применяют разбиение проекта на этапы, определяемые спецификой предметной области проекта. Мы будем употреблять эти термины как синонимы.
Выделение этапов проекта позволяет упростить исходную задачу, зафиксировать промежуточные результаты работы, обеспечить поступательное движение от одной задачи к другой. Для того чтобы разбиение на этапы было полезным, необходимо описать следующие параметры этапа:
• результат этапа;
• руководитель этапа (ответственный за результат этапа);
• содержание этапа (выполняемая работа);
• имеющиеся подэтапы;
• перечень работ (операций) этапа (иерархическая структура работ);
• ключевые события (вехи) этапа;
• участники этапа (команда);
• ресурсы этапа;
• контрольные точки этапа;
• календари этапа (интервалы времени, когда работы этапа не могут выполняться, например из-за праздников);
• ограничения этапа;
• необходимая информация для выполнения работ этапа.
В ряде случаев перечень и содержание этапов проекта могут задаваться нормативными документами. Например, при разработке технического изделия можно выделить следующие этапы:
• предпроектные исследования. Проводится изучение ситуации;
• техническое задание. Осуществляются разработка, согласование и утверждение. Выполняется совместно исполнителем и заказчиком;
• техническое предложение. Осуществляются выбор и обоснование оптимального варианта, происходят согласование и утверждение технического предложения;
• эскизный проект. Разрабатываются принципиальные решения по созданию системы, происходят согласование и утверждение эскизного проекта;
• технический проект. Разрабатываются окончательные решения по созданию системы, проводятся согласование и утверждение технического проекта;
• рабочий проект. Разрабатывается рабочая документация;
• изготовление, отладка, испытания. Изготавливаются и отлаживаются компоненты системы, осуществляется подготовка к вводу в действие;
• ввод в действие. Производятся опытное функционирование и приемочные испытания системы.
Содержание этапов и требования к документам проекта создания технической системы приведены ниже.
Предпроектные исследования
На данном этапе проводятся:
• обследование предприятия;
• оценка возможности создания системы;
• сбор данных;
• описание существующих систем и их анализ;
• сбор предложений по созданию системы, составу подсистем, разработке компонентов системы;
• формирование технических требований к функциям и структуре системы;
• изучение видов обеспечения.
Результатом этапа является отчет.
Техническое задание
Осуществляются разработка, согласование и утверждение технического задания (ТЗ). ТЗ является исходным и обязательным элементом для создания, приемки и сдачи системы и должно содержать все исходные данные и требования, необходимые для создания системы. ТЗ разрабатывает исполнитель с учетом результатов предпроектных исследований.
Техническое задание содержит разделы:
• наименование и область применения системы;
• основание для создания;
• характеристика объектов проектирования – сведения о назначении, составе, об условиях применения разрабатываемого объекта;
• цель и назначение – цель создания системы, назначение и критерий эффективности функционирования;
• характеристика процесса проектирования (разработки, создания) – приводятся общее описание процесса разработки, требования к входным и выходным данным;
• требования к системе в целом, к составу подсистем, к включению в состав ранее созданных подсистем и компонентов;
• требования к взаимосвязи с другими системами, видам обеспечения;
• требования к возможности развития;
• технико-экономические показатели – оценка затрат на создание системы, источники экономии, ожидаемая эффективность от применения системы, требования к технико-экономическим показателям объекта, которые будут достигнуты в результате функционирования системы;
• стадии и этапы – стадии создания, очередность ввода в действие, этапы по стадиям, сроки выполнения работ и исполнители;
• перечень документации, предъявляемой по окончании стадии;
• объемы работ в соответствии с действующими нормативно-техническими и методическими документами;
• порядок испытаний и ввода в действие;
• источники разработки – перечень научно-исследовательских, опытно-конструкторских и экспериментальных работ, нормативных документов, методических материалов, используемых при создании системы;
• приложения – таблицы, схемы, расчеты, библиография, обоснования, доказательства.
Техническое предложение
Осуществляются выбор и обоснование оптимального варианта, происходят согласование и утверждение технического предложения.
Целью технического предложения (ТП) является выбор оптимальных вариантов системы, учитывающих требования ТЗ. При разработке ТП выполняются следующие работы: анализ производственных процессов, выявление возможных вариантов структуры, выбор рационального варианта структуры, технико-экономическое обоснование варианта, составление дополнительных по сравнению с ТЗ требований, уточнение требований к содержанию работ на последующих стадиях.
ТП содержит разделы:
• общие положения (цель разработки ТП, наименование и дата утверждения ТЗ, назначение и область применения системы, описание объекта проектирования: основные составные элементы проектирования, их взаимосвязь, схема деления, результаты анализа объекта, характеристика и анализ вариантов структуры системы с выделением подсистем и компонентов и связей между ними, предложения по использованию существующих подсистем, компонентов и устройств);
• обоснование и описание выбранного варианта с указанием взаимодействия подсистем и компонентов и выполняемых ими функций;
• технико-экономическое обоснование (основные технико-экономические показатели создаваемой системы);
• предложения по содержанию и организации работ на последующих стадиях (уточненные по сравнению с ТЗ данные по очередности и содержанию работ).
Эскизный проект
На этом этапе разрабатываются принципиальные решения по созданию системы и документации, согласовывается и утверждается эскизный проект.
Эскизный проект содержит:
• основные решения по взаимодействию создаваемой системы с другими системами;
• основные технические решения по структуре подсистем, разработку вопросов функционирования подсистем на уровне компонентов;
• описание исходных данных на разработку компонентов подсистем.
Технический проект
Разрабатываются окончательные решения по созданию системы, происходят согласование и утверждение технического проекта.
На стадии технического проекта выполняются работы:
• принятие решений по процессу проектирования с обеспечением взаимодействия и совместимости процедур;
• получение окончательной схемы функционирования системы;
• разработка структуры и состава подсистем;
• получение окончательной структуры всех видов обеспечений;
• выбор математических моделей объекта проектирования и его элементов;
• разработка алгоритмов проектных операций;
• формирование общесистемного программного обеспечения;
• расчет производительности и выбор режимов работы средств технического обеспечения;
• определение требований к представлению исходных данных, результатов проектирования и проектных документов;
• оформление и утверждение совокупности документов, составляющих технический проект.
Технический проект включает следующие документы:
• ведомость;
• пояснительную записку;
• схемы процессов проектирования;
• схемы подсистем и средств обеспечения;
• спецификацию компонентов всех видов обеспечения;
• смету затрат на создание системы;
• ТЗ на разработку соисполнителями отдельных компонентов;
• расчет ожидаемых технико-экономических показателей.
Рабочий проект
Разрабатывается рабочая документация.
На данной стадии проводятся:
• разработка детальной структуры системы, ее подсистем, взаимосвязи с другими системами и ее уточнение;
• разработка структурных схем процессов;
• разработка документации для монтажа, настройки и эксплуатации системы;
• создание проектов программ и методик испытаний и опытной эксплуатации;
• оформление и утверждение.
В рабочем проекте содержатся:
• ведомость;
• пояснительная записка;
• спецификация – перечень подсистем, спецификации видов обеспечений;
• документация технического обеспечения – спецификация, комплект конструкторских документов;
• документация информационного обеспечения – спецификация, описание базы данных, инструкция по ее заполнению, инструкция по введению массива данных;
• документация программного обеспечения – спецификация, тексты программ, порядок и методика испытаний;
• программа и методика опытного функционирования системы и подсистем, данные, обеспечивающие получение и проверку проектных решений, выявление причин сбоев, показателей качества функционирования системы и подсистем;
• комплект эксплуатационных документов.
Изготовление, отладка, испытания
Изготавливаются и отлаживаются компоненты системы, осуществляется подготовка к вводу в действие.
Выполняются работы:
• подготовка организации к вводу в действие системы, включая обучение персонала;
• изготовление и отладка компонентов системы на машинных носителях;
• монтаж, отладка и испытание системы и подсистем;
• организация работ по оформлению и утверждению актов сдачи компонентов системы;
• проведение опытного функционирования системы (проверка работоспособности и взаимодействия подразделений организации с подсистемами системы, выявление неисправностей и отказов, определение фактических технико-экономических показателей системы и корректировка документации, устранение дефектов, оформление протокола);
• приемочные испытания (оценка качества разработки системы, проверка готовности организации к промышленному функционированию системы, оценка качества опытного функционирования, проверка документации на систему);
• ввод в действие системы (оформление и утверждение протокола опытного функционирования и акта приемки системы в промышленное функционирование);
• корректировка, доработка и выпуск эксплуатационных документов;
• промышленная эксплуатация и развитие системы.
Как мы видим, от этапа к этапу уменьшается исходная неопределенность в понимании того, что нужно сделать, как это сделать, каким будет итоговый результат. Такое разбиение позволяет существенно снизить риски: для заказчика не платить сразу значительную сумму за неопределенный результат, а исполнителю, изучив ситуацию, формировать структуру и наполнение будущего изделия, поэтапно согласуя с заказчиком результат каждого этапа.
Аналогичная ситуация характерна для прединвестиционной фазы проекта.
Цели прединвестиционной фазы проекта:
• определение участников инвестиционного проекта;
• разработка бизнес-плана проекта;
• выбор финансовой схемы осуществления проекта;
• представление лицу, принимающему решение, всей необходимой информации для заключения о целесообразности осуществления инвестиционного проекта (о начале реализации, об отказе от проекта или о корректировке предполагаемого плана осуществления проекта инвестиций).
Имеет смысл выделить три подэтапа. На первом подэтапе исследуются преимущественно вопросы, лежащие на поверхности, не требующие значительных усилий и финансовых затрат. На этом подэтапе проводится сбор исходных данных для выполнения следующего подэтапа, на котором изучаются технические и технологические стороны проекта. На третьем подэтапе проводится изучение рынка, оценивается экономическая эффективность проекта и готовится бизнес-план проекта.
Примерное содержание подэтапов прединвестиционной фазы проекта может быть следующим.
Подэтап 1: исследование возможностей осуществления проекта. Результатом первого подэтапа является экспертная оценка возможности осуществления проекта: проблемы, преимущества, сильные и слабые стороны проекта, рекомендации по формам дальнейшей работы.
Подэтап 2: подготовительные исследования. Результатом второго подэтапа является подготовленное технико-экономическое обоснование проекта.
Подэтап 3: оценка осуществимости проекта. Результатом третьего подэтапа является бизнес-план проекта.
2.3
Функции и подсистемы управления проектом
В рамках каждого проекта реализуются следующие функции:
• планирование;
• контроль;
• анализ;
• принятие решений;
• составление и сопровождение бюджета проекта;
• организация осуществления;
• мониторинг;
• оценка;
• отчетность;
• экспертиза;
• проверка и приемка;
• бухгалтерский учет;
• администрирование.
Эти функции могут реализовываться различным образом, в зависимости от опыта и квалификации менеджера. Выполняя структуризацию, т. е. разбиение проекта на более простые элементы, необходимо по возможности выделить компоненты, отвечающие за осуществление тех или иных функций. Как и в технических системах, функции проекта реализуются через подсистемы управления.
Как уже говорилось, в стандарте PMI введено понятие «области знаний». Представляется более удобным использовать термин «подсистемы проекта», хотя и это понятие не всегда полностью соответствует содержанию.
Рассмотрим более детально некоторые из показанных на рис. 2.3 подсистем управления проектом. Все подсистемы управления реализуются через процессы управления. Каждая подсистема управления включает в себя ряд процессов, через которые и реализуются функции управления проектами.
Управление интеграционными процессами
Управление проектами является интегрированным процессом: действия или невозможность совершить действие в одном направлении обычно влияют и на остальные направления. Это влияние может быть непосредственным и хорошо понятным или неуловимым и неясным. Например, изменение целей почти всегда затрагивает стоимость проекта, но может не повлиять на качество. Такая взаимосвязь заставляет балансировать между задачами проекта: часто улучшение в одной области может быть достигнуто за счет ухудшения в другой. Успешное управление проектом требует активного управления этими взаимодействиями.
Интеграция – это принятие решений о том, где концентрировать ресурсы на каждую конкретную дату, предугадывание потенциальных проблем и их решение до того, как эти проблемы станут критическими, и хорошая координация проблем проекта в целом. Интеграция подразумевает нахождение компромиссов между пересекающимися целями и альтернативами. По определению, интеграция заключается в координации работы с различными подрядчиками, системами, компонентами и другими элементами проекта. Таким образом, она затрагивает все области управления проектами. Как отмечалось выше, развитая интеграционная функция управления является непременным условием менеджмента высокого уровня.
Рис. 2.3. Подсистемы управления проектами
Известно, что невозможно управлять проектом каким-либо одним-единственным способом. Каждый менеджер применяет свои знания и опыт, управленческие воздействия в различной последовательности и с различной степенью жесткости. Здесь ключевую роль начинают играть навыки общего менеджмента, такие как лидерство, взаимодействие, умение настоять на своем, навыки разрешения конфликтов и т. п.
Разработка паспорта (устава проекта в рамках терминологии PMI) проекта позволяет обеспечить формальную авторизацию проекта. Паспорт проекта наделяет менеджера полномочиями задействовать ресурсы организации на операциях проекта. Если правила выделения ресурсов, в том числе людских, хорошо прописаны, то подписание паспорта проекта наделяет руководителя проекта полномочиями «работодателя». Менеджер получает право нанимать сотрудников в проект и расходовать финансовые и материальные ресурсы в соответствии с определенным ему бюджетом.
Разработка плана управления проектом – интеграционный процесс, заключающийся в документировании операций, необходимых для исполнения проекта. План управления проектом является основным документом, необходимым для исполнения проекта. Он может корректироваться в зависимости от прогресса проекта или отклонений проекта от плана в случае появления рисковых событий.
Руководство и управление исполнением проекта – интеграционный процесс, в рамках которого выполняются работы, определенные в плане управления проектом. Руководство и управление исполнением проекта требует от менеджера владения всеми приемами управления.
Мониторинг проекта – интеграционный процесс, обеспечивающий отслеживание хода работ и отклонений от плана проекта. Мониторинг и управление работами проекта организуются для наблюдения за процессами проекта.
Общее управление изменениями – интеграционный процесс, содержанием которого являются обработка всех запросов на изменение и управление этими изменениями для оптимизации результата. Общее управление изменениями включает в себя следующие операции, различающиеся уровнем детализации:
• идентификацию необходимости появления изменения;
• рассмотрение и одобрение запрошенных изменений;
• поддержание целостности базовых планов путем внесения в них только одобренных изменений и корректировку документации;
• контроль и обновление содержания, стоимости, бюджета, расписания проекта, требований к качеству на основе одобренных изменений путем координации изменений по всему проекту;
• документирование в полном объеме корректировок, вызванных запрошенными изменениями;
• контроль качества проекта по стандартам на основе отчетов о качестве.
Глубина управления изменениями зависит в первую очередь от сложности проекта.
Закрытие проекта – интеграционный процесс, обеспечивающий завершение всех операций проекта.
Следует отметить, что успешная реализация интеграционных процессов в значительной степени обусловлена опытом, квалификацией, интуицией менеджера и чрезвычайно трудно поддается формализации. Тем не менее в ряде случаев это оказывается возможным и позволяет вовлечь в управление проектами широкие слои управленцев, не обладающих достаточным опытом.
Управление содержанием
Управление содержанием, или предметной областью, проекта включает в себя процессы, обеспечивающие внесение в проект только тех работ, которые необходимы для успешного выполнения проекта. Оно непосредственно связано с определением того, что включено или не включено в проект. Термин «содержание проекта» относится к работам, которые необходимо выполнить, чтобы получить продукт, услугу или результат с заданными характеристиками.
В некоторых проектах результат бывает плохо определен, поэтому организация управления содержанием становится первостепенной задачей менеджера. Особенно это важно для инновационных проектов, поскольку именно в них зачастую высока начальная неопределенность как в содержании проекта, так и в его результатах.
В процессе реализации проекта должно обеспечиваться детальное планирование работ, которые необходимо выполнить в текущей фазе для успешного завершения проекта. При высокой начальной неопределенности приходится обеспечивать постепенную детализацию плана проекта. Такой режим работы называется rolling wave planning, т. е. планирование методом бегущей волны. Таким образом, работы планируются на каждом этапе последовательно, по мере развертывания работ по проекту и уменьшения начальной неопределенности.
В рамках данной подсистемы управления необходимо документировать процесс формулирования содержания и процесс создания иерархической структуры работ (ИСР).
Управление сроками
В рамках этой подсистемы описываются процессы, обеспечивающие своевременное завершение проекта.
Управление сроками включает в себя:
• определение продолжительности работ – сроков начала и завершения проекта, его частей, важнейших (контрольных) событий и каждой из выполняемых операций;
• минимизацию (оптимизацию) временных характеристик;
• разработку расписания;
• разумное использование резервов времени;
• контроль развития проекта по временным характеристикам;
• прогнозирование сроков завершения работ, этапов и проекта в целом;
• принятие решений по ликвидации нежелательных временных отклонений;
• оценку продолжительностей;
• календарное планирование.
Необходимость использования системы управления сроками (временем) хорошо видна из следующего реального примера.
ПРИМЕР. Иностранная компания S нуждалась в переводе на английский язык 85 патентов (примерно 1000 страниц текста с формулами). Если бы этот объем работы был запланирован на год, вряд ли возникла необходимость использования каких-либо специфических методов управления проектами при выполнении этой работы: можно выдавать одному-двум переводчикам по 5–10 страниц в день и вести учет. При этом какие-либо риски отсутствуют. В данном случае сроки были жестче: перевод патентов необходимо было выполнить за полтора месяца. Компания S обратилась в консалтинговую компанию М-С с просьбой помочь ей решить эту проблему. Важным требованием являлось выполнение работы точно в срок. Материалы необходимо было отправить самолетом не позднее заранее известной даты: если опоздал, то работа теряла смысл, а значит, исполнитель не получил бы оплату за выполненную работу. Сотрудники М-С проанализировали свои возможности и согласились выполнить работу. Были определены: стоимость работы, количество необходимых переводчиков, срок работы. Однако заказчику показалась завышенной названная стоимость работы, и было решено поручить ее специализированному переводческому бюро. Сотрудники инофирмы начали переговоры с несколькими переводческими бюро по условиям выполнения работы. Однако переводческие бюро одно за другим отказывались от этой работы: в самом деле, сложный технический текст, отсутствие переводчиков, понимающих терминологию данной предметной области, а полтора месяца – очень жесткий срок. Шло время. Когда до требуемого срока оставалось семь дней (!), иностранная компания снова обратилась в М-С с просьбой организовать перевод патентов. Совершенно ясно, что риски проекта возросли многократно, как и сложность работы. Если при отсутствии ограничений по времени проблем с выполнением работ не возникало, как и с организацией работы, то при таком жесточайшем сроке завершения проекта было не обойтись без специфических методов управления.
Для того чтобы успеть в срок, была проведена структуризация проекта и разработана система управления временем проекта, в первую очередь система прогноза развития проекта.
При анализе возможности выполнения работы в крайне сжатые сроки учитывалось следующее. Известно, что технический текст переводчики в среднем переводят со скоростью около семи страниц в день. Учитывался также тот факт, что многие переводчики, желая заработать, возьмутся за нее, а посмотрев дома текст, поймут, что текст технически сложный, требует знания специфической терминологии, поэтому перевести его не смогут. При этом большинство из них «забудет» предупредить заказчика (М-С) о том, что работа не будет сделана. Процент таких отказов определялся в 30 %, т. е. был весьма высоким.
Была разработана система прогноза времени завершения проекта с использованием Exel. Ежедневно руководитель проекта определял ожидаемую дату завершения проекта в зависимости от того, сколько переводчиков пришло в этот день и какой объем работ выполнен. Пример такого ежедневного прогноза приведен на рисунке. В результате работа была выполнена в срок и с требуемым качеством.
Рисунок. Подсистема управления временем проекта (прогноз времени завершения)
Какое значение имеет этот пример для практического применения? Ясно ведь, что проект достаточно уникальный, вряд ли возможно его повторение. На самом деле результат этого проекта может быть использован в значительном количестве проектов из самых разных сфер деятельности.
Рассмотрим похожую задачу. Необходимо выкопать траншею длиной 1000 м. Производительность рабочего – 7 м в день. Рабочий может не выйти на работу, его могут перебросить на другой объект, т. е. можно, как и выше, задать процент «отказов». Задача оказывается совершенно такой же. Для того чтобы успеть завершить работу в срок, менеджер должен постоянно оценивать время завершения проекта и назначать в зависимости от этого соответствующее количество рабочих. Решение принимается на основе четкого расчета, и назначается то количество рабочих, которое необходимо для того, чтобы уложиться в срок.
Еще один пример, в котором использовалась та же самая система прогноза времени завершения работы. Строительная компания «АВС-строй» осуществляла строительство важного объекта. Большой объем работ составляли работы по фигурной укладке кирпича, примерно 1000 кв. м (цифры условные). Эта работа должна выполняться каменщиками высокой квалификации, обученными вести фигурную кладку. Если бы сроки, как это часто бывает, были заданы не очень жестко, никаких проблем с выполнением этого объема работы не возникло бы. Вряд ли появилась бы и необходимость каких-либо специфических методов выполнения этой работы: можно ежедневно выдавать задания имеющемуся составу рабочих и вести учет. В этом случае какие-либо риски отсутствуют. В описываемом примере сроки были заданы гораздо жестче: кладку необходимо было завершить в течение месяца – к началу октября. Руководитель проекта (прораб) считал, что он успевает закончить работы в срок. Однако руководители компании опасались, что проект может быть выполнен с опозданием, поскольку приходилось перебрасывать рабочих на другие объекты и было трудно оценить дату завершения.
Для того чтобы успеть в срок, была проведена структуризация проекта и разработана система управления временем проекта, в первую очередь система прогноза развития проекта.
При анализе возможности выполнения работы к заданному сроку учитывалось следующее. Известно, что средняя производительность каменщика, осуществляющего фигурную кладку, составляет P кв. м в день. Принимался во внимание также тот факт, что рабочие регулярно перебрасываются на другие объекты или по разным причинам не выходят на работу, – в среднем до 40 % рабочих могло отсутствовать на объекте. Руководитель проекта ежедневно сообщал в офис информацию об оставшемся объеме работ и о количестве имеющихся рабочих.
Используя эту информацию, специалисты ежедневно рассчитывали предполагаемую дату завершения проекта, допуская, что с текущей даты количество рабочих не будет меняться. Для прогноза времени завершения Тпрi на i-й день использовалась формула Тпрi = 1000 – Vi/Ккi × P, где Ккi – количество каменщиков, вышедших на работу в i-й день.
Оказалось, что при имеющемся ежедневно количестве работников проект будет завершен с опозданием на месяц, что было недопустимо. На основе прогноза по аналогичной формуле ежедневно исходя из объема оставшейся работы определялось требуемое количество работников. Были приняты меры по поиску дополнительных рабочих-каменщиков, в результате проект был завершен в срок, хотя и с превышением первоначального бюджета.
Интересно, что используемые в управлении проектами программные продукты типа MS Project позволяют рассчитать время завершения операции именно по такой формуле. Однако соответствующий программный продукт не всегда имеется под рукой и поэтому необходимо уметь рассчитывать прогнозные сроки завершения работ «вручную». Кроме того, важно понимать смысл «зашитых» в программном продукте формул, для того чтобы использовать их осмысленно.
Управление стоимостью
Подсистема управления стоимостью объединяет процессы, выполняемые в ходе планирования, разработки бюджета и контроля затрат и обеспечивающие завершение проекта в рамках утвержденного бюджета. Управление стоимостью касается прежде всего стоимости ресурсов, необходимых для выполнения плановых операций.
Эта подсистема включает в себя:
• предварительную оценку расходов, связанных с проектом;
• определение сметы расходов, источников финансирования и бюджета проекта;
• планирование денежных потоков;
• прогнозирование доходов и прибылей;
• контроль за расходованием и поступлением денежных средств и принятие решений в случаях превышения расходов и других отклонений от финансовых планов.
Главная задача полсистемы управления стоимостью – соблюдение бюджетных рамок проекта и получение предусмотренной прибыли от его осуществления.
Управление качеством проекта
Процессы управления качеством объединяют все осуществляемые в исполняющей организации операции, определяющие политику, цели и распределение ответственности в области качества.
Управление качеством содержит:
• технические аспекты (контроль качества);
• управленческие аспекты (обеспечение качества);
Технические аспекты связаны с обеспечением действенной системы контроля качества. Управленческие аспекты направлены на создание таких условий, при которых участникам проекта было бы затруднительно совершать отклонения от заданных требований по качеству. Строго говоря, вся система управления проектами и является такой обеспечивающей системой.
Управление качеством распространяется на весь жизненный цикл, все стороны и элементы проекта:
• проектные, организационные и управленческие решения;
• используемые материалы, оборудование, сырье;
• качество выполняемых работ при реализации проекта;
• качество полученных результатов проекта (продукции, оказываемых услуг).
Управление качеством реализуется через установление стандартов и требований к качеству результатов проекта, обеспечение выполнения этих требований в процессе реализации проекта посредством системы контроля и поддержки.
Наиболее сложная задача для менеджера проекта – обеспечить эффективный баланс сроков, целей и стоимостей при соблюдении надлежащего качества работ. Но это является задачей подсистемы управления интеграционными процессами. Из сказанного видно, как тесно переплетены между собой компоненты управления проектами. Любое разбиение сложной системы на элементы подсистемы есть «резание по живому» и допустимо в ситуации, когда требуется упростить систему управления, сформировать ее компоненты. Но после того, как элементы системы управления сформированы, необходимо провести синтез, интеграцию разрозненных решений в единое, целостное, комплексное решение. Подсистемы управления могут хорошо решать частную задачу, но не справляться с решением общих для проекта проблем. Задача менеджера заключается в постоянном отслеживании изменений, интеграции частных решений и принятии системных, интеграционных решений, обеспечивающих достижение целей проекта.
Управление персоналом (человеческими ресурсами)
Важной проблемой является отбор и назначение персонала на операции проекта. Управление человеческими ресурсами проекта охватывает процессы организации команды проекта и управления ею. Эта подсистема включает в себя:
• определение потребности в численном и квалификационном составе на все периоды времени осуществления проекта;
• поиск и отбор кандидатур;
• оформление приема на работу и увольнения;
• планирование и распределение работников по рабочим местам;
• организацию обучения и повышения квалификации;
• определение ответственности;
• создание условий и рабочей атмосферы для коллективной работы;
• предупреждение и разрешение возникающих конфликтов;
• оплату труда.
Заметим, что в литературе встречаются утверждения, согласно которым в рамках проекта большое значение необходимо придавать командообразованию. Рекомендуют использовать для этого различные подходы, в частности назначение персонала на основе классической матрицы распределения ролей, по Беллбину. На практике использование этого подхода встречается достаточно редко, только в специфических проектах, успех реализации которых почти полностью зависит от возможности формирования эффективно работающей команды.
Персонал проекта назначается на операции (работы) проекта, а также на подсистемы проекта. В этом случае ключевое значение имеет информация о том, может ли данный сотрудник выполнить поручаемую работу и будет ли он свободен в нужный отрезок времени.
В большинстве проектов менеджер не имеет возможности заниматься вопросами повышения квалификации персонала, психологической совместимости и т. п., поскольку проект – это временное мероприятие и, в отличие от функционального подразделения, после завершения проекта команда будет расформирована. Существует достаточно ограниченный круг проектов, в которых могут применяться принципы командообразования, в частности в проектах, требующих значительных творческих усилий. (Пример такого проекта будет приведен в гл. 9, п. 9.4.)
При назначении персонала необходимо иметь ввиду следующее, и об этом нам напоминает стандарт PMI:
1) не допускать неопределенности по поводу дальнейшего использования сотрудника после завершения им работы проекта. С этим трудно не согласиться: сотрудник должен знать свое будущее и планировать свои действия;
2) не пытаться загрузить сотрудника какой-либо работой, чтобы удержать работника в целях его дальнейшего использования. С этим требованием можно согласиться далеко не всегда. Хороших специалистов не так много. Если он уйдет, в дальнейшем при появлении нового проекта организация может столкнуться с проблемами и в итоге потерять в разы больше, чем затратила бы на удержание специалиста.
При формировании подхода к управлению персоналом руководитель проекта должен сформировать свое видение этой проблемы. Например, если мобильность персонала невысока, могут возникнуть трудности с привлечением сотрудника из другого региона. Именно поэтому специалиста приходится загружать какой-либо работой, не связанной с его основной деятельностью, чтобы удержать его в рамках организации.
Управление взаимодействием (коммуникациями)
Управление взаимодействиями и информационными связями, или коммуникациями, проекта заключается в разработке, организации и контроле процесса информационного обмена с помощью разнообразных средств для удовлетворения потребностей участников проекта. Включает процессы сбора, передачи, переработки, сортировки, отображения, интерпретации информации, необходимой и достаточной для всех участников проекта и его окружения.
В терминах управления проектами проектное взаимодействие означает эффективное распространение и сбор текущих проектных данных, а также связанной корпоративной информации, т. е. таких данных, как сообщения о совещаниях в компании, проверках и т. д.
При планировании взаимодействия важно определить потоки информации и способы взаимодействия, необходимые для участников проекта. Технология взаимодействия может быть самой разнообразной: инструкции, заседания, печатные документы, компьютерные графики, базы данных. Требуется разработать структуру сбора информации (кто и какую информацию получает, от кого и какими методами), структуру распределения информации (кому и какая информация направляется), описание формы, содержания, степени детализации, условных обозначений, сроки представления информации.
Взаимодействие является важной функцией управления. В реальной жизни слабое взаимодействие часто приводит к неудачам: непонятое или неправильно понятое распоряжение может привести к тому, что выполняемые исполнителем действия объективно будут направлены не на успех проекта, а во вред ему. Чтобы этого избежать, существуют простые правила. Так, в армии после получения приказания принято отвечать: «Есть!» Это означает: приказ понят и принят к исполнению. На флоте же требуется повторить любое приказание («Право руля!» – «Есть право руля!»). Связано это с тем, что ошибка в понимании отданного распоряжения, да еще в условиях шторма, чревата тяжелыми последствиями.
Хороший пример организованного взаимодействия приведен в фильме «Экипаж» режиссера А. Митты. По сценарию самолет во время извержения вулкана забирает людей. Посадка закончилась, когда лава подступила к аэродрому. Казалось бы, надо срочно взлетать: самолет вот-вот сгорит. Вместо этого экипаж читает предполетную карту – перечень действий, которые необходимо выполнить для безопасного взлета. Все это время перед глазами светится табло «К взлету не готов». И только когда все требуемые действия выполнены, загорается другое табло: «К взлету готов», после чего командир отдает долгожданную команду: «Экипаж, взлетаем!» Подобное организованное взаимодействие чрезвычайно полезно не только в технических системах, но и в социотехнических, каковыми и являются большинство проектов.
Подсистема управления взаимодействиями – одна из важнейших подсистем управления проектом. Значение этой подсистемы видно из следующего примера. Крупная корпорация открыла новое направление, связанное с реализацией технологических проектов. Предполагалось поставить клиенту некую технологию вместе с оборудованием, которая позволила бы компании клиента выйти на новый уровень. Однако реализация проекта по непонятным причинам существенно тормозилась. В проекте был выделен ряд последовательных этапов, каждым из которых руководил отдельный менеджер, что обусловливалось спецификой каждого этапа.
Для выяснения причин сбоев проекта проведен детальный анализ двух потоков информации: той, которую должен был поставить руководитель первого этапа для реализации второго этапа, и той, которую ожидал руководитель второго этапа. Выяснилось, что расхождение в составе информационных потоков было более 40 %, и это при том, что никто не ограничивал менеджеров одной компании в обмене информацией.
Таким образом, можно сделать вывод о том, что обмен информацией в проекте должен быть специально организован.
Управление рисками
Важным элементом системы управления проектом является подсистема управления рисками проекта. Под риском проекта понимается событие или условие, которое в случае возникновения оказывает негативное воздействие на одну из целей проекта, например на сроки или стоимость. Надо заметить, что в стандарте PM BOK упоминается, что риски могут оказывать и положительное влияние на проект, однако в рамках данной книги подобные рисковые события рассматриваться не будут.
Управление рисками – это искусство и формальные методы определения, анализа, оценки, предупреждения возникновения, принятия мер по снижению степени риска на протяжении жизни проекта и распределения возможного ущерба от риска между участниками проекта.
Управление рисками является одной из сложнейших сфер деятельности менеджера. Обратим внимание на слова «искусство и формальные методы». Роль искусства, опыта, интуиции в управлении рисками чрезвычайно велика. По этой причине ведущие специалисты в области управления проектами рекомендуют выносить значительную часть подсистемы управления рисками за пределы проекта. Связано это с тем фактом, что не всегда квалификация менеджера достаточна для самостоятельного и эффективного управления рисками в рамках проекта. Для части этой подсистемы приходится привлекать внешних специалистов или менеджеров более высокого ранга и квалификации.
Система управления рисками отвечает за определение (идентификацию), оценку тем или иным способом степени угрозы от рискового события и разработку методов реагирования, т. е. защитных мер, способных предотвратить угрозу или уменьшить последствия ее наступления.
Управление рисками в реальном проекте отличается от методов, применяемых, например, в проектном анализе, в первую очередь тем, что менеджеру необходимо устранять или уменьшать результаты вредного воздействия рисков и тем самым влиять на успех проекта. По этой причине в реальном управлении не так важна оценка рисков на основе формально-математических методов. Чаще используются оценки рисков, основанные на опыте и здравом смысле менеджера проекта. Формализации поддается лишь часть процесса идентификации рисков.
Риску подвержены в той или иной мере все проекты и большинство аспектов проекта: финансовый, технический, организационный (нарушение сроков), социально-политический и т. п.
Умение предвидеть риски проекта (прогнозировать «возможные неприятности») в значительной степени зависит от опыта менеджера. Особенно это касается сложных многоплановых проектов типа НИОКР со значительной начальной неопределенностью многих параметров проекта. Эта неопределенность может относиться к результатам отдельных этапов, стоимости работ, эффективности тех или иных решений, выбору технологий и т. п. В этой ситуации в полной мере оправдывается наставление медиков – болезнь легче предотвратить, чем лечить. В управлении проектом это означает, что проще предвидеть неприятность (угрозу), чем потом из нее «выкарабкиваться».
Грамотное управление рисками позволяет руководителю проекта заранее увидеть возможные опасности и вовремя на них среагировать. Образно говоря, менеджер проекта, профессионально умеющий учитывать возможные риски и своевременно разрабатывать меры по минимизации их негативных воздействий, подобен капитану судна, у которого есть на борту хороший локатор и поэтому он уверенно и безопасно управляет судном в узком проливе и в туман, и ночью, и в условиях интенсивного движения.
Итак, руководитель проекта должен выработать в себе привычку в процессе реализации проекта постоянно прогнозировать возможные неприятности и своевременно готовиться к их устранению. Необходимо предвидеть наступление рисковых событий, а для снижения степени рисков создать систему реагирования на рисковые события, т. е. управлять рисками. Однако часто неопытные менеджеры для управления рисками используют методы, разработанные для оценки рисков и степени их угрозы в рамках проектного анализа, т. е. до начала исполнения проектов.
В проектном анализе (т. е. до начала проекта, например при разработке бизнес-плана) риск проекта характеризуется тремя факторами: событиями, оказывающими негативное воздействие на проект, вероятностью появления этих событий и оценкой возможного ущерба в результате наступления этих событий. Это позволяет определить возможные угрозы проекту и оценить величину потери в случае наступления этих нежелательных событий.
Методики определения числовых значений этих факторов широко используются на стадии предпроектных исследований. На этой стадии оценка рисков позволяет на основе некоторых критериев сравнивать проекты по такой их характеристике, как степень «опасности» для инвестора. Высокая оценка риска проекта служит сигналом опасности для инвестора. Конечно, низкая оценка риска проекта не гарантирует его 100 %-ную реализацию. Это означает лишь, что в проекте не предвидится больших или почти неотвратимых угроз.
Рассмотрим пример простого проекта, слабо привязанного к предметной области, что позволит нам понять суть отличия методологии управления рисками от анализа рисков на предпроектной стадии. Предположим, перед нами поставлена задача: закупить и доставить к месту монтажа какое-либо оборудование или продукцию (цель проекта). Для достижения этой цели выделены необходимые финансовые и иные ресурсы. Эти ресурсы, как и сроки, естественно, ограниченны.
По всем признакам это самый настоящий проект (или часть проекта), который, кстати, можно выполнять по-разному (выбрать подрядчика, у которого продукция дешевле или качественнее либо устраивают условия поставки и т. п.). В этом проекте, как и в любом другом, присутствуют различные риски, среди которых – срыв поставок, или поставка не в полном объеме, с ненадлежащим качеством, или плохие погодные условия, помешавшие поставке в срок.
Попытка в этой ситуации использовать подход к управлению рисками из проектного анализа обречена на неудачу. В самом деле, если определить возможные события риска вполне удастся, то дальше возникает неясность. Как определить вероятность того, что предполагаемый поставщик сорвет контракт? Чему будет равен ущерб? Как оценить вероятность плохой погоды? Как это отразится на проекте?
В реальном процессе управления для большинства проектов не столь уж важны численные значения вероятности и размера ущерба от наступления рискового события. Гораздо важнее выработать системную процедуру, позволяющую руководителю проекта реально воздействовать на успех проекта. Опытному руководителю проекта достаточно знать, что такое событие может наступить и ущерб от него может оказаться значительным. При этом отсутствие численных характеристик этих факторов отнюдь не означает невозможности или бесполезности реагирования на риски. Например, осторожный водитель в гололед не оценивает вероятность наступления рискового события (аварии) и величину ущерба, а минимизирует вероятность его наступления: ставит зимнюю резину, при езде по опасному участку снижает скорость и т. п.
Надо иметь в виду, что, если проект реализуется на чрезвычайно рисковом поле, система реагирования на рисковые события становится по затратам достаточно весомой, поэтому руководитель проекта должен реагировать не на все риски, а лишь на те из них, которые представляют наибольшую угрозу проекту. Вот для такого случая могут оказаться полезными модели, которые с приемлемой точностью позволяют оценить вероятность наступления нежелательного события и возможный ущерб от него. Кроме того, оценка вероятности риска в ряде случаев может помочь определить величину смещения сроков реализации проекта или оценить размер средств, которые будут использованы на компенсацию рискового события. Например, в описанном выше проекте «Перевод» оцененная экспертами максимальная доля ненадежных переводчиков, т. е. тех, кто может сорвать работу, вынуждает руководителя проекта пропорционально увеличить количество дополнительно привлеченных переводчиков (а значит, и увеличить бюджет проекта) или же согласиться с продлением срока завершения работы в случае невозможности привлечения дополнительных ресурсов.
Если же возникает необходимость не только оценивать величину смещения сроков проекта или размер дополнительных ресурсов, но и оперативно управлять рисками, следует использовать несколько иной подход.
В реальном проекте механизм управления рисками заключается в их идентификации, оценке угрозы, разработке защитных мер и реализации этих мер в случае наступления рискового события. Таким образом, система управления рисками включает в себя следующие основные процессы:
• идентификацию рисков;
• оценку рисков;
• разработку реагирования;
• управление реагированием.
Процесс идентификации рисков позволяет определить события риска, которые могут повлиять на проект. Далее следует оценка рисков, в результате которой риски разделяются на две группы: риски, требующие реагирования, и риски, не требующие реагирования. Вторая группа рисков не должна исчезать из поля зрения менеджера: может так случиться, что риски из второй группы перейдут в первую. Третий процесс – разработка реагирования, в результате которого вырабатываются меры по обеспечению противодействия рискам. Эти три процесса относятся к группе процессов планирования, и их использование подробнее рассматривается в гл. 4, п. 4.11.
Процесс «Управление реагированием» осуществляется на стадии управления проектом и включается в тот момент, когда обнаружено наступление соответствующего рискового события.
Управление поставками проекта
Эта система управления отвечает за весь спектр работ с поставщиками и подрядчиками. Можно выделить две группы процессов: первая группа связана с организацией поиска и отбора подрядчиков, включая организацию тендеров, вторая – с управлением контрактами. Стандарт PMI определяет следующие основные процессы этой подсистемы управления:
• планирование закупок и приобретений;
• запрос информации у продавцов;
• выбор продавцов;
• планирование контрактов;
• администрирование контрактов;
• закрытие контрактов.
Процессы, связанные с поиском и наймом подрядчиков, позволяют унифицировать эту процедуру, снизить влияние личностных предпочтений (включая угрозу так называемых откатов), уменьшить количество ошибок.
Процессы управления контрактами обеспечивают все действия по контрактам: выбор типа контракта, условий поставок, контроль документов, закрытие этапов и проекта и т. п.
2.4
Группы процессов проекта
В управлении проектами выделяют пять групп процессов управления, которые существуют в любом проекте, т. е. не зависят от предметной области проекта: процессы инициации, планирования, исполнения, анализа и завершения (рис. 2.4). Все процессы управления, входящие в группы процессов, связаны своими входами и выходами, т. е. результат одного процесса является входом для другого.
Рис. 2.4. Взаимосвязи групп процессов управления
Группа процессов инициации определяет и авторизует проект или фазу проекта. Под авторизацией понимается разрешение или указание начать работы по определенной плановой операции или пакету работ. В больших проектах инициация часто осуществляется вне рамок проекта путем разработки устава проекта – выпущенного инициатором проекта документа, который формально узаконивает существование проекта и наделяет менеджера проекта правом использовать ресурсы проекта для его реализации. В рамках процессов инициации формируются также требования к продукту проекта, методы приемки результата и общие подходы к управлению содержанием проекта.
Поскольку стандарт PMI описывает наиболее общие подходы к управлению проектами, в конкретном проекте не всегда легко понять, в чем же состоит суть инициации. Мы будем инициацию проекта понимать несколько иначе – как решение начать этап проекта, включая этап подготовки обоснования. В этом случае инициация проекта в целом или его этапа обеспечивается паспортом проекта – более простым документом, который готовится менеджером проекта и утверждается руководством или проектным комитетом.
Группа процессов планирования определяет и уточняет цели, обеспечивает разработку рабочих схем (планов), которые необходимы для достижения цели и результатов проекта. Данная группа процессов дает возможность уточнить содержание проекта, детализировать перечень ресурсов, необходимых для реализации проекта, составить расписание операций проекта, определить стоимость и сформировать бюджет, назначить персонал и подрядчиков, определить рисковые события и разработать защитные меры. Все это в итоге позволяет сформировать план управления проектом, на основе которого в дальнейшем будет осуществляться управление последним. В ходе реализации проекта по мере поступления новой информации может появиться необходимость пересмотра одного или нескольких процессов планирования и соответственно формирования нового плана проекта или его этапа.
Группа процессов исполнения состоит из процессов, используемых для осуществления работ, описанных в плане управления проектом. Эта группа процессов включает в себя координацию работы людей и ресурсов, выделенных на реализацию проекта, и обеспечивает их интеграцию и исполнение операций проекта. Поскольку в любом проекте наблюдаются те или иные отклонения от плана проекта, эти изменения в итоге могут привести к корректировке плана исполнения проекта.
Группа процессов анализа обеспечивает регулярную оценку исполнения проекта с целью обнаружения отклонения от плана проекта и проведения, в случае необходимости, корректирующих действий. Постоянный мониторинг проекта дает возможность команде вовремя обнаружить отклонения проекта от плана или возможные угрозы для его реализации и принять меры к ликвидации отклонений. В зависимости от того, какого рода отклонение обнаружено, будут предприниматься различные действия для его компенсации. Эти действия могут касаться как отдельных работ, так и всего плана проекта в целом. Например, если обнаружилось, что прогноз развития проекта пессимистичен, т. е. команда проекта не успевает завершить его к намеченному сроку, может потребоваться увеличение ресурсов, что приведет к увеличению стоимости проекта.
Группа процессов завершения формализует приемку продукта, услуги или результата проекта и подводит проект к правильному завершению. В эту группу входят процессы, которые необходимы для формального завершения всех операций, сохранения и накопления опыта реализации проекта, а также для использования его в других проектах, сбора и архивации полученных материалов.
Контрольные вопросы
1. Что такое структуризация инновационного проекта?
2. В чем смысл выделения этапов проекта?
3. Какие функции управления можно выделить в проекте?
4. В чем смысл структуризации проекта?
5. По каким параметрам проводится структуризация проекта?
6. Какие функции и подсистемы управления проектом можно выделить?