Vinaora Nivo Slider 3.xVinaora Nivo Slider 3.xVinaora Nivo Slider 3.xVinaora Nivo Slider 3.xVinaora Nivo Slider 3.xVinaora Nivo Slider 3.xVinaora Nivo Slider 3.xVinaora Nivo Slider 3.xVinaora Nivo Slider 3.xVinaora Nivo Slider 3.x

Мы предлагаем разработать для Вас календарно-сетевой график (модель) в системе Spider Project.

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

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

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

Система управления строительными проектами Spider Project позволит Вам значительно снизить Ваши строительные затраты, усилит контроль над производством работ и финансовыми затратами на всех этапах строительства.

Установит контроль и управление над ресурсами Вашей компании.

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

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

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

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

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

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

Spider Project дозволяет завести в проекте огромное количество разных ИСР, в каждой из которых можно задавать огромное количество уровней иерархии.

Составляющие цены

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

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

Операции проекта

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

Продолжительность выполнения,

Размер работ на операции (изюминка Spider Project),

Трудозатратность операции (ресурсо-часы, нужные для ее выполнения),

- Календарь операции,

- Прямые траты на операцию (по каждой составляющей издержек),

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

- Ограничения на сроки выполнения операции (к примеру, начало не ранее определенной даты).

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

Главные типы операций:

– с фиксированной продолжительностью,

- с фиксированным размером (продолжительность – личное от деления размера на суммарную продуктивность назначенных ресурсов),

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

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

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

Ресурсы проекта

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

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

К главным чертам возобновляемых ресурсов относятся:

полное количество,

цена часа работы (по элементам цены),

- потребление материалов за час работы,

- календари работы ресурсов,

- принадлежность к подразделению Иерархической Структуры Ресурсов.

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

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

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

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

Среди систем управления строительными проектами ведущими в настоящее время являются Primavera, Spider Project и MS Project.

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

Spider Project - интегрированная система управления проектами, спроектированная и разработанная с учётом большого практического опыта, потребностей, особенностей и приоритетов Российского рынка. Уникальные функциональные возможности пакета обрадуют профессионалов, а лёгкость использования и обучения приятно удивит новичков.

К особенностям пакета Spider Project, выгодно отличающим его от западных аналогов, относятся:

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

Вы получите полный контроль над строительным объектом:

  1. Контроль сроков выполнения работ
  2. Контроль бюджета
  3. Контроль всех ресурсов
  4. Контроль финансирования
  5. Контроль выполнения
  6. Оптимальное управление ресурсами Вашей строительной компании

Предлагаем Вам следующие услуги:

  1. Календарно-сетевое планирование в системе Spider Project
  2. Управленческий учет выполнения работ на объекте
  3. Мобильный ПТО (исполнительная документация, лаборатория, проектирование и т.д.)
  4. Внедрение системы управления проектом Spider Project (планирование, учет, контроль)
  5. Обучение Ваших сотрудников и сопровождение проекта в системе Spider Project.

 

Позвоните нам, мы приедем и покажем Вам возможности системы Spider Project и Вы оцените пользу от внедрения этого программного продукта на Вашем предприятии.

Мы профессионально занимаемся управлением строительными проектами уже более 7 лет. 

 

ОПРЕДЕЛЕНИЕ КОНТРАКТНЫХ СРОКОВ ПРОИЗВОДСТВА СТРОИТЕЛЬНО-МОНТАЖНЫХ РАБОТ С ПРИМЕНЕНИЕМ ПАКЕТА УПРАВЛЕНИЯ ПРОЕКТАМИ Spider Project

 

Оксана Сахрауи, Технологии управления Спайдер

  

ВВЕДЕНИЕ

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

В настоящем докладе описывается методология и опыт использования пакета управления проектами Spider Project для расчета плановых и контрактных сроков строительства с учетом рисков.

МОДЕЛИРОВАНИЕ И АНАЛИЗ РИСКОВ

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

Идентификация и оценка рисков иногда рассматривается как единый процесс, называемый анализом рисков.

Идентификация рисков касается как внешних, так и внутренних рисков. Внешние риски - это риски, не зависящие от проекта (изменения рынка, действия правительства, природные катаклизмы). Внутренние риски - это те, на которые команда управления проектами способна оказывать влияние.

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

К внутренним рискам, как правило, относится неточности определения следующих исходных параметров планирования:

  1. Длительности операций;
  2. Объемы работ;
  3. Производительности ресурсов;
  4. Количество используемых ресурсов
  5. Вынужденные простои оборудования;
  6. Неблагоприятные погодные условия;
  7. Сроки поставок материалов;
  8. Нарушения качества выполненных работ.

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

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

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

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

При строительстве жилого дома по улице Крылатские Холмы, дом 15 возникла необходимость в пересмотре контрактных сроков производства монолитных работ. Для оптимизации графика производства работ и убедительной (для Инвестора и Заказчика) корректировке контрактных сроков был выполнен анализ сроков строительства с учетом имеющихся ресурсов, технологических ограничений и возможных рисков с применением пакета управления проектами Spider Project.

Планирование и анализ сроков строительства был выполнен Руководством стройки и Информационным центром ЗАО “Монолит СМ” с привлечением экспертов Московского отделения Института Управления Проектами (Project Management Institute).

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

Методология И ИСХОДНАЯ ИНФОРМАЦИЯ ДЛЯ моделирования

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

Каждый из этажей был разбит на три зоны производства работ, каждая из которых обслуживалась отдельным краном. Согласно принятой технологии производства работ в каждой из зон работала своя бригада строителей. Это позволило организовать работы оптимальным с точки зрения скорости строительства образом (равномерно распределить места проведения строительных работ, организовать соревнование между строителями, объективно контролировать отклонение хода выполнения работ от запланированного). Каждая из зон состояла из трех технологических захваток, в которых основные виды монолитных работ (армирование, установка опалубки, бетонирование, прогрев, снятие опалубки) выполнялись последовательно.

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

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

Моделирование строительных работ, составление графика и определение необходимого состава ресурсов осуществлялось с помощью пакета управления проектами Spider Project.

Моделирование рисков базировалось на следующей исходной информации:

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

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

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

В результате произведенных расчетов было получено, что «сверхоптимистический» срок завершения строительства - 6 июля 1998 года. Завершение работ до указанного срока автоматически означало, что работы были выполнены с серьезными нарушениями технологии, а значит и качества строительства.

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

Наименование

Последствия

Кол-во

Длительность

(смен)

Подготовка оборудования

Простой

1/2/3

2/3/4

Отказ крана

Простой

1/2/4

2/3/4

Отказ бетононасоса

Простой бетонирования

1/2/3

2/3/4

Непоставка бетона

Простой бетонирования

1/2/4

1/1 (дней)

Отключение электроэнергии

Простой

0/3/6

0.5/1/1

Морозные дни - январь

Задержка снятия опалубки

1/3/6

3

Морозные дни - февраль

Задержка снятия опалубки

1/2/4

3

Морозные дни - март

Задержка снятия опалубки

1/2/4

3

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

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

           

Наименование

Последствия

Кол-во

Длительность

(смен)

Подготовка оборудования

Простой

1/2/3

1/1.5/2

Отказ крана

Простой

1/2/4

2/3/4

Непоставка бетона

Простой бетонирования

1/2/4

1/1 (дней)

Отключение электроэнергии

Простой

0/3/5

0.5/1/1

Морозные дни - январь

Задержка снятия опалубки

1/3/6

3

Морозные дни - февраль

Задержка снятия опалубки

1/2/4

3

Морозные дни - март

Задержка снятия опалубки

1/2/4

3

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

По реальной оценке число ежемесячных вынужденных простоев - 12 смен при 2 днях простоя бетонных работ и 7 морозных днях.

По пессимистической оценке число ежемесячных вынужденных простоев - 25 смен при 4 днях непоставки бетона и 14 морозных днях.

АНАЛИЗ РЕЗУЛЬТАТОВ моделирования

В результате анализа вышеприведенной информации был получен ожидаемый (наиболее вероятный) сценарий выполнения строительных работ, по которому ежемесячно простои составят 12.75 смены при 2 днях простоя бетонных работ и 7.5 морозных днях. В соответствии с этими расчетами монолитные работы должны были быть законченными 3 августа 1998г.

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

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

Сценарий

Срок завершения работ

Сверхоптимистический

6 июля

Оптимистический

17 июля

Плановый

31 июля

Пессимистический

24 августа

Ожидаемый

3 августа 1998г.

На следующем рисунке представлено распределение вероятности срока завершения работ.

Из диаграммы распределения вероятностей срока завершения монолитных работ видно, что ожидаемому (базовому) графику соответствует 50%-я вероятность завершения строительства в срок. Заключение контракта с этим сроком - рискованное предприятие. Для обеспечения по крайней мере 75% вероятности своевременного завершения проекта рекомендуется в качестве контрактного срока завершения работ - 10 августа 1998г.

Монолитные работы не могут быть завершены до 6 июля 1998 года без нарушения технологии строительства и требований к качеству работ. Реально даже при неограниченных ресурсах строителей (людях, механизмах, опалубке и т.д.) срок завершения работ лежит между 17 июля и 24 августа.

Ожидаемый (наиболее вероятный) срок завершения работ с учетом проектных рисков - 3 августа 1998 года, который и следует принять в качестве планового, но не контрактного. Для обеспечения надежности выполнения контракта необходимо обеспечить резерв. Для данного проекта резерв составляет 7 дней, если ориентироваться на 75% надежность выполнения контракта в срок. Опоздание к этому сроку может быть вызвано неблагоприятными внешними факторами. Завершение работ позднее пессимистического срока может означать либо недостаток ресурсов у строителей, либо плохое управление работами.

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

С января  по июнь 1998 года выполнение работ шло в полном соответствии с составленным графиком, но затем Заказчик по определенным причинам приостановил финансирование данного объекта (что явилось фактором внешнего риска) и сроки завершения строительства были сорваны.

 

ВЫВОДЫ и рекомендации

 

Описанная технология моделирования рисков рассчитана на применение программного пакета управления проектами Spider Project. Принятая в Западных пакетах технология моделирования рисков базируется лишь на экспертных оценках длительностей операций, что не позволяет охватить полный спектр рисковых событий строительного проекта.

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

 

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

Компания "Сити Старс" имеет большой опыт обучения специалистов строительных компаний системе управления проектом Spider Project.

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

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

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

Мы готовы скорректировать программу обучения применительно к специфике Вашей компании.

По окончанию обучения Ваши сотрудники получат Сертификат о прохождении курса Spider Project.

Программа курса «Стандарт»

 1-й день

Введение

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

Создание модели проекта

  • Иерархическая структура работ
  • Операции проекта и их характеристики
  • Взаимосвязи операций
  • Стоимостные составляющие, центры стоимостей
  • Ресурсы, мультиресурсы, роли
  • Материалы проекта
  • Назначения стоимостей, ресурсов, материалов
  • Составление расписания без учета ресурсных ограничений

 2-й день…        

Типовые фрагменты.

  • Формирование модели проекта из типовых фрагментов

Расчёт расписания и затрат

  • Расчёт расписания проекта с выравниванием ресурсов.
  • Анализ расписания и методы корректировки графика.
  • Диаграммы затрат.
  • Диаграммы загрузки ресурсов, индикатор перегрузки ресурсов.

Версии проекта

  • Создание и сравнение версий проекта
  • Анализ "Что если"
  • Базовый план

Корпоративные справочники

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

 3-й день…                    

Учёт исполнения проекта

  • Ввод фактического исполнения в проект
  • Архив исполнения
  • Сравнение версий проекта
  • Анализ отклонений и создание сигналов
  • Анализ трендов
  • Анализ освоенных объемов

Отчёты

  • Подготовка отчетов
  • Шаблоны отчетов
  • Отчеты за период
  • Срез проекта

Печать

  • Печать диаграмм
  • Печать отчетов
  • Шаблоны печати

Портфель проектов

  • Создание мультипроекта и портфеля проектов 

Программа курса «Профессионал»

 

1-й день…         

Анализ модели проекта

Создание и использование справочников

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

Моделирование и анализ рисков

  • Метод трех сценариев
  • Тренды вероятности успеха

2-й день…         

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

  • Ресурсы и материалы

o          Моделирование сменной работы

o          Производство ресурсов

o          Сверхурочные

o          Переменная загрузка

o          Центры ресурсов

o          Центры материалов, комплекты материалов

o          Моделирование поставок

Стоимости

  • Периоды стоимостей
  • Показатели экономической эффективности проекта
  • Финансирование проекта
  • Расчет расписания с учетом ограничений по финансированию и поставкам

Групповая работа

  • Права доступа
  • Структура ответственности
  • Рассылка и сборка подпроектов
  • Работа с портфелем проектов

Дополнительные возможности системы

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

стоимость

БАЗОВЫЙ КУРС СТАНДАРТ  

Длительность – 3 дня,

Стоимость участия 1 человека – 15 000 руб,

Стоимость корпоративного курса – 100 000 руб.

КУРС ПРОФЕССИОНАЛ

Длительность – 2 дня,

Cтоимость участия 1 человека – 10 000 руб,

Cтоимость корпоративного курса – 80 000 руб.

ОБЩИЕ УСЛОВИЯ ОБУЧЕНИЯ

Курсы проводятся в Москве на территории компании-заказчика.

Максимальное количество обучаемых в группе – 8 человек.

Курсы проходят с перерывами на кофе-брейки и обед.

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

Все обучаемые должны быть обеспечены компьютерами (стационарными, ноутбуками) с ОС Windows и установленной демо-версией программы Spider Project.

ПРИМЕЧАНИЕ. При проведении корпоративного курса не в Москве заказчик оплачивает командировочные расходы преподавателя.

 

 

Корпорация "Сити Старс" обладает достаточным опытом в сопровождении строительных и девлоперских проектов в системе управления проектом Spider Project.

Предлагаем Вам воспользоваться нашими знаниями при управлении Вашими строительными проектами.

Мы разаработаем для Вас финасново-производственную модель в системе Spider Project, со стоимостями, ресурсами, сроками.

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

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

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

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

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

Результатом сопровождения Ваших проектов в системе Spider Project будет:

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

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

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

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

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

Вы задаете вопрос о бюджете, но и на этот вопрос не получаете исчерпывающий ответ. А почему такой бюджет? А по той же самой причине, иди и работай! И вам деваться не куда. Вы идете на рабочее место и начинаете что-то делать.

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

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

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

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

PM Book – свод правил по управлению проектами, в общем Запад живет по этой книжке, проекты управляются успешно.

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

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

Нам нужно будет с вами ответить на три основных вопроса. Первый вопрос: что такое проект. До тех пор пока мы не ответим на вопрос, что такое проект. Мы будем не адекватно использовать инструменты, будем получать не качественный результат.

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

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

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

Мы с вами последовательно пройдемся по всем основным процессом. Как стартовать проект как его спланировать. Как организовать его исполнение как проконтролировать исполнение.

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

Другие описывают, что в компании с проектами делается плохо. Так вот, этот список гораздо длиннее, пишут методологию, 15 кг методологии ложится на стол генеральному. Тот счастлив! Вот оно счастье то! Ходит и смотрит.

Понимает, что это же Гениально! Появился инструмент с помощью которого можно управлять проектами, но все это превращается в бюрократию и не работает.

Второй вариант, - есть такая программа под названием Microsoft Project. Программа управления проектами отличная. Установили, смотрят, на экране иконка Microsoft Project. Кликнули, открылась! Так, открыла секундочка. Всё замечательно. Написал, работа появилась, колбаса какая то, я тут в Экселе мучился, а здесь все сделано!

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

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

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

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

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

Технология Спайдер планирования проектов

Либерзон В.И., Ефремов К.Н., Бодунков П.В.

«Технологии управления Спайдер»

Введение

Технология планирования проектов, принятая в России и реализованная в программе управления проектами Спайдер Проджект, отличается от технологии, описанной в A Guide Line to the Project Management Body of Knowledge – американских стандартах управления проектами. Американцы в своих подходах ограничиваются укрупненным планированием, когда исходной информацией о работах проекта является их длительность. В нашем подходе, наряду с длительностью, исходной информацией для расчета расписания исполнения проекта могут быть объемы работ и производительности назначенных ресурсов. Такой подход позволяет унифицировать систему планирования в фирме, использующей пакет Спайдер Проджект для управления проектами, разработать базы данных, резко сокращающие трудоемкость планирования. В нашей технологии планирования проектов мы отказались от надуманных ограничений (одна иерархическая структура работ проекта) и расширили возможности анализа проектов на стадии планирования (использование пулов взаимозаменяемых ресурсов, моделирование поставок и финансирования).

Последовательному описанию процесса планирования проекта с помощью пакета Спайдер Проджект посвящена данная работа.

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

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

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

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

ИСР по процессам на верхнем уровне использует процессы, а на более низких – объекты проекта.

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

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

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

  1. Перечень операций и типовых фрагментов проекта

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

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

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

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

  1. Объемы либо длительности операций и фрагментов.

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

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

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

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

  1. Взаимосвязи операций

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

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

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

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

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

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

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

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

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

 

  1. Календари и временные ограничения операций, ресурсов и связей

На сроки исполнения операций оказывают влияние и календари операций, связей и ресурсов.

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

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

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

  1. Потребности операций проекта в затратах и материалах

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

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

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

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

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

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

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

  1. Организационная структура ресурсов

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

  1. Перечень и количество ресурсов и материалов проекта

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

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

  1. Взаимозаменяемые ресурсы (пулы) и мультиресурсы

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

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

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

  1. Производительности ресурсов на типовых назначениях

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

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

  1. Процентная загрузка ресурсов на типовых назначениях

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

  1. Назначения ресурсов

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

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

  1. Потребности назначений проекта в затратах и материалах

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

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

  1. Расписание проекта

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

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

  1. Бюджет и потребность проекта в материалах

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

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

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

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

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

  1. Планирование финансирования

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

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

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

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

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

  1. Итерации

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

Обычными средствами менеджера для достижения удовлетворительного расписания являются:

  • Ресурсы проекта. Можно изменить исходное количество ресурсов проекта или изменить их состав,
  • Назначения ресурсов. Спайдер Проджект отображает ресурсно-критический путь – те операции проекта, задержка завершения которых приводит к задержке завершения проекта в целом при данном составе ресурсов. Изменяя состав и количество ресурсов, назначенных на исполнение ресурсно-критических операций, можно сократить длительность проекта.
  • Взаимосвязи работ. Для сокращения длительности проекта полезно проанализировать взаимосвязи критических работ. Иногда возможно вместо последовательного исполнения работ допустить их параллельное исполнение, хотя и с некоторым сдвигом во времени.
  • График поставок. Расписание исполнения проекта рассчитывается с учетом графиков поставок материалов. Если анализ показал, что какие-либо операции задерживаются из-за отсутствия материалов, можно пересмотреть график поставок.
  • График финансирования. Это же относится и к графику финансирования проекта.

       20. Заключение

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

Свод знаний по управлению проектами (PMBoK)

Свод знаний по управлению проектами (PMBoK)

Обзор PMBoK

A Guide to the Project Management Body of Knowledge (Руководство к своду знаний по управлению проектами, далее PMBoK) - представляет собой совокупность профессиональных знаний по управлению проектами, признанных в качестве стандарта. Стандарт – это официальный документ, в котором описываются установленные нормы, методы, процессы и практики. Как и в других профессиональных областях, таких как юриспруденция, медицина, бухгалтерский учет, свод знаний опирается на передовой опыт специалистов-практиков интернациональных компаний и крупных организаций США в управлении проектами, которые внесли вклад в разработку данного стандарта.

Руководство PMBoK знакомит с ключевыми понятиями и терминами в области управления проектами, определяет 10 областей знаний проектного управления, жизненный цикл проекта, группы процессов и процессы (в том числе входы, выходы и активности в рамках конкретного процесса), определяются внешние и внутренние организационные факторы, окружающие проект или оказывающие влияние на его успех, методы и методики, применяемые в рамках отдельных областей знаний по управлению проектами. Является основным стандартом по управлению проектами в США и некоторых других странах (в России, Украине и Белоруссии данный стандарт носит рекомендательный характер).

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

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

Институт управления проектами (Project Management Institute, PMI) использует данный стандарт в качестве основного справочного материала по управлению проектами для своих программ профессионального развития и сертификации.

Скачать PMBoK нельзя и данный стандарт распространяется только на платной основе.

История PMBoK

Первое издание PMBoK, было выпущено Институтом управления проектами (PMI - Project Management Institute) еще в 1986 году. Это была революционная методология, которую изначально ориентировали на помощь членам института в рамках подготовки к экзамену PMP (Project Management Professional), а так же данная методология по управлению проектами должна была оказать влияние на подход к управлению проектами в будущем. Методология получила название "A guide to the Project Management Body of Knowledge" или "PMBoK". Уже в 1991 году методологию PMBoK Guide признают национальным стандартом ANSI (American National Standards Institute). Первую редакцию такого стандарта по управлению проектами опубликовали в 1994 году. Через два года была выпущена вторая редакция PMBoK, это произошло из-за быстрого роста членов PMI. В скором будущем появилась третья редакция и называлась она - PMBoK Guide 2000. В 2004 году PMI выпускает своё очередное творение - PMBoK Guide Third Edition, которое получило самое большое распространение свода знаний по управлению проектами PMI. 31 декабря в 2008 году вышла в свет новая версия методологии - PMBoK Fourth Edition, которая, как и свой предшественник претерпела значительные изменения и стала по сути таким же революционным изданием. В этой версии были изменены сами методики PMI. В стандарт включили дополнительные методики: ведения аналитических работ, прототипирование, итеративность и применение систем искусственного интеллекта с целью построения прогноза реализации и завершения проекта в части сроков и бюджета. В настоящее время выпущена еще одна версия - PMBoK Guide Fifth Edition, которая включает в себя уже 10 областей знаний и 5 дополнительных процессов (количество процессов всегда менялось от версии к версии, но вот дополнительная область знаний по управлению проектами, добавили впервые). Перечень поколений PMBoK представлены на Рисунке 1. 

Рисунок 1. Поколения PMBoK.

Дополнительная область знания - Управление заинтересованными лицами (разделили область знаний Communication Management на две: Communication Management и Stakeholders Management). Дополнительные процессы следующие - Plan Scope Management, Plan Schedule Management, Plan Cost Management, Plan Stakeholder Management, а также Control Stakeholder Engagement. Обновление программ сертификации произойдет с 1 июля 2013 года. Дата выпуска PMBoK Guide Six Edition еще не известна, но PMI уже определились с годом - 2017 год.

Описание методологии PMBoK

Области знаний PMBoK:

Руководство PMBoK описывает десять областей знаний, которыми должен обладать руководитель проекта (он же Project Manager). В стандарте рассматривается каждая область знаний в отдельности, описываются её процессы входов и выходов. Процессы областей знаний представлены в PMBoK в виде дискретных элементов, которые имеют четко определенные границы. Правда на практике эти процессы являются итеративными - могут взаимодействовать между собой и накладываться друг на друга. Такие наложения и взаимодействия не описываются в своде знаний по управлению проектами (PMBoK). И так, данный стандарт рассматривает следующие области знаний по управлению проектами:

  • Управление интеграцией проекта (Project Integration Management). Под интеграцией понимается объединение, консолидация, сочленение и разнообразные интегративные действия, направленные на успешное управление ожиданиями заинтересованных сторон и выполнения определенных требований. В данном разделе описывается распределение ресурсов по проекту, процессы поиска компромиссов, между конфликтующими целями и альтернативами, а также определяются интегральные связи между остальными областями знаний. В частности даётся схема процессов разработки Устава проекта, Плана управления проектами, Руководства управлением исполнения проекта, Мониторинга и управления работами проекта, описываются процессы общего управления изменениями проекта и завершения проекта или фазы проекта.
  • Управление содержанием проекта (Project Scope Management). Под управлением содержанием понимаются процессы, позволяющие производить выборку, фильтрацию и группировку по проекту тех и только тех работ, которые понадобятся Руководителю проекта для успешного завершения проекта. Управление содержанием проекта напрямую связано с определением и контролем того (содержания), что будет включено и что не будет включено в проект. Описываются схемы процессов Сбора требований, Определения содержания проекта, создания Иерархической структуры работ - ИСР (Work Breakdown Structure, WBS), Подтверждения содержания и Управления содержанием.
  • Управление сроками проекта (Project Time Management). Под управлением сроками проекта или точнее говоря временем т.к. время, более широкое понятие, понимаются процессы, посредством которых обеспечивается своевременное завершение проекта. Схема данных процессов подразумевает: Определение операций, Определение последовательности операций, Оценка ресурсов операций, Оценка длительности операций, Разработка расписания и Управление расписанием.
  • Управление стоимостью проекта (Project Cost Management). Под управлением стоимостью проекта понимаются процессы, в части планирования и разработки бюджета, а также управления расходами, которые обеспечивают завершение проекта в рамках утвержденного бюджета. Общая блок-схема процессов включает в себя: Оценку стоимости, Определения бюджета и Управление стоимостью.
  • Управление качеством проекта (Project Quality Management). Под управлением качеством проекта подразумеваются процессы и различные действия со стороны исполняющей организации, подходы и политики в области качества, цели, задачи и зоны ответственности в области качества следующим образом - проект должен удовлетворять тем потребностям, ради которых он был инициирован. Само управление качеством проекта производится с помощью системы управления качеством, которая предусматривает набор определенных правил и процедур, в том числе и действия по постоянному совершенствованию процессов. Лучшей практикой считается, когда данные действия проводятся на всем протяжении проекта. Схема процессов управления качеством включает в себя: Планирование качества, Обеспечение качества и Контроль качества.
  • Управление человеческими ресурсами проекта (Project Human Resource Management). Процессы управления человеческими ресурсами организации, включают в себя подходы к управлению и руководством команды проекта. Под командой проекта подразумевается пул квалифицированных работников для которых определены конкретные роли и ответственности за выполнение проекта. В ходе реализации проекта профессиональный и количественный состав команды проекта зачастую может меняться. Правильное распределение ролей по проекту и ответственности между членами команды проекта даёт возможность всем членам команды быть задействованными на этапе планирования проекта и принятия решений. В случае привлечение членов команды к проекту на ранних стадиях даёт возможность применять имеющийся у них опыт уже на этапе планирования проекта, позволяет укрепить нацеленность команды проекта на достижение определенных результатов. Схема процессов управления человеческими ресурсами включает в себя: Разработку плана управления человеческими ресурсами, Набор команды проекта, Развитие команды проекта и Управление командой проекта.
  • Управление коммуникациями проекта (Project Communications Management). Процессы управления коммуникациями, применяют с целью обеспечения своевременного формирования, подготовки, распространения, архивации, передачи, получения, использования информации на проекте. Наибольшая часть времени на проекте, у Руководителей проектов уходит на осуществление коммуникаций с членами команды и с другими заинтересованными сторонами проекта (внутренние, от обычных сотрудников до высшего руководства или внешние). Эффективность коммуникации заключается в том, что они служат связующим звеном между различными заинтересованными сторонами, вовлеченными в конкретный проект. Правильное управление коммуникациями заключается в объединении разнообразных культурных и организационных особенностей, консолидации накопленного опыта, сопоставления различных взглядов и интересов с целью выстраивания базовой структуры управления проектом. Схема  процессов управления коммуникациями проекта включает в себя: Определение заинтересованных сторон проекта, Планирование коммуникаций, Распространение информации, Управление ожиданиями заинтересованных сторон проекта (начиная с пятой версии - PMBoK Fifth Edition, данные процессы вынесли в отдельную область знаний - Управление заинтересованными сторонами проекта Project Stakeholder Management), Отчеты об исполнении.
  • Управление рисками проекта (Project Risk Management). Под процессами управления рисками проекта понимается планирование управления рисками, идентификация и анализ рисков, выработке методов реагирования на риски, контроль, мониторинг и управление рисками в ходе реализации проекта. Посредством процессов управления рисками проекта, Руководители проектов добиваются повышения вероятности возникновения и воздействия (влияния) благоприятных рисков (событий) на проект и снижают вероятность возникновения и воздействия (влияния) неблагоприятных рисков (событий) на проект в момент исполнения этого проекта. Схема процессов управления рисками проекта включает в себя: Планирование управления рисками, Идентификация рисков, Качественный анализ рисков, Количественный анализ рисков, Планирование реагирования на известные риски, Мониторинг и управление рисками.
  • Управление поставками проекта (Project Procurement Management). Процессы управления поставками проекта включают в себя покупку или приобретение тех или иных необходимых сущностей (продукты, услуги, результаты, документы), которые производятся внешними (подрядными) организациями по отношению к той, в которой реализуется проект. Сама организация, в которой выполняется проект может выступать в качестве покупателя или продавца этих сущностей. Также процессы управления поставками проекта включают в себя подпроцессы управления контрактами и изменениями, необходимые для разработки и сопровождения контрактов или заказов на покупку. Благодаря процессам управления поставками проекта появляется возможность администрировать все контракты на приобретение чего-либо в ходе реализации проекта и управлять контрактными обязательствами, которые были возложены на команду проекта. Схема процессов управления поставками проекта включает в себя: Планирование закупок, Осуществление закупок, Управление закупочной деятельностью, Закрытие закупок.
  • Управление заинтересованными сторонами проекта (Project Stakeholder Management). Под процессами управления ожиданиями заинтересованными сторонами проекта понимается как таковое общение между командой проекта и заинтересованными лицами, а также работы направленные на  удовлетворение их потребностей и решение возникающих проблем, которые могут повлечь за собой изменения на проекте. Благодаря правильному выстраиванию отношений между всеми заинтересованными сторонами на проекте, Руководитель проекта может увеличить вероятность успеха.

Группы процессов PMBoK:

Все процессы в руководстве PMBoK разделяются на следующие группы:

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

  • Разработка Устава проекта (Develop Project Charter)
  • Определение заинтересованных сторон (Identity Stakeholders)

2. Группа процессов планирования
Определяет и уточняет цели и планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект. В группу процессов планирования входят следующие процессы:

  • Разработка плана управления проектом (Develop Project Management Plan)
  • План управления содержанием (Plan Scope Management)
  • Сбор требований (Collect Requirements)
  • Определение содержания (Define Scope)
  • Создание иерархической структуры работ - ИСР (Create Work Breakdown Structure - WBS)
  • Разработка плана управления расписанием (Develop Schedule Management Plan)
  • Определение операций (Define Activities)
  • Определение последовательности операций (Sequence Activities)
  • Оценка ресурсов операций (Estimate Activity Resources)
  • Оценка длительности операций (Estimate Activity Durations)
  • Разработка расписания (Develop Schedule)
  • Разраотка плана управления стоимостью (Develop Cost Management Plan)
  • Оценка стоимости (Estimate Costs)
  • Определение бюджета (Determine Budget)
  • Планирование качества (Plan Quality)
  • Разработка плана управления человеческими ресурсами (Develop Human Resource Plan)
  • Планирование коммуникаций (Plan Communications)
  • Планирование управления рисками (Plan Risk Management)
  • Идентификация рисков (Identify Risks)
  • Качественный анализ рисков (Perform Qualitative Risk Analysis)
  • Количественный анализ рисков (Perform Quantitative Risk Analysis)
  • Планирование реагирования на риски (Plan Risk Responses)
  • Планирование закупок (Plan Procurements)
  • Разработка плана управления заинтересованными сторонами (Develop Stakeholder Management Plan)

3. Группа процессов исполнения
Объединяет человеческие и другие ресурсы для выполнения плана управления проектом данного проекта. В группу процессов исполнения входят следующие процессы:

  • Руководство и управление исполнением проекта (Direct and Manage Project Execution)
  • Обеспечение качества (Perform Quality Assurance)
  • Набор команды проекта (Acquire Project Team)
  • Развитие команды проекта (Develop Project Team)
  • Управление командой проекта (Manage Project Team)
  • Управление коммуникациями (Manage Communications)
  • Осуществление закупок (Conduct Procurements)
  • Управление вовлеченностью заинтересованных сторон (Manage Stakeholder Engagement)

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

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

  • Мониторинг и управление работами проекта (Monitor and Control Project Work)
  • Общее управление изменениями\Общий контроль изменений (Perform Integrated Change Control)
  • Подтверждение содержания (Validate Scope)
  • Контроль содержания\Управление содержанием (Control Scope)
  • Контроль расписания\Управление расписанием (Control Schedule)
  • Контроль стоимости\Управление стоимостью (Control Costs)
  • Процесс контроля качества (Perform Quality Control)
  • Мониторинг и контроль коммуникаций (Monitor and Control Communications)
  • Мониторинг и контроль рисков (Monitor and Control Risks)
  • Контроль закупок\контрактов (Control Procurement)
  • Контроль вовлеченности заинтересованных сторон (Control Stakeholder Engagement)

5. Группа завершающих процессов

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

  • Закрытие проекта или фазы (Close Project or Phase)
  • Закрытие контрактов (Close Procurement)

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

Рисунок 2. Группы процессов по PMBoK.

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

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

Жизненный цикл по PMBoK

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

Рисунок 4. Жизненный цикл проекта.

Инструменты и методы PMBoK

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

Методы PMBoK:

  • Анализ дерева решений (Decision Tree Analysis).
  • Анализ допущений (Assumptions Analysis).
  • Анализ ожидаемого денежного значения (Expected Monetary Value (EMV) Analysis).
  • Анализ отклонений (Variance Analysis).
  • Анализ сети (Schedule Network Analysis или Network Analysis).
  • Анализ сильных и слабых сторон, возможностей и угроз (Strengths, Weaknesses, Opportunities, and Threats Analysis, или SWOT Analysis).
  • Анализ характера и последствий отказов (Failure Mode and Effect Analysis, FMEA).
  • Aнализ чувствительности (Sensitivity Analysis).
  • Быстрый проход (Fast Tracking).
  • Выравнивание ресурсов (Resource Leveling).
  • Декомпозиция (Decomposition).
  • Метод «операции в узлах» (метод диаграмм предшествования) (Precedence Diagramming Method, PDM).
  • Метод Дельфи (дельфийский метод) (Delphi Technique).
  • Метод критического пути (Critical Path Methodology, CPM).
  • Метод критической цепи (Critical Chain Method).
  • Метод Монте-Карло (Monte Carlo Analysis).
  • Метод освоенного объема (Earned Value Technique, EVT).
  • Метод оценки и анализа программ (Program Evaluation and Review Technique, PERT).
  • Мозговой штурм (Brainstorming).
  • Оценка «снизу вверх» (Bottom-up Estimating).
  • Планирование методом набегающей волны (Rolling Wave Planning).
  • Управление освоенным объемом (Earned Value Management, EVM).

Инструменты PMBoK:

  • Диаграмма Ганта (Gantt Chart).
  • Диаграмма Парето (Pareto Chart).
  • Иерархическая структура рисков (Risk Breakdown Structure, RBS).
  • Информационная система управления проектами (Project Management Information System, PMIS).
  • Матрица вероятности и воздействия (Probability and Impact Matrix).
  • Матрица ответственности (Responsibility Assignment Matrix, RAM).
  • Расписание контрольных событий (Milestone Schedule).
  • Сетевая модель (Schedule Model).
  • Система санкционирования выполнения работ (Work Authorization System).
  • Система управления изменениями (Change Control System).
  • Система управления конфигурацией (Configuration Management System).

Экзамены, сертификация и обучение

На данный момент в мире насчитывается более 470 000 менеджеров и специалистов по управлению проектами, имеющих сертификацию PMP – Project Management Professional. Степень по управлению проектами PMP, может получить каждый специалист из любой отрасли. PMP позволяет войти в ряды самого большого и престижного сообщества специалистов по управлению проектами. Для получения степени PMP,  необходимо соответствовать определенным требованиям к образованию и опыту работы. Также необходимо пройти экзамен в виде теста на компьютере в специализированных аккредитованных центрах по всему миру (Registered Education Provider). Данный тест разработан для объективной оценки компетенций претендента в части управления проектами.

Требования к кандидату:

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

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

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

Посредством теста на степень PMP оцениваются применение знаний и навыков, использование инструментов и методов применяемых на практике при управлении проектами. Еще в 1997 году были разработаны требования к экзамену. Претенденту необходимо выбрать один правильный ответ из 4 вариантов по каждому из 200 вопросов. Сам тест состоит из 175 вопросов, остальные 25 вопросов определяются, как претестовые и в зачет не идут. Все вопросы в тесте разрабатываются комиссией, состоящей из специалистов со степенью PMP. Вопросы входящие в тест, ежегодно проверяются на соответствие экзаменационным требованиям. Для успешного прохождения теста, претенденту, за 4 часа, необходимо положительно ответить на 106 вопросов из 175. Получается, что проходной балл по экзамену составляет 61%.

Подготовка к экзамену PMP:

Из множества учебников и материалов для подготовки к экзамену на степень PMP, основным конечно же является сам свод знаний по управлению проектами - PMBoK Guide. Данный стандарт на двух языках (английский и русский) и множество дополнительных материалов (книг и учебников) по управлению проектами можно приобрести в специализированных on-line магазинах PMI. Но получение сертификата PMP не заключается в одной лишь теории, кандидату необходимо будет применить свой опыт т.к. большинство вопросов в тесте основаны на ситуациях. Для участия в экзамене не требуется в обязательном порядке проходить специализированные курсы PMI, хотя список сертифицированных провайдеров всегда можно найти на сайте PMI.

Дополнительно можно выделить труд Риты Мулкахи (Rita Mulcahy) - PMP Exam Prep (Rita's Course in a Book for Passing the PMP Exam), целью которого является подготовить читателя к экзамену PMP (Project Management Professional). Даннвая книга не переписывает PMBoK, как это случается зачастую с остальными материалами по подготовке к экзамену, а даёт понимание того, как будет проходить сертификация, какие будут вопросы т.е. является прикладной (Рисунок 5).

Рисунок 5. PMP Exam Prep (Rita's Course in a Book for Passing the PMP Exam)

Содержание экзамена PMP:

Далее в процентном соотношении представлена разбивка вопросов экзамена по группам процессов:

  • Инициация проекта (Project Initiating) – 13 % вопросов
  • Планирование проекта (Project Planning) – 24 % вопросов
  • Исполнение проекта (Project Executing) - 30 % вопросов
  • Контроль проекта (Project Control) – 25 % вопросов
  • Завершение проекта (Project Closing) – 8 % вопросов

В свое время, PMI провело исследование по описанию ролей (The Role Delineation Study), которое в последствии легло в основу Кодекса Профессиональной Этики (PMP Examination Specification). Данное исследование описывает экзаменационные вопросы, и как следствие служит отличным материалом для подготовки к экзамену.

Дополнительно:

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

Основные стандарты (Foundational Standards):

Практические стандарты PMI и фреймворки (Practice Standards & Frameworks):

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

Лексикон (основные термины):

Организация: Project Management Institute
Сайт организацииhttp://www.pmi.com
Страны: США, Россия, Литва, Финляндия, Норвегия, Дания, Швеция, Китай, ЮАР.