Глава 3. Основы проектного управления.

3.1. Управление содержанием проекта.

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

 

В процессе формирования замысла проекта необходимо ответить на ряд вопросов. Список наиболее значимых из них представлен ниже:

 

 

 

 

Приведем несколько примеров:

Далее представим ключевые процессы управления содержанием проекта:

 

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

 

На процесс утверждения проекта, как правило, влияет ряд факторов. Представим ключевые из них проиллюстрировав примером:

 

 

 

 

 

Рассмотрим основные типы моделей выбора проекта.

Перечислим ключевые методы планирования содержания проекта.

 

Результатом планирования содержания проекта являются:

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

v Обоснование проекта – деловая необходимость, ради которой был предпринят проект; v Предметы проекта – количественные критерии (стоимость, расписание). Предметы должны иметь единицу измерений ($), абсолютные и относительные величины (менее или более 1,5 млрд), неколичественные характеристики (чувство удовлетворения заказчика). Предметы проекта – критические факторы успеха; v Продукт проекта – краткое описание продукта – резюме; v Цели проекта – список под-продуктов (программный продукт = программа + пособие + материалы).

 

2. Цели, которые удовлетворяют следующим характеристикам:

 

Определение содержания проекта предполагает собой процесс дробления ключевых целей проекта на более мелкие в целях:

 

 

 

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

 

 

3.2. Описание проекта. Спецификация.

 

 

 

 

Спецификация проекта

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

 

 

 

Планирование проекта.

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

 

 

 

 

 

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

 

 

 

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

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

 

 

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

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

 

Критические области (слабые стороны) традиционных подходов к планированию проекта.

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

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

 

 

•

 

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

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

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

 

 

 

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

 

 

 

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

 

 

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

 

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

 

 

 

 

3.4. Иерархическая структура работ проекта.

 

 

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

Различные типы и способы использования иерархических структур. Концепция, лежащая в основе иерархической структуры проекта/работ и впервыепоявившаяся в начале 60-х годов XX века в аэрокосмических и оборонныхпрограммах и проектах, породила множество различных иерархических структур,полезных в управлении сложными проектами. К наиболее широко используемымотносятся структуры, описывающие работы или задачи (PBS/WBS,ИСП/ИСР), организации (OBS, ИСО), стоимость (CBS, ИСС), расписания (SBS,ИСРС) и продукт. Либерзон и Лобанов сообщают об использовании большогоколичества иерархических структур в России и приводят примеры структур дляописания целей проекта, процессов проекта, ресурсов проекта и “обязанностей к онструкторов (реализующих проектный замысел)”, что, по сути, не отличаетсяот ИСО. Другие авторы описывают использование данного подходадля разбиения содержания проекта. Следует отметить, что структура ответственности(обязанностей) успешно заменяет матрицу ответственности, котораяобычно разрабатывается как часть плана проекта. Обязанности обычнораспределяются по иерархической структуре, и лишь в малых проектах структураответственности становится плоской и может быть трансформирована в матрицу.

 

 

 

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

 

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

 

 

В проекте к анализу одного события могут быть применимы следующие даты:

 

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

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

 

 

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

 

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

 

1. Главное расписание проекта (главное расписание фаз). 2. Расписание основных контрольных событий. 3. Главное расписание инженерно-конструкторских работ. 4. Главное расписание производственных работ. 5. Главные итоговые расписания: ИСП уровней 2, 3 и т.д. 6. Краткосрочное расписание контрольных событий. 7. Графики трендов проекта: графики стоимости и прохождения контрольных событий. 8. Сетевой план проекта - логическая диаграмма управления. 9. Расписания задач. 10. Расписания функциональных операций. 11. Подробный сетевой план (подробные сетевые планы) PERT. 12. Основные расписания создания продукта. 13. Расписание эксплуатации аппаратных средств. 14. Расписания доставки элементов аппаратных средств. 15. Расписания субподрядов, заключаемых до оплаты контракта. 16. Предоставленные субподрядчиком расписания инженерных работ, производства и поставок. 17. Расписание выпуска чертежной документации. 18. Расписания проведения обзоров, требуемых по контрактам. 19. Расписание эксплуатационных испытаний. 20. Расписание собственности, предоставленное правительством или заказчиком. 21. Информация со стороны правительства или заказчика либо другое расписание ответственности. 22. Расписание демонстраций оборудования для обучения или сопровождения. 23. Расписание технических публикаций. 24. Расписание вспомогательных испытаний материалов. 25. Расписание требований контракта. 26. Расписания демонстраций системы.

 

 

Сетевой план PERT/CPM/PDM НА уровне проекта Правильное применение методов сетевого планирования PERT/CPM/PDM и метода анализа критического пути проекта к планированию всего проекта может принести следующие значительные выгоды:

 

 

 

Представим ниже ключевые компоненты сетевого плана: