Сердцевиной управления проектами являются два процесса – планирование и контроль проекта. По объему планирование составляет около половины всей области знаний управления проектами. Эту самую половину можно оценивать разными способами, например, по количеству процессов (~20 из ~40), или по количеству страниц в стандартах ISO или PMBOK. А по концептуальной значимости – может даже больше половины, так как суть концепции управления проектом – контроль исполнения плана, значит, план проекта – это основа, фундамент, база управления проектом, а разработка плана – это основа профессиональных умений менеджера проекта.
Основным объектом управления в проекте является работа. В этой главе мы рассмотрим основу основ управления проектами – планирование работ проекта. Планирование работ проекта еще называют разработкой календарного плана проекта.
Хотя современные методики управления проектами обычно не настаивают на некой строго определенной последовательности разработки плана работ, однако шаги планирования образуют строгую логическую цепочку, в которой результаты каждого шага являются необходимыми входными данными для последующего шага. И эта цепочка такова: потребности – результаты – структура работ – операции – ресурсы – сроки – стоимость. Тех читателей, которым цепочка показалась слишком длинной, возможно утешит то соображение, что эта цепочка – основа профессиональных знаний руководителя проектов и в таком качестве она может быть и не так уж длинна. Мы будем строго придерживаться этой последовательности не только и не столько потому, что так принято, или так говорит стандарт ISO или PMBOK, сколько потому, что именно такова внутренняя логика процесса разработки плана работ. Предвижу возражение такого типа, мол, в жизни все не так! Мол, любой профессионал без проблем начнет с конца цепочки – со стоимости, он не задумываясь и не выстраивая никаких цепочек, сразу оценит стоимость работы, да еще и со своим наваром. Не сомневаюсь! Сомневаюсь в другом – что он сможет убедить заказчика и тем более получить с него деньги без понятных пояснений. А единственное убедительное пояснение – это именно логика процесса.
Еще одно замечание качается заинтересованных сторон и их требований. В этой главе предполагается, что требования уже определены и известны. Способы выявления требований рассматриваются в разделе «Управление участниками проекта».
И последнее замечание. Разработка любых планов – это итеративный циклический процесс. В каждом цикле мы что-то уточняем и корректируем. Описываемая далее последовательность шагов разработки плана работ относится к одному циклу этого процесса.
Стандарты управления проектами объединяют работы и результаты проекта одним термином: «содержание» проекта, или, по-английски, «scope». Вот, для примера, определение PMBOK:
Содержание продукта – свойства и функции, которые характеризуют продукт, услугу или результат.Содержание проекта – работы, которые необходимо выполнить, чтобы получить продукт, услугу или результат с заданными характеристиками и функциями.
Современное программное обеспечение для календарного планирования проектов исповедует такой же подход – результаты являются разновидностью работ и моделируются как квази-работы с нулевой длительностью. Такой подход является практичным, но он вольно или невольно скрывает принципиально разные роли, которые исполняют в проектах работы и результаты. Мы же должны внести полную ясность в этот вопрос, и я вынужден озвучить пусть и очевидные, но принципиальные для адекватного понимания сути проектов, слова. Итак.
Результаты – это то, ради чего проект затевается. К результатам относят все выходы проекта – от продукта, или продуктов, если их несколько, до любых компонентов, их составляющих, которые могут считаться промежуточными результатами.
Для проекта первичными являются именно результаты, а не работы. Работы исполняются только те и только такие, которые обеспечат нужные результаты, а не наоборот – мы исполняем работы те и такие, которые нам нравятся, чисто из любви к искусству, а уж что получится – то и получится.
Я все это веду к тому, что планирование проекта производится от результатов к работам, то есть работы проекта определяются требуемыми результатами, а исполнение – наоборот, от работ – к результатам, или, работы создают результаты.
Общепринятым инструментом представления результатов является ИСП - Иерархическая структура продукта (PBS - Product Breakdown Structure), которая описывает состав и иерархию компонентов продукта.
Для небольшого домика Иерархическая структура продукта может выглядеть так:
Или так:
Рисунок 2.1. Иерархическая структура продукта
Существенным является не способ представления, он может быть любым, а именно структурность, иерархичность, декомпозиция любого результата на его составляющие. От сложного – к простому. Разделяй и властвуй!
Пока все это достаточно банально. И очевидно. Мы декомпозируем результаты потому, что любой материальный (и нематериальный тоже) объект состоит из элементов, компонентов и т.д. И чтобы создать объект, нет другого способа, кроме как создать его составляющие и затем соединить их в целое. Значит, мы должны выявить и задокументировать эти самые составляющие. Так? Так. Однако, по-прежнему банально и очевидно.
Не очевидно следующее: где предел декомпозиции? До какого уровня декомпозировать? Ведь если вовремя не остановиться, то можно добраться до молекул и атомов! Ответ может быть таким. Глубина декомпозиции определяется потребностями управления созданием объекта. А именно, если создателям результата все ясно и понятно про очередную составляющую, то дальше делить ее не имеет смысла. Если же есть неясности, то значит, надо декомпозировать, причем именно для того, чтобы снять неясности. Остается вопрос насчет «ясно и понятно» - как определить, ясно или неясно? Тут ответ может быть таким. Ясно и понятно должно быть всем лицам, принимающим решения по результату и его составляющим. Управленческие решения, типа: «будем производить результат именно такой, из именно таких составляющих». А раз решение управленческое, то надо обратиться к троице управленческих показателей: сроки, стоимость, качество. Так как мы говорим сейчас не о работах, а о результатах, то в первую очередь нас интересуют не сроки и стоимость, а качество, то есть характеристики и спецификации составляющих. И тогда можно сказать так:
Декомпозиция результата производится до того уровня, на котором характеристики и спецификации результата и его составляющих могут быть оценены с достаточной для принятия решений точностью.
Общепринятым инструментом представления работ проекта является ИСР - Иерархическая структура работ (WBS - Work Breakdown Structure), которая описывает состав и иерархию работ проекта.
Иерархия работ для нашего домика может быть такой:
Или такой:
Рисунок 2.2. Иерархическая структура работ
Здесь опять существенен не способ представления, а иерархичность, то есть разбиение работ на под-работы и вызванные этим группировки работ.
И так же, как со структурой продукта (см. выше обсуждение иерархии продукта), возникает основной вопрос философии планирования: глубина иерархии работ - или вовремя остановиться! Ответ мы уже знаем - глубина декомпозиции определяется потребностями управления работами. А именно, если управленцам и исполнителям очередной работы все ясно и понятно, то дальше делить ее не имеет смысла. Если же есть неясности, то значит, надо декомпозировать, чтобы снять неясности. Вопрос насчет «ясно или неясно» разрешается относительно троицы управленческих показателей: сроки, стоимость, качество. Так как мы говорим сейчас не о результатах, а о работах, то в первую очередь нас интересуют сроки и стоимость, а не характеристики и спецификации составляющих. И тогда можно сказать так:
Декомпозиция работ производится до того уровня, на котором сроки и стоимость работ могут быть оценены с достаточной для принятия решений точностью.
Есть довольно существенная проблема – чем глубже уровень декомпозиции, тем меньше людей способны понять работы и результаты этого уровня. Верхние уровни декомпозиции работ и результатов понятны всем либо сразу, либо с небольшими разъяснениями, а нижние уровни понятны только узким спецам. У плана проекта есть два разных назначения – служить путеводителем для исполнителей и служить основой для согласования с заинтересованными сторонами. Очевидно, что путеводителем являются нижние уровни декомпозиции, а основой для согласования – верхние. Более того, дилетантам обычно лучше не показывать нижние уровни – хотя бы для того, чтобы не пугать их. Поэтому рекомендуется содержание проекта делать двух-слойным и разрабатывать его в два шага. Сначала разрабатываем верхние уровни работ и результатов, это уровни, понятные всем участникам проекта. После согласования верхних уровней отдаем их узким спецам для профессиональной декомпозиции и тогда получим детальный состав работ и результатов проекта.
Никакой проект не является чистым производством продукта. Посмотрите на структуру работ примера со строительством домика – кроме собственно строительных работ мы имеем множество обеспечивающих работ: управление проектом, получение разрешений, сдача/приемка и т.д. Все эти дополнительные работы исполняются не из прихоти исполнителя проекта и не из желания больше работать и больше заработать. Совсем нет! Дополнительные работы возникают потому, что у каждого проекта, кроме требования производства основного продукта, всегда есть куча других требований, а, значит, и соответствующая этим требованиям куча других продуктов и результатов. Мы это обсудим, когда доберемся до участников проекта и их потребностей – еще один важный объект управления в модели проекта. Но так как нам нужна ясность, то мы будем именно добираться, а пока оставим эту тему на будущее.
Любая декомпозиция работы приводит к тому, что работа перестает быть собственно работой, она становится группой работ. А работами становятся ее компоненты нижнего уровня. Посмотрите на работу «Построить коробку» на рисунке выше. Пока мы ее не декомпозировали, она была нормальной работой, как ее соседи по уровню «Построить фундамент» и «Построить крышу». Но после декомпозиции истинными работами становятся ее составляющие, а она переходит в разряд логических группировок работ. И вообще, в иерархии работ «истинные работы» находятся в листьях дерева, то есть в низу каждой ветки, а все узлы дерева работ – это группы работ.
Посмотрите на две разные иерархии одних и тех же работ:
Рисунок 2.3. Первая иерархия работ
Рисунок 2.4. Вторая иерархия работ
Первая иерархия группирует работы по категориям «стены-полы-потолок», вторая – по категориям «сборка-отделка». Подчеркиваю – работы одни и те же, разные только группировки. Первая иерархия позволяет получить сводную информацию, например, стоимость в разрезе «стены-полы-потолок», вторая же не способна дать такой свод, зато способна дать стоимость в разрезе «сборка-отделка». Полезные своды? Конечно. Если понадобятся своды в других разрезах, нам придется определить соответствующую иерархию. А они понадобятся. Получается, что в проектах нам нужно иметь множество иерархий работ в целях получения множества сводов. Но вот вопрос – какую то иерархию ведь надо сделать главной, чтобы согласовывать ее с внешними участниками и не запутать вконец исполнителей? Ответ ниже.
С точки зрения планирования, работы являются следствием результатов, а с точки зрения исполнения, все наоборот – результаты являются следствием работ. Вы можете спросить – на что же опираться? Я отвечу вопросом на вопрос: что важнее – правильные работы или правильные результаты? Кто-то может возмутиться: - так вопрос ставить нельзя, важно и то, и другое. Согласен, важно и то и другое. Но в нашем мире одно все же важнее другого. Позвольте небольшое философское отступление.
Мир устроен так, что исполнители мыслят в терминах работ, а заказчики – в терминах результатов. Величайшая мечта исполнителя – работа без результата, но с оплатой, естественно. Величайшая мечта заказчика – результат немедленно без работ и желательно без оплаты. Так происходит потому, что заказчик не является специалистом в производстве нужного ему продукта, иначе он бы сделал его сам.
С другой стороны, согласитесь, результаты всегда виднее и ощутимее, чем работы. Результат, я уж не говорю про конечный продукт, можно пощупать, примерить, проверить. А работа? – Когда не делаешь ее сам, остается только смотреть, как работают другие – весьма интересное занятие.
Еще соображение - в современном конкурентном мире производство действует не ради самого себя, а ради потребителя, ради производства и продажи качественных и полезных продуктов. Поэтому «хорошие», «правильные» продукты и результаты – это интерес потребителя и они первичны. А «правильные» работы – это забота и головная боль производителя и, вообще, его внутреннее дело.
Есть еще немаловажный аспект – все мы являемся и исполнителями, когда действуем в своей профессиональной сфере, и потребителями – когда мы в иной сфере, когда нам нужно то, чего мы сделать сами не можем. В разных сферах у нас разный менталитет, в своей – нам нужны работы, в чужой – результаты. Можно целое эссе написать на тему «Жизнь – это обмен своих работ на чужие результаты», но пора возвращаться к ИСР.
Раз уж основной задачей проекта является продукт, то главным является именно он и результаты, а не работы, создающие продукт и результаты. Все! Точка. Поэтому та иерархия, которая лучше ориентирована на результаты, должна быть главной и именно ее называют ИСР.
Вот определение PMBOK:
Иерархическая структура работ (ИСР) – ориентированная на результаты иерархия работ.
То есть в качестве главной надо выбирать ту иерархию, которая лучше ориентирована на результаты.
В примере с двумя разными иерархиями «стены-полы-потолок» и «сборка-отделка» - которая лучше ориентирована на результаты?
Иерархическая структура работ завершается пакетами работ. Как мы говорили выше, пакет работ – это такой элемент структуры работ, про который менеджеру проекта все достаточно понятно, чтобы он мог управлять созданием этого элемента. Но управлять – не значит создавать! Для создания необходимо декомпозировать пакеты работ до уровня конкретных действий. Такие реальные действия, при исполнении которых расходуются реальные ресурсы, называются операциями.
Контрольные события и вехи – это важные моменты и события проекта. Они соотносятся с операциями так же как результаты с работами: контрольные события - это «результаты» операций. В программном обеспечении управления проектами контрольное событие – это квази-операция с нулевой длительностью.
Основным назначением контрольных событий и вех является контроль сроков. У любой операции есть две основных даты – даты начала и завершения. А два параметра – это слишком много для управления. Вехи имеют нулевую длительность и, соответственно, только одну дату – дату наступления. И, соответственно, отчет по вехам является основным инструментом контроля сроков проекта.
Так же, как и все содержание проекта, вехи имеют два уровня – верхний, уровень внешних интересантов, и нижний, уровень исполнителей. Вехи верхнего уровня служат для контроля исполнения проекта сверху и являются основными отчетными контрольными событиями проекта. Вехи нижнего уровня являются промежуточными контрольными событиями и служат для внутреннего контроля исполнения сроков исполнителями проекта.
Рекомендуется именовать работы и результаты так, чтобы уже по названию можно было отличать работы от результатов. А именно, результаты принято именовать существительными: «коробка», «крыша». А работы - глаголами: «построить коробку», «устроить крышу», или отглагольными существительными: «строительство коробки», «устройство крыши». Есть также рекомендация по именованию вех – глаголом в страдательном залоге: «коробка построена», «крыша устроена».
projectbureau.ru
Эта диаграмма показывает расположение контрольных событий относительно временной шкалы с целью обозначить ключевые даты и обратить на них внимание руководства (рис. 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
В каждом из проектов должны быть задачи, не имеющие длительности, так называемые Контрольные события(вехи). Обычно они отображают наступление важных событий проекта (например, «Подписан договор отвода земельного участка») или достижение запланированных результатов. В нашем учебном проекте контрольными событиями буду заканчиваться все этапы проекта.
Для того, что задачу сделать вехой, необходимо в окне Сведениях о задаче, на закладкеДополнительнопоставить флажокПометить задачу как веху (рис.3.4). Для того чтобы вставить новую веху в проект, необходимо на закладкеЗадачав областиВставитьнажать кнопкуВеха.
Перечень задач в проекте определяют, как правило, лица, ответственные за контроль реализации проекта. Уровень детализации операций проекта должен быть обязательно согласован с ответственным за проект (менеджером проекта) и с генеральным директором компании. В основу декомпозиций должен быть положен принцип достаточности, иначе такую операцию как, например, «разработка грунта вручную» (т.е. когда яму нужно выкопать), можно раздробить на элементарные операции типа: «поиск лопаты», «перекур» и т.п.
Чтобы определить, когда остановить декомпозицию и удовлетвориться достигнутой степенью детализации, рекомендуется использовать следующие правила:
на операции можно назначить определенных исполнителей, которые заняты на ней от начала и до конца;
продолжительность исполнения операций сопоставима с периодом учета исполнения;
на операции можно назначить стоимость и расход материалов.
Система управления проектами MicrosoftProjectориентирована на западные стандарты, которые далеко не всегда совпадают с отечественными стандартами. В данном учебном пособии мы будем рассматривать учебный строительный проект, в котором использовано такое понятие, как объем работ. Единицами измерения объема работ могут быть килограммы, квадратные метры, кубометры и т.д. В западных пакетах по управлению проектами такого понятия как объем работ нет, и вся отчетность идет через процент завершения и анализ освоенных объемов. Поэтому для учета объемов работ нам придется использовать соответствующие настраиваемые поля. Так настраиваемые числовые поля «Число1», «Число2», «Число3», «Число4» мы переименуем соответственно в «Плановый объем», «Выполненный объем», «Остаток по плану» и «% выполнения по объему». В колонку «Плановый объем» мы будем заносить информацию об объеме работы, необходимом для выполнения работы по плану. В колонке «Выполненный объем» будут размещаться данные о фактически выполненном объеме работ. В колонке «Остаток по плану» будет отображаться разница между запланированным и выполненным объемом работ. В колонку «% выполнения по объему» будет размещены результаты расчёта по соответствующей формуле.
Задание 3.3. Исследовать технологию создания настраиваемых полей. Создать пользовательские поля для моделирования объема работ (Плановый объем, Выполненный объем, Остаток по плану, % выполнения по объему), выполнив следующие операции:
Открыть проект Коттедж Задание 3.2. На вкладке Проект в области Свойства выбрать команду Настраиваемые поля.
В диалоговом окне Настраиваемые поля выбрать переключатель Задача и тип поля Число;
Выделить нужное поле (Число 1) и нажать кнопку Переименовать. В окне переименование поля записать Плановый объем. Аналогично переименовать поле Число 2 в поле Выполненный объем, Число 3 в Остаток по плану и Число 4 в % выполнения по плану.
Поле Остаток по плану будет рассчитываться как разница между Плановым объемом (Число1) и Выполненным объемом (Число2). Для того чтобы задать формулу для расчета поля, необходимо в окне Настраиваемые поля выделить нужно поле, в нашем случае Остаток по плану (Число3), в разделе Настраиваемые атрибуты переключиться на Формулу или нажать кнопку Формула и в окне Формула для … ввести формулу: [Число1]-[Число2]. Для этого нужно в нажать на кнопку Поле и в раскрывшемся меню Поле – Число – Настраиваемое число выбрать Плановый объем (Число1) и Выполненный объем (Число2)». Между выбранными полями нужно поставить знак «минус» (рис.3.7).
Рисунок 3.33. Создание формул
Так как в нашем проекте мы будет собирать отчетность и анализировать ход исполнения проекта через выполненные объемы работы, а Microsoft Project анализирует ход проекта только через встроенную колонку «% завершения», нам необходимо связующее звено, которым будет выступать настраиваемое поле «% выполнения по объему». Поле «% выполнения по объему» по идее должна рассчитываться по формуле: Выполненный объем (Число2) / Плановый объем (Число1) * 100. Установите эту формулу для поля % выполнения по объему и закройте диалоговые окна, нажав кнопку Ок. Сохраните проект под новым именем Коттедж Задание 3.3.
Примечание: следует учесть, что возможны следующие жизненные ситуации:
Когда планировали, например, залить 120 м3 бетона, а залили 150 м3. В этом случае «% выполнения по объему» равно 125%. Однако встроенное в Microsoft Project поле «% завершения» не может быть больше 100%. В этом случае:
Данная формула говорить о том, что если отношение выполненного объема к плановому будет меньше единицы, то будет отображаться реальный «% выполнения по объему», в другом случае, т.е. если отношение выполненного объема к плановому будет больше единицы, то «% выполнения по объему» будет считаться как 100%.
Когда планировали, например, залить 120 м3 бетона, а залили 115 м3. и больше не надо. В этом случае «% выполнения по объему» будет равно 92%. Значение в поле «% завершения» тоже будет отображаться как 92%. В этом случае, единственный вариант, это уменьшение значение планового объема до фактически выполненного, т.е. до 115 м3.
Прежде чем продолжить работу по установке связей между созданными полями (% выполнения по объему и % завершения) целесообразно провести соответствующие настройки окна программы – создать удобную информационную среду (ненужные сейчас поля скрыть, а нужные – вставить):
Вставьте в проект созданные пользовательские поля (Плановый объем, Выполненный объем, Остаток по плану, % выполнения по объему) и поле % завершения. Для того чтобы в столбце % выполнения по объему не было ошибок в столбец Плановый объем для каждой задачи нужно выставить соответствующие данные (в данном случае 100 для каждой вложенной задачи).
Рисунок 3.34. Вставка созданных пользовательских полей
Для установки связей между созданными полями (% выполнения по объему и % завершения) выделить поле % выполнения по объему, скопировать его (Ctrl + C), выделить поле % завершения, и на закладке Задача в разделе Буфер обмена нажать Вставить – Специальная вставка – Связать – Текстовые данные (рис.3.9). Теперь при любом изменении значений в столбце % выполнения по объему, значения в столбце % завершения будут пересчитываться. Сохраните внесенные в проект изменения. Для проверки работоспособности настроенных полей вставьте соответствующие данные в столбец Выполненный объем. Результаты проверки сохранять не надо.
Рисунок 3.35. Связывание полей
Кроме числовых полей нам понадобится текстовое поле Единица объема, которое будет содержать значения единиц измерения объемов работ. Для этого пользовательское полеТекст1 (рис. 3.10) переименовываем вЕдиница объема. Затем нажмите кнопкуПодстановкаи в появившемся окнеИзменение таблицы подстановки для Единицы объемав колонкеЗначениявведите единицы измерения объема работ - %, м3, м2, тонн, м.п., шт, компл. (рис. 3.11).
Рисунок 3.36. Настройка текстового поля
Рисунок 3.37. Настройка таблицы подстановки
В случае, если вы хотите какое-то значение использовать по умолчанию, то для него нужно выставить флажок Использовать значение из таблицы в качестве значения поля по умолчанию и нажать кнопку Задать значение по умолчанию.
Если вы чувствуете, что созданный список значений в процессе работы дополнять, нужно выставить флажок Разрешить ввод дополнительных элементов в поля.
Добавьте в проект после столбца Плановый объемсозданный столбецЕдиница объема, установите в столбце нужные единицы и сохраните все изменения в проекте. Сформулируйте выводы по результатам исследования, ответив на следующие вопросы:
Зачем и когда вы будете использовать настраиваемые поля?
Какие типы полей предусмотрены для задачи и для ресурса?
На какой основе создаются настраиваемые поля? Что может размещаться внутри настраиваемого поля?
Как создать формулу для размещения в настраиваемом поле?
Рисунок 3.38. Проект с включенными средствами моделирования объема работ
После того как удобная информационная среда создана можно приступать к детальному планированию проекта. Детализация будет заключаться в том, что в каждую суммарную задачу проекта мы вставим соответствующие вложенные задачи.
studfiles.net
Дата начала выполнения проекта: 01.08.2010
Дата завершения проекта: 01.10.2011.
Компания «Client Company» осуществляет данный проект совместно с компанией «Big&Co», выступающей генеральным подрядчиком по проекту.
Инициатор проекта (спонсор) – генеральный директор компании «Client Company» Большова Ю.Б.
Заказчик – компания «Client Company».
Руководители проекта, команда проекта – определены в п. .
Функциональные группы – будут определены в содержании проекта.
Генеральный подрядчик – «Big&Co».
Лицензоры – Microsoft.
Органы власти – Фонд социального страхования РФ, Пенсионный фонд РФ, Фонд обязательного медицинского страхования, налоговая инспекция, Правительство РФ.
Допущения
Все изменения содержания будут своевременно выноситься на рассмотрение управляющего комитета.
Критически важный персонал не покинет компанию.
Сроки выполнения проекта могут быть пересмотрены в ходе реализации проекта в сторону уменьшения.
Ограничения
Окружение проекта
При реализации системы Исполнитель обязан учитывать ограничения, накладываемые:
организационной структурой компании;
корпоративной культурой;
государственными стандартами и законодательством;
существующими в компании процедурами управления персоналом;
существующими человеческими ресурсами (навыки, знания, специализации).
Технологии
Проект должен быть реализован в рамках следующего программного обеспечения:
- Microsoft Dynamics AX;
- Microsoft SQL Server – СУБД, используемая для работы Microsoft Dynamics AX;
- Локальные ИС – локальные информационные системы Заказчика;
- Приложения Microsoft Office;
- Microsoft Visio, ARIS – графические системы для отражения бизнес-процессов («Как есть» и «Как будет»).
Совокупная стоимость проекта внедрения ERP-системы для компании «Client Company» составит 2 000 000 евро (без НДС). Данный показатель состоит из стоимости прав пользования ERP-системы (лицензионная составляющая), стоимости консалтинговых услуг и стоимости обучения конечных пользователей.
Инициатором (спонсором) проекта является генеральный директор компании «Client Company» Большова Ю.Б..
Руководителем проекта со стороны компании «Client Company» назначается ведущий специалист департамента информатизации компании «Client Company» Бахвалова Евгения Анатольевна.
Руководителем проекта со стороны «Big&Co» назначается Захарова Екатерина Павловна.
| Роль | ФИО | Контактная информация | Должностная ответственность |
| Спонсор проекта со стороны компании «Client Company» | Большова Юлия Борисовна | 119017, г. Москва, ул. Большая Ордынка, д.24/26 (офисный адрес), тел. 8(495)7889085 (доб.1234) |
|
| Спонсор проекта со стороны «Big&Co» | Никитин Павел Борисович | Малая Ордынка, д.27 (офисный адрес), тел. 8(495)7950807 (доб.8123) |
|
| Руководитель проекта со стороны компании «Client Company» | Бахвалова Евгения Анатольевна | 119017, г. Москва, ул. Большая Ордынка, д.24/26 (офисный адрес), тел. 8(495)7889085 (доб.1235) |
|
| Руководитель проекта со стороны «Big&Co» | Захарова Екатерина Павловна | 119018, г. Москва, ул. Малая Ордынка, д.27 (офисный адрес), тел. 8(495)7950807 (доб.8976) |
|
| Команда исполнителей проекта – предмет дальнейшего уточнения при планировании проекта. Содержание проекта утверждает управляющий комитет | |||
В сферу общей ответственности руководителей проекта входит:
контроль хода реализации проекта и отслеживание планов работ по программе;
обеспечение эффективной взаимосвязи между членами рабочих групп в рамках проекта;
обеспечение своевременного решения возникших проблем или своевременной их передачи на соответствующий уровень для рассмотрения;
утверждение существенных изменений, вносимых в программу;
обеспечение своевременного создания выходных документов и предоставления их на рассмотрение и утверждение председателю управляющего комитета и управляющему комитету;
регулярное сообщение о статусе проекта председателю управляющего комитета.
Для выполнения проекта формируется проектная команда. В ее состав включаются сотрудники Заказчика и Исполнителя. Проектная команда утверждается руководителями проекта. Для каждого члена проектной команды определяются его роль и область ответственности. В ходе выполнения проекта состав проектной команды и полномочия членов команды могут быть изменены и дополнены.
Для выполнения работ проекта могут привлекаться специалисты Заказчика, обладающие специфическими знаниями предметных областей.
Описание содержания проекта будет представлено на рассмотрение управляющего комитета 10 сентября 2009 года руководителем проекта со стороны «Big&Co» Захаровой Е.П.
studfiles.net
В – выполняет; У – утверждает; И – информируется; К – контролирует; М – мониторинг; С – согласует.
poisk-ru.ru
В разделе перечислены в табличном виде существенные события проекта уровня Заказчика проекта и ожидаемое время их наступления.
Рисунок 2. Перечень контрольных событий
План управления изменениями расписания
Управление изменениями осуществляется по общим принципам принятым в Организации, описанным в документе «Методология управления проектами» (п. 6.17.1. Общее управление изменениями проекта).
План управления стоимостью
Стоимостные показатели объекта строительства / реконструкции
| Наименование показателей | Стоимость в ценах 2008 года | Выполнено на 1.01.2008 | Подлежит выполнению до конца работ в ц.2008 г. | в том числе | ||
| всего | в том числе в 2007 году | в 2008 году | в после-дующие годы | |||
| Основные фонды | 1 243 812,91 | 1 243 812,91 | 1 243 812,91 | |||
| Капвложения, всего | 1 243 812,91 | 756 182,28 | 680 385,50 | 487 630,63 | 487 630,63 | 0,00 |
| в том числе: | ||||||
| Затраты подрядчика, всего | 1 046 468,92 | 665 899,40 | 629 056,99 | 380 569,52 | 380 569,52 | 0,00 |
| из них возвратные суммы | ||||||
| Затраты заказчика, всего | 197 343,99 | 90 282,88 | 51 328,51 | 107 061,11 | 107 061,11 | 0,00 |
| из них: | ||||||
| предпроектная документация (с учетом экспертизы) | ||||||
| проектная документация (с учетом экспертизы) | 8 455,79 | 8 455,79 | ||||
| затраты по отводу земель и оформлению прав на них | 1,86 | 1,86 | 1,86 | |||
| компенсационные выплаты | 138 835,50 | 78 335,01 | 48 241,91 | 60 500,49 | 60 500,49 | |
| непредвиденные работы и затраты | 34 321,29 | 34 321,29 | 34 321,29 | |||
| Незавершенное производство | х | х | х | х |
План управления изменениями стоимости
Управление изменениями осуществляется по общим принципам принятым в Организации, описанным в документе «Методология управления проектами» (п. 6.17.1. Общее управление изменениями проекта).
План управления качеством
Цели в отношении качества
· Завершение Проекта в соответствии с действующими стандартами в отношении качества.
· Реализация Общей программы управления качеством Проекта (англ. сокр. ISO9001) c целью улучшения качества работы всех участников Проекта. Особое внимание в Общей программе управления качеством должно быть уделено следующим вопросам:
o производственная безопасность, охрана здоровья и личная безопасность персонала, безопасность собственности;
o разработка и использование технических решений созданных по концепции экономичности не в ущерб качеству;
· Завершение Проекта без заключений Заказчика о несоответствиях техническим требованиям.
· Завершение Проекта без переделок как по причине несовершенства ПСД так и по причине несоблюдения технологий строительства.
Организационная структура контрольной деятельности по проекту
Организационная структура контрольной деятельности в проекте определяется и устанавливается Заказчиком проекта, и включает в себя: контроль качества проведения работ закрепленным представителем Заказчика (Куратор проекта), плановые и внеплановые проверки лабораторией контроля качества дорожных работ. На протяжении всего срока действия Проекта Подрядчик использует обычные проверенные практикой системы и процедуры контроля.
6.4.3. График плановых проверок
В разделе в табличном виде приводится график плановых проверок
| Цель выезда | Дата выезда | Плановый / внеплановый |
| Контроль качества СМР (ОККДР УАД) - | 1 раз в месяц | плановый |
| Проверка оформления исполнительной документации по выполненным работам и соответствия выполненных работ требованиям нормативных документов и проектной документации (ИГСН ПК, ОПВДР УАД) | 1 раз в 2 месяца | плановый |
| Контроль качества СМР (ОПВДР УАД) | 2 раза в неделю | плановый |
6.5. План управления обеспечения проекта персоналом (управление командой проекта)
Руководитель проекта определяет требуемых для выполнения работ исполнителей и формирует ресурсный план проекта, который включает информацию об исполнителях и временных промежутках, в которые необходимо участие этих исполнителей.
В случае решения о привлечении внешних специалистов согласование запроса на ресурс, стоимости ресурса и планирование загрузки ресурса производятся Руководителем проекта с руководством подрядной организации.
Участники проекта
| Государственный заказчик | Дорожное агентство Пермского края |
| Заказчик-застройщик | Государственное учреждение «Управление автомобильных дорог» Пермского края |
| Проектная организация, дата и номер договора | Пермское краевое государственное унитарное предприятие «Пермдорпроект», договор от 25.08.2004г. №24 |
| Организация, выдавшая экспертное заключение, его дата | Главгосэкспертиза России Управление по Свердловской области Положительное заключение от 16.10.2006г. №06-110 |
| Дата и номер протокола результатов конкурса, кем утвержден | Протокол №2/4 от 06.09.2006г. повторной оценки и сопоставления заявок на участие в конкурсе на право заключения государственного контракта на выполнение работ на строительство объекта «Южный обход г. Перми», председатель конкурсной комиссии Е.В.Зырянова |
| Генеральная подрядная организация, дата и номер договора | ОАО «Пермдорстрой», Государственный контракт №05-06-стр от 16.09.2006г. на строительство объекта «Южный обход г. Перми» |
| Подрядные организации | СУ-1 ОАО «Пермдорстрой», ЗАО «Уралмостострой» Мостоотряд-123 и Мостоотряд-59, ООО «СпецМонтажПроект», ОАО ППМП «Востокпромсвязьмонтаж», ООО «Электрострой», ООО ПМК-214, МУП НО «Горсвет» |
Рабочая группа проекта
| Роль в проекте | Ф.И.О. | Должность, контакты |
| Руководитель проекта | Вольф Владимир Федорович | Начальник ГУ «Управтодор» 8 902 472 39 71 |
| Представитель ГРБС | Даниелян Глеб Иосифович | Руководитель Дорожного агентства Пермского края 8 342 298 34 34 |
| Инженер ОПВДР (Куратор) | Лубнин Александр Владимирович | Зам. начальника ОПВДР ГУ «Управтодор» 8 908 259 99 52 |
| Администратор проекта (ЦУП) | Днепровская Лидия Валерьевна | Главный специалист ЦУП ГУ «Управтодор» 244 69 95 |
| Инженер ОПДРиЭ | Федотов Юрий Александрович | Зам. начальника ОПДРиЭ ГУ «Управтодор» 8 902 648 50 09 |
| Юридическое сопровождение проекта | Запольских Альберт Владимирович | Юрист Дорожного агентства Пермского края |
| ГИП проекта | Спирин Николай Александрович | Главный инженер проектов ПКГУП «Пермдорпроект», т.212-51-24 (8 951 931 65 35) |
| Авторский надзор | Спирин Николай Александрович, Давыдова Ирина Петровна | Главный инженер проектов ПКГУП «Пермдорпроект» т.212-51-24 (8 951 931 65 35) т.212-51-24 (8 912 982 00 88) |
| Руководитель проекта от ген. подрядчика | Голубев Сергей Михайлович | Руководитель проектов ОАО «Пермдорстрой 8 902 476 02 34 |
| Эксперты | Карабаев Владислав Евгеньевич | Зам. начальника ОККДР ГУ «Управтодор» 244 90 28 |
cyberpedia.su
Лекция 5. Управление сроками проекта
Определение состава операций. Инструменты и методы. Список плановых операций. Параметры операций. Список контрольных событий. Определение взаимосвязи операций. Оценка ресурсов операций. Инструменты и методы Требования к ресурсам операции. Календарь ресурсов. Оценка длительности операций. Понятие длительности операций, периода времени выполнения операций. Разработка расписания. Инструменты и методы. Базовый план расписания. Управление расписанием. Отчетность о прогрессе проекта. Анализ отклонений по срокам. Управление расписанием.
Ключевые слова: пакет операций, список операций, параметры операций, взаимосвязи операций, контрольные события (вехи проекта), ресурсы операции, календарь ресурсов проекта, длительность операции, расписание проекта, базовый план расписания проекта.
Процессы управления сроками проекта
Согласно РMBOК [5.1], управление сроками проекта (time management) – это процесс, используемый для обеспечения своевременного завершения проекта..
Управления сроками проекта состоит из шести процессов [5.1]:
Определение состава операций – процесс определения конкретных плановых операций, которые необходимо выполнить для получения результатов проекта – внедрения ИС.
Определение взаимосвязей операций – процесс выявления и документирования последовательности выполнения плановых операций.
Определение ресурсов операции – процесс определения, необходимых для выполнения каждой плановой операции ресурсов и их количества.
Определение длительности операций – процесс определения продолжительности выполнения каждой плановой операции.
Разработка расписания – процесс составления расписания проекта с учетом последовательностей операций, их длительности, требований к ресурсам и ограничений на сроки выполнения проекта в целом.
Управление расписанием – процесс управления изменениями расписания проекта.
Первые пять процессов относятся к группе процессов планирования, шестой – к группе процессов мониторинга и управления. Процессы взаимодействуют как между собой, так и с процессами из других областей знаний.
Процессам управления сроками проекта предшествует процесс планирования, определяющий формат и критерии разработки и контроля расписания проекта, управления проектом, в ходе которого разрабатывается план управления расписанием. План управления расписанием входит в план управления проектом, либо является его вспомогательным планом.
На рисунке 5.1 показана последовательность процессов, приводящая к разработке расписания проекта и затем к управлению расписанием. Разработка расписания проекта начинается с определения состава операций. После того как операции определены, между ними устанавливаются взаимосвязи. Для того чтобы определить длительность операций следует определить специалистов, которые будут выполнять операции. Уровень их квалификации оказывает влияние на длительность операции. Рассмотрим подробнее, каким образом определяются операции проекта, их взаимосвязи, требуемые ресурсы, длительность операций, как составляется расписание проекта и осуществляется управление им.
Рис. 5.1.Связь процессов управления сроками проекта.
Определение состава операций предполагает определение и документирование работ, запланированных для выполнения. Инструментальным средством для определения состава операций, а также для оценки их взаимосвязи и длительности служит ИСР. В предыдущем разделе был рассмотрен вопрос создания иерархической структуры работ путем декомпозиции. Напомним, что результатом процесса декомпозиции является нижний уровень работ, необходимых для завершения проекта. В процессе декомпозиции определяется нижний уровень управления, с которым работает руководитель проекта - уровень пакетов работ. Пакеты работ, как правило, определяются Методологией внедрения ИС. Пакет работ состоит из операций, имеющих общие функции или конечный результат.
Пакеты работ разбивают на операции. Операция - это единица работ, в результате которой имеется конкретный результат по внедрению информационной системы.
Перед началом определения состава операций рекомендуется еще раз проанализировать описание содержания проекта, ограничения и допущения с точки зрения полноты списка операций, который будет основой для составления смет, планирования сроков, выполнения и контроля проектных работ.
Состав операций может определяться последовательно, методом набегающей волны. Этот метод используется в крупных или долгосрочных проектах, когда имеется неопределенность относительно выполнения некоторых работ. При использовании метода набегающей волны пакеты работ, расположенные в отдаленном будущем, планируются только на высоком уровне, в то время как пакеты работ, расположенные ближе по оси времени планируются детально.
Входом для процесса определения состава операций являются [5.1]:
Методология внедрения ИС
Контракт
Описание содержания проекта
Иерархическая структура работ (ИСР)
Словарь ИСР
Для определения состава операций используют следующие инструменты и методы:
Процесс определения состава операций завершается формированием следующих документов[5.1]:
Список операций – перечень работ, запланированных для выполнения.
Параметры операций – могут включать в себя идентификатор операции, коды операции, длительность, начало, окончание, исполнителя операции, перечни предшествующих и последующих операций, логические взаимосвязи, опережения и задержки, плановая трудоемкость работ и другие необходимые для управления проектом параметры операций.
Список контрольных событий (вех проекта) – определяет все контрольные события расписания, необходимые для контроля хода выполнения и управление проектом. Список контрольных событий является элементом плана управления проектом. Вехапроекта определяет момент перехода проекта из одного состояния в другое. Важным отличием вех от операций проекта является то, что они не имеют длительности.
Запрошенные изменения – изменения в составе работ, которые могут появиться в ходе выполнения работ по внедрению ИС и повлиять на описание содержания проекта.
Примеры состава операций и контрольных событий (вех проекта) представлены в таблице 5.1. и 5.2
Таблица 5.1
Пример списка состава операций.
| Наименование пакета работ | Наименование операций |
| Обследование | Формирование и согласование плана проведения интервью Подготовка и рассылка опросных листов для интервью Проведение интервью для описания бизнес-процессов |
| Описание бизнес-процессов | Описание бизнес-процессов по функциональной области Финансы. Описание бизнес-процессов по функциональной области Логистика. Описание бизнес-процессов по функциональной области Персонал |
| Разработка системы | Разработка решений по функциональной архитектуре. Подготовка функционального дизайна расширений. Настройка системы. Техническое проектирование расширений. Разработка расширений. Техническое проектирование программ конвертации данных Разработка программ конвертации данных Планирование тестирования приложения и интеграционного тестирования |
| Тестирование системы | Разработка сценариев тестирования Подготовка тестовых данных Проведение тестирования по функциональным областям Финансы, Логистика, Персонал Проведение интеграционного тестирования Проведение тестирования конвертации данных |
Таблица 5.2
Пример списка вех проекта.
| Вехи проекта |
| Входящие вехи проекта: Начало работ акцептовано Заказчиком Рабочие места подготовлены Команда проекта сформирована Подготовлено и проведено стартовое совещание Утверждено расписание проекта. Вехи проекта: Завершен сбор информации для описания бизнес-процессов Обследование завершено Завершена разработка системы Завершено приемочное тестирование Завершено тестирование производительности Готовность к конвертации данных Готовность к развертыванию системы. |
Планирование сроков проекта может быть выполнено с помощью специализированных программных средств. Пример планирования сроков работ в специализированной системе MS Project приведен на рисунке 5.2.
Рис. 5.2. Планирование работ в MS Project
studfiles.net
