Управление проектами по созданию программного обеспечения. Количество контрольных точек проекта

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

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

Элементы проекта.

1.        Цель проекта. Измеряемый конечный результат (выход, продукция), определяемый в терминах затрат, качества и времени реализации (чего? Сколько? И когда?).

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

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

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

5.        Жизненный цикл. По мере реализации проекта изменяется потребность в тех или иных ресурсах. Это изменение идет в определенной предсказуемой последовательности.

С точки зрения планирования и контроля проект целесообразно разбивать на этапы:

Процесс планирования и управления проектом состоит из 5 этапов:

1)        Этап 1. Среда проекта, влияющие на проект внутренние и внешние факторы.

2)        Этап 2. Формулирование проекта – постановка целей, задач и выработка стратегии реализации проекта.

3)        Этап 3. Планирование проекта – система мероприятий по реализации проекта.

4)        Этап 4. Техническое исполнение – непосредственное техническое выполнение пунктов плана проекта (набора мероприятий).

5)        Этап 5. Управление проектом – контроль за выполнением проекта в соответствии с планом.

Формулирование проекта.

В основе лежат 3 элемента:

•          Цели проекта – чего достигнет проект в своей конечной точке,

•          Задачи проекта – спектр работ и операций (мероприятий) пот проекту,

•          Стратегия – каким путем руководители проекта приведут его к цели (способ достижения цели).

Иерархия целей.

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

Ясность цели. Хорошая цель – это ясная цель, измеримая, предпочтительно количественно. Для уяснения цели проект полезно разбить на 3 составляющие:

1)        цель – преодолеть кризис, предотвратить спад производства, обеспечить запланированный объемы выпуска продукции;

2)        конечный результат – представить отчет о причинах снижения производственных показателей и рекомендуемых мерах по исправлению положения дел;

3)        критерий успеха – отчет должен быть готов к 30 июня, рекомендации должны предусматривать объем выпуска на уровне не ниже 70 тонн в год, а стоимость плана мероприятий (рекомендаций) не должна превышать 100 тыс. долл.

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

Затрагиваемые части организации (например, «разработка и монтаж системы автоматической транспортировки грузов на складе»).

Срок исполнения («Монтаж начинается 15.01 и завершается не позднее 2.03»).

Используемый бизнес-процесс. «Интерфейс между системой приема заказов и системой размещения товаров на складе».

Необходимые ресурсы. «Использовать собственную силовую линию и ограничить количество рабочих численностью в 5 человек».

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

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

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

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

Качество – результат должен соответствовать цели, работать так, как задумано.

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

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

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

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

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

Стратегия проекта.

Стратегия проекта – это способ достижения целей и показателей проекта.

Пример: 2 вида стратегии Олимпиады в Сочи: 1) все объекты строить в самом Сочи, 2) сделать Сочи только титульной столицей.

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

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

•          Этап спецификации – учет требований потребителей, составление спецификаций системы.

•          Этап разработки – определение структуры системы и составление спецификаций подсистем.

•          Этап реализации – разработка модулей.

•          Этап тестирования модулей – каждый модуль тестируется отдельно.

•          Этап поставки – передача системы покупателю.

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

1.        Согласование общей концепции с клиентом;

2.        Подготовка и согласование сценария;

3.        Съемка рекламного ролика;

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

5.        Окончательная съемка ролика, согласованного с клиентом.

Выявление отношений и зависимостей.

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

Выявление ограничений.

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

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

Ограничение по времени – главный приоритет – завершение проекта точно в срок. После использования накопленных ресурсов привлекаются дополнительные «пороговые» ресурсы.

 Кто же такой - РУКОВОДИТЕЛЬ  ПРОЕКТА?

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

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

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

Из чего складывается компетентность менеджера проекта

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

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

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

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

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

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

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

Эти качества особенно важны, так как подчиненные обычно воспроизводят стиль работы руководителя;

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

Подготовка и сертификация менеджеров проектов

Как становятся менеджером проектов? Есть несколько основных путей.

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

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

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

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

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

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

- Сдать экзамены на степень МВА. Вы получите много полезных знаний «из первых рук»: от консультантов и топ-менеджеров, преподающих в крупных бизнес-школах, а также расширите свои деловые связи. Основные недостатки — высокая стоимость и нередко недостаток практики. Удобно то, что учиться можно по вечерам.

- Пройти очное или заочное обучение в западных бизнес-школах, большинство из которых сейчас готовят специалистов в сфере проектного управления. Например, знаменитые французская LILLE Graduate School of Management ианглийский Henley Management College UK.

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

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

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

Общепринятые системы сертификации базируются на одном из двух принципов:

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

-«деятельностный» или «менеджерский», принятый в качестве стандарта более чем в 30 странах мира и основанный на Международных требованиях к компетентности менеджеров проектов ICB IPMA. Его основу разработала Международная ассоциация управления проектами IPMA, представленная в нашей стране Российской ассоциацией управления проектами СОВНЕТ. Пройдя сертификацию IPMA, можно подтвердить свое соответствие одному из четырех уровней: от «сертифицированного специалиста по управлению проектами» (уровень D),способного быть членом проектных команд, до «сертифицированного директора программ или проектов» (уровень А),который способен управлять всеми проектами компании, или проектами ее отделения, или всеми проектами программы (группы взаимосвязанных проектов). В зависимости от уровня экзамен может состоять из письменных тестов, собеседований с асессорами, решения практических задач (кейсов), представления отчетов о ранее реализованных проектах.

Система непрерывного обучения РМ

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

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

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

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

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

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

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

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

- система отбора проектов и мониторинга их эффективности;

- система отбора персонала в проекты: как с внешнего рынка, так и внутри компании;

- система расстановки кадров;

- система карьерного роста, включая управление кадровым резервом компании;

-система наставничества;

-система материальной и нематериальной мотивации персонала.

Перспективы для РМ

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

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

По проектному принципу построена работа большинства ИТ-компаний и системных интеграторов, консалтинговых фирм.

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

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

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

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

ГОСТ Р 54871- 2011 Управление-программой-проектов.pdf

ГОСТ Р 54870—2011 Проектный менеджмент. Требования к управлению портфелем проектов.pdf

ГОСТ Р 54869—2011 Проектный менеджмент. Требования к управлению проектом.pdf

       Также, мы хотим предложить Вашему вниманию несколько статей по данной тематике:

Проф пригодность руководителя.pdf

Сто правил руководителей проектов NASA.pdf

Словарь ненормативной лексики руководителя .pdf

Сертификация.pdf

Роль руководителя проекта.pdf

Нормативные документы:

Хрестоматия руководителя проекта.docx

Хрестоматия руководителя проекта.pdf

http://www.cons-systems.ru/

cons-systems.ru

Определение проекта. Часть 1. Определение объема проекта.

Определение проекта. Часть 1. Определение объема проекта.

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

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

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

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

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

Использование контрольного перечня проекта

Очевидно, что объем проекта – основа, фундамент, на котором строят все элементы плана. Чтобы проверить правильность определения объема, эксперты советуют использовать нижеприведенный список:

1. Основная цель.
2. Список задач.
3. Вехи проекта.
4. Технические требования.
5. Исключения.
6. Анализ совместно с заказчиком.

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

Основная цель

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

Список задач

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

Вехи проекта

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

Технические требования

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

Исключения

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

Анализ совместно с заказчиком

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

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

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

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

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

gantbpm.ru

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

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

Журнал «Инициативы XXI века» является не только научным, но и просветительским изданием, поэтому позволю себе напомнить ряд теоретических положений. Так называемый Базовый план проекта должен содержать, в соответствии с теорией, 9 разделов, соответствующих 9 областям знаний в управлении проектами:

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

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

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

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

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

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

1. Плановый объем (плановая стоимость запланированных работ, ПСЗР, англ. Budget Cost of Work Scheduled, BCWS, Planned Value, PV) — бюджетная стоимость работы, которая согласно расписания должна быть выполнена в результате операции или элемента ИСР к определенному сроку.
2. Освоенный объем (плановая стоимость выполненных работ, ПСВР, англ. Budget Cost of Work Performed, BCWP, Earned Value, EV) — указанный в бюджете объем работы, действительно выполненный в результате плановой операции или элемента ИСР в течение определенного отрезка времени.
3. Фактическая стоимость (фактическая стоимость выполненных работ, ФСВР, англ. Actual Cost of Work Performed, ACWP, Actual Cost, AC) — общая стоимость выполнения работы в результате плановой операции или элемента ИСР в течение определенного периода времени.

Следует сразу сделать две оговорки:

• Применение метода освоенного объема возможно лишь тогда, когда Базовый план построен по типу PMB (англ. Performance Measurement Baseline), то есть, как минимум, должен быть прописан временной график осуществления затрат по проекту.
• Как известно, затраты по проекту могут быть разделены на прямые, оцениваемые методом «снизу вверх» при помощи назначения и стоимостной оценки ресурсов, необходимых для выполнения работ из ИСР и накладные, которые не могут быть соотнесены с тем или иным элементом ИСР экономически целесообразным способом и относятся на проект в целом по некоторому правилу. По моему мнению, контролю при помощи метода освоенного объема поддаются только прямые затраты.

CV и SV производные

Отклонение по стоимости (ОСТ, англ. Cost Variance, CV) — представляет собой разность освоенного объема EV и фактической стоимости АС.

Отклонение по срокам (ОСР, англ. Schedule Variance, SV) — представляет собой разность между освоенным объемом EV и плановым объемом PV.

CPI и SPI индексы

Индекс выполнения стоимости (ИВСТ, англ. Cost Performance Index, CPI) — равен отношению освоенного объема EV к фактическим затратам АС.

Индекс выполнения сроков (ИВСР, англ. Schedule Performance Index, SPI) — равен отношению освоенного объема EV к плановому объему PV.

Базовые правилах метода освоенного объема

Правило 1

Если освоенный объем превышает фактические затраты, т.е.

имеет место экономия бюджета. Если же наоборот, фактические затраты превышают освоенный объем,

то имеет место перерасход бюджета.

Правило 2

Если освоенный объем превышает плановый, т.е.

имеет место опережение графика. Если же наоборот, плановый объем превышает освоенный,

то имеет место отставание от графика.

Эти два правила становятся абсолютно очевидными, если плановый объем PV интерпретировать, как то, что на некоторую дату необходимо сделать в стоимостном выражении, освоенный объем EV, как то, что фактически сделано на эту дату в стоимостном выражении, а фактические затраты AC, как стоимость средств, затраченных к рассматриваемой дате для достижения целей проекта.

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

Графики метода освоенного объема

Метод освоенного объема допускает удобное геометрическое толкование (рисунок 1).

Рисунок 1. Графики метода освоенного объема

Совмещая три графика PV, EV и AC в зависимости от времени, мы можем сделать выводы относительно экономии/перерасхода бюджета и опережения расписания / отставания от расписания (рисунок 2)

Рисунок 2. Контроль сроков и расходов проекта по граификам освоенного объема

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

Также можно получить картину изменения статуса проекта, вычисляя в фиксированные даты индексы выполнения сроков и стоимости и отмечая соответствующие точки на плоскости в осях (SPI, CPI) (рисунки 3а и 3б).

Рис. 3а

Рис. 3б

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

Для решения данной задачи обычно вычисляют:

Критический коэффициент (англ. Critical Ratio, CR), равный произведению индекса выполнения сроков и индекса выполнения стоимости:

Если критический коэффициент превышает единицу, т.е.

то статус проекта следует признать удовлетворительным, и неудовлетворительным, если имеет место обратное неравенство:

Для иллюстрации метода EV рассмотрим простой пример проекта, ИСР которого представлена в Таблица 1.

Данный проект состоит из двух задач верхнего уровня (1.1 и 1.2), связанных параллельно (тип связи SS = Start-to-Start), внутри которых рабочие пакеты (задачи нижнего уровня 1.1.1, 1.1.2 и 1.2.1, 1.2.2) связаны последовательно (тип связи FS = Finish-to-Start). В таблице указана лишь оценочная длительность рабочих пакетов (например, в днях). Длительность выполнения задач верхнего уровня и всего проекта легко вычисляется при помощи сетевой диаграммы проекта, показывающей временную зависимость между рабочими пакетами. Используя сетевую диаграмму, можно найти и критический путь проекта, т.е. последовательность задач, имеющих нулевой запас времени (рисунок 4).

Рисунок 4. Критический путь на сетевой диаграмме.

Маркировка рабочих пакетов производится следующим образом (рисунок 5). Считается, что длительность выполнения задач D известна. Дата раннего старта ES определяется из тех соображений, что до этой даты предшествующие задачи не будут выполнены, тогда дата раннего финиша EF находится из соотношения.

EF = ES + D

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

LS = LF — D

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

TS = LS — ES = LF — EF

Рисунок 5. Старт и финиш задач

Итак, длительность выполнения проекта составляет 16 дней, а прямые расходы BAC (Budget at Completion) — $3,300.

Предположим теперь, что нам нужно осуществить на 12-й день мониторинг статуса проекта. Построив диаграмму Гантта (рисунок 6), мы можем увидеть, что к этому сроку по плану должны быть завершены работы по задачам 1.1.1 и 1.2.1, а задачи 1.1.2 и 1.2.2 будут находиться в стадии выполнения. Критический путь на диаграмме Гантта показан серым цветом.

Каков алгоритм вычисления планового объема 1? Необходимо вычислить сумму прямых расходов по проекту (по всем задачам), умноженных на плановый процент выполнения работ. Таким образом, если работа по плану должна быть выполнена полностью, то плановый процент выполнения составляет 100%, если работа в соответствии с планом не должна быть начата к дате мониторинга, то плановый процент равен 0%. Как быть с работами, которые к данному моменту времени начаты, но не завершены? При решении практических задач на курсах по управлению проектами многие тренеры и преподаватели предлагают следующий геометрический подход.

Пусть плановая длительность работы составляет (X + Y) единиц времени, и в соответствии с планом на момент проведения мониторинга должно пройти X ед. (Y ед. — оставшаяся часть). Тогда плановый процент выполнения работы вычисляется по формуле:

Рис. 6

Этот метод определения планового процента выполнения работ является частным случаем метода эквивалентных выполненных единиц. Основываясь на вышеизложенной методологии и приписав задачам 1.1.2 и 1.2.2 плановые проценты выполнения, равные 4/6 и 5/9 соответственно, мы можем вычислить плановый объем PV на 12-й день выполнения проекта:

Предположим, что работы по задаче 1.1.1 были завершены досрочно (на 2 дня раньше), а выполнение работ по задаче 1.2.1 задержалось на 3 дня. К 12-му дню (дата осуществления мониторинга) выполнение работ по задачам 1.1.2 и 1.2.2 завершено не было (рисунок 7). Фактическая длительность работ показана штриховкой.

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

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

Метод фиксированной формулы

Этот метод еще называют методом (50%/50%, 20%/80% и т.д.) Суть его состоит в том, что в момент начала работ по задаче ей сразу приписывают процент выполнения, равный . Оставшиеся приписываются лишь после полного завершения работ. Этот способ достаточно субъективен, но прост в использовании и, по крайней мере, задает известные «правила игры». Соотношение должно фиксироваться в Корпоративном Стандарте Управления Проектами в части, посвященной методологии мониторинга статуса проекта.

Метод фиксированных вех

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

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

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

Метод эквивалентных выполненных единиц

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

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

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

Вернемся к рассматриваемому примеру. Пусть при помощи одного из описанных методов мы определили процент выполнения работ по задачам 1.1.2 и 1.2.2 (5/6 и 6/9 соответственно).

Рисунок 7.

Тогда освоенный объем EV на 12-й день выполнения проекта равен:

Предположим далее, что фактические затраты по проекту AC составляют $3,100. Теперь мы можем вычислить все производные величины и индексы:

отклонение по стоимости

отклонение по срокам

индекс выполнения стоимости

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

критический коэффициент

Основываясь на полученных данных, мы можем сделать вывод, что в проекте имеет место перерасход бюджета (EV < AC, CV < 0, CPI < 1), но происходит опережение графика (EV > PV, SV > 0, SPI > 1). При этом статус проекта следует признать удовлетворительным, поскольку перерасход бюджета компенсируется опережением графика (CR > 1).

Мы разобрали на тривиальном примере, как работает метод EV. Но уже на этом примере можно продемонстрировать некоторые проблемы, связанные с его применением. Изменим значения фактического процента выполнения с 5/6 до 1 (100%) для задачи 1.1.2 и с 6/9 до 4/9 для задачи 1.2.2. Значение освоенного объема при этом составит $2,800, что теоретически по прежнему свидетельствует об опережении графика. Однако, если задача 1.1.2 действительно завершена с опережением графика, то по задаче 1.2.2 мы имеем очевидное запаздывание, причем задача 1.2.2 находится на критическом пути проекта. Поэтому, несмотря на позитивные значения показателей метода EV, имеет место отставание от графика. Следовательно, применение метода EV следует сочетать с анализом критического пути.

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

EV -> PV, SV -> 0, SPI -> 1

в силу чего стоимостное выражение отклонения по срокам перестает давать адекватную оценку выполнения расписания. В [3] вместо стоимостных характеристик расписания предложено рассматривать временные, т.н. затраченное время или Elapsed Working Time, однако, методология вычисления этой величины изложена неясно.

Если говорить о практической ценности использования критического коэффициента CR для оценки статуса проекта, то здесь также возникает достаточно много вопросов. Метод предусматривает формальное перемножение двух факторов, один из которых характеризует отклонение от расписания, другой — от бюджета. При этом абсолютно игнорируются приоритеты в выполнении проекта (так называемая модель тройных ограничений, Triple Constraints). Более того, как отмечалось выше, фактор SPI, отвечающий за отклонение от расписания, описывает положение дел неадекватно. Даже игнорируя проблему адекватности оценок отклонения от графика и бюджета, задаваемых введенными индексами, стоит задуматься о следующем. Если в некотором условном пространстве параметров проекта выделить гиперповерхности, задаваемые уравнениями

CPI = 1, SPI = 1, CR = 1

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

CPI > 1, SPI > 1, CR > 1

сколько то, насколько далеко параметры проекта отошли от этой границы.

В частности, в рассмотренном примере, что показывает лишь 0,5% «положительного эффекта», а это означает что проект находится в зоне риска. Т.е., например, небольшое изменение в фактических процентах выполнения работ (которые, как мы видели, достаточно субъективны) может привести к уходу в «область неэффективности».

Тем не менее, большие систематические отклонения от единицы в положительную сторону индексов CPI, SPI и CR (например, более 20%) может означать отнюдь не качественную работу команды проекта, а преднамеренную заниженность плановых показателей.

Перейдем к анализу проблемы, заявленной в самом начале статьи — к обсуждению методологии контроля стоимости проекта. Возвращаясь к рассмотренному примеру, зададимся вопросом, откуда взялось значение? Цитируемое по [2] определение фактических затрат AC (см. выше), не дает никакого понимания природы этой величины. Оно тавтологично и по сути, сводится к формуле:

Фактические затраты = Фактические затраты !

Как известно, в практике бухгалтерского учета существует два метода признания доходов / расходов — кассовый метод и метод начисления. При использовании первого метода затраты признаются по факту «выгона» денежных средств из организации, направленных на достижение целей проекта на определенную дату. Во втором случае мы должны признавать затраты на определенную дату, например, по закрытым счетам-фактурам. Если мы будем основываться на кассовом методе признания затрат, то расхождение между освоенным объемом EV и фактическими затратами AC может порождаться одним из следующих факторов:

1. несовершенство методологии и субъективность в определении фактического процента выполнения незавершенных работ;
2. наличие кредиторской или дебиторской задолженности перед поставщиками и подрядчиками;
3. наличие выполненных и оплаченных работ, не включенных в Базовый план (т.н. Scope Creep Phenomenon — явление спонтанного разрастания объема работ). Стоимость этих работ не может быть включена в освоенный объем, поскольку Базовый план их «не видит»;
4. изменение масштаба цен на текущую дату по сравнению с датой бюджетирования проекта.

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

Поэтому неравенство

CV > 0 (CV < 0)

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

Подводные камни в определении фактических затрат по проекту заложены также в самой природе составления проектных бюджетов и смет. Если проектный план составляется по типу PMB (англ. Performance Measurement Baseline), то нужно четко задаться вопросом, какой тип центра финансовой ответственности моделирует проектный план (центр затрат, центр доходов, центр прибыли или центр инвестиций)? Трактовка проекта как определенного центра финансовой ответственности дает понимание при разделении проектных затрат на прямые и накладные, что бывает особенно критично при трактовке проекта как центра прибыли.

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

Даже если предположить, что методологи компании установили правила «справедливого» разнесения затрат по проектам, то далее возникает вопрос об учете использования данного оборудования при оценке планового PV и освоенного объема EV, а главное — отражение факта закупки в фактических затратах AC по конкретному проекту. Еще один казус кроется в оценке так называемых условно-бесплатных ресурсов, т.е. ресурсов, используемых в некотором проекте и принадлежащих самой организации.

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

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

Метод освоенного объема используется также для прогноза на дату мониторинга фактических сроков выполнения проекта и бюджета по завершению (ППЗ, Estimate at Completion, EAC). Приводимая оценка

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

В PMBoK предпоследней версии рекомендуется несколько методов прогнозирования бюджета по завершению. Приведу две оценки:

или

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

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

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

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

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

Литература:

• Вайдман, Р. М. Контроль стоимости проекта — это просто.
• Guide to the Project Management Body of Knowledge (PMBOK® Guide), 4th Edition, PMI, 2008.
• Управление проектами. Основы проектного управления.
• Мазур, И.И., Шапиро, В.Д., Ольдерогге Н.Г. Управление проектами. — М.: Омега — Л, 2005.
• Бредбери, Д., Гаррет, Д. Как пасти кур. Нестандартное управление проектами. — М.: NTPress, 2006.
• Милошевич, Д.З. Набор инструментов для управления проектами — М.: АйТи, ДМК пресс, 2008.
• Ньюэлл М. Управление проектами для профессионалов. Руководство по подготовке к сдаче сертификационного экзамена. М.: КУДИЦ-ОБРАЗ, 2008.
• Вахрушина М.А. Бухгалтерский управленческий учет. ¾ М.: Омега-Л, 2004.

Станислав ФуртаОпубликовано на E-xecutive.ru

Просмотры: 22 738

forpm.ru

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

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

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

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

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

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

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

Чтобы написать отличный отчет о состоянии, вам нужно понимать следующее:

• Три составляющих состояния.
• Как писать краткие отчеты.
• Какие основные данные необходимы руководству.

Три составляющих состояния

Есть три основных составляющих, которые должны входить в отчет о состоянии проекта:

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

Организация вашего отчета о состоянии

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

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

Краткие отчеты

Ваша работа состоит в том, чтобы сообщать о деталях вашего проекта в кратких, лаконичных отчетах о состоянии, с которыми руководитель мог бы быстро ознакомиться без необходимости тратить на это много времени. Вы можете потратить 30 минут на написание отчета о состоянии, но всегда помните, что ваш руководитель не может потратить 30 минут на изучение отчета. В реальности он имеет только 30 секунд на ознакомление с состоянием проекта, поскольку он может отвечать за 30, 40, 100 или даже за большее число проектов.

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

Что должно быть включено в краткие отчеты

Как можно представить описание состояния проекта без многословности? Это трудноразрешимая задача, но она не является невозможной. Здесь приводится несколько советов:

• Пишите в виде списка, а не сплошным текстом. В вашем отчете о состоянии нигде не должно быть абзацев.
• Избегайте излишнего использования заголовков и двоеточий. Очевидно, что 7/4/2008 – это дата. Написав "дата: 7/4/2008", вы не сообщите никакой дополнительной информации.
• Сокращайте отчет, насколько это возможно. Сокращайте все обороты речи и предложения.
• Избегайте использования наречий (действительно, очень, много) и прилагательных (хороший, плохой, скверный).

Основные данные

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

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

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

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

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

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

• Название контрольной точки.
• Доля завершенной работы в процентах для контрольной точки.
• Плановое начало.
• Плановое завершение.
• Реальное начало.
• Реальное завершение.

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

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

Разрешение проблем

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

• Номер сертификата: если имеется система сертификации, предоставьте (нам) ссылку на сертификат или на номер сертификата.
• Название проблемы: оно должно быть очень наглядным и кратким.
• Дата и время сообщения: нужно, чтобы увидеть срок давности проблемы. Чем он больше, тем больше вероятность возникновения серьезных неприятностей, если проблема не будет быстро разрешена.
• Приоритет или серьезность проблемы: ваша проблема является очень важной, если она останавливает реализацию проекта. Если проблема останавливает продвижение проекта вперед и единолично ставит под удар срок его сдачи, то это очень серьезная проблема. Если проблема – это очередная ошибка в программе, то она может быть быстро разрешена, и не является серьезной.
• Имя человека, который в данный момент занимается разрешением этой проблемы.
• Предполагаемое время завершения: Руководителям желательно предоставить время и дату, когда проблема будет разрешена. Если это невозможно, то предоставьте время и дату, когда вы перейдете на следующий этап в процессе разрешения проблемы. Если и это невозможно, предоставьте предполагаемое время следующего обновленного состояния проблемы.
• Текущие действия: Что в данный момент делается для разрешения этой проблемы? Организуете ли вы селекторное совещание? Просите ли вы помощи у конкретной группы специалистов? Что делается для смягчения последствий? Есть ли альтернативные варианты решения проблемы.

Ожидаемые результаты

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

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

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

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

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

Newer news items:

Older news items:

www.pmtoday.ru

Контрольные точки процесса

Представляется важным наличие наглядных контрольных.

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

■ Согласование ожиданий заинтересованных сторон и трех составляющих проекта: требований, проектных решений и планов.

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

■ Выявление важных рисков, проблем и невыполнимых условий.

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

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

В процессе руководства проектом проводятся совместные оценки трех разных типов:.

1.

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

2.

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

.

3.

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

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

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

Описания этого раздела напоминают подход с «якорными» точками жизненного цикла, рассмотренный в статье «Anchoring the Software Process» [Boehm, 1996]. Четыре основные контрольные точки располагаются в точках перехода между стадиями жизненного цикла. Они могут использоваться в самых разнообразных моделях процесса, включая традиционную водопадную модель. В итерационной модели основные

Рис. 9.1. Типичная последовательность контрольных точек на протяжении всего жизненного цикла.

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

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

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

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

■ Разработчики: детальность требований и описаний сценариев использования, основа для выбора или разработки компонентов, разрешение рисков при разработке, достаточность среды разработки.

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

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

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

Таблица 9.1.

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

Таблица 9.1. (продолжение).

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

Контрольная точка жизненного цикла по целям.

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

Контрольная точка жизненного цикла по архитектуре.

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

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

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

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

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

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

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

■ Представление и обзор текущего состояния проекта.

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

■ Демонстрация возможностей.

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

Рис. 9.2. Рабочие продукты разработки, доступные при достижении контрольной точки жизненного цикла по архитектуре

I.

Требования.

A.

Модель вариантов использования.

B.

Документ с общей концепцией (текст, варианты использования).

C.

Критерии оценки для стадии уточнения (текст, сценарии).

II.

Архитектура.

A.

Проектное представление (объектные модели).

B.

Представление процессов (при необходимости — разбивка на модули, структура исполняемого кода).

C.

Представление компонентов (структура подсистем, идентификация создаваемых/покупаемых/повторно используемых компонентов).

D.

Представление внедрения (физическое размещение компонентов, структура исполняемого кода).

E.

Представление вариантов использования (структура тестовых вариантов, ожидаемые результаты тестов).

1. Черновой вариант руководства пользователя.

III.

Библиотеки исходных текстов и исполняемых компонентов.

A.

Компоненты продукта.

B.

Компоненты для тестирования.

C.

Компоненты среды и инструментария

Контрольная точка по начальной эксплуатационной версии.

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

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

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

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

.

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

project.dovidnyk.info

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

• 
  Контрольная съемка земельного участка
• 
  Инвентаризация это контрольное мероприятие
• Понятие мировоззрения контрольная работа
• 
  Решения о капиталовложениях контрольная
• Кредитный договор контрольная работа
• 
  Контрольная сумма code 128
• Контрольная работа по кпзс
• Черная лисица контрольный диктант
• 
  Контрольный электрод наличия пламени
• 
  Контрольная работа по эмм
• 
  Контрольные элементы содержания образования