Линейные модели и их применение для управления проектами: график Ганта (ленточная диа­грамма), циклограмма. Недостатки линейных моделей и пути их преодоления

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

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

централизованное хранение информации по графику работ, ресурсам и стоимостям;

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

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

∙ возможности автоматизированной генерации отчетов и графических диаграмм, разработки документации по проекту.

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

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

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

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

неспособность в полной мере отражать взаимосвязи отдельных операций;

недостаточная гибкость линейной модели;

трудность ее корректировки при изменившихся условиях;

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

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

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

 

28 График Ганта (ленточная диаграмма) и его построение для различных видов технологических связей между работами проекта

 

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

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

Для моделирования параллельных работ применяют связь «конец — конец». При этом окончание последующей работы соотносится с окончанием предшествующей.

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

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

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

Более наглядно календарный план можно представить в виде линейных диаграмм, или графиков Ганта (названных по имени Генри Ганта, который впервые использовал их). На рис. 24.1 приведена линейная диаграмма выполнения дорожного покрытия. Такие ленточные (поэтапные) графики применяются при планировании сравнительно несложных работ и объектов, не содержащих элементов риска. Если же риск предвидится, то фактор риска включают в расчет трудоемкости работ или затрат. По горизонтали откладывают календарные периоды (дни, смены, декады, месяцы и другие временные отрезки), а по вертикали проставляют последовательно виды работ. Эти графики достаточно просты и наглядны, но имеют существенные недостатки. В них не отражается взаимосвязь между отдельными работами, по ним трудно выделить работы, сроки выполнения, которых надо сократить, особенно когда они выполняются параллельно и параллельно-последовательно.

 

29 Иерархические графы и их разновидности (дерево целей, организационная структура, дерево ре­шения, причинно-следственная диаграмма и др.).

 

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

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

 

 

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

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

 

Причинно-следственная диаграмма (Диаграмма Исикава)

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

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

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

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

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

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

 

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

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

Для каждой альтернативы мы считаем ожидаемую стоимостную оценку (EMV) — максимальную из сумм оценок выигрышей, умноженных на вероятность реализации выигрышей, для всех возможных вариантов.

Пример 1. Главному инженеру компании надо решить, монтировать или нет новую производственную линию, использующую новейшую технологию. Если новая линия будет работать безотказно, компания получит прибыль 200 млн. рублей. Если же она откажет, компания может потерять 150 млн. рублей. По оценкам главного инженера, существует 60% шансов, что новая производственная линия откажет. Можно создать экспериментальную установку, а затем уже решать, монтировать или нет производственную линию. Эксперимент обойдется в 10 млн. рублей. Главный инженер считает, что существует 50% шансов, что экспериментальная установка будет работать. Если экспериментальная установка будет работать, то 90% шансов зато, что смонтированная производственная линия также будет работать. Если же экспериментальная установка не будет работать, то только 20% шансов за то, что производственная линия заработает. Следует ли строить экспериментальную установку? Следует ли монтировать производственную линию? Какова ожидаемая стоимостная оценка наилучшего решения?

В узле F возможны исходы «линия работает» с вероятностью 0,4 (что приносит прибыль 200) и «линия не работает» с вероятностью 0,6 (что приносит убыток -150) => оценка узла F. EMV(F) = 0,4 x 200 + 0,6 х (-150) = -10. Это число мы пишем над узлом F.

 

EMV(G) = 0.

В узле 4 мы выбираем между решением «монтируем линию» (оценка этого решения EMV(F) = -10) и решением «не монтируем линию» (оценка этого решения EMV(G) = 0): EMV(4) = max {EMV(F), EMV(G)} = max {-10, 0} = 0 = EMV(G). Эту оценку мы пишем над узлом 4, а решение «монтируем линию» отбрасываем и зачеркиваем.

Аналогично:

EMV(B) = 0,9 х 200 + 0,1 х (-150) = 180 - 15 = 165.

EMV(С) = 0.

EMV(2) = max {EMV(В), EMV(С} = max {165, 0} = 165 = EMV(5). Поэтому в узле 2 отбрасываем возможное решение «не монтируем линию».

EM V(D) = 0,2 х 200 + 0,8 х (-150) = 40 — 120 = -80.

EMV(E) = 0.

EMV(3) = max {EMV(D), EMV(E)} = max {-80, 0} = 0 = EMV(E). Поэтому в узле 3 отбрасываем возможное решение «монтируем линию».

ЕМ V(A) = 0,5 х 165 + 0,5 х 0 — 10 = 72,5.

EMV(l) = max {EMV(A), EMV(4)} = max {72,5; 0} = 72,5 = EMV(A). Поэтому в узле 1 отбрасываем возможное решение «не строим установку».

Ожидаемая стоимостная оценка наилучшего решения равна 72,5 млн. рублей. Строим установку. Если установка работает, то монтируем линию. Если установка не работает, то линию монтировать не надо.

30 Сетевое планирование и управление (СПУ). Основные понятия и определения СПУ: сетевая мо­дель, работа, событие, путь. Виды сетевых моделей, работ, событий и путей. Правила построения се­тевых моделей. Критический путь. Подкритический путь.

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

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

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

 

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

· действительной, т.е. требующей затрат времени;

· фиктивной, т.е. формально не требующей затрат времени.

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

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

 

 

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

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

· длина стрелки не зависит от времени выполнения работы;

· стрелка может не быть прямолинейным отрезком;

· для действительных работ используются сплошные, а для фиктивных – пунктирные стрелки;

· каждая операция должна быть представлена только одной стрелкой;

· между одними и теми же событиями не должно быть параллельных работ, т.е. работ с одинаковыми кодами;

· следует избегать пересечения стрелок;

· не должно быть стрелок, направленных справа налево;

· номер начального события должен быть меньше номера конечного события;

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

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

· не должно быть циклов

 

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

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

 

31 Матрицы ответственности проекта, их разновидности и примеры использования.

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

 

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

 

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

Степеней ответственности может быть много. Например, РМВОК определяет 4 вида ответственности:

1. Ответственный (О)- полностью отвечает за выполнение задачи и вправе принимать решения по способу ее реализации

2. Исполнитель (И) - исполняет задачу, но в обшем случае, не несет ответственности за способ ее решения.

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

4. Наблюдатель (Н) - то же самое что и консультант, но ответственности не несет.

Матрица ответственности выглядит таким образом:

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

 

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

 

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

 

32 Иерархический граф структуры декомпозиции (разбиения) работ как эффективный инструмент управления проектом.

Структура разбиения (декомпозиции) работ (WBS — Work Breakdown Structure) — иерархическая структура последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня, пакеты детальных работ. СРР является базовым средством для создания системы управления проектом, так как позволяет решать проблемы организации работ, распределения ответственности, оценки стоимости, создания системы отчетности, эффективно поддерживать процедуры сбора информации о выполнении работ и отображать результаты в информационной управленческой системе для обобщения графиков работ, стоимости, ресурсов и дат завершения.

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

» определить работы, пакеты работ, обеспечивающие достижение подцелей (частных целей) проекта;

» проверить, все ли цели будут достигнуты в результате реализации проекта;

» создать удобную, соответствующую целям проекта структуру отчетности;

» определить на соответствующем уровне детализации плана вехи (ключевые результаты), которые должны стать контрольными точками по проекту;

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

» обеспечить членам команды понимание общих целей и задач по проекту.

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

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

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

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

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

Основанием декомпозиции СРР могут служить:

♦ компоненты товара (объекта, услуги, направления деятельности), получаемого в результате реализации проекта;

♦ процессные или функциональные элементы деятельности организации, реализующей проект;

♦ этапы жизненного цикла проекта, основные фазы;

♦ подразделения организационной структуры;

♦ географическое размещение для пространственно распределенных проектов.

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

Искусство декомпозиции проекта состоит в умелом согласовании основных структур проекта, к которым относят, прежде всего, организационную структуру (OBS — Organization Breakdown Structure), структуру статей затрат (ABS —- Account Breakdown Structure), структуру ресурсов (RBS — Resource Breakdown Structure), функциональную структуру, информационную структуру, структуру временных интервалов (порядок и состав фаз, этапов, ключевых событий проекта) и их возможные составные структуры. СРР служит основой для подобного согласования.

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

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

Правила, основные этапы построения и возможности использования СРР следующие:

» на основе информации о плане мероприятий проводится последовательная декомпозиция (разбиение, деление на категории, классификация) по заданным основаниям (признакам, критериям) работ проекта.

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

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

Рис. 13.4.1. СРР для смешанного подхода

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

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

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

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

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

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

» аналогично график и план по вехам может быть представлен с помощью СРР в виде главного, укрупненного графика (project master schedule), в котором указаны основные компоненты и этапы проекта. Он является всеобъемлющим и может включать в себя контрактные обязательства, ключевые контакты, порядок действий, важные события и отчеты о ходе выполнения работ.

Возможные ошибки структуризации проекта:

» пропуск стадии структуризации проекта и переход непосредственно к поиску и решению текущих, оперативных проблем проекта;

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

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

» повторение элементов структуры;

» отсутствие интеграции структуры проекта с системой ведения бухгалтерских счетов в компании и с системой подготовки проектно-сметной документации (гл. 9);

» излишняя или недостаточная детализация;

» невозможность компьютерной обработки результатов структуризации — планов проекта из-за ошибок формального характера (каждый уровень или элемент плана должен быть определенным образом закодирован);

» неучет «неосязаемых» конечных продуктов, таких как услуги;

» информационное или программное обеспечение.

 

33 Метод освоенного объема и его роль в управлении проектом.

Метод освоенного объема — интегрированный анализ исполнения календарного плана проекта и бюджета по стоимостным оценкам, наиболее распространенный метод измерения исполнения проекта и его управления (освоенный объем задачи — это утвержденный бюджет, выделенный на ее решение).

Метод позволяет получить ответы на следующие вопросы.

· Фактические затраты меньше запланированных на данный момент. Выигрывает ли мой проект или он, напротив, есть отставание от расписания?

· Фактические затраты на проект выше плановых, хотя проект выполнен лишь наполовину. Какова будет его стоимость к моменту завершения всех проектных работ?

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

· Есть ли у меня исполнители для выполнения нового контракта?

· Будут ли влиять изменения в ставках оплаты исполнителей и в курсе валют на стоимость моего проекта?

· Как сокращение финансирования проекта повлияет на план движения денежных средств в проекте?

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

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

· Фактическая стоимость выполненных работ — AC (Actual Cost). Фактическая стоимость с нарастающим итогом отображается во времени для каждого отчетного периода.

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

Ключевыми показателями методики освоенного объема являются:

· отклонение по стоимости — CV (Cost Variance). Равно разнице между плановой стоимостью выполненной работы и ее фактической стоимостью: CV = EV – AC;

· отклонение по срокам — SV (Schedule Variance). Равно разнице между плановой стоимостью выполненной работы и плановой стоимостью запланированных работ: SV = EV – PV;

· коэффициент выполнения бюджета (или индекс выполнения стоимости) — CPI (Cost Performance Index): CPI = EV / AC;

· коэффициент выполнения календарного плана (или индекс выполнения сроков) — SPI (Schedule Performance Index). SPI = EV / PV.

 

 

34 Базовые показатели метода освоенного объема.

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

• Базовая стоимость запланированных работ (BCWS, БСЗР) обозначает сводную стоимость работ, которые должны были быть осуществлены к текущему моменту. Другими словами, параметр обозначает, каковы должны быть затраты на проект на текущий момент по базовому плану.
• Фактическая стоимость выполненных работ (ACWP, ФСВР) обозначает сводную фактическую стоимость трудозатрат на текущий момент, то есть сколько фактически потрачено на проект к текущему моменту.
• Базовая стоимость выполненных работ (BCWP, БСВР) обозначает запланированную по базовому плану стоимость фактически выполненных работ, то есть сколько планировалось потратить на осуществление тех трудозатрат, что были фактически осуществлены. Этот параметр часто называется освоенным объемом.

Каждая из величин определяется в денежных единицах, и благодаря этому методика позволяет анализировать одновременно данные о затратах и трудозатратах. Название методики часто переводится как «приобретенная стоимость», и этот перевод помогает понять ее суть. Трудозатраты рассматриваются как средство, благодаря которому проект «приобретает» стоимость (осваивает объем). Соответственно, в каждый момент известно, какую стоимость проект должен был приобрести (BCWS, БСЗР), какую стоимость он приобрел (BCWP, БСВР) и сколько было затрачено на ее приобретение (ACWP, ФСВР). Именно поэтому BCWP (БСВР) часто называется освоенным объемом (или приобретенной стоимостью, earned value).

 

 

35. Управление качеством проектов.

 

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

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

Пример. Взаимосвязь качества проекта и качества продукции проекта.

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

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

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

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

 

Планирование качества — выявление требований к качеству проекта и продукции проекта, а также определение путей их удовлетворения.

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

 

 

36 Методы управления качеством проектов.

 

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

» анализ затрат и выгод;

» установление желательного уровня показателей качества проекта исходя из сравнения с соответствующими показателями других проектов;

» диаграммы:

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

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

» эксперименты.

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

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

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

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

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

Рис. 18.2.2. Диаграмма причин-следствий (диаграмма Исикавы)

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

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

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

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

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

» проверок;

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

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

» статистических выборок, анализа динамических рядов, корреляционно-регрессионного анализа и других статистических методов;

» диаграмм.

 

Рис. 18.2.3. Контрольная карта реализации проекта

Рис. 18.2.4. Диаграмма Парето

Контроль качества может завершиться следующими решениями:

» улучшением качества;

» принятием продукции;

» идентификацией брака и реализацией действий по управлению несоответствующей продукцией;

» переработкой продукции с целью дальнейшего представления для контроля и испытаний;

» исправлением процессов.

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

Рис. 18.2.5. Организация контроля качества

Классификация видов и методов контроля качества в управлении проектом представлена на рис. 18.2.6

Рис. 18.2.6. Классификация видов и методов контроля качества в управлении проектом

 

37 Управление рисками проектов.

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

связанных ними последствий в виде потерь, ущерба, убытков, например — ожидаемой

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

Управление рисками — совокупность методов анализа и нейтрализации факторов

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

воздействий. Управление рисками является подсистемой управления проектом.

 

 

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

 

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

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

Можно сформулировать несколько наиболее часто встречающихся ошибок планирования

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

 

39. КЛАССИФИКАЦИЯ ВРЕМЕННЫХ ОГРАНИЧЕНИЙ ПРОЕКТА В MS PROJECT.

Алгоритм такой:

В Окне задачи:

1.Окно сведения о задаче

2.Выбираем вкладку «дополнительно»

3.Там типы ограничений, всего их три:

· Гибкие

· Полужесткие

· Жесткие

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

 

40. РЕСУРСНОЕ ПЛАНИРОВАНИЕ ПРОЕКТА В MS PROJECT

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

Для того чтобы начать планирование ресурсов "от работ", необходимо вызвать уже знакомое нам окно информации о работе (Task Information), а конкретнее - его вкладку "Ресурсы" (Resources). Нашим взорам откроется список назначенных работе ресурсов, состоящий из двух колонок: "Имя ресурса" (Resource Name) и степень его загрузки (Units). Роль списка ресурсов двояка. С одной стороны, добавляя в него название ресурса, мы назначаем этот ресурс текущей работе. С другой стороны, если назначенного нами ресурса ранее не было в общем перечне ресурсов проекта, он автоматически добавляется в этот перечень. Если же мы назначаем работе один из ранее описанных ресурсов, мы можем выбрать его наименование из выпадающего списка.

Назначение ресурсов работе

 

Этот проект мы используем в качестве примера

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

Список ресурсов в режиме Resource Sheet

Напомню, что режимы отображения информации в MS Project переключаются с помощью иконок, расположенных в левой части окна проекта или с помощью меню Views. Список ресурсов отображается в виде электронной таблицы. В этой таблице, помимо наименования, указываются: тип ресурса (Type), единицы измерения (Material Label) "инициалы" (Initials), максимальное количество единиц ресурса (Max. Units), обычная стоимость использования (Std. Rate), стоимость "сверхурочного" использования (Ovt. Rate), стоимость одного использования (Cost/Use), способ учета затрат ресурса (Accrue At), базовый календарь (Base Calendar) и поля с дополнительными признаками для удобства групповых операций (Code, Group).

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

С единицами измерения все просто - в чем ресурс измеряется, то и пишем. Измеряется в тоннах - пишем тонны, в литрах - пишем литры, и так далее. Для рабочих ресурсов этот параметр заблокирован, поскольку в любом случае ясно, что эти ресурсы измеряются в человеко/машино-часах. Инициалы ресурса используются при необходимости его краткого обозначения. При создании ресурса инициалы задаются автоматически по первой букве наименования, но пользователь может переопределить их по своему усмотрению. Параметр Max. Units показывает, насколько эффективно ресурс использует рабочее время. По общему правилу, Max. Units устанавливается в 1 (или в 100% - в зависимости от того, в каких единицах измеряется загрузка ресурса). Однако если у нас есть несколько однотипных ресурсов, выполняющих одни и те же функции, мы можем вместо них определить один ресурс с максимальной загрузкой в 200%, 300% и так далее - в зависимости от количества и "мощности" объединенных ресурсов. Если же известно, что какой-либо ресурс работает менее эффективно, чем "эталонный", параметр выставляется, например, на 80% - в зависимости от уровня лени, имманентно (что это означает, представляю смутно, но Word не ругается - и ладно) присущего ресурсу. Для материальных ресурсов этот параметр заблокирован.

Выбор ресурса из выпадающего списка

 

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

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

Иногда для сокращения времени выполнения работы ресурсу приходится работать сверхурочно. Стоимость работы ресурса в нерабочее время определяется параметром Ovt. Rate. Для материальных ресурсов этот параметр заблокирован. Бывают случаи, когда в дополнение к обычным затратам на использование ресурса приходится нести дополнительные "единовременные" затраты - например, по доставке специалиста к месту работы. Эти затраты учитываются в графе Cost/Use. Три упомянутых "денежных" параметра имеют значение, прежде всего, при составлении бюджета проекта. На этапах собственно планирования и оптимизации стоимостная информация вполне может оказаться невостребованной, поэтому и вводить ее можно не сразу.

Более актуальными являются такие характеристики ресурса, как способ отнесения затрат на работы и календарь. Способ отнесения затрат (Accrue At) определяет, в какой момент выполнения работы назначенный ей ресурс считается затраченным. Возможны три варианта: полностью в момент начала выполнения (Begin), полностью в момент окончания выполнения (End) и равномерно в течение всего периода выполнения работы (Prorated). По умолчанию устанавливается последний вариант.

Сетевой график с назначенными ресурсами

 

Календарь ресурса

Важным моментом в описания ресурса является его рабочий календарь. Фактически, он определяет, каким бюджетом рабочего времени располагает ресурс. В таблице ресурсов можно указать лишь базовый тип календаря ресурса. Тонкая настройка календаря осуществляется на вкладке "Рабочее время" (Working Time) окна информации о ресурсе (Resource Information). Рабочий календарь любого ресурса основывается на одном из базовых типов календаря. Базовых типов всего три: обычный (Standard - с 8-00 до 17-00, перерыв с 12-00 до 13-00), "ночная смена" (Night Shift - с 0-00 до 8-00, перерыв с 3-00 до 4-00) и круглосуточный (24 Hours - без перерывов). С помощью вкладки "Рабочее время" можно как задать часы работы и отдыха для отдельных дат индивидуально, так и изменить распорядок дня рабочей недели в целом. Для каждых суток можно установить до четырех перерывов в работе - вполне достаточно для самого замысловатого рабочего графика.

Делаем пятницу коротким днем

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

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

Назначать ресурсы на работы можно не только из Resource Sheet данного проекта. Источниками также могут служить другие проекты и так называемые "пулы" ресурсов. Для того чтобы получить ресурсы из другого проекта, необходимо выбрать пункт Share Resources из подменю Resources меню Tools. В появившемся диалоговом окне указывается источник (это может быть другой одновременно открытый проект), а также тот из проектов, который имеет преимущество при конфликтах календарей или информации о ресурсах. "Пул" ресурсов - это файл проекта, в котором описаны лишь ресурсы, но не работы. Такой файл используется в качестве источника ресурсов для других проектов.

Таким образом, мы научились описывать как работы проекта, так и его ресурсы. Однако этим возможности MS Project, разумеется, не исчерпываются. Распараллеливание работ и возможность назначения одного ресурса на несколько работ приводит к опасности перегрузки ресурса. Что это такое и как с ним бороться, мы расскажем в следующий раз.

 

41. РАСЧЕТ СТОИМОСТИ ПРОЕКТА В ПРОДЖЕКТ

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

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

Для сохранения базовой версии проекта нужно в списке "Track" на панели "Project Guide" выбрали опцию "Save a baseline plan to compare with later versions". Если мы сохраняем базовый впервые, то в левой панели "Save Baseline" появится кнопка "Save Baseline", которую нужно нажать. Если же мы уже сохраняли baseline ранее, то в левой панели появится соответствующее соообщение: " You have already saved baseline information for this project. " Мы можем сохранить измененный baseline или создать еще один, новый базовый план. (Общее число базовых план может достигать 11.) Об этом говорится в сообщении: " You can either update an existing baseline or save a completely new one. You can save up to 11 baselines in a project ". Соответственно, если мы хотим создать новый базовый план, то выберем из предлагаемого списка опцию "Save a new baseline"; если же хотим обновить существующий, то выберем "Update baseline". Укажем с помощью радиокнопки - сохраняем ли мы базовый план для всего проекта ("The entire project") или для выбранных (на правой панели) заданий ("Only tasks selected on the right"). Нажмем кнопку "Save Baseline" и гиперссылку "Done".