Методы составления расписания проекта. Контрольные события проекта

Диаграмма контрольных событий - Набор инструментов для управления проектами - Драган Милошевич - rutlib2.com

Диаграмма контрольных событий

Что такое диаграмма контрольных событий?

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

Построение диаграммы контрольных событий

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

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

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

•области ответственности;

•система управления расписанием;

•расписание проекта, возможно с показом взаимозависимостей.

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

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

КТО ВЛАДЕЕТ РАСПИСАНИЯМИ?

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

Члены команды обычно владеют пакетами работ / задачами, отчитываются об их выполнении и оценивают, сколько еще времени необходимо, чтобы завершить незаконченные пакет работ или задачу. Хотя они должны понимать значение некоторых терминов, используемых в календарном планировании (дата старта, дата финиша, отчетная дата, доступность ресурса и т. д.), обширных знаний в области теории календарного планирования не требуется. Являясь поставщиками ресурсов, функциональные руководители заботятся о точности оценок и доступности ресурсов, когда проекты испытывают нужду в них [6]. Подобно членам команды проекта, они обладают лишь базовыми теоретическими знаниями.

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

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

Рис. 6.3.Пример диаграммы контрольных событий

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

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

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

УПРАВЛЕНЧЕСКАЯ ДИАГРАММА КОНТРОЛЬНЫХ СОБЫТИЙ

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

СОВЕТЫ ПО ДИАГРАММАМ КОНТРОЛЬНЫХ СОБЫТИЙ

• Не скучивайте контрольные события, разносите их во времени;

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

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

• задействуйте диаграмму в сочетании с другим расписанием, показывающим взаимозависимости между операциями;

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

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

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

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

Использование диаграммы контрольных событий

Когда использовать.Традиционно диаграмма контрольных событий служит для того, чтобы обратить внимание руководства на особо важные события, вне зависимости от размера проекта [12]. Как следствие, на диаграмму обычно помещают небольшое число ключевых контрольных событий. Иными словами, диаграмма контрольных событий удобна для представления основных данных о плановом и фактическом ходе продвижения проекта высшему руководству. Если в проекте используется СДР, эти события особой важности и ключевые данные обычно относятся к уровню 1 СДР. Недавние исследования показали, что несколько диаграмм контрольных событий часто применяются одновременно, причем каждая диаграмма соответствует конкретному уровню СДР. В результате диаграмма уровня 4 пятиуровневой СДР вполне способна содержать пару сотен контрольных событий, каждое из которых привязано к определенному пакету работ. Такая диаграмма может использоваться в сочетании с сетевым графиком, подчеркивающим взаимозависимости между контрольными событиями. Такая практика весьма распространена в технологических организациях, конкурирующих по скорости выполнения проекта (см. раздел «Иерархическое расписание»).

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

Выгоды.Диаграмма с небольшим количеством ключевых контрольных событий, например соотносимая с уровнем 1 СДР, способна привлечь внимание даже занятых руководителей, поскольку она отражает ключевые события высокой важности (см. врезку «Недостаток контрольных событий может привести к потере многих тысяч») [13]. Диаграммы, которые включают в себя множество контрольных событий, связанных с пакетами работ, полезны тем, что усиливают акцент на цели («контрольное событие наступило» или «контрольное событие не наступило»), уменьшая акцент на операции («Я работаю над тем-то и тем-то»).

Преимущества и недостатки.Диаграмма контрольных событий имеет следующие преимущества:

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

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

•полезность в качестве инструмента планирования и отслеживания.

НЕДОСТАТОК КОНТРОЛЬНЫХ СОБЫТИЙ МОЖЕТ ПРИВЕСТИ К ПОТЕРЕ МНОГИХ ТЫСЯЧ

Наполеон, знаток военного дела, во время своих походов никогда не составлял каких-либо планов, исключая разве что самые схематичные наброски [1]. Эти схемы, вероятно, напоминали диаграммы контрольных событий, обозначавшие ключевые моменты кампании. Когда Наполеон вторгся в Египет, он четко разъяснил генералам свои цели. Действия генералов в значительной степени опирались на это расписание высокого уровня, что и привело к победе. Напротив, когда в июне 1812 года Наполеон вторгся в Россию с более чем 400-тысячным войском, он решил не информировать генералитет о своих планах. В результате в декабре 1812 года разбитая армия Наполеона, насчитывавшая к тому времени всего 20 тысяч человек, была вынуждена отступить.

ПРОВЕРКА ДИАГРАММЫ КОНТРОЛЬНЫХ СОБЫТИЙ

Убедитесь, что диаграмма контрольных событий:

• включает в себя ключевые контрольные события;

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

• содержит контрольные события, расположенные на разумном расстоянии друг от друга;

• верно располагает контрольные события относительно временной шкалы.

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

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

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

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

Резюме

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

© RuTLib.com 2015-2016

rutlib2.com

Процедура утверждения документов

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

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

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

Утверждающие лица после получения извещения детально знакомятся с пакетом документов. После ознакомления и согласования утверждающее лицо подписывает документ.

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

Организация управления качеством

Обеспечение качества - процесс выполнения плановых систематических операций по качеству, которые обеспечивают выполнение всех предусмотренных процессов, необходимых для того, чтобы проект соответствовал установленным требованиям по качеству [23]. Функцию обеспечения качества может выполнять команда проекта, руководство исполняющей организации, заказчик или спонсор, другие участники проекта. Для контроля качества проекта проводятся аудиторские проверки, целью которых является выяснение соответствия качества проекта стандартам, установленным в плане обеспечения качества.

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

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

Пояснения к заполнению формы контрольных списков

• Этап проекта - процесс, для которого необходимо прописать ожидаемый результат.

• Ожидаемый результат - метрика качества, которую необходимо достичь.

• Тип - присвоенный тип данной метрики, может быть критический, серьезный, желательный.

• Да/Нет - достигнут ли ожидаемый результат. Заполняется на этапе контроля и обеспечения качества проекта.

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

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

увеличить изображение Рис. 4.1. Процедура разработки контрольных списков (графическое изображение)

Для выполнения операций по обеспечению (оценке) качества используют аудит. Аудит качества - независимая экспертная оценка, определяющая, насколько операции проекта соответствуют установленным в рамках проекта или организации правилам, процессам и процедурам. Целью аудита качества является выявление неэффективных и экономически не оправданных правил, процессов и процедур, используемых в проекте. Количество и сроки плановых проектных аудитов могут определяться основными этапами проекта или ключевыми событиями. Внеплановые аудиты проводятся по запросам заказчика, руководителей департаментов и отделов. Аудиты качества проводятся на основе критериев, каждый из которых является следствием требований нормативной документации системы менеджмента качества (требование ISO 9000) и системы управления проектами (PMBOK). Схема проведения внутреннего аудита качества проекта может выглядеть следующим образом:

• анализ исправления замечаний предыдущей проверки;

• проведение проверки проекта в соответствии с контрольными списками ;

• оформление отчета о контроле качества;

• информирование команды проекта о появлении новых отчетных документов.

Ниже приведен шаблон для регистрации списка отклонений и описание процедуры обеспечения качества (табл. 4.6).

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

Рис. 3.1. Пример линии исполнения проекта (адаптировано из [18])

5. Рисование линии исполнения.

• Взять базовое расписание проекта и отметить на календаре (в шапке базового расписания) дату проведения совещания - статусную или отчетную.

• От этой даты рисовать вниз вертикальную линию до пересечения со строкой первой операции

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

Таким образом, линия исполнения позволяет регулярно контролировать и корректировать выполнение базового расписания проекта.

Диаграмма контрольных событий

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

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

Рис. 3.2. Пример диаграммы прогнозирования контрольных событий

Построение диаграммы контрольных событий

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

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

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

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

Графически представленная информация о ходе выполнения проекта дает наглядное представление о внутренней динамике проекта.

studfiles.net

Что включает документ Содержания проекта

СОДЕРЖАНИЕ ПРОЕКТА

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

Предварительное описание содержания проекта включает в себя:

Цели проекта . Цели и задачи проекта определяют, что должно быть выполнено для достижения успешного завершения проекта. Цели проекта должны быть согласованы с целями компании и стратегическим планом развития компании на 3-5 лет. При этом цели должны быть:

• Конкретные (Specific) – позволяющие сформировать расписание проекта;

• Измеримые (Measurable)– позволяющие качественно (или количественно) оценить, что результат получен;

• Достижимые (Achievable)– принципиально реализуемые Исполнителем в рамках проекта, с учетом декларируемой помощи со стороны Заказчика;

• Приносящие результат (Relevant) - соответствуют ожидаемой Заказчиком пользе;

• Ограниченные во времени (Time-bound) – реализуемые в ожидаемые Заказчиком временные в рамках проекта.

В таблице 1 приведен пример документирования целей проекта и критериев их достижения

Таблица 1

Цели Проекта и критерии их достижения (фрагмент).

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

Рис.2 Пример ИСР, выполненной в виде древовидной структуры

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

В таблице 2 представлен пример фрагмента списка работ проекта.

Таблица 2

Фрагмент списка работ проекта

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

Календарный план работ. Календарный план работ разрабатывается на основе контрольные события Устава и укрупненной Первоначальная иерархическая структура работ (ИСР). Календарный плана работ выполнить в программе Microsoft Project и представить в виде рисунка. Пример укрупненного содержания календарного плана приведен ниже в таблице 3

Таблица 3.

Укрупненный Календарный план работ

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

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

Рис. 3. Пример документирования критериев приемки (фрагмент)

Окружение проекта. В состав окружения проекта входят:

• Заинтересованные стороны проекта (подразделения и специалисты, на которых наибольшее влияние оказывают результаты проекта, контрагенты предприятия…)

• Факторы окружения (характеристики организации, степень знакомства с используемыми технологиями, квалификация сотрудников…)

Ниже приведен пример документирования окружения проекта

Рис.4.6. Пример документирования окружения проекта (фрагмент)

Критические факторы успеха проекта внедрения ИС (примеры):

• Прямое участие в проекте ведущих топ – менеджеров компании;

• Выделение персонала организации в соответствии с согласованным планом работ;

• Точно определенные рамки проекта;

• Квалификация персонала проекта;

• Обучение членов команды и пользователей;

• Четкое распределение ролей и ответственности

• Проработанный рабочий план

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

Таблица 4

Границы проекта (фрагмент).

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

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

Пример документирования допущений представлен на рисунке 5

Рис.5. Пример документирования допущений

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

Определение ролей проекта выполняется также на основании ИСР. К столбцу таблицы 2 «работы проекта» добавляется столбец «роли проекта» (таблица 4)

Таблица 4

Определение ролей проекта

Совмещение таблицы ролей с календарным планом позволит составить план занятости персонала.

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

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

• Консервативность пользователей и неприятие новой системы.

• Сложность эксплуатации системы.

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

• Несвоевременность разработки интерфейсов, обеспечивающих связь SAP ERP с внешними системами.

• Незнание методологии.

• Невнимание Управляющего совета и руководства компании.

• Уход членов проектной группы до конца проекта.

• Изменения структуры компании и/или методов ведения бизнеса.

• Нехватка выделенного бюджета.

• Растяжение сроков внедрения Проекта.

Смета расходов с указанием порядка величин

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

Требования к управлению конфигурацией проекта

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

Требования к одобрению.

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

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

Основные результаты и критерии успеха.

Результаты проекта – это продукт или услуга, получаемые в рамках выполнения проекта или решения конкретной задачи. Пример документирования результатов приведен ниже (рис.6).

Рис.6. Результаты проекта (фрагмент)

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

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

• Наличие спонсора проекта и его активное участие в реализации проекта;

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

• Четко определенный и стабильный объем проекта;

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

• Выделение в проектную команду компетентных, обученных и заинтересованных пользователей;

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

• Оперативное принятие решений по проекту;

• Наличие четких процедур и стандартов управления проектом и реализации решений.

Процедуры Управления проектом

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

План управления проектом

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

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

• План управления содержанием.

• План управления расписанием.

• План управления стоимостью.

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

• План управления обеспечения проекта персоналом.

• План управления коммуникациями проекта.

• План управления рисками.

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

• План управления изменениями.

studfiles.net

Методы составления расписания проекта - Управление проектами

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

Управление проектами — это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту [2]. Результат эффективного управления — реализация проекта в рамках необходимых сроков, бюджета и в соответствии с первоначальными требованиями. Ключевым фактором успеха проектного управления является наличие четкого заранее определенного расписания проекта.

Разработка расписания — процесс анализа последовательностей операций, их длительности, требований к ресурсам и временных ограничений для создания расписания проекта. Ввод операций, длительностей и ресурсов в инструмент составления расписания генерирует расписание с запланированными датами завершения операций проекта [1]. Разработка приемлемого расписания проекта зачастую является итеративным процессом, т. е. конкретные этапы формирования расписания происходят многократно. В результате определяются запланированные даты старта и финиша операций и контрольных событий проекта. Управление расписанием проекта, включает в себя все действия по планированию, контролю и корректирующие расписание действия. Именно расписание проекта позволяет использовать ресурсы наиболее эффективным способом, привлекать их в те даты, когда они необходимы и высвобождать, когда необходимость в ресурсах отпадает. С финансовой точки зрения, компания сможет спланировать свои платежи, посредством расписания проекта, что позволяет избежать таких негативных вещей, как например, кассовые разрывы. Пересмотр расписания и поддержание его реалистичности продолжается на всем протяжении проекта по мере выполнения работ, изменения плана управления проектом и выявления характера событий риска. Ниже представлена диаграмма управления сроками проекта (Рисунок 1) [2].

Рисунок  1.  Диаграмма  управления  сроками  проекта

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

1. Метод  PERT.
2. Метод  критического  пути.
3. Метод  критической  цепи.

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

Метод  PERT

PERT был создан в конце 50-х годов в военно-морских силах США для ускорения разработки лодочной баллистической ракеты «Полярис». При разработке этой системы оружия требовалось координировать работу нескольких тысяч частных подрядчиков и правительственных организаций. Координация работ оказалась настолько успешной, что весь проект был завершен на два года раньше планового срока. Это привело к дальнейшему применению PERT в других программах разработки оружия в ВМС, ВВС и сухопутных восках США. В настоящее время он широко применяется в промышленности, а так же в обслуживающих организациях [1, c. 291].

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

Можно отметить ряд особенностей метода PERT:

• PERT следует применять только для крупных проектов с большим количеством работ (более 300). Помимо достаточного числа работ критического пути это обеспечит независимость случайных величин их продолжительностей.
• Для применения PERT необходимо подобрать экспертов и организовать их работу для получения оценок оптимистичной, пессимистичной и наиболее вероятной продолжительностей для каждой работы проекта. От качества этой работы будет зависеть качество применения PERT
• PERT занижает оценку продолжительности проекта. Чем больше параллельно идущих работ, тем серьезней ошибка. Для ее утсранения следует воспользоваться методом Монте-Карло.
• Критическим путем проекта при его реализации может оказаться путь, отличный от того, который был получен с помощью метода PERT. Степень критичности той или иной работы проекта также зависит от конкретной реализации. Можно говорить лишь о вероятности, что работа будет критичной.

PERT не учитывает существующие ограничения на ресурсы и действия проектного менеджера, который стремится выполнять проект в назначенные сроки. Для успешности PERT необходимо сделать одно допущение: все случайные величины продолжительностей работ критического пути — независимы. В противном случае это повлияет на дисперсию продолжительности проекта [2, c. 297].

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

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

Метод  критического  пути

Метод критического пути (МКП) во многих отношениях напоминает PERT, но был разработан независимо от него фирмой «Дюпон де Немур». Фактически оба метода — PERT и CPM — разработаны почти одновременно [1, c. 290]. Основное различие между ними состоит в том, что CPM не учитывает случайные колебания продолжительности работ. Вместо этого предполагается, что продолжительность работы пропорциональна количеству выделяемых ресурсов и что, изменяя количество ресурсов, можно изменять продолжительность работы и сроки завершения проекта. Таким образом, при использовании МКП на основе имеющегося опыта осуществления аналогичных проектов устанавливаются соотношения между имеющимися ресурсами и продолжительностями работ. Затем оцениваются компромиссные соотношения между затратами и продолжительность проекта.

МКП предъявляет следующие требования к модели проекта [3, c. 280]:

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

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

1. Прохода вперед. Вычисляются самые ранние возможные сроки выполнения работ проекта.
2. Проход назад. Вычисляются самые поздние возможные сроки выполнения работы проекта.

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

На рассчитанные ранние и поздние даты старта и финиша может влиять общий временной резерв операции, который определяется как разность между поздними и ранними сроками выполнения работ. Это позволяет делать расписание гибким и может быть положительным, отрицательным или нулевым. Для любого пути в сети гибкость расписания, называемая «полным временным резервом», измеряется положительной разницей между ранними и поздними датами. У критических путей полный временной резерв либо нулевой, либо отрицательный, а запланированные операции на критическом пути называются «критическими операциями». Критический путь обычно характеризуется нулевым полным временным резервом, т. е. с самым длинным путем в сети. В сетях может существовать несколько путей, близких к критическому. Для создания путей в сети с нулевым или положительным полным временным резервом может потребоваться адаптация длительностей операций, логических связей, опережений, задержек и других временных ограничений. После подсчета полного временного резерва пути в сети также может быть определен свободный временной резерв — период времени, на который операция может быть отложена, не вызывая задержки раннего старта любой непосредственно последующей операции в данном сетевом пути [2].

Для расчета критического пути необходимо проделать следующие шаги:

• Перечислить все задания (операции) с указанием номера задания или номера в ИСР.
• Перечислить зависимости по каждой операции.
• Записать продолжительность каждой операции.
• Рассчитать раннюю дату начала и раннюю дату окончания каждого задания. Соответственно при расчете дат раннего начала надо учитывать все зависимости, которые есть у данной операции.
• Рассчитать дату позднего старта и позднего окончания для каждой операции, учитывая существующие зависимости между операциями.
• Рассчитать резерв времени для каждой операции, как разницу между датами раннего и позднего начала (или окончания). Резерв времени — всегда положительная величина.
• Определить критический путь проекта путем суммирования длительности каждой операции с нулевым запасом времени.

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

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

По данным многочисленных исследований Standish Group для традиционных методов управления проектами, только 44% проектов обычно завершаются вовремя. В среднем проекты занимают 222% процента от изначально запланированной длительности, 189% от начального бюджета. 70% проектов сокращают исходный объем работ проекта, 30% проектов закрываются досрочно.

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

Метод  критической  цепи

Впервые метод описан в 1997 году в книге Голдратта «Критическая цепь», метод встретил широкую поддержку специалистов, так как был близок по технике классическому методу PERT (ресурсные связи фактически являлись расширением сетевой модели на ресурсы), а расчётные алгоритмы оказались достаточно просты и эффективны по быстродействию. Расчёт буферов также был прост и аналогичен методике расчёта длительности работ в некоторых расширениях метода PERT и соответствовал сложившейся практике во многих организациях.

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

Действуя согласно ТОС, определим проблемные зоны управления проектами по CPM/PERT, которые напрямую влияют на скорость выполнения проекта. Результатом подобного анализа стал следующий список проблем:

1. Выигрыш по времени не передается.
2. Работа занимает все отведенное на неё время.
3. Исполнители не передают работу на следующий этап раньше при досрочном выполнении.
4. Невозможно точно оценить продолжительность каждой работы.
5. В случаи нарушения сроков выполнения работы, предпринимаются корректирующие действия, связанные с увеличением бюджета или уменьшением объемов работ.
6. Необходимые ресурсы заняты выполнением других проектов.
7. Необходимые для выполнения задачи работы некритического пути еще не закончены.

После подробного анализа каждой из проблем, Голдратт предложил свой подход к решению проблем:

1. Использовать оценки времени с 50 % перекрытием неопределенности.
2. Исполнители защищены от давления руководства на сроки выполнения работы. Обеспечить напряженную работу исполнителей над своей задачей.
3. Сконцентрироваться на дате окончания проекта, а не на определении срока выполнения каждого задания.
4. Введение проектного буфера — общий для проекта запас времени для компенсации неопределённости.
5. Введение ресурсных буферов — оповещение ресурсов занятых на критической цепи, о том, что скоро необходимо будет переключиться на выполнение задания по данному проекту.
6. Введение питающих буферов — временной резерв на покрытие неопределенности при выполнении работ некритической цепи.

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

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

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

Опишем основные особенности метода критической цепи [3. c. 321]:

1. Метод нацелен на скорейшее выполнение проекта.
2. Позволяет управлять расписанием проекта в условиях ограниченных возобновляемых ресурсов.
3. Учитывает неопределенность продолжительностей работ.
4. Позволяет мобилизировать команду проекта на достижение его целей, обладая организационными и психологическими механизмами стимулирования.
5. Существует проблема оценки питающих и проектных буферов.

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

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

1. Методы анализа сетей: пер. с англ. Филлипс Д., Гарсиа-Диас А. М.: Мир, 1984. — 496 с.
2. Руководство к Своду знаний по управлению проектами (Руководство PMBOK). 4-е изд., 2008. Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA / США ANSI/PMI 99-001-2008.
3. Управление проектами. Фундаментальный курс. Учебник. Валерий Аньшин, Ольга Ильина. М.: Высшая Школа Экономики (Государственный Университет), ISBN 978-5-7598-0868-8; 2013 г — 624 с.

Сухотерин Павел Александровичаспирант, Московский Государственный Университет приборостроения и информатики, РФ. г. Москва

Просмотры: 7 423

forpm.ru

Смотрите также

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