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

Что такое проект?

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

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

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

Программы и портфели проектов

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

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

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

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

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

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

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

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

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

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

Основные этапы управления проектами

Управление проектами происходит по этапам и фазам комплексности менеджмента. Взаимосвязь этапов и фаз приводится в таблице ниже.

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

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

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

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

Проектное управление в строительной отрасли

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

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

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

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

Опыт внедрения проектного управления в Белгородской области

Проектное государственное управление хорошо зарекомендовало себя во всем мире. В России же имеется опыт применения этой технологии в Белгородской области.

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

Проектное управление Белгородской области теперь включает коллегиальные органы проектного управления:

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

Принцип «одного окна»

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

Автоматизированная информационная система «Проектное управление»

Информационная и техническая поддержка проектного управления в Белгородской области осуществляется через автоматизированную информационную систему (АИС) «Проектное управление». Это web-приложение, не требующее установки дополнительного ПО и выполняющее следующие функции для проектов, портфелей и программ:

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

Достоинства и недостатки проектного менеджмента

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

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

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

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

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

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

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

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

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

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

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

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

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

Менеджер проекта — индивидуум, отвечающий за управление проектом.

Команда проекта — люди, прямо или косвенно отчитывающиеся по проекту.

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

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

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

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

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

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

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

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

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

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

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

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

Матричные структуры

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

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

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

Экспедитор проекта

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

Координатор проекта

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

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

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

Сильная матрица

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

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

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

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

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

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

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

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

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

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

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

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

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

Проектный офис

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

Типичными подразделениями проектного офиса являются:

— аналитический центр, в котором ведутся компьютерные модели проектов;

— архив, в котором ведутся архивы проектной документации;

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

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

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

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

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

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

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

Организация проектного офиса — важный элемент и показатель зрелости системы управления проектами в организац

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

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

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

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

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

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

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

Офисные программные пакеты по управлению проектами широко распространены на Западе. Так, популярный пакет MSR Office в профессиональном исполнении включает в себя инструмент для управления проектами MSR Project.

Для управления проектами на промышленных предприятиях нужны более развитые средства. Компания PRIMAVERA Systems, Inc. и ее партнер на российском рынке компания Консалтинг ПРИМ предлагают серию продуктов PRIMAVERA по управлению большими проектами в многопользовательской среде. Во-первых, это PRIMAVERA Project Planner (P3R) - мощное средство планирования, управления и контроля. С его помощью можно управлять большими проектами (до 100000 работ, без ограничений по ресурсам), которые выполняются в распределенной среде. Проект может создаваться из блоков (фрагментов) предыдущих проектов или собираться из проектов, подготовленных с помощью инструмента PRIMAVERA SureTrak Project Manager. Р3 предоставляет удобные средства для просмотра состояния проекта в различных управленческих ситуациях: работы можно группировать, сортировать, фильтровать по различным признакам, имеется большой арсенал разнообразных представлений информации в виде графиков (в том числе, гистограммы, таблицы), поддерживается внедрение документов, таблиц и других объектов из других приложений Задание зависимостей между работами и ограничений на разных типов сроки выполнения работ влияют на расчет критического пути, полного и свободного резерва и т.д. Перерасчет расписания может осуществляться как от начальной даты, так и от конечной желательной даты завершения проекта. Р3 - хороший инструмент для ресурсного и стоимостного планирования и контроля, в частности, он позволяет описывать ресурс с помощью назначения нормального и максимального количества ресурса, а также различной цены ресурса по временным интервалам, задавать нелинейный профиль потребления ресурса на отдельную работу, разрешать конфликты коллективного использования ресурсов, а также выполнять сглаживание перегрузок ресурсов с помощью набора стратегий и т.д. Развитые средства коммуникации по проекту позволяют установить пароли пользователей и полномочия по выполнению функций, в частности, по расчету расписания и разрешению конфликтов ресурсов. Многочисленные отчеты позволяют как выдавать задания персоналу, так и отслеживать состояние проекта. Реализация проекта отображается также в графических и табличных отчетах. Например, пользователь может посмотреть бюджет проекта, в котором приводятся фактические затраты за период и на дату, процент выполнения работ, освоенный объем ресурсов, стоимость до завершения проекта. Обмен информацией по проекту также может осуществляться с помощью электронной почты.

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

Программный продукт Р3 обеспечивает окрытый доступ к базе данных из других программ, интегрируется с корпоративной системой по управлению ресурсами предприятия и взаимодействует с контуром повседневного управления. Кроме того, возможна тесная интеграция и объединение баз данных Р3 со специфическими программными продуктами пользователей - будь то бухгалтерия или специальная программа по управлению производством. Пакет Р3 интегрируется с системой документооборота, построенной на основе LotusR Notes. Также в семействе продуктов PRIMAVERA Systems, Inc. имеется собственный инструмент по управлению контрактами Expedition 6.0, который поддерживает все возможные виды документооборота по проекту. В базе данных Expedition 6.0 могут храниться чертежи и другая инженерная документация, контракты, договора платежные документы, а также приказы, распоряжения, бюллетени, протоколы собраний - многочисленные административные документы. Специальные средства поддерживают и регистрируют ввод всевозможных документов в документооборот, обеспечивают выборку документов по ключевым словам и другими способами, сохраняют данные о процессах обработки документов: об изменении документов, о движении документов между участниками проекта, а также сводные данные по проекту (так автоматически формируется таблица затрат, в которой отражаются все доходные и расходные статьи по контрактам). Проводится аналитическая обработка данных по документообороту и проекту, в частности, рассчитываются тенденции изменения стоимости, строятся прогнозы результатов изменений. С помощью системы Expedition 6.0 можно получить информацию о фактических платежах, состоянии работ по субподрядам, готовности документов различных типов и т.д. Пакет Monte Carlo, разработанный компанией Primavera, предназначен для оценки риска по проекту и обеспечивает вероятностную оценку сроков и стоимости завершения проекта.

Управление при помощи проектов означает не только успешное завершение проекта, но и использование гибкости управления проектами как основного принципа управления сложной организацией в сложной внешней среде. Это утверждение объясняет, почему управление при помощи проектов и соответствующие инструменты PRIMAVERA Systems, Inc. применяется в очень разных сферах деятельности: на российских предприятиях нефтегазовой промышленности (проекты по разведке и разработке нефтяных, газовых и других месторождений, организации добычи, транспортировки и переработки нефти и т.д. являются очень сложными и носят уникальный характер), при восстановлении инфраструктуры Боснии (с помощью проектного управления единая картина проведения работ объединяет, с одной стороны, различные секторы экономики: энергетику, здравоохранение, образование и т.д., а с другой, многочисленных субподрядчиков), для организации снабжения научно-исследовательских станций в Антарктике (промежуток времени, в течение которого могут выполняться инженерно-технические работы, - очень короткий и необходимо очень точно спланировать работы и рассчитать ресурсы), реконструкции МКАД и организации Олимпийских Игр, строительство плавучей платформы для запуска космических спутников и т.д.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Подобные документы

Понятие, состав и виды проектов. Этапы управления проектами на предприятии. Организационно-экономическая характеристика ТОО "Казцинктех". Анализ экономических показателей работы предприятия. Основные проблемы в управления проектами и пути их решения.

дипломная работа , добавлен 22.05.2012


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

дипломная работа , добавлен 23.08.2011


Понятие и структура корпоративной системы управления проектами. Основные методы диагностики уровня зрелости управления проектами. Инициация и планирование, финансирование проектов. Управление программами, рисками, коммуникациями и портфелем предприятия.

дипломная работа , добавлен 20.08.2017


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

курсовая работа , добавлен 23.11.2010


Характеристика этапов развития управления проектами в России. Понятие, роль и актуальность проектного управления. Основные формы планирования и контроля текущей деятельности фирмы. Особенности управления проектами в фирмах-партнерах "1С:Франчайзи".

курсовая работа , добавлен 23.10.2015


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

реферат , добавлен 29.09.2012


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

курсовая работа , добавлен 05.11.2011

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

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

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

И, наконец, упомянем, тот факт, что практика создания собственных методик и руководств по управлению проектами широко распространена в крупнейших западных компаниях, таких как Oracle, IBM, PricewaterhouseCoopers, Andersen Consulting, SAP AG, Siemens и др.

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

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

Этим и другим смежным вопросам посвящён доклад.

1. Общие соображения по созданию стандарта. Специализация и детализация.

Стандарты управления проектами уровня предприятия в части методологии обычно имеют основу, определяемую документами достаточно общего характера (иногда эти документы называют "рамочными"). К таким документам относится Project Management Body of Knowledge (PMBoK) Американского института управления проектами (PMI), признаваемый многими международным стандартом де-факто, и стандарт ISO 10006:1997, придавший ряду наиболее важных положений PMBoK статус стандарта де-юре. Смысл и содержание перехода от рамочных стандартов (какими, являются и PMBoK, и в еще большей степени ISO 10006) к стандарту предприятия состоит в их специализации и детализации.

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

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

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

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

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

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

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

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

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

Рис. 1. Пространство процессов управления

Рис. 2. Структура стандарта управления проектами

2. Классификация проектов как первый этап создания стандарта

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

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

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

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

Что должно быть отражено в Плане управления проектом

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

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

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

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

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

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

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

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

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

Классификация по масштабности проекта позволяет специализировать разделы Организационная структура , Управление отклонениями, Обеспечение качества . Для построения этой классификации могут использоваться различные основания - территориальная разбросанность, как это принято в Enron Corp., или стоимость проекта (IBM), может быть, какие-то другие основания и их комбинации.

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

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

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

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

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

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

При построении специализированного микрошаблона "Содержание и границы проекта" мы использовали рекомендации PMBoK PMI (Табл. 1).

В этом шаблоне остается менять только названия программного обеспечения и сроки выполнения этапов работ.

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

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

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

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

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

Сопоставив приведенное в примере содержание разделов Продукт проекта и Результаты проекта , можно заметить, что результатами проекта являются элементы декомпозиции продукта проекта. Именно поэтому при формировании Плана (а, следовательно, и при формировании шаблона Плана) часто используют структуру декомпозиции работ (WBS – Work Breakdown Structure), а многие ведущие компании включают в свои методологии и стандарты типовые WBS как в явном виде (Andersen Consulting), так и неявно (IBM).

Структура декомпозиции работ

Провести декомпозицию и составить структуру декомпозиции работ (WBS – Work Breakdown Structure) по утверждению некоторых авторов очень легко: "Прежде всего, следует разбить проект на несколько подпроектов. Каждый из подпроектов, в свою очередь, может быть разбит на некоторое число подподпроектов. Так следует последовательно делить проект на составные части до тех пор, пока не будет достигнут нужный уровень детализации" (Цитируем по статье М. Ньюэлла "Структура декомпозиции работ" в мартовском номере журнала "Директор информационной службы" за 2001 г.).

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

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

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

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

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

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

А следовательно, первое, что должно быть отражено в специализированном шаблоне WBS, это какие альтернативные взгляды на структуру декомпозиции работ должны поддерживаться в проекте (взгляд руководителя проекта, взгляд куратора, взгляд инвестора и т.д.).

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

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

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

Проиллюстрируем это на примере не самого сложного раздела плана "Организационная структура проекта". В PMBoK необходимая информация разбросана по нескольким разделам (2.2.; 2.3.; 2;4.; 4.1.3.; 9), а в ISO 10006:1997(Е) - разделе 5.8. Но и в том и в другом случае для создания специализированного шаблона этой информации не достаточно!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4. Общая схема управления отклонениями

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

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

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

И все это в результате привело к необходимости внесения изменений в план проекта.

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

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

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

Управление рисками

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

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

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

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

Табл. 2. Матрица степени угрозы риска

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

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

Управление проблемами

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

В ходе реальной работы по созданию и внедрению стандарта управления проектами на предприятии авторам пришлось столкнуться с тем, что словосочетание "управление проблемами" вызывает недоумение у коллег, не имевших опыта знакомства с англоязычными стандартами управления проектами. Многим кажутся более привычными укоренившиеся в русскоязычной литературе термины «решение» или «разрешение проблем», которые соответствуют определениям «problem solving» или «problem resolution», принятым в упоминавшихся выше так называемых "рамочных" стандартах.

Авторы в этом вопросе предпочитают следовать духу и букве таких стандартов управления проектами как MITP/PMM/WISDDM корпорации IBM, в которых этот процесс называется "problems/issues management", что в русском переводе лучше всего, на наш взгляд, выглядит именно как "управление проблемами".

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

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

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

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

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

Табл. 2. Матрица приоритетов решения проблем

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 5. Области потерь

Рис. 6. Стратегии изменений в проекте

5. Организационные структуры в проектах

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

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

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

Начальник отдела и руководитель проекта

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

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

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

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

Часто возникает путаница, какие функции относятся к компетенции начальника подразделения, а какие – к компетенции руководителя проекта. Особенно это характерно для случаев когда «руководитель проекта» - не должность в штатном расписании предприятия, а только проектная роль, которую может исполнять, в том числе, и начальник подразделения. В Табл. 3 приведено несколько примеров, иллюстрирующих эти различия в некоторых областях, где административное и проектное управление имеют точки соприкосновения.

Табл. 3. Разделение ответственности при административном управлении и управлении проектами

Исполнитель

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

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

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

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

Команда проекта

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

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

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

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

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

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

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

Рис. 7. Схема формирования команды проекта

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

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

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

Планирование и контроль качества в проекте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 9. Структура и функции служб, отвечающих за качество исполнения проектов

Служба управления качеством в части управления проектами обеспечивает:

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

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

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

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

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

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

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

7. Тактика и стратегия внедрения стандарта управления проектами

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

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

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

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

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

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

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

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

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

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

Стандарт управления проектами в общем контексте управления предприятием

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

Рис. 11. Стандарт управления проектами в системе управления предприятием

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

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

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

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

Информационные технологии в управлении проектами

Здесь мы выделим два основных направления – автоматизация стандарта управления проектами и автоматизация функций управления проектами.

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

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

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

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

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

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

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

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

Автоматизация управления проектами не является темой этого доклада. Поэтому здесь мы ограничимся констатацией того, что средства автоматизации управления проектами необходимо связывать с другими информационными системами предприятия (например, с системой управления персоналом, с ERP-системой и т.д.). А это, в свою очередь, приведет к необходимости установления интерфейсов между базовыми пакетами прикладных программ, использованных для создания связываемых элементов интегрированной системы предприятия. . В последнее время модули управления проектами всё чаще становятся частью таких прикладных систем как ERP , например модуль Project System в SAP R /3 и CRM , например, модуль Eventix Engagement в SalesLogix .

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

8. Глоссарий управления проектами

Начнем этот раздел с рассказа об одном забавном эпизоде. Однажды, в нашей компании проходили практику студенты-дипломники, специализирующиеся по управлению проектами. Выдавая им задание, руководитель практики (один из авторов этого доклада) попросил описать scope проекта (он так и сказал – скоуп). ”А что такое scope?” – осторожно уточнила одна девушка. ”О, scope – это…” – ответил руководитель и нарисовал руками в воздухе нечто, напоминающее средних размеров глобус. “Понятно, - грустно сказала девушка. – Нам в институте также объясняли”.

Ситуация очень характерная и довольно опасная. Есть некий термин, употребляемый в англоязычных источниках и не имеющий очевидного и однозначного перевода на русский язык в контексте управления проектами. На профессиональном жаргоне мы привыкли пользоваться этим термином на языке оригинала. Действительно, гораздо удобнее сказать scope , чем какое-нибудь достаточно громоздкое “содержание и границы”. Если кому-то непонятно, то всегда можно объяснить, хотя бы с помощью жестов. А приводит все это к тому, что некоторое время спустя точного значения термина никто уже не помнит, каждый трактует его по-своему, и при этом все думают, что понимают друг друга!

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

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

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

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

Краткий глоссарий

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

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

Проект – целенаправленная деятельность временного характера, предназначенная для создания уникального продукта или услуги [НТК].

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

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

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

План управления проектом (Project Management Plan) - основополагающий документ (baseline document), с которого должен начинаться любой проект. Содержит согласованное всеми участниками документально зафиксированное представление о проекте. В инвестиционных проектах – Мастер-план проекта (Project Master Plan) (УП).

Устав Проекта ( Project Charter) - документ, разработанный вышестоящей администрацией, который предоставляет менеджеру проекта право использовать ресурсы организации для выполнения работ проекта [ PMBOK].

Определение Проекта ( Project Definition Report) - документ, определяющий проект, в том числе: каковы цели и результаты проекта; в чём его необходимость; что должно быть сделано; как, когда, и где это должно быть сделано; что для этого нужно; сколько это будет стоить; какие необходимо привлечь внешние ресурсы и организации; какие стандарты и процедуры подлежат соблюдению при осуществлении проекта [НТК].

Базис (Project Baseline) - Основополагающие параметры и фиксирующие их согласованное понимание всеми участниками документы проекта – «точка опоры» для всего последующего развития проекта.

Базовый план (Baseline) - Первоначальный план проекта с утвержденными изменениями. Базовый план бывает также и по составляющим проекта - стоимости, расписанию и т.д. [ОУП].

Предметная область ( Scope) – совокупность продуктов и услуг, производство которых должно быть обеспечено в рамках осуществляемого проекта [ PMBOK].

Цели ( Scope) - совокупность продуктов и услуг, намеченных к производству в проекте [ОУП].

Ключевые вехи проекта (Project Milestones) - ключевые события проекта, свершение которых является необходимым и достаточным условием, определяющим достижение результатов проекта. Обычно представляются в виде схемы или таблицы с взаимосвязями и сроками свершения, образуя План по Вехам (Milestone Plan, Milestone Schedule, Master Schedule).

Контрольное событие - важное событие проекта, обычно связанное с достижением важнейших результатов [ОУП].

Другие варианты – ключевое событие [УП], контрольная точка [УП].

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

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

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

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

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

Отклонение ( Deviation) – выход за пределы установленных требований. К отклонениям относятся случаи, когда результат работы не удовлетворяет требованиям или необоснованно их превышает[ QMPP].

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

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

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

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

Проблемные ситуации ( Problem situations) – возникающие при осуществлении проекта ситуации, для выхода из которых необходимо находить оптимальные решения [НТК].

Решение проблем ( Problem Solving) – определение последовательных систематических процедур, с помощью которых анализируются и решаются проблемные ситуации [НТК].

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

Изменения – Увеличение или уменьшение характеристик элементов проекта. Пересмотр базового плана проекта. Подразумевает документально оформленные и утвержденные изменения [УП].

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

Расписание проекта - плановые даты для выполнения работ и плановые даты для наступления контрольных (ключевых) событий («вех») проекта [НТК].

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

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

Руководитель проекта (Project manager) - менеджер, отвечающий за успешную реализацию проекта, взаимодействие с Заказчиком, субподрядчиками и подразделениями Компании, организацию подготовки и предоставление отчетности по проекту.

Менеджер проекта - лицо, ответственное за управление проектом [ PMBOK].

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

Бюджет проекта – сметная стоимость, распределенная по периодам выполнения проекта [НТК].

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

Участники проекта – физические лица и организации, которые непосредственно вовлечены в проект или чьи интересы могут быть затронуты при осуществлении проекта [ PMBOK].

9. Дополнительные преимущества от внедрения стандарта.

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

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

Стандарт не заменит этой литературы, но роль его в целенаправленном обучении персонала компании может быть весьма значительной. Здесь, на наш взгляд, будет уместной следующая параллель. В части процессов управления проектами стандарт предприятия специализирует и детализирует требования рамочных стандартов (таких как ISO 10006 или PMBOK PMI). Точно также в части квалификации управленческого персонала стандарт предприятия специализирует и детализирует требования нормативных документов рамочного характера в этой области (таких как ICB или НТК).

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

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

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

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

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

В качестве другого примера приведем пятиуровневую модель (PM) 2 – Project Management Process Maturity Model .

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

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

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

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

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

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

Стандарт управления проектами и маркетинг

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

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

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

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

10. Литература:

1 Михеев В.Н., Товб А.С. Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов. В сб. Трудов 2-ой Всероссийской практической конференции «Стандарты в проектах современных информационных систем», М., 2002. – с.33-37.

2 Товб А.С. Ципес Г.Л. Метод и опыт создания предприятия по управлению ИТ-проектами. В сб. Трудов 2-ой Всероссийской практической конференции «Стандарты в проектах современных информационных систем», М., 2002. – с.42-47.

3 Товб А.С. Ципес Г.Л. Заметки по управлению проектами. Стандарт управления проектами уровня предприятия. «Директор информационной службы» №№ 1-6, 2001 и №№ 1-6, 2002.

4 «Директор информационной службы» №5, 2001.

5 C. William Ibbs, Young-Hoon Kwak. The benefits of Project Management: financial and organizational rewards to corporations. - Project Management Institute Education Foundation, 1997

11. Источники, по которым цитируются определения:

Британский стандартBS 6079-2:2000 Project management Part 2 Vocabulary. (перевод авт.).

ISO/TR 10006: 1997 (E). Quality Management – Guidelines to quality in project management (используется перевод Г.Е. Герасимовой).

Wideman Comparative Glossary of Project Management Terms. PMForum, 2000 (www.maxwideman.com).

A Guide to the Project Management Body of Knowledge. PMI Standards Committee.1996 Edition (используется перевод М. Грашиной).

Quality Management for Projects and Programs, Lew Ireland, Project Management Institute , Newtown Square, PA, 1991. (Цитируется по , перевод авт.)

[НТК] Основы Профессиональных Знаний и Национальные Требования к Компетентности специалистов по управлению проектами. Под ред. В.И. Воропаева, 2001.

[ОУП] Основы управления проектами. В.И. Либерзон.

[УП] Управление проектами. Справочник для профессионалов. Под ред. И.И. Мазура и В.Д. Шапиро, 2001.

[УПП] Управление программами и проектами. 17-модульная программа для менеджеров «Управление развитием организации». Модуль 8. М.Л. Разу, В.И. Воропаев и другие, 1999. Ссылки

В отличии от PM BoK PMI в методологии MITP(PMM) IBM термин Project objectives означает задачи проекта, решение которых, т.е. достижение соответствующих подцелей может быть оценено по количественным критериям.

Например, в различных материалах, основанных на методологии MITP компании IBM, проектные риски не всегда включаются в состав отклонений.