textarchive.ru

Главная > Документ

1

Смотреть полностью

Алексей Полковников

ЭФФЕКТИВНОЕ
УПРАВЛЕНИЕ
ПРОЕКТАМИ

Начальный курс

СЕТЕВАЯ АКАДЕМИЯ

Москва - 1998

Содержание

1 РАЗДЕЛ 1. ПРОЕКТЫ И УПРАВЛЕНИЕ ПРОЕКТАМИ 7

1.1 Проекты 7

1.1.1 Проекты и процессы 7

1.1.2 Проекты развития 11

1.1.3 Проектно-ориентированная организация 13

1.2 Жизненный цикл проекта 14

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

1.4 Команда и участники проекта 19

2 РАЗДЕЛ 2. ПЛАНИРОВАНИЕ ПРОЕКТА 25

2.1 Стадии планирования и виды планов 25

2.2 Процедура построения календарного плана 26

2.3 Ключевые определения и концепции методов планирования, организации и контроля проектов. 28

2.4 Построение Иерархической Структуры Работ 32

2.5 Назначение ответственных 35

2.6 Определение основных вех 36

2.7 Разработка сетевых моделей 36

2.8 Календарное планирование по методу критического пути 38

2.9 Ресурсное планирование проекта 41

2.10 Стоимостной анализ 43

2.11 Документирование плана проекта 46

3 РАЗДЕЛ 3. ОРГАНИЗАЦИЯ УПРАВЛЕНИЯ ПРОЕКТОМ 48

3.1 Цели организации управления проектом 48

3.2 Организационные уровни планирования и управления 50

3.3 Выбор организационной формы управления 52

4 РАЗДЕЛ 4. ИСПОЛНЕНИЕ ПРОЕКТА И КОНТРОЛЬ 55

4.1 Цели и содержание процесса контроля проекта 55

4.2 Отслеживание фактического выполнения работ 58

4.3 Измерение прогресса и анализ результатов. 60

4.4 Корректирующие действия 68

4.5 4Управление изменениями 69

4.5.1 Цели управления изменениями 69

4.5.2 Процесс контроля за реализацией изменений 70

5 РАЗДЕЛ 5. ИНФОРМАЦИОННАЯ СИСТЕМА УПРАВЛЕНИЯ ПРОЕКТОМ 72

5.1 Основные определения 72

5.2 Управление коммуникациями проекта 73

5.2.1 Процессы управления коммуникациями 73

5.2.2 Управление коммуникациями и информационные технологии 75

5.3 Цели и принципы создания автоматизированной информационной системы управления проектом 76

5.3.1 Потребность в информационной системе 76

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

5.3.3 Основные характеристики системы 77

5.4 Структура и основные элементы информационной системы 78

5.4.1 Структуризация системы по этапам проектного цикла 78

5.4.2 Основные функциональные элементы системы 79

5.4.3 Структуризация системы по уровням управления 80

5.5 Программное обеспечение календарного планирования 81

5.6 Разработка и внедрение информационной системы 85

5.6.1 Стратегия построения информационной системы 85

5.6.2 Разработка информационной системы 87

5.6.3 Внедрение системы 88

Введение

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

В основе современных методов управления проектами лежат методики структуризации работ и сетевого планирования, разработанные в конце 50-х годов в США.

  • В 1956 г. М. Уолкер из фирмы «Дюпон», исследуя возможности более эффективного использования принадлежащей фирме вычислительной машины Univac, объединил свои усилия с Д. Келли из группы планирования капитального строительства фирмы «Ремингтон Рэнд». Они попытались использовать ЭВМ для составления планов-графиков крупных комплексов работ по модернизации заводов фирмы «Дюпон». В результате был создан рациональный и простой метод описания проекта с использованием ЭВМ. Первоначально он был назван методом Уолкера-Келли, а позже получил название Метода Критического Пути - МКП (или СРМ - Critical Path Method).

  • Одним из наиболее известных проектов, на котором были впервые использованы методы моделирования и согласования комплекса работ, является проект разработки ракетной системы «Поларис», начатый в 1957 году. Данный проект имел жесткие ограничения по срокам, поскольку был привязан к предполагаемой дате ввода в эксплуатацию в СССР ракет, способных нести ядерные заряды и достигать территории США. В то же время в рамках данного проекта необходимо было разработать, провести сборку и тестирование значительного количества не имеющих аналогов компонент. Реализация проекта, объединявшего около 3800 основных подрядчиков и состоявшего из 60 тысяч задач, была поручена Главному управлению вооружений ВМС США. В целях управления реализацией этого проекта корпорацией «Локхид» и консалтинговой фирмой «Буз, Аллен энд Гамильтон» был создан специальный метод планирования работ на основании оптимальной логической схемы процесса, названный методом анализа и оценки программ PERT (Program Evaluation and Review Technique). Использование метода PERT позволило руководству программы точно знать, что требуется делать в каждый момент времени и кто именно должен это делать, а также вероятность своевременного завершения отдельных операций. Руководство программой оказалось настолько успешным, что проект удалось завершить раньше запланированного срока. Благодаря такому успешному началу данный метод управления был засекречен и вскоре стал использоваться для планирования проектов во всех вооруженных силах США. Методика отлично себя зарекомендовала при координации работ, выполняемых различными подрядчиками в рамках крупных проектов по разработке новых видов вооружения.

Крупные промышленные корпорации начали применение подобной методики управления практически одновременно с военными для разработки новых видов продукции и модернизации производства. Широкое применение методика планирования работ на основе проекта получила в строительстве. Например, для управления проектом сооружения гидроэлектростанции на реке Черчилль в Ньюфаундленде (полуостров Лабрадор). Стоимость проекта составила 950 млн. долларов. Гидроэлектростанция строилась с 1967 по 1976 г. Этот проект включал более 100 строительных контрактов, причем стоимость некоторых из них достигала 76 млн. долларов. В 1974 году ход работ по проекту опережал расписание на 18 месяцев и укладывался в плановую оценку затрат. Заказчиком проекта была корпорация Churchill Falls Labrador Corp., которая для разработки проекта и управления строительством наняла фирму Acress Canadian Betchel.

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

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

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

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

Освоив курс, Вы сможете:

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

  • Разрабатывать иерархическую и логичекую структуры проекта

  • Осуществлять расчет сроков исполнения работ проекта по методу критического пути

  • Классифицировать наличные ресурсы и строить график потребностей проекта в ресурсах

  • Строить график потребностей проекта в финансировании

  • Применять методы контроля и анализа хода исполнения работ

  • Выявлять и систематизировать проблемы управления проектами в организации

  • Применять системные подходы и методы управления проектами

  • Определять роли участников проектов

  • Разрабатывать, анализирвоатьь и оптимизировать план проекта

  • Разрабатывать и внедрять процедуры контроля реализации проекта

  • Устанавливать и контролировать критерии оптимальной реализации проекта

  • Разрабатывать отчеты по проекту

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

1РАЗДЕЛ 1. ПРОЕКТЫ И УПРАВЛЕНИЕ ПРОЕКТАМИ

1.1Проекты

1.1.1Проекты и процессы

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

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

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

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

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

Примерами проектов являются:

Сооружение атомной электростанции

Освоение месторождения

Строительство завода или жилого дома

Разработкаи вывод на рынок новой продукции или услуг

Проведение исследований и опытно-конструкторских работ

Разработка и внедрение информационной системы

Открытие филиала компании

Проведение ремонта в офисе

Подготовка к юбилею

Написание книги….

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

1. они направлены на достижение конкретных целей;

2. они предполагают координированное выполнение взаимосвязанных действий;

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

4. все они в определенной степени неповторимы и уникальны.

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

Направленность на достижение целей.

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

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

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

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

Ограниченная протяженность во времени.

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

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

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

Уникальность.

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

  • Чем выше уникальность проекта, тем выше неопределенность и сложнее планирование и управление

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

1.1.2Проекты развития

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

Проекты развития являются инвестиционными и связаны со стратегией развития компании.

Например:

  • Развитие новых направлений

  • Модернизация продукции и оборудования

  • Выход на новые рынки

  • Модернизация технологий и оборудования

  • Развитие инфраструктуры компании

  • Реорганизация

  • Автоматизация

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

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

1.1.3Проектно-ориентированная организация

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

1.2Жизненный цикл проекта

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

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

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

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

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

Инициация

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

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

Планирование

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

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

Осуществление (исполнение и контроль)

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

Завершение

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

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

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

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

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

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

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

ТРИ КИТА УПРАВЛЕНИЯ ПРОЕКТАМИ

Концепция «ЖИЗНЕННОГО ЦИКЛА ПРОЕКТА»:
единый, неразрывный процесс достижения цели.

Концепция «КОМАНДЫ ПРОЕКТА»:
единая организационная структура,
отвечающая за успех проекта на всех стадиях.

Концепция «ФИНАНСИРОВАНИЯ ПРОЕКТА»:
соответствия затрат объемам и качеству выполненных работ.

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

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

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

Итак, руководители проектов отвечают за три аспекта реализации проекта:

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

1.4Команда и участники проекта

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

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

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

Рис. 1.4. Пример организации проекта.

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

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

В крупных проектах могут быть также:

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

Руководитель служб поддержки - отвечает за функционирование служб информационной поддержки и поддержки общеуправленческих функций.

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

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

Итоги раздела

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

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

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

  • Проект - способ, организационная форма достижения целей

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

  • Проект предполагает наличие плана достижения поставленных целей (комплекса работ)

  • Проект предполагает наличие системы полномочий и ответственности за достижение целей во главе с менеджером проекта

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

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

Критерии классификации:

  • Место в структуре бизнес-процессов компании

  • Основной бизнес процесс

  • Проекты развития бизнеса

  • Вид деятельности

  • Строительство

  • Штучное и мелкосерийное производство

  • Разработка информационных систем

  • другие

  • Способ финансирования

  • Инвестиционный проект

  • Контрактный проект

  • Степень новизны (неопределенности) целей проекта и процесса их достижения

  • Масштаб, сложность, важность

Ключевые процессы управления проектами и их результаты

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

Действие

Результат успешного выполнения действия

Инициация

1. Демонстрация необходимости проекта и его осуществимости

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

2. Получение одобрения проекта

  • Получение одобрения или отказа со стороны спонсора проекта

  • Назначение менеджера проекта

  • «Решение (приказ) о начале работ» обладает следующими характеристиками:

  • Формальное признание проекта

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

  • Дает санкции менеджеру проекта на привлечение ресурсов на работы проекта

3. Получение разрешения на проект на данной фазе

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

  • Письменное разрешение на переход к следующей фазе проекта

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

Планирование

4. Описание состава работ проекта

  • Утверждение состава работ проекта

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

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

5. Описание последовательности выполнения работ

  • Список работ (в него включаются все работы, которые должны быть выполнены в рамках проекта)

  • Корректировка и детализация иерархической структуры работ

  • Сетевая диаграмма комплекса работ проекта

6. Оценка длительности работ и потребности в ресурсах

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

  • Определение потребности в ресурсах

  • Коррекция списка работ

7. Разработка календарного плана работ

  • График работ проекта в форме диаграмм Ганта, сетевых диаграмм, диаграмм ключевых событий (вех), текстовых таблиц

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

8. Оценка затрат

  • Оценка затрат на каждую работу проекта

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

  • План управления затратами по проекту, включая управление отклонениями

9. Разработка бюджета и плана расходов

  • Исходный план финансирования или бюджет для контроля/мониторинга затрат в привязке к календарю

10. Создание формального плана управления качеством (если требуется)

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

  • Критерии контроля качества

11. Создание формального плана управления взаимодействиями (если требуется)

  • План управления взаимодействиями, в который входят:

  • Содержание и структура информации, которая должна распространяться

  • Каналы сбора информации

  • Каналы распределения информации

  • Расписания, регулирующие, сбор и распространение информации

  • Методы обновления плана взаимодействия

12. Набор и организация работы персонала

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

  • Состав проектной команды и план кадрового обеспечения

13. Идентификация рисков и план ответных действий (если требуется)

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

14. План по организации работы с внешними исполнителями/поставщикам и (если требуется)

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

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

  • Тендерная документация (например, заявка на подготовку коммерческого предложения, приглашение к участию в торгах или переговорах о выдаче подряда)

  • Критерии оценки предложений

  • Контакты с одним или несколькими поставщиками товаров и/или услуг

15. Разработка плана проекта

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

16. Завершение фазы планирования проекта

  • План проекта был одобрен спонсором в письменной форме. Формально дается «зеленый свет» на начало работ по проекту.

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

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

Исполнение

18. Выполнение работ проекта

  • Результаты работ

  • Запросы на внесение изменений в состав или содержание работ -1 Регулярные отчеты по прогрессу

  • Работа команды проекта оценивается, корректируется, при необходимости улучшается

  • Определены цены поставок/предложений, выбраны подрядчики (поставщики), контракты подписаны и исполняются

Контроль

19. Контроль работ проекта

  • Решения о принятии выполненных работ и полученных результатов

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

  • Корректировка планов и состава работ

  • Формализованное описание полезного опыта

  • Улучшение качества выполнения работ з Оценка эффективности исполнения работ проекта

Завершение

20. Завершение проекта

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

  • Формальное принятие продуктов и работ субподрядчиков

  • Подготовка данных по проекту к архивации

  • План для продолжения и/или передачи продуктов работы

2РАЗДЕЛ 2. ПЛАНИРОВАНИЕ ПРОЕКТА

2.1Стадии планирования и виды планов

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

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

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

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

  • концептуальный план

  • стратегический план реализации проекта

  • тактические (детальные) планы.

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

Входными данными для разработки плана проекта являются:

  • Договорные требования.

  • Описание доступных ресурсов.

  • Оценочные и стоимостные модели.

  • Документация по аналогичным разработкам.

2.2Процедура построения календарного плана

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

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

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

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

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

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

Таблица 2.1. Последовательность шагов календарного планирования

Шаг

Содержательная сущность шага

Разработка концепции и целей проекта

Почему?

Построение ИСР

Что?

Построение ОСРР Назначение ответственных

Кто?

Разработка стратегии реализации Определение основных вех

Как?

Разработка сетевых моделей

Как?

Расчет календарного графика по МКП

Когда? Идеальные сроки

Расчет календарного графика с учетом ограничений на ресурсы

Когда? Реальные сроки

Анализ стоимостной информации Разработка финансового плана

Сколько это будет стоить?

2.3Ключевые определения и концепции методов планирования, организации и контроля проектов.

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

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

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

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

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

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

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

Рисунок 2.2. Диаграмма предшествования

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

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

  • Методы сетевого планирования - методы, основная цель которых заключается в том, чтобы сократить до минимума продолжительность проекта. Основываются на разработанных практически одновременно и независимо методе критического пути МКП и методе оценки и пересмотра планов PERT (Program Evaluation and Review Technique). Первый метод разработан в 1956 году для составления планов-графиков крупных комплексов работ по модернизации заводов фирмы «Дюпон». Второй метод разработан корпорацией «Локхид» и консалтинговой фирмой «Буз, Аллен энд Гамильтон» для реализации крупного проекта разработки ракетной системы «Поларис».

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

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

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

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

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

Рисунок 2.3. Диаграмма Ганта

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

  • структуризации работ на основные компоненты и подкомпоненты

  • обеспечении направленности деятельности на достижение всего комплекса целей

  • разработке системы ответственности за выполнение работ проекта а разработке системы отчетности и обобщения информации по проекту.

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

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

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

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

Рисунок 2.4. Гистограмма использования ресурса

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

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

Анализ реализуемости проекта - понятие реализуемости имеет ряд своих разновидностей: логическая реализуемость (учет логических ограничений на возможный порядок выполнения работ во времени); временной анализ (расчет и анализ временных характеристик работ: ранняя/поздняя дата начала/окончания работы, полный, свободный временной резерв и другие); физическая (ресурсная реализуемость (учет ограниченности наличных или доступных ресурсов в каждый момент времени выполнения проекта); финансовая реализуемость (обеспечение положительного баланса денежных средств как особого вида ресурса).

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

2.4Построение Иерархической Структуры Работ

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

Создание ИСР в начале работ по планированию предоставляет менеджеру возможность:

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

  • Проверить, все ли цели отражены в плане проекта а Создать эффективную структуру отчетности

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

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

  • Обеспечить членам команды понимание их роли в контексте общей работы по выполнению проекта.

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

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

Определение основы для структуризации проекта

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

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

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

  • компоненты продукции проекта;

  • функциональные элементы деятельности;

  • этапы жизненного цикла проекта;

  • элементы организационной структуры.

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

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

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

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

Рис. 2.5. Пример ИСР, построенной с использованием смешанного подхода к структуризации.

Правила для построения иерархии

Несколько простых правил применяются при формировании ИСР:

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

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

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

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

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

Наиболее распространенными ошибками, допускаемыми в процессе структуризации проекта, являются:

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

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

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

  • неучет того, что элементы структуры не должны повторяться;

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

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

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

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

2.5Назначение ответственных

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

Построение структурной схемы организации

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

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

Использование матрицы ответственности

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

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

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

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

На рис. 2.6. показан пример матрицы ответственности. Роли в примере указывают вид участия подразделения в работе: О - Ответственный исполнитель, И - Исполнитель, П - Приемка работ, К - Консультации.

Рис. 2.6. Матрица ответственности

Исполнители

Задачи

Менеджер проекта

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

Планово-финансовый отдел

Отдел сбыта

Согласование целей

O

К

План по вехам

O

И

К

Бюджет проекта

O

И

К

План проекта

П

O

Утверждение плана

O

К

К

2.6Определение основных вех

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

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

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

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

2.7Разработка сетевых моделей

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

Ниже рассматриваются три шага разработки сетевой модели:

  • Определение комплекса работ проекта.

  • Оценка параметров работ.

  • Определение взаимосвязей между работами, работами.

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

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

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

Оценка параметров работ

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

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

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

В реальной жизни существует два типа работ:

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

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

Определение взаимосвязей между работами

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

Для описания зависимостей между работами может использоваться четыре типа связей предшествования:

  • Конец-Начало. Это стандартная последовательность при которой предшествующая задача должна завершиться до начала последующей.

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

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

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

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

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

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

2.8Календарное планирование по методу критического пути

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

Методика календарного планирования по МКП

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

Для расчета календарного графика по МКП требуются следующие входные данные:

  • Комплекс задач.

  • Взаимосвязи между задачами.

  • Оценки продолжительности для каждой работы.

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

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

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

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

Пример расчета графика работ по методу критического пути приведен в Приложении.

В результате вычислений по МКП менеджер проекта получает следующие данные:

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

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

  • Ранние и поздние календарные даты начала и конца для каждой задачи.

Таблица 2.2. обобщает входные и выходные данные для выполнения прямого и обратного прохода по МКП.

Таблица 2.2. Входные и выходные данные для выполнения расчета по МКП

Тип данных

Прямой проход

Обратный проход

Входные данные

Работы Предшественники

Работы Предшественники

Продолжительности

Продолжительности

Начальная дата проекта

Конечная дата проекта

Выходные данные

Ранние даты начала и окончания - для всех работ.

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

Дата окончания проекта

Позднейшая дата начала проекта

Величина резерва -для всех работ

Критические работы (величина временного резерва = 0)

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

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

Анализ календарного графика работ

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

  • Совпадает ли полученная конечная дата с ожидаемой? Приемлемо ли это с точки зрения целей проекта?

  • Какие работы являются критическими? Совпадают ли они с теми, которые предполагались предварительно членами команды?

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

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

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

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

Информация, получаемая вычислениями по МКП, обычно представляется в табличной форме, подобной представленной в таблице 2.3.

Таблица 2.3. Представление расчета по МКП

Проект:

Дата анализа:

Начало проекта:

Окончание проекта:

Работа

Описание

Продолжи тельность

Раннее начало

Раннее окончание

Позднее начало

Позднее окончание

Общий резерв

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

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

2.9Ресурсное планирование проекта

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

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

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

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

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

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

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

Основными выгодами от включения информации по ресурсам в расписание проекта являются на этапе планирования:

  • возможность оценить конкретные сроки и объемы потребностей в ресурсах;

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

  • возможность оценить стоимость проекта на основе данных об использовании ресурсов.

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

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

1. Определение ресурсов (описание ресурса и определение максимально доступного количества данного ресурса);

2. Назначение ресурсов задачам;

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

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

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

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

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

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

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

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

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

Существуют два основных пути разрешения ресурсных перегрузок:

  • Ресурсное планирование при ограничении по времени;

  • Планирование при ограниченных ресурсах.

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

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

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

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

2.10Стоимостной анализ

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

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

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

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

  • рабочие (трудовые ресурсы);

  • материалы;

  • оборудование;

  • соисполнители;

  • накладные расходы;

  • другие источники затрат.

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

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

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

Рис. 2.8. Пример гистограммы расходов по проекту

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

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

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

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

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

  • После окончательного утверждения даты начала проекта и расчета всех дат можно ввести в расписание дополнительные задачи-вехи, отмечающие достижение промежуточных результатов и зафиксировать даты их наступления. Такие задачи-вехи могут являться контрольными точками в ходе выполнения проекта. Важно также обратить внимание на уровень критичности проекта. Если процент критических работ в проекте превышает 20-25% от общего количества работ, то это означает что разработан напряженный план. Любая задержка в выполнении работы, лежащей на критическом пути, повлечет за собой задержку срока окончания всего проекта. Опытные разработчики в таких случаях часто предусматривают в расписании некоторый дополнительный резерв времени на непредвиденные задержки. Такой резерв может быть задан в расписании проекта путем введения задач-вех с фиксированной датой, предусматривающей некоторый резерв времени или «пустыми» задачами с определенной длительностью.

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

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

2.11Документирование плана проекта

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

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

  • Обеспечить понимание и одобрение целей проекта и средств их достижения.

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

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

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

  • Являться основанием для оценки и отображения прогресса.

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

  • Являться основанием для контроля изменений.

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

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

  • Краткий обзор проекта

  • Введение

  • Цели и ожидаемые результаты проекта

  • Стратегия

  • Объем работ

  • Организационные связи

  • Ссылки на внешние документы

  • Структура проекта

  • Роли и ответственности

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

  • Обзоры и утверждения

  • Комплекс работ

  • Работы проекта, оценка объема работ и квалификации

  • Внешние задачи

  • Возможные изменения

  • Ресурсное обеспечение

  • Персонал

  • Оборудование

  • Средства

  • Прочее

  • График работ

  • График работ по этапам

  • Список вех

  • Финансирование

  • История финансирования подобных проектов

  • Бюджет

  • План затрат

  • Фонды

  • Предположения

  • Ограничения, риски и неопределенности проекта

  • Зависимости от внешних проектов/событий

  • Риски и неопределенности

  • Процесс решения проблем

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

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

Менеджер проекта завершает обзор проекта, получает одобрение плана руководством организации и формирует команду проекта.

3РАЗДЕЛ 3. ОРГАНИЗАЦИЯ УПРАВЛЕНИЯ ПРОЕКТОМ

3.1Цели организации управления проектом

Как показано в разделе 2, планирование обеспечивает руководству и участникам проекта:

  • понимание целей проекта;

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

  • основу для получения и назначения ресурсов;

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

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

Цели организации управления проектом включают:

  • Обеспечение взаимодействия;

  • Разделение ролей и ответственностей;

  • Определение ответственности за принятие решений;

  • Обеспечение эффективного распределения информации;

  • Обеспечение гибкости использования ресурсов.

Обеспечение взаимодействия

Для обеспечения эффективного взаимодействия необходимо:

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

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

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

Разделение ролей и ответственности

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

  • Внутренние и внешние пользователи результатов проекта;

  • Внутренние и внешние поставщики ресурсов;

  • Внутренние функциональные отделы, например, бухгалтерия и т.д.

Для обеспечения эффективного взаимодействия должно быть четко определено:

  • Кто должен принимать то или иное решение.

  • Кто выполняет ту или иную работу.

  • Кто несет ответственность за те или иные управленческие функции.

  • Кто получает ту или иную информацию.

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

Определение ответственности за принятие решений

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

Обеспечение эффективного распределения информации

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

Рассматривая проблему организации коммуникации внутри проекта, руководитель проекта должен:

  • Стремиться к обеспечению участников проекта лишь необходимой для них информацией в необходимое время;

  • Определить каналы коммуникации заранее;

  • Строго контролировать эффективность информационных каналов;

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

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

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

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

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

  • Привлекать исполнителей в команду проекта только на период, когда их квалификация необходима.

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

3.2Организационные уровни планирования и управления

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

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

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

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

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

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

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

Рис. 3.1. Уровни организационной структуры проекта и соответствующие им типы управленческих решений и привлекаемый персонал(адаптировано из [3]).

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

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

Рис.3.2. Роль различных уровней организационной структуры проекта в принятии решений на разных стадиях проектного цикла.

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

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

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

3.3Выбор организационной формы управления

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

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

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

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

  • Функциональная структура.

  • Матричная структура.

  • Проектная структура.

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

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

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

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

  • дивизионально-региональная структура,

  • дивизионально-продуктовая структура,

  • дивизионально-технологическая структура.

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

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

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

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

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

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

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

  • Слабая матрица.

  • Сбалансированная матрица.

  • Жесткая матрица.

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

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

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

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

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

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

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

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

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

Таблица 3.1. Характеристики основных форм организации управления

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

Форма организации проекта

Функцио­нальная

Слабая матрица

Сбаланси­рованная матрица

Жесткая матрица

Проектная

Власть менеджера проекта

Слабая или отсутствует

Ограниче н-ная, ниже чем

У линейных менеджер ов

Средняя, равен по власти с линейными руководителя ми

Высокая, выше чем у линейных менеджеров

Очень высокая или полная

Роль менеджера проекта

Лидер проекта, координатор Частичная загрузка

Координа­тор проекта, лидер Частичная загрузка

Руководи­тель проекта, координатор Полная загрузка

Руководи­тель проекта/ программы Полная загрузка

Руководи­тель проекта/ программы Полная загрузка

Процент персонала, полностью задействованного на проекте

нет

0-25%

15-60%

50-95%

85-100%

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

Частичная загрузка

Частичная загрузка

Частичная загрузка

Полная загрузка

Полная загрузка

4РАЗДЕЛ 4. ИСПОЛНЕНИЕ ПРОЕКТА И КОНТРОЛЬ

4.1Цели и содержание процесса контроля проекта

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

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

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

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

Основные принципы построения эффективной системы контроля

Основные принципы построения эффективной системы контроля включают:

  • Наличие четких планов.

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

  • Наличие ясной системы отчетности.

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

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

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

  • Наличие эффективной системы анализа фактических показателей и тенденций.

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

  • Наличие эффективной системы реагирования.

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

Процесс контроля проекта

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

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

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

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

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

Отслеживание фактического состояния работ - сбор и документирование фактических данных;

Анализ результатов и измерение прогресса - оценка текущего состояния работ и сравнение достигнутых результатов с запланированными;

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

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

Рис. 4.1. Обобщенная схема процесса контроля исполнения проекта

4.2Отслеживание фактического выполнения работ

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

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

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

  • Существует два основных метода контроля фактического выполнения: «простой контроль» и «детальный контроль».

  • Метод простого контроля также называют методом «О-100», поскольку он отслеживает только моменты завершения детальных задач (существуют только две степени завершенности задачи: 0% и 100%). Другими словами, считается, что работа выполнена только тогда, кода достигнут ее конечный результат.

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

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

Иногда встречаются несколько модифицированные варианты метода детального контроля:

  • Метод 50/50 - признает возможность учета некоторого промежуточного результата для незавершенных работ. Степень завершенности работы определяется в момент, когда работа израсходовала 50% бюджета.

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

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

Данные, необходимые для контроля основных параметров проекта, представлены в Таблице 4.1.

Таблица 4.1. Критерии для контроля и требуемые данные.

Критерий контроля

Количественные данные

Качественные данные

Время и стоимость

Планируемая дата начала/окончания, Фактическая дата начала/окончания, Объем выполненных работ, Объем предстоящих работ, Другие фактические затраты, Другие предстоящие затраты

Качество

Проблемы качества

Организация

Внешние задержки, Проблемы внутренней координации ресурсов

Содержание работ

Изменения в объеме работ, Технические проблемы

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

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

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

4.3Измерение прогресса и анализ результатов.

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

  • время,

  • стоимость,

  • качество,

  • организация проекта,

  • содержание работ.

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

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

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

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

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

Рис. 4.2. Фрагмент диаграммы Ганта, план/факт

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

Предсказание сроков окончания работ

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

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

Выполненная продолжительность + оставшаяся продолжительность (оценка) = (пересмотренная) общая продолжительность.

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

Выполнение и потраченное время

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

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

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

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

  • для пересмотра оценок длительностей работ;

  • для определения причин задержек;

  • для стоимостного анализа на основе фактической выработки.

Пересмотр оценок длительностей работ.

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

Определение причин задержек.

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

Таблица 4.2. Определение причин задержек путем сравнения объема работ и дат завершения.

Даты завершения вовремя

Даты завершения с задержкой

Объем работ соответствует плану

Нет проблем

Внешние задержки. Внутренние организационные проблемы

Объем работ выше запланированного

Небольшие ошибки в оценках

Серьезные ошибки в оценках, Изменения в содержании работ, Проблемы качества (исправление недостатков)

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

Таблица 4.3. Показатели временных параметров и объемов работ

Показатель

Формула расчета

Плановая Длительность Длительность задачи, записанная в исходном плане.

Плановый Объем Работ - Объем работ для задачи, записанный в исходном плане.

Плановая Конечная Дата - Дата окончания задачи, записанная в исходном плане.

Плановая Начальная Дата - Дата начала задачи, записанная в исходном плане.

Объем Работ - Вводится для задач с фиксированным объемом работ и рассчитывается для задач с фиксированной продолжительностью.

Оставшийся объем работ. - сэкономленный объем работ.

Плановый объем работ - Объем работ

Исчерпано времени,%. - Процентное выражение истекшей части задачи (относительная часть израсходованного времени).

(Пороговая Дата - Начальная Дата)/Продолжительность.

Задержка Даты Завершения.

Плановая Конечная Дата - Конечная Дата.

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

Поздняя Свободная Дата Окончания -Дата Окончания

Процент Выполнения.

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

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

Продолжительность * (Процент Потраченого Времени / Процент Выполнения)

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

Проекция Конечной Даты.- Оценка даты окончания задачи.

Дата Начала + Проекция Продолжительности.

Текущий процент отработанного времени.-

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

Потраченное время/Плановая длительность.

Фактический объем работ (к текущему моменту).

Оставшееся Время. Оставшееся время до окончания задачи.

Оставшийся Объем Работ. Оставшаяся часть объема работ.

(Объем работ -(Затраченный объем работ + Сверхурочный объем работ)).

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

Относительный полный резерв.

Полный резерв/Длительность.

Оценка стоимости выполнения и предсказание стоимости проекта.

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

  • Необходимо Для Завершения (НДЗ): устанавливается оценка затрат, которые предстоят для завершения работы или проекта.

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

  • Расчетная Стоимость (PC): наилучшая оценка общей стоимости, которую будет иметь работа или проект при завершении.

Для вычисления PC используется следующая формула:

PC = Фактические затраты на текущую дату + НДЗ

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

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

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

  • Плановая Стоимость Запланированных Работ (ПСЗР) представляет запланированную стоимость выполнения работ каждого периода по графику. Плановые стоимостные показатели были заложены в финансовом плане.

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

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

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

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

Данные показатели в MS Project 98:

ACWP

Фактическая Стоимость Выполненных Работ, ФСВР

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

Используется как элемент анализа состояния работ на основании фактической выработки (earned value analysis).

BCWP

Плановая Стоимость Выполненных Работ, ПСВР

РассчитываетсяПлановая Стоимость Выполненных Работ (ПСВР) показывает плановую суммарную стоимость всех работ задачи, выполненных на дату анализа (Status Date или текущую дату). Данный показатель также наывают earned value («заработанная стоимость»). Элемент анализа состояния работ на основании фактической выработки (earned value analysis). Значение BCWP сравнивается с величиной ACWP (Фактическая Стоимость Выполненных Работ) для определения случаев перерасхода бюджета на выполненном объеме работ. Поле CV (Отклонение затрат) показывает разницу между данными показателями. Значение BCWP также может сравниваться с величиной BCWS (Плановая Стоимость Запланированных Работ) для определения случаев отклонений в освоении бюджета от графика на дату анализа. Поле SV (Отклонение от графика) показывает разницу между данными показателями.

BCWS

Плановая Стоимость Запланированн ых Работ, ПСЗР

РассчитываетсяПлановая Стоимость Запланированных Работ (ПСЗР) показывает плановую суммарную стоимость всех работ, которые должны были быть выполнены на дату анализа (Status Date или текущую дату) по плану. Элемент анализа состояния работ на основании фактической выработки (earned value analysis). Значение BCWS также может сравниваться с величиной BCWP (Плановая Стоимость Выполненных Работ) для определения случаев отклонений в освоении бюджета от графика на дату анализа. Поле SV (Отклонение от графика) показывает разницу между данными показателями.

CV

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

РассчитываетсяПоле CV (Отклонение по затратам) показывает разницу между показателями BCWP (Плановая Стоимость Выполненных Работ) и ACWP (Фактическая Стоимость Выполненных Работ) для определения случаев перерасхода бюджета на выполненном объеме работ: CV = BCWP - ACWP Другими словами, разница между тем сколько планировалось затратить на достижение полученных ресурсом результатов и сколько фактически затрачено. Если отклонение положительно, то стоимость выполненных на текущий момент работ ниже запланированной.

SV

Отклонение от расписания на дату

РассчитываетсяПоле SV (Отклонение от графика) показывает разницу между показателями BCWP (Плановая Стоимость Выполненных Работ) и BCWS (Плановая Стоимость Запланированных Работ) для определения случаев отклонений в освоении бюджета от графика на дату анализа: SV = BCWP - BCWS Другими словами, разница между тем сколько средств планировалось освоить по графику на дату анализ и сколько было бы освоено (при условии, что стоимость фактически выполненных работ соответствует плановым оценкам). Если значение положительно, то выполнение работ (освоение бюджета) опережает график, и наоборот.

Рисунок 4.3. дает графическое представление анализа на основе фактической вьфаботки.

Рис. 4.3. Иллюстрация анализа на основе фактической выработки с помощью S-кривых.

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

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

Таблица 4.4. Стоимостные параметры работ проекта

Показатель

Формула расчета

Плановая Стоимость. Полная стоимость задачи, записанная в исходном плане.

Эффективность Затрат - степень перерасхода. =1 -затраты на данный момент соответствуют плану. 1 - на данный момент затрачено меньше средств, чем предусмотрено. < 1 - на данный момент средств затрачено больше, чем предусмотрено.

Бюджетная стоимость/Фактические затраты

Текущая экономия.

<0 - перерасход средств на данный момент >0 - недорасход средств на данный момент

Бюджетная Стоимость -Фактические Затраты

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

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

Фактические Затраты + (Плановая Стоимость - Бюджетная Стоимость)

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

Плановая Стоимость * (Фактические Затраты / Бюджетная Стоимость)

Степень Выполнения Плана. Отношение бюджетной стоимости (при достигнутом проценте выполнения) к стоимости работ по плану к данному моменту.

Бюджетная Стоимость/Должно Быть Освоено.

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

Бюджетная стоимость - Должно быть освоено

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

Сальдо освоения/Должно быть освоено.

Индекс фактического выполнения.

Должно быть освоено/Фактические затраты.

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

Текущий процент затрат к данному моменту времени.

Фактические затраты/Плановые затраты.

Осталось Затратить. Часть стоимости еще не истраченная.

Полная стоимость - (Затраченная стоимость + Сверхурочная стоимость)

Общая стоимость.

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

Перерасход стоимости.

<0 - задача не укладывается в бюджет.

Разность плановой оценки и текущей оценки стоимости.

Процент перерасхода стоимости.

Процент перерасхода стоимости по отношению к плану

Степень перерасхода стоимости. >1 - перерасход стоимости.

Отношение плановой стоимости к действительной.

4.4Корректирующие действия

Определив отклонения проекта от плана, менеджер должен предпринять соответствующие действия. Чем раньше корректирующие действия предприняты, тем лучше. Действия по восстановлению контроля над проектом рекомендуется также тщательно планировать.

Возможные варианты действий.

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

  • Найти альтернативное решение.

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

  • Пересмотр стоимости.

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

  • Пересмотр сроков.

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

  • Пересмотр содержания работ.

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

  • Прекращение проекта.

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

4.54Управление изменениями

4.5.1Цели управления изменениями

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

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

  • Цели проекта

  • Специфические планы

  • Организация проекта

  • Использование ресурсов

  • Контракты

  • Используемые стандарты

  • Внешние факторы, влияющие на проект.

Причинами изменений в содержании работ проекта могут быть:

  • Изменения на рынке

  • Действия конкурентов

  • Технологические изменения

  • Изменения в ценах и доступности ресурсов

  • Экономическая нестабильность

  • Ошибки в планах и оценках

  • Ошибки в выборе методов, инструментов, организационной структуре или стандартах

  • Изменения в контрактах и спецификациях

  • Задержки поставок или поставки низкого качества

  • Необходимость ускорения работ

  • Влияние других проектов.

Все множество изменений можно разделить на два основных типа:

  • Осознанные (желательные) изменения

  • Вынужденные изменения.

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

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

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

Данная методика должна обеспечивать:

  • эффективные взаимосвязи между участниками проекта;

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

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

4.5.2Процесс контроля за реализацией изменений

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

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

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

1. Описание.

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

2. Оценка.

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

3. Одобрение.

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

4. Реализация.

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

5. Подтверждение исполнения,

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

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

  • «Отчет о проблеме» - описание проблемы, возникшей в ходе реализации проекта. Формируется на начальной стадии.

  • «Запрос на осуществление изменения». Формируется на начальной стадии.

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

  • «Сводная форма контроля изменения» - содержит обобщенную информацию об изменении (см. Рисунок 4.5.)

Рис. 4.5. Пример формы контроля изменения.

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

Проект:

Пакет работ:

Работа:

Описание изменения:

Последствия изменения:

Стоимость изменения:

Экономия в результате изменения:

ФИО

Подпись

Дата

Инициировано:

Контроль:

Разрешено:

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

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

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

Таблица 4.5. Цикл контроля изменения.

Шаг

Начальный статус

Конечный статус

Идентификация проблемы

Нет

Проблема

Описание проблемы

Проблема

Разрешение проблемы или Заявка на изменение

Анализ и описание изменения

Заявка на изменение

Предлагаемое изменение

Рассмотрение и утверждение изменения

Предлагаемое изменение

  • Предложение отвергнуто

  • Необходима доработка

  • Необходимо утверждение финансирования

  • Изменение утверждено

Доработка (детальный анализ последствий)

Предлагаемое изменение

Детальное описание изменения и последствий

Переговоры

Предлагаемое изменение

Финансирование утверждено

Реализация

Изменение утверждено

Изменение реализовано

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

Реализованное изменение

Реализация принята

Закрытие

Реализованное изменение Корректность реализации подтверждена

Снято с контроля

5РАЗДЕЛ 5. ИНФОРМАЦИОННАЯ СИСТЕМА УПРАВЛЕНИЯ ПРОЕКТОМ

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

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

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

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

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

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

Программное обеспечение календарного планирования и контроля (в

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

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

5.2.1Процессы управления коммуникациями

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

  • Планирование системы коммуникаций - определение информационных потребностей участников проекта (состав информации, сроки и способы доставки).

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

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

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

Планирование системы коммуникаций.

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

  • Логическая структура организации проекта и матрица ответственности.

  • Информационные потребности участников проекта.

  • Физическая структура распределения участников проекта.

  • Внешние информационные потребности проекта.

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

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

  • Доступностью технологий.

  • Квалификацией и подготовленностью кадров.

План управления коммуникациями включает в себя:

  • План сбора информации, в котором определяются источники информации и методы ее получения.

  • План распределения информации, в котором определяются потребители информации и методы доставки.

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

  • Расписание и частота взаимодействий.

  • Метод внесения изменений в план коммуникаций.

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

Оценка и отображение прогресса

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

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

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

Сбор и распределение информации

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

  • Внутренние (внутри команды проекта) и внешние(с руководством компании, заказчиком, внешними организациями и т.д.);

  • Формальные (отчеты, запросы, совещания) и неформальные (напоминания, обсуждения);

  • Письменные и устные,

  • Вертикальные и горизонтальные.

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

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

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

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

Документирование хода работ.

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

Документирование результатов хода работ включает в себя:

  • Сбор и верификацию окончательных данных;

  • Анализ и выводы о степени достижения результатов проекта и эффективности выполненных работ;

  • Архивирование результатов с целью дальнейшего использования.

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

5.2.2Управление коммуникациями и информационные технологии

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

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

Эра господства больших ЭВМ, дорогостоящего специализированного программного обеспечения для управления проектами и дорогостоящих экспертов, умевших использовать это программное обеспечение, продолжалась до середины 80-х годов. Использование автоматизированных систем управления проектами было ограничено организациями и проектами, бюджет которых позволял оплатить от $500.000 до $1.000.000 за установку соответствующих систем и привлечение специалистов.

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

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

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

5.3Цели и принципы создания автоматизированной информационной системы управления проектом

5.3.1Потребность в информационной системе

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

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

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

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

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

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

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

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

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

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

В современной организации, как правило, функционирует целый ряд автоматизированных систем, обеспечивающих информационную поддержку текущей управленческой деятельности. Системы поддержки принятия решений (Decision Support Systems - DSS) разрабатываются и используются для поддержки специфических управленческих процедур. Структура данных систем обычно соответствует функциональной структуре организации и уровням управления. Например, корпоративные финансовые приложения могут включать системы автоматизации бухгалтерии, начисления зарплаты, планирования выплат поставщикам. Для автоматизации отдела продаж могут использоваться системы учета продукции на складах, выписки счетов, база данных клиентов и т.п. Информационные системы высшего руководства (Executive Information Systems - EIS) предоставляют обобщенную информацию о результатах деятельности и состоянии компании в виде, удобном для принятия решений стратегического характера.

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

Итак, следующие отличия ИСУП от корпоративных информационных систем являются принципиальными:

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

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

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

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

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

5.3.3Основные характеристики системы

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

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

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

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

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

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

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

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

5.4Структура и основные элементы информационной системы

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

Информационная система управления проектом может быть структурирована:

  • по этапам проектного цикла;

  • по функциям;

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

5.4.1Структуризация системы по этапам проектного цикла

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

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

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

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

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

5.4.2Основные функциональные элементы системы

Основные функциональные элементы ИСУП на стадии исполнения проекта включают в себя:

  • Модуль планирования и контроля календарных планов работ;

  • Модуль ведения бухгалтерии проекта;

  • Модуль финансового контроля и прогнозирования. Модуль планирования и контроля календарных планов.

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

Модуль ведения бухгалтерии проекта.

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

Модуль финансового контроля и прогнозирования.

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

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

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

5.4.3Структуризация системы по уровням управления

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

  • Стратегический уровень управления портфелем проектов (высшее звено руководства организации).

  • Уровень управления проектом (руководство проекта).

  • Уровень исполнения проекта (команда проекта).

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

Таблица 5.1. Требования к ИСУП по yровням управления

Стратегический уровень управления портфелем проектов (высшее звено руководства организации)

Уровень управления проектом (руководство проекта)

Уровень исполнения проекта(команда проекта)

  • Простота использования

  • Средства сбора и обобщения данных

  • Средства представления информации

  • Возможности укрупненного планирования

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

  • Мощные аналитические возможности

  • Средства создания и распределения отчетов

  • Средства сбора и передачи данных

  • Простота использования

  • Удобные средства ввода данных

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

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

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

5.5Программное обеспечение календарного планирования

Функции программного обеспечения

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

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

Благодаря повышению мощности и снижению стоимости персональных компьютеров, а также, при участии таких корпораций, как Microsoft и Symantec, буквально заваливших рынок дешевыми системами для управления проектами, программное обеспечение и методики управления, доступные раньше только состоятельным организациям, пришли на рабочие столы и вошли в повседневную практику менеджеров и сотрудников средних и малых компаний. А наиболее мощные из систем для персональных компьютеров, такие как Open Plan Professional, позволили управлять проектами в таких областях, где раньше управление без использования больших ЭВМ и не мыслилось.

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

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

  • средства проектирования структуры работ проекта,

  • средства планирования по МКП,

  • средства ресурсного планирования (описание, назначение и оптимизация загрузки ресурсов),

  • некоторые возможности стоимостного анализа,

  • средства контроля ходом исполнения проекта,

  • средства создания отчетов и графических диаграмм.

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

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

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

  • Описания глобальных параметров планирования проекта

  • Описание логической структуры комплекса работ

  • Многоуровневое представление проекта

  • Назначение временных параметров планирования задач

  • Поддержка календаря проекта

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

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

  • Поддержка календарей ресурсов

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

  • Календарное планирование при ограниченных ресурсах

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

  • Фиксация плановых параметров расписания проекта в базе данных

  • Ввод фактических показателей состояния задач

  • Ввод фактических объемов работ и использования ресурсов

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

Графические средства представления структуры проекта, средства создания различных отчетов по проекту.

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

  • PERT диаграмма (сетевая диаграмма)

  • Создание отчетов, необходимых для планирования и контроля

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

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

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

1. Средства описания комплекса работ проекта, связей между работами и их временных характеристик:

  • Поддержка календаря проекта (максимальный размер календаря, наиболее поздняя дата, максимальное количество праздников в одном календаре, возможность задавать рабочие дни недели и различные рабочие дни для различных недель, возможность задавать обычные рабочие часы);

  • Ограничения, накладываемые на работы проекта (типы работ (Как Можно Раньше, Как Можно Позже, работы с фиксированной датой начала/окончания), возможность планирования выполнения работ по индивидуальным календарям);

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

  • Связи между задачами (максимальное количество предшествующих и последующих задач, допустимые типы связей, допустимые типы задержек/перекрытий);

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

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

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

Назначение ресурсов задачам (максимальное количество ресурсов на задачу, возможность задания частичного использования ресурсов, возможность задания задержек при использовании ресурса);

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

3. Средства контроля ходом выполнения проекта.

  • Средства отслеживания состояния задач проекта (фиксация планарасписания проекта, средства поддержки фактических показателей состояния задач (процент завершения));

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

  • Средства стоимостного анализа состояния проекта и анализа на основе выполненных объемов работ.

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

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

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

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

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

  • Сортировка данных (максимальное количество критериев, сортировка по кодам задач и датам);

  • Критерии отбора данных (исключающий и выделяющий отбор);

  • Возможности печати (типы принтеров, плоттеры, многостраничный отчет);

  • Средства обмена данными (поддержка технологии клиент/сервер, стандартов SQL 1 и ODBC 2, интеграция с ресурсами Web 3, импорт/экспорт (ASCII 4, dBase, Lotus, другие системы для управления проектами);

  • Работа в сети;

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

  • Языки программирования и разработки макроопределений.

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

5.6Разработка и внедрение информационной системы

5.6.1Стратегия построения информационной системы

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

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

  • Разработка собственной специализированной системы или настройка существующих систем.

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

  • Интеграция существующих подсистем по функциям и по данным.

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

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

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

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

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

  • только планирование или планирование и контроль хода проекта;

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

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

  • детальное планирование использования ресурсов;

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

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

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

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

5.6.2Разработка информационной системы

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

  • Изучение и анализ возможностей автоматизации процедур управления;

  • Проектирование и разработка системы;

  • Тестирование и подготовка документации.

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

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

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

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

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

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

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

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

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

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

5.6.3Внедрение системы

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

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

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

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

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

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

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

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

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

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

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

Литература

[I]. Л Guide to the Project Management Body of Knowledge (PMBOK), PMI, 1994.

[2]. Andersen E, Grude K, Haug T, Turner J, Goal Directed Project Management, Kogan Page, 1995.

[3]. Morris P, Managing Project Interfaces - Key Points for Project Success, Project Management Handbook, edited by D. Cleland and W. King, Van Nostrand Reinhold, 1988.

[4]. Meredith J., Mantel S., Project Management, Managerial Approach, Wiley, 1989.

[5]. The Implementation of Project Management: The Professional Handbook, Wesley, 1991.

[б]. Полковникова Е.В., Полковников А.В., Планирование и управление проектами с использованием Time Line, Диалог-МИФИ, 1994.

[7]. Thuman J, Development and Implementation of Project Management Systems, Project Management Handbook, edited by D. Cleland and W. King, Van Nostrand Reinhold, 1988.

[8]. Badiru A, Whitehouse G, Computer Tools, Models and Techniques for Project Management, TAB Professional and Reference Books, 1989.

[9]. Levine H A, Project Management Using Microcomputers, McGraw Hill, 1986.

[10]. Wall A, Project Planning and Control Using Micros, NCC Publications, 1988.

1 SQL (Structured Query Language) - стандартный, структурированный язык построения запросов к базам данных.

2 ODBC (Open Data Base Connectivity) - стандарт доступа к базам данных различных форматов.

3 Web - всемирная сеть, построенная по технологии Internet.

4 ASCII - формат сруктурированного текстового файла.

1

Смотреть полностью


Скачать документ

Похожие документы:

  1. Курс «управление проектами»

    Документ
    ... изменили системы управленияпроектами и соответственно возможности организации эффективногоуправленияпроектами. Внедрение единой информационной системы управленияпроектами, как ...
  2. Проект ingsat

    Документ
    ... рассказы полковника Платова ... .html Скворцов Алексей - Косово ... Управлениепроектами. Курс лекций. М., 2005. 201 с\ Управлениепроектами. Курс ... эффективной организации учебного процесса. Лекция. Октябрь. 2005. 10 с.pdf Пути модернизации начального ...
  3. Алексей Валериевич Исаев Антисуворов Большая ложь маленького человечка Антисуворов – Аннотация Алексей Валериевич Исаев Антисуворов Большая ложь маленького человечка Введение А врать‑то зачем?

    Книга
    ... человечка» Алексей Валериевич ... видимо, не в курсе происходившего в связи с ... фронтовые управления. За управлениями соответствующих ... полковника Роблинга, автора проекта ... сомнительную эффективность оборонительного ... лица операций и начального, и последующих ...
  4. Курс современной политической истории россии (период 1980 – 1991) глава первая

    Документ
    ... создание эффективной системы федерального управления и местного ... Жириновского, генерал-полковника А.Макашова, ... и Всея Руси Алексию II, призвали ... управления, отвечавшие потребностям курса ... внесли развернутый проект соглашения о начальном сокращении СССР ...
  5. Проект (грант) № 175 организация-грантополучатель некоммерческое партнерство проектно-консультативный центр «территория роста» тема проекта (гранта)

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

Другие похожие документы..