Управление проектами. Фундаментальный курс
Автор: Коллектив авторов
Серия книг: Учебники Высшей школы экономики
Жанр: менеджмент,управление бизнесом,книги по экономике
Издатель: Высшая Школа Экономики (ВШЭ)
Дата выхода: 2013
Возрастное ограничение: 12+
Тип: книга
ISBN: 978-5-7598-0868-8
Цена: 247.50 Руб
В книге подробно и систематически излагаются фундаментальные положения,основные методы и инструменты управления проектами.Рассматриваются вопросы управления программами и портфелями проектов,создания систем управления проектами в компании.Подробно представлены функциональные области управления проектами-управление содержанием,сроками,качеством,стоимостью,рисками,коммуникациями,человеческими ресурсами,конфликтами,знаниями проекта.Материалы книги опираются на требования международных стандартов в сфере управления проектами. Для студентов бакалавриата и магистратуры,слушателей программ системы дополнительного образования,изучающих управление проектами,аспирантов,исследователей,а также специалистов-практиков,вовлеченных в процессы управления проектами,программами и портфелями проектов в организациях.!
Коллектив авторов
Учебники Высшей школы экономики
В книге подробно и систематически излагаются фундаментальные положения, основные методы и инструменты управления проектами. Рассматриваются вопросы управления программами и портфелями проектов, создания систем управления проектами в компании. Подробно представлены функциональные области управления проектами – управление содержанием, сроками, качеством, стоимостью, рисками, коммуникациями, человеческими ресурсами, конфликтами, знаниями проекта. Материалы книги опираются на требования международных стандартов в сфере управления проектами.
Для студентов бакалавриата и магистратуры, слушателей программ системы дополнительного образования, изучающих управление проектами, аспирантов, исследователей, а также специалистов-практиков, вовлеченных в процессы управления проектами, программами и портфелями проектов в организациях.
Управление проектами. Фундаментальный курс
© Национальный исследовательский университет «Высшая школа экономики», кафедра управления проектами, 2013
© Оформление. Издательский дом Высшей школы экономики, 2013
Все права защищены. Никакая часть электронной версии этой книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, включая размещение в сети Интернет и в корпоративных сетях, для частного и публичного использования без письменного разрешения владельца авторских прав.
Дорогие читатели!
Современные компании, различные отрасли и даже целые государства приходят сегодня к осознанию себя проектно-ориентированными и, как следствие, к необходимости учиться грамотно и эффективно управлять проектами. Управление проектами, зародившись как практическая деятельность в глубокой древности и пережив свое становление как научно-методическая дисциплина во второй половине XX в., превратилось в настоящее время в одну из самых востребованных и перспективных методологий менеджмента во всем мире со своей системой международных и национальных профессиональных организаций и стандартов, а также сложившейся терминологией и совокупностью методов и инструментов.
История управления проектами своими корнями уходит вглубь времен. Известны многие артефакты крупных, средних и малых проектов, созданных в разное время.
В новейший период проектная методология в своем развитии прошла ряд важных этапов.
Значимые результаты в развитии рассматриваемых методов были получены в 1950-1960-е годы, когда был сформирован базовый инструментарий и основные методические и практические подходы. Далее в 1970-1990-е годы создавались профессиональные организации и развивалась практика и методы стандартизации в управлении отдельными проектами.
В 1990-е годы возникла концепция управления при помощи проектов (management by projects), и управление проектами пришло непосредственно в компании. Возникли методологии управления портфелями проектов и программами, на многих предприятиях и в организациях стали создаваться корпоративные системы управления проектами (КСУП). Появилась необходимость разработки способов измерения зрелости управления проектами в компаниях, и такие приемы были разработаны и стандартизированы.
В последние годы набирают популярность так называемые гибкие методологии управления проектами, происходит их обобщение, осмысление и активная популяризация.
Управление проектами по природе своей является синтетической дисциплиной, объединяющей весь сложный комплекс вопросов по управлению различными функциональными областями знаний проекта (содержание проекта, сроки, стоимость, риски, персонал, коммуникации и др.). Коллектив авторов, работавший над данным учебником, стремился представить рассматриваемую методологию во всем ее многообразии с тем, чтобы обеспечить читателям системное представление о существующих подходах по многим аспектам управления проектами. С учетом этого стремления и была сформирована структура учебника.
Первый раздел книги призван ознакомить читателя с историей и основными понятиями проектной методологии и современным ее состоянием. В этом разделе рассматриваются методологические аспекты управления проектами, его историческая эволюция, базовые понятия и современное состояние.
Во втором разделе изложены основные вопросы системного управления проектами. С позиций системного подхода рассмотрены несколько уровней управления проектами (управление проектами в широком смысле): управление портфелем проектов, управление программами и собственно основы создания и функционирования корпоративных систем управления проектами.
В третьем разделе системный подход реализован посредством рассмотрения функциональных подсистем (областей знаний) управления проектами. Важность этих подсистем связана с тем, что процессы управления проектами имеют функциональное наполнение, например, если речь о процессе планирования, то подразумевается планирование сроков, планирование затрат, качества, рисков и т. д. То же можно проиллюстрировать и на примере других процессов. Поэтому изучение инструментов, механизмов и форм каждой подсистем является необходимой частью наращивания компетенций проектного менеджера.
В четвертом разделе рассматриваются возможности и опыт использования проектной методологии в управлении государственными проектами и программами и инновациями.
В настоящее время существуют учебники и пособия, на достаточно высоком уровне и детально описывающие многие вопросы управления проектами[1 - Управление проектом. Основы проектного управления: учебник / под ред. проф. Л. М. Разу. М.: КНОРУС, 2006; Мазур И. И., Шапиро В. Д., Ольдерогге Н. Г. Управление проектами. М.: Омега-Л, 2006; Романова М. В. Управление проектами. М.: ИД «ФОРУМ»; ИНФРА-М, 2007; Ларсон Э. У., Грей К. Ф. Управление проектами. М.: Дело и Сервис, 2013.]. В данной книге сделана попытка системного подхода к рассмотрению управления проектами, раскрытию процессов, протекающих при формировании портфелей, программ и отдельных проектов, встраивании проектной методологии в стратегический бизнес-процесс компании.
В заключение хотелось бы пожелать вам успехов в освоении материала нашего учебника и в вашем дальнейшем профессиональном становлении и развитии в сфере проектного управления.
Научные редакторы:
Валерий Аньшин, д.э.н., профессор
Ольга Ильина, к.т.н., доцент
Раздел I. История и методология управления проектами
Глава 1. Историческая эволюция управления проектами
Изучив материал данной главы, вы узнаете:
• каковы исторические корни управления проектами;
• какие основные этапы прошла дисциплина управления проектами в своем развитии;
• как развивалась методология управления проектами в России.
1.1. Зарождение и становление управления проектами
Проекты осуществлялись на протяжении всей истории развития человеческой цивилизации. Фактически история человечества может быть рассмотрена через призму проектов, которые были реализованы в ту или иную эпоху. Египетские пирамиды, Великая Китайская стена, Тадж-Махал, Кёльнский собор, собор Святого Петра и многие другие сооружения, потрясающие воображение и сегодня, спустя сотни и тысячи лет после их завершения, являются яркими примерами концентрации духовных и интеллектуальных усилий при реализации великих проектов прошлого.
Исторические корни дисциплины управления проектами связаны с работами классиков менеджмента Г. Гантта, А. Файоля, Ф. Тейлора. Генри Гантт (Henry Gantt, 1861–1919) – американский инженер, предложивший в 1910 г. новую технику календарного планирования с использованием горизонтальных диаграмм. Впоследствии диаграмма Гантта стала инструментом де-факто, а изобретателю присвоили звание «отца техники планирования». Диаграмма Гантта оказалась настолько серьезным аналитическим инструментом, что на протяжении почти ста лет не претерпевала изменений. И только в 1990-х годах для более подробного описания зависимостей между задачами были добавлены связи. А. Файоль (Henri Fayol, 1841–1925) – создатель классической теории управления, определивший пять основных функций менеджмента, ставших основой управления проектами. Работы автора «научного менеджмента Ф. У. Тейлора (Frederick Winslow Taylor, 1856–1915) стали прототипами многих современных инструментов, включая иерархическую структуру работ (Work Breakdown Structure).
Теоретические основы проектного управления развивались эволюционно [Баркалов и др., 2005].
В 1937 г. американским ученым Гуликом была предпринята первая разработка по матричной организации для руководства и осуществления сложных проектов. Это был первый реальный шаг по преодолению господствовавшего на тот момент идеала бюрократической организации. Матричная организация является адаптивной структурой, состоящей из межфункциональных, ориентированных на конкретные задачи временных рабочих групп, а не из постоянно действующих функциональных отделов. В противоположность бюрократической организации с характерной для нее четкой иерархией власти и базовым принципом единоначалия матричная организация отличается децентрализацией власти и ее горизонтальным распространением. Для бюрократической организации постоянным является набор служебных должностей, в то время как для матричной организации постоянен некоторый набор высококвалифицированных сотрудников.
В 1950-х годах управление проектами окончательно сформировалось как отдельная область знаний. В эти годы появилось два основных математических метода управления расписанием проектов – метод критического пути СРМ и метод оценки и анализа программ PERT Метод критического пути возник благодаря трудам специалистов корпораций DuPont и Remington Rand, работавших над проектами по ремонту оборудования заводов DuPont. История появления методики PERT типична для многих изобретений периода «холодной войны». В целях управления очередным проектом ВМФ США – разработкой баллистической ракеты «Поларис» – компанией Lockheed и консалтинговой фирмой Booz Allen Hamilton был создан метод планирования работ на основании оптимальной логической схемы процесса, названный методом оценки и анализа программ.
В 1959 г. комитетом Андерсона (NASA) был предложен системный подход к управлению проектом по стадиям его жизненного цикла, в котором особое внимание уделялось предпроектному анализу.
В 1966 г. появляется система GERT (Graphical Evaluation and Review Technique), использующая новую генерацию сетевых моделей. GERT – вероятностный метод сетевого планирования – применяется в случаях организации работ, когда последующие задачи могут начинаться только по завершении некоторого числа предшествующих задач. Этот метод, используется для определения оценок вероятности реализации событий, основанных на статических данных, получаемых в результате моделирования, и применяется в случае, когда затруднительно или невозможно однозначно определить, какие именно работы и в какой последовательности должны быть выполнены для достижения цели проекта, т. е. существует многовариантность реализации проекта.
1970-е годы характеризуются разработкой и развитием системного подхода к управлению проектами – это учет внешнего окружения проектов (экономических, экологических, общественных и др.), разработка и внедрение в практику методов управления конфликтами, разработка организационных структур управления проектами и система ролей в ней.
В 1980-е годы управление проектами сформировалось как сфера профессиональной деятельности: появились новые значимые дополнения, такие как управление ресурсами (финансы, люди и проч.), управление рисками и проблемами проекта, управление качеством, формирование команды. В США публикуется первая версия коллективной работы института PMI – Project Management Body of Knowledge (Свод знаний по УП), в которой определены место, роль и структура методов и средств УП и их вклад в общее управление.
1990-е годы можно обозначить как начало массового проникновения методов управления проектами в менеджмент компаний различных сфер деятельности и расширение их применения в различных отраслях и странах, включая развивающиеся. Начался процесс унификации и стандартизации методов и подходов к управлению проектами, в частности, были разработаны и введены в действие международные (ISO 10006-10007) и национальные (АРМ, PMI, AI PM) стандарты по управлению проектами.
Этапы развития методов управления проектами представлены в табл. 1.1.
Важную роль в развитии управления проектами играют профессиональные ассоциации.
В 1967 г. в Европе основана Международная ассоциация управления проектами INTERNET, которая позже была переименована в International Project Management Association (IPMA), создавшая стандарт (профессиональные требования) к деятельности специалистов по управлению проектами IPMA Competence Baseline (ICB).
В 1969 г. в США появилась профессиональная некоммерческая организация, представляющая интересы индустрии управления проектов, – Институт управления проектами (PMI). В 1981 г. в PMI началась подготовка документа, содержащего методологические основы управления проектами, – «A Guide to the Project Management Body of Knowledge» (PMBOK Guide). Пробный вариант руководства стал доступен в 1987 г., а первая редакция опубликована в 1996-м. Сегодня стандарт PMBOK признан во всем мире и является международным де-факто.
Таблица 1.1
Этапы развития методов управления проектами
За последующие десятилетия в рамках управления проектами были разработаны различные методы, модели и инструменты, сформированы профессиональные стандарты по различным аспектам проектного управления. В профессиональной литературе достаточно подробно рассмотрены основные вехи становления управления проектами в России и за рубежом.
1.2. Современное состояние управления проектами
Современное управление проектами является зрелой профессиональной научно-практической сферой, включающей:
• сложившиеся и выверенные практикой концепции, теорию, методологию и развитые технологии;
• признанные международные и национальные стандарты и другие нормативно-методические документы;
• развитый мир профессиональных публикаций, конференций и конгрессов;
• богатый рынок профессиональных программных приложений;
• развитый рынок профессиональных услуг;
• современные системы образования, включая различные программы сертификации профессионалов;
• обширные области применения в современном обществе;
• растущую популярность и значение.
Анализ эволюции научных исследований по управлению проектами был проведен группой ученых под руководством проф. Т. Клоппенборга (Xavier University, США). В ходе исследования были проанализированы 3554 работы по управлению проектами за 1960–1999 гг., причем рассматривались только англоязычные научные статьи и монографии, имеющиеся в библиотеках США. Результаты исследования приведены в табл. 1.2–1.5.
Таблица 1.2
Распределение общего количества цитат в области управления проектами
Таблица 1.3
Распределение работ по группам процессов управления проектами
Таблица 1.4
Распределение работ по областям знаний управления проектами
Таблица 1.5
Распределение работ по отраслям
Одним из результатов исследования стало выявление трендов дальнейшего развития управления проектами в 1990-2000-х годах:
• компетенции;
• поведенческий аспект;
• управление стейкхолдерами;
• коммуникации;
• карьерный путь менеджера проекта;
• стандарты и сертификация.
Также были даны прогнозы относительно наиболее перспективных направлений для научных исследований в области управления проектами, в качестве которых были названы следующие:
• стандартизация;
• интернет-технологии;
• контракты;
• аутсорсинг;
• роль менеджера проекта;
• отбор проектов;
• обучение управлению проектами;
• управление рисками;
• коммуникации.
Сегодня стало очевидно, что большинство прогнозов оправдалось в 2000-е годы.
1.3. Управление проектами в России
Управление проектами, как его принято трактовать в международном формате понятий, определений, стандартов, методов и инструментов, начало формироваться в России достаточно поздно, в 1990-е годы. Однако на протяжении всего XX в. в рамках различных научных школ велась разработка отдельных методов и инструментов, которые сегодня относятся к истокам формирования российского управления проектами в его современном звучании. Так, сетевые графики, ставшие широко известными во всем мире в связи с появлением методов управления проектами СРМ и PERT в США в 1950-е годы, были предложены российским инженером А. А. Эрасмусом в 1925 г. [Гусаков, 1993].
Основными вехами становления управления проектами в СССР и России являются:
1. 1920-1930-е годы. Зарождение идеи регламентации и технологической увязки комплекса работ при реализации крупных проектов в строительстве с использованием календарных планов и циклограмм.
2. Организация поточного строительства (1930-1960-е годы). Начало управления проектами в СССР своими корнями уходит в индустриализацию 1930-х годов, когда сформировалась теория строительного потока, явившаяся основой современной научной организации и управления строительным производством. Планирование и контроль выполнения проектов в этот период базируются на детерминированных линейных моделях Гантта и циклограммах с использованием графоаналитических методов их расчета и оптимизации. Реализация принципов управления крупными проектами – в строительстве, оборонно-промышленном комплексе (атомный проект, космическая программа).
3. Сетевое планирование и управление (1960-1980-е годы). Первые работы по сетевым методам были опубликованы в СССР в начале 1960-х годов. В. И. Воропаевым были созданы сетевые модели – обобщенные сетевые модели, особенно полезные для описания сложных проектов с различными взаимосвязями между работами и временными ограничениями разного типа. Тогда же появились первые программные системы планирования и контроля проектов, такие как «А-ПЛАН», «АККОРД», «ГАУСС» и др. [Баркалов и др., 2005].
4. Развитие методов и средств управления проектами (с 1980 г. по наст. время). В это время формируется несколько научно-теоретических направлений развития методов и инструментов управления проектами. Сущность направления концептуального проектирования СП. Никанорова состоит в том, что с помощью логического аппарата представляется возможным формализовать описание предметных областей любой степени сложности. В теории активных систем В. Н. Буркова разработаны организационно-экономические механизмы для управления проектами с учетом человеческого фактора, а именно с учетом достоверности информации, получаемой от исполнителей, и их заинтересованности в выполнении работ в планируемые сроки [Бурков и др., 1984]. В рамках научной школы А. А. Гусакова разработаны теория организационно-технологической надежности, позволяющая учитывать различные случайные факторы, влияющие на выполнение проекта, методы и средства имитационного моделирования, теория системотехники строительства, основанная на системном подходе к осуществлению инвестиционно-строительных проектов, принципы разработки и применения экспертных систем и баз знаний в проектировании и строительстве. Робастная технология Б. П. Титаренко предназначена для поддержки проектных решений на всех фазах управления проектом в условиях неопределенности. В 2000-2010-е годы научные исследования в области управления проектами проводятся В. И. Воропаевым (системная модель управления проектами), В. М. Аньшиным (управление портфелем проектов), Г. Л. Ципесом (корпоративные системы управления проектами), В. Н. Михеевым (определение и развитие компетенций менеджеров проектов «третьей волны»), Д. А. Новиковым (развитие теории активных систем) и др. [Аньшин, 2008; Ципес, Товб, 2009; Михеев, 2009; Новиков А., Новиков Д., 2007]. В целом современные российские научно-методические работы в сфере управления проектами характеризуются широким использованием всего спектра методов и средств управления проектами, нацеленных на решение актуальных современных задач, таких как управление проектами в условиях экономики знаний и устойчивого развития, активизация и развитие человеческого потенциала, достижение долгосрочного успеха.
В последние годы получили бурное развитие так называемые гибкие методологии управления проектами (agile). Методологии Agile зародились в ИТ-сфере и являются альтернативой традиционному управлению проектами, смещая акцент на коммуникации и командную работу, быструю реакцию на изменения и итерационный характер ведения проекта.
Сегодня в России сформировано профессиональное сообщество менеджеров проектов. Активную роль в нем играют профессиональные ассоциации – Российская ассоциация управления проектами СОВНЕТ и Московское и Санкт-Петербургское отделения Института управления проектами США. Набирает темпы процесс сертификации в области управления проектами.
Резюме
Следует различать управление проектами как практическую деятельность и как научную дисциплину. Управление проектами как практическая деятельность зародилось в древние времена, когда человечество встало перед необходимостью осуществления первых масштабных проектов. Формирование управления проектами как научно-теоретической дисциплины пришлось на середину и вторую половину XX в. Важную роль в становлении дисциплины управления проектами сыграли профессиональные ассоциации управления проектами.
Ключевые термины
Диаграмма Гантта (Gantt chart) – графическое представление информации, относящейся к расписанию. В типичной ленточной диаграмме перечень запланированных операций или элементов иерархической структуры работ располагается вдоль левой стороны диаграммы, даты размещены сверху, а длительности операций показаны в виде горизонтальных полос (лент), привязанных к датам.
Проект — временное предприятие, направленное на создание уникальных продуктов, услуг или результатов.
Управление проектами – приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту.
Контрольные вопросы
1. Каковы результаты исследования, предпринятого группой профессора Т. Клоппенборга?
2. Какие профессиональные ассоциации управления проектами вы знаете?
3. Как развивались методы управления проектами в XX в.?
4. Какие основные этапы развития управления проектами в России вы можете назвать?
Литература
1. Аньшин В. М., Демкин И. В., Никонов И. М., Царьков И. Н. Модели управления портфелем проектов в условиях неопределенности. М.: МАТИ, 2008.
2. Баркалов С. А., Воропаев В. И., Секлетова Г. И. и др. Математические основы управления проектами: учеб. пособие / под ред. В. Н. Буркова. М.: Высшая школа, 2005.
3. Бурков В. Н., Кондратьев В. В., Цыганов В. В., Черкашин А. М. Теория активных систем и совершенствование хозяйственного механизма. М.: Наука, 1984.
4. Грей К. Ф., Ларсон Э. У. Управление проектами: учебник. М.: Дело и Сервис, 2007.
5. Гусаков А. А., Гинзбург А. В., Веремеенко С. А. и др. Организационно-технологическая надежность строительства. М.: SvR-Арус, 1994.
6. Гусаков А. А. Системотехника строительства // Российск. ан. науч. совет по комплексной проблеме «Кибернетика». 2-е изд., перераб. и доп. М.: Стройиздат, 1993.
7. Ильина О. Н. Методология управления проектами: становление, современное состояние и развитие. М.: ИНФРА-М; Вузовский учебник, 2011.
8. Мазур И. И., Шапиро В. Д., Ольдерогге Н. Г., Полковников А. В. Управление проектами. М.: Омега-Л, 2009.
9. Мир управления проектами / пер. с англ.; под ред. Х. Решке, Х. Шелле. М.: Аланс, 1993.
10. Михеев В. Н. Драйв-управляющий проектов. М.: Эксмо, 2009.
11. Новиков А. М., Новиков Д. А. Методология. М.: СИНТЕГ, 2007.
12. Шрейбер А. К., Абрамов Л. И., Гусаков А. А. и др. Организация и планирование строительного производства / под ред. А. К. Шрейбера. М.: Высшая школа, 1987.
13. Управление проектами: Основы профессиональных знаний, Национальные требования к компетентности специалистов (NCB – SOVNET, National Competence Baseline Version 3.0). М.: ЗАО «Проектная ПРАКТИКА», 2010.
14. Ципес Г. Л., Товб А. С. Проекты и управление проектами в современной компании. М.: ЗАО «Олимп – Бизнес», 2009.
15. PMBOK Guide. 4th ed. Newton Square, Pennsylvania, USA: Project Management Institute, 2008.
Задание
Проанализируйте какой-либо из известных проектов прошлого с точки зрения современных методологических подходов к управлению проектами.
Примеры анализа великих проектов прошлого с точки зрения современной методологии управления проектами
Проект: собор Святого Петра в Ватикане
Собор Святого Петра расположен к западу от центра Рима, на территории суверенного государства Ватикан. История рассказывает, что на месте нынешнего собора Святого Петра находился цирк, на арене которого во времена Нерона предавали мученической смерти христиан. В 67 г. сюда после судилища был приведен и апостол Петр. Петр попросил, чтобы казнь его не уподобляли Христовой. Тогда он был распят головой вниз.
В 326 г. в память об этом император Константин повелел построить базилику во имя Святого Петра. Когда она обветшала, папа римский Николай V в 1452 г. начал строительство собора. После его смерти работы были приостановлены, и только в 1506 г. папа Юлий II поручил архитектору Браманте строительство собора.
На момент проектирования собора Святого Петра такую область знаний, как управление проектами, не выделяли, что сказалось в дальнейшем на строительстве этого сооружения. В настоящее время управление проектами завоевывает повсеместное признание. Оно показывает, что применение соответствующих знаний, процессов, навыков, инструментов и методов может иметь решающее значение для успеха проекта.
В середине 1990-х годов Институт управления проектами (Project Management Institute, PMI) выпустил первый Свод знаний по управлению проектами – Руководство PMBоK. Каждые четыре года выходит его обновленная версия.
Для того чтобы разобрать сам проект строительства собора Святого Петра, будет разумно обратиться именно к Своду знаний по управлению проектами, так как он является основным руководством для изучения проектов и в нем четко расписаны все его составляющие. Рассмотрим каждый из них по отдельности, чтобы выявить, где были нарушения и насколько проект XVI в. отличается от проектов, создаваемых в наше время.
Для начала возьмем определение проекта. Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. В данном случае собор Святого Петра в Риме полностью соответствует определению проекта, особенно с точки зрения его уникальности.
В Своде знаний по управлению проектами выделяется четыре фазы жизненного цикла проекта:
• начало проекта;
• организация и подготовка;
• выполнение работ;
• завершение проекта.
Если рассматривать жизненный цикл проекта собора Святого Петра, то он не вызывает сомнений, так как все его части необходимы для создания и воплощения проекта.
Да, строительство было начато еще в 1452 г., но проекта как единого целого не существовало, ведь только после указа папы Юлия II архитектор Браманте начал создавать проект, по которому велись работы в будущем. Сама идея воплощалась в проекты дважды: первый раз папой Николаем V неудачно, так как проект был незавершен, а во второй раз папой Юлием II, как известно, удачно. Несмотря на то что проект изменялся и пересматривался, он не прекращал своего существования.
Рассматривая проект собора далее, отметим, что руководство PMBоK выделяет пять групп процессов проекта:
• инициация;
• планирование;
• исполнение;
• мониторинг и контроль;
• завершение.
Они в каком-то смысле очень схожи с жизненным циклом проекта, поэтому нет необходимости рассматривать их детально. Процесс планирования был очень слабым из-за постоянной смены желаний заказчика, на которого никто не мог повлиять в силу его значимости. Но в итоге проект все-таки был завершен, и 18 ноября 1626 г., в 1300-летний юбилей первой базилики и через 120 лет после начала строительства нынешнего собора Святого Петра, папа Урбан VIII освятил новый собор.
Рассмотрим теперь проект собора с другой стороны.
В управление проектами, как указано в Руководстве PMBOK, как правило, входят:
• определение требований;
• удовлетворение различных потребностей, решение проблем и удовлетворение ожиданий различных заинтересованных сторон проекта в ходе планирования и выполнения проекта;
• уравновешивание конкурирующих ограничений проекта, среди прочих:
? содержание;
? качество;
? расписание;
? бюджет;
? ресурсы;
? риски.
Требования к проекту довольно часто менялись. Самым главным требованием первого заказчика – папы Юлия II – была фигура собора – греческий равносторонний крест, все остальное было на усмотрение выбранного архитектора, на тот момент Донато Браманте. Архитектор так и задумал церковь – в виде греческого равностороннего креста. Далее, после смерти Юлия II, пришел править следующий папа – Лев X, который принимал участие в проектировании собора не более чем предыдущий, но его желание кардинально меняло ход строительства. Его требованием было создать собор в виде латинского креста. И следующему архитектору, Рафаэлю Санти, пришлось менять проект в корне. Таким образом, сменились двадцать глав государства Ватикана, последним из которых был Урбан VIII, освятивший собор.
Нужно заметить, что вся истории строительства собора Святого Петра – это история борьбы двух архитектурных концепций – собора в виде греческого креста и храма в виде латинского креста. Греческий крест – равносторонний крест, символ Христианской Церкви. Латинский крест – в христианстве символ Христа, его страстей и искупления, – его продольная перекладина длиннее поперечной.
Как было сказано выше, вместе с папами менялись и архитекторы, которым приходилось пересматривать проект под натиском духовенства. Архитекторами в свое время были Донато Браманте, Рафаэль Санти, Бальдассаре Перуцци, Антонио да Сагалло, Микеланджело, Джакомо дела Виньола и Джакомо дела Порта, Карло Мадерно. В действительности их было намного больше, чем перечислено, но другие были, скорее, субподрядчиками и участвовали в основном во внутреннем убранстве собора.
Как свидетельствует история, проекты собора в части лежащей в его основе креста – греческого или латинского, – чередовались в шахматном порядке. И, конечно, такие «перемены» не могли не тормозить строительство. Удлинение нефа, вызывавшее множество обсуждений и споров, нарушило гармонию первоначального проекта Браманте. Однако церковь в виде латинского креста больше соответствовала римской традиции.
Как видно, при строительстве собора Святого Петра заказчиком всегда был верховный глава государства Ватикан – папа римский.
Отслеживались разделение и значимость каждой роли, а именно, существовали заказчик, проектировщики, архитекторы, строители-подрядчики, поставщики. В данном случае изначально роли архитектора и проектировщика совпадали. Последующие архитекторы работали в основном по проекту первого архитектора, но в связи с постоянным контролем и мониторингом, а также с требованиями заказчика (пап) они вносили изменения.
В результате содержание проекта, структура работ, определение операций и их последовательность нарушались с появлением каждого нового папы римского. И это было неизбежно. Любой крупный проект, который затягивается более чем на продолжительность жизни заказчика, будет претерпевать изменения на всех этапах.
Далее, по цепочке, в связи с частым изменением содержания, сдвигались сроки. Насколько известно, проект длился 120 лет. У нас нет точных данных о стоимости проекта, но несложно предположить ее величину, ведь при изменении проекта необходимо было менять что-то уже построенное, что требовало лишних затрат. А также за увеличением сроков всегда следует увеличение стоимости проекта.
Относительно качества точно сказать ничего нельзя, ведь собор Святого Петра и сегодня предстает во всем великолепии. Пожалуй, можно отметить, что его качество превосходит качество многих современных построек, которые, по моим наблюдениям, требуют реконструкции намного чаще, чем описываемая историческая постройка.
Огромное количество людей было задействовано в строительстве собора. Ведь если сменилось столько заказчиков и архитекторов, что тогда говорить о подрядчиках? К сожалению, нет точной цифры, которая бы описала величину человеческих ресурсов, и вряд ли она была зафиксирована. Ведь при смене заказчиков и самих проектов многое могло затеряться. Развитием команды проекта занимались только архитекторы, они передавали свои знания более молодым архитекторам, которые потом переносили это на проект.
При данном проекте в планировании и исполнении процесса коммуникаций не было необходимости. Собор Святого Петра был крупнейшим на тот момент и до сих пор остается одной из крупнейших католических церквей. Заинтересованной стороной этого проекта был в первую очередь Ватикан. Его глава, являясь заказчиком, был постоянным наблюдателем за строительством, и все коммуникации происходили с ним. Они не были спланированы по срокам, а осуществлялись при необходимости.
Риски при строительстве собора были колоссальными. Во-первых, не было определено содержание проекта, что повлекло за собой сбои во всех остальных процессах. Менялись необходимые ресурсы, сдвигались сроки. Во-вторых, при такой длительности проекта вообще просчитать все риски невозможно.
Про закупки проекта информацию получить очень сложно, но вероятнее всего управление закупочной деятельностью не доставляло хлопот исполнителям проекта. Собор Святого Петра был величайшим проектом на тот момент, и для его строительства выделялось все необходимое. Ведь заинтересованными лицами были все жители города и даже страны. А учитывая, что заказчиком был сам папа римский, ему никто отказать не мог.
Итак, строительство собора Святого Петра длилось 120 лет, с 1506 по 1626 г. Это был уникальный проект. Он был завершен, когда были достигнуты все цели проекта – был построен самый величественный собор во имя Святого Петра.
Проект прошел все 5 процессов, начиная с инициации и заканчивая торжественным завершением.
Присутствовала монополия заказчика. Им являлся глава государства Ватикан папа римский. Инициация произошла еще при папе Николае V, а затем, после длительного перерыва, папой Юлием II, после чего статус заказчика передавался его последователям 19 раз. Был завершен папой Урбаном VIII.
При проекте наблюдалось разделение ролей на заказчика, архитектора, строителей-подрядчиков и т. д. У каждого была своя задача, и он нес свою ответственность.
Кроме этого можно выделить такие процессы, как консалтинг и инжиниринг, без которых такое величественное здание невозможно было бы построить.
Проект: дамба Гувера
Данная работа посвящена одному из величайших сооружений в истории Америки – дамбе Гувера. Перед тем как описывать процесс построения этой плотины, стоит рассказать непосредственно о том, что получилось в результате реализации проекта.
Дамба Гувера представляет собой уникальную плотину высотой 221 метр и гидроэлектростанцию в нижнем течении реки Колорадо. Свое название она получила по имени президента США Герберта Гувера, который сыграл важную роль в ее постройке. Строительство дамбы завершилось на два года раньше планируемого срока и длилось с 1931 г. по 1936 г. включительно. В настоящий момент плотина включена в Национальный регистр исторических мест США, а также является одной из самых известных достопримечательностей в штате Невада.
Целью возведения плотины Гувера было сглаживание колебаний уровня реки Колорадо, поскольку во время таяния снегов в горах фермерские наделы оказывались затопленными; также планировалось, что водохранилище, образованное в результате строительства плотины, поможет водоснабжению районов Южной Калифорнии. Помимо всего прочего на плотине была построена электростанция, поэтому еще одной целью строительства было получение энергоснабжения.
Основными стейкхолдерами проекта стали правительство США, правительства штатов Невада и Калифорния, фермеры, имеющие наделы вдоль течения реки Колорадо, а также просто население штатов Невада и Калифорния, компания, осуществлявшая строительство, и, конечно же, работники, занятые при возведении плотины.
Интересы правительства США в какой-то степени объединяли интересы правительств штатов Невада и Калифорния: решить проблемы фермеров, обеспечить занятость населения, улучшить водоснабжение штатов. Однако при рассмотрении интересов на уровне правительств штатов можно понять, что эти интересы конфликтуют между собой, поскольку правительство Невады вполне справедливо предполагало, что правительство Калифорнии, обладающее большим влиянием и финансами, из-за нехватки воды в штате могло предъявить права на большую часть водных ресурсов.
Что касается отношения к проекту стейкхолдеров, становится ясно, что наиболее влиятельными стейкхолдерами являлись правительство США наравне с правительствами других штатов, а также компания, которая занималась строительством плотины. Все они относились положительно к проекту. Вторым по степени важности было население, которое также положительно относилось к проекту, но имело низкую степень влияния на проект.
В итоге для избежания конфликтов между стейкхолдерами на стадии инициации проекта в 1922 г. была создана комиссия по этому вопросу, результатом работы которой стал документ, закреплявший методики раздела водных ресурсов и способствовавший усилению кооперации между стейкхолдерами проекта.
Что касается управления персоналом, то нельзя не отметить отличительные особенности проекта, а также проблемы, с которыми столкнулась команда управления проектом. Особенность проекта заключалась в том, что к рабочим предъявлялись определенные требования: во-первых, к строительству не допускались выходцы из Китая, а во-вторых, крайне неохотно принимали на работы чернокожих людей, и их число за все время проекта не превысило тридцати человек. В связи с тем, что сроки строительства плотины сократились, возникла еще одна проблема с персоналом – не был построен городок для строителей. Такое изменение плана произошло из-за Великой депрессии (требовалось увеличить количество рабочих мест, чтобы снизить уровень безработицы). Все это вылилось в массовые недовольства рабочих, вынужденных жить в опасных условиях, и привело к забастовке, которая была разогнана с помощью полиции. На примере этой ситуации можно увидеть то, что при строительстве плотины недостаточно внимания уделялось управлению рисками, и управление персоналом также имело свои провалы. Однозначно оценить управление персоналом в данном проекте очень сложно. С одной стороны, проявления недовольства и забастовки достаточно быстро подавлялись, и, несмотря на сдвиги по срокам, сдача временного жилья была значительно ускорена и условия жизни работников улучшены. С другой стороны, работодатель нарушал нормы труда: часть работ проводилась в тоннелях, в которых работники страдали от избытка угарного газа, что наносило серьезный вред их здоровью, нередко вплоть до летального исхода. При этом работодатель снимал с себя всю ответственность, заявляя, что это последствия обыкновенной пневмонии. В настоящее время при проекте такого уровня, тем более государственного масштаба, особенно в США, компания-исполнитель понесла бы серьезное наказание со стороны регулирующих органов. Дальнейшая гуманизация общества, а также улучшение условий труда положительно сказались на управлении персоналом.
Продолжая говорить об управлении рисками, нельзя не отметить еще один провал при возведении дамбы Гувера. При проектировании и непосредственно строительстве не было должным образом оцененено влияние дамбы на окружающую среду, поэтому в настоящий момент в реке Колорадо наблюдается сокращение популяций определенных видов рыб до критических значений.
Но при этом следует отметить, что планирование сроков было осуществлено на достаточно высоком уровне. Плюс ко всему корректировки сроков в результате изменения планов, загруженности достаточно быстро находили свое отражение в новом плане. Помимо этого устав проекта предполагал значительный бонус за перевыполнение плана, поэтому компании, ответственные за строительство, были заинтересованы в точном управлении сроками, в результате чего удалось сдать дамбу на два года раньше запланированного.
Управление качеством проекта также отличалось высоким уровнем. Еще при проектировании было решено использовать для сброса воды не тело плотины, а тоннели в скалах, что значительно повысило стабильность и безопасность дамбы. (В качестве контрпримера можно привести Саяно-Шушенскую ГЭС, при строительстве которой, вероятно, ответственные лица уделяли не столько внимания управлению качеством, поэтому она была спроектирована со сбросом воды через тело плотины.) Помимо этого инженеры просчитали, что при существовавших способах строительства плотина разрушится через 100 лет, и разработали новую уникальную методику строительства сооружений подобного масштаба – в виде взаимно связанных колон.
Что касается управления интеграцией и коммуникациями, то стоит отметить, что в данном проекте эти области знаний имели достаточно критическую роль. Поскольку строительство осуществлял консорциум из шести крупных компаний, отсутствие согласия между ними могло повлечь серьезные задержки в реализации проекта.
При этом налаженная система коммуникаций между членами консорциума и внешним миром позволила внести коррективы в изначальный проект дамбы Гувера, сделав его более привлекательным с эстетической точки зрения.
В отношении управления поставками можно сказать, что данный вопрос был решен достаточно радикально. Специально для строительства дамбы Гувера были построены два завода по производству бетона, который доставлялся непосредственно до места строительства по рельсам. Для поднятия грузов использовалась специальная система подвесных кабелей.
Управление стоимостью в проекте строительства плотины осуществлялось также на высоком уровне. Консорциум компаний не мог превысить бюджет, на который они изначально согласились, поэтому существовали все стимулы к тому, чтобы максимально снизить издержки, не забывая при этом об управлении качеством.
В целом по проекту строительства дамбы Гувера можно сказать, что он во многом опередил свое время, и не только благодаря технологиям, которые были использованы впервые. Несмотря на отсутствие в то время современных стандартов в области управления проектами, при анализе можно заметить, что многие рекомендации, которые содержатся, например, в PMBOK, были соблюдены при выполнении проекта плотины Гувера. Стоит отметить, что проект был выполнен на крайне высоком уровне по всем параметрам. Что касается тех областей, где можно наблюдать некоторый провал (например, управление персоналом), то справедливости ради нельзя не сказать, что провалом это можно назвать только при сравнении проекта дамбы Гувера с современными проектами. Во время строительства данной плотины подобное отношение к рабочим и к определенным национальностям было общей практикой. Поэтому если принимать за точку отсчета стандарты того времени, то в данном случае проект дамбы Гувера не имеет провалов ни в одной из областей. Это был один из самых успешных проектов в истории США.
Глава 2. Тенденции развития управления проектами в России и за рубежом
Изучив материал данной главы, вы узнаете:
• в каких направлениях развивается теория и практика проектного менеджмента;
• какие профессиональные ассоциации существуют в области управления проектами в России и в мире;
• какие существуют виды профессиональной сертификации специалистов в области управления проектами и требования, предъявляемые данными сертификациями;
• какие модели оценки зрелости организаций в области управления проектами развиваются на международном уровне.
Проектный менеджмент в настоящее время заслужил признание как самостоятельная дисциплина управления. За пятьдесят с лишним лет, в течение которых развивается менеджмент проектов, не только значительно расширилась область его применения, но и сложилась целостная структура методов и инструментов, призванных помочь руководителям проектов.
Развитие дисциплины проектного менеджмента можно представить в виде спирали (рис. 2.1), объединяющей три взаимосвязанных процесса: разработку и накопление практического опыта (лучшие практики), обобщение и стандартизацию передового опыта, расширение областей применения и адаптацию стандартизированных подходов.
Первые разработки в области проектного менеджмента появились вследствие необходимости решения конкретных практических задач управления сложными, масштабными проектами и программами. И сегодня развитие методов и инструментов управления проектами опирается на практический опыт. Важную роль в развитии дисциплины управления проектами играют процессы накопления лучших практик, их обобщения и стандартизации. Однако для применения методов и инструментов управления проектами в различных отраслях и на конкретных проектах менеджерам приходится их дорабатывать и адаптировать, что, в свою очередь, ведет к разработке новых методик и инструментов.
Рис. 2.1. Цикл процессов развития дисциплины проектного менеджмента
В условиях развития конкуренции на рынках, повышения требований потребителей к качеству продукции и услуг и соответственно усиления потребности организаций в проведении постоянных изменений в продуктовой линейке, технологиях производства и маркетинге значение проектного менеджмента значительно возрастает. За последние годы значительно расширилась область использования методологии проектного менеджмента. Применение методов проектного менеджмента к разработке и внедрению информационных систем, реорганизации бизнеса, маркетинговым кампаниям, программам развития персонала и многим другим видам деятельности стало привычным для многих организаций. Новые области применения данных подходов включают как масштабные государственные проекты и программы, так и небольшие проекты в сфере малого и среднего бизнеса. Все больше предприятий с традиционной процессно-ориентированной системой производства и управления начинают внедрять системы управления проектами для повышения эффективности собственных процессов развития.
Однако количество неудачных проектов остается значительным. Немалая часть инициированных проектов завершается с превышением ограничений по срокам и бюджету, не достигает полностью заявленных целей или вообще не доводится до завершения. Эти факты говорят о том, что, с одной стороны, существует разрыв между развитием теории проектного менеджмента и практикой его применения, а с другой – новые области применения проектного менеджмента требуют дальнейшего развития и адаптации методов и инструментария.
Далее в данной главе будут рассмотрены тенденции развития управления проектами в мире и в России как в направлении стандартизации и развития науки управления проектами, так и в направлении расширения областей практического применения данных подходов. Отдельный раздел посвящен деятельности профессиональных ассоциаций в части управления проектами, которые играют важную роль в развитии проектного менеджмента.
2.1. Тенденции практического применения управления проектами, стандартизации и развития науки управления проектами
Изменения в практике управления проектами связаны как с расширением спектра объектов управления, к которым применяются методы проектного менеджмента, так и с применением усовершенствованных или новых методик и инструментов с учетом особенностей проектов и способов их реализации.
Расширение областей применения проектного менеджмента
Методы управления проектами применяются сегодня не только в традиционных областях, таких как крупные комплексные проекты, строительство и инжиниринг, проектно-ориентированное производство, высококонкурентные, высокотехнологичные отрасли, но и практически во всех отраслях промышленности для управления деятельностью по развитию предприятий, творческими проектами в масс-медиа, политическими и социальными проектами.
Применение методов управления проектами перестало быть прерогативой крупных компаний, предприятия среднего и малого бизнеса также начинают использовать данные подходы и обучать специалистов.
Растет интерес к проектному менеджменту и со стороны органов государственной власти. Проектно-ориентированные методы применяются как для управления отдельными проектами, так и на уровне целевых программ. Проекты и программы, реализуемые в государственном секторе, обладают рядом особенностей, что предполагает доработку и адаптацию традиционных методов управления проектами.
В ряде стран мира правительство и органы государственного управления увидели в методологии проектного менеджмента важный инструмент обеспечения эффективного государственного развития и заявили о формировании национального потенциала в области управления проектами.
Изменение роли менеджера проекта
Важной тенденцией, проявляющейся на практике, является трансформация роли менеджера проекта. Это связано с тем, что определение проекта как объекта управления становится более комплексным.
За последние годы значительно изменились подходы к постановке целей и формулированию критериев успеха проектов. Если еще в середине 1990-х годов цели большинства проектов формулировались в виде требований к создаваемому в рамках проекта продукту (активу, системе) и критерии успеха формулировались соответственно в терминах «в срок, в рамках бюджета, в соответствии со спецификацией», то сегодня большинство организаций стремится связывать цели проектов и критерии успеха с достижением стратегических целей бизнеса и учитывать интересы всех основных участников проекта. Как следствие, меняются не только масштаб и временные границы проектов, но и роль менеджера проекта, его ответственность и требования к компетенции менеджера и организации реализации проектов. Например, постановка целей проекта и критериев успеха показателями, связанными с достижением бизнес-целей компании, сдвигает временные рамки проекта в фазу эксплуатации актива и вовлекает в проект участников, связанных не только с созданием актива, но и с его эксплуатацией.
Интегрированное управление проектами, программами, портфелями проектов
Однако полностью решить задачу интеграции стратегического и проектного менеджмента в компании только за счет согласования целей на уровне отдельных проектов не удается. Для построения эффективной системы управления проектами необходимо обеспечить управление на уровне программ и портфелей проектов. Эта потребность вызвала активное развитие теории и инструментария управления программами и портфелями проектов.
Развитие методов и инструментов управления проектами в условиях высокой неопределенности
Другой важной тенденцией в области реализации проектов является повышение динамики бизнеса и уровня неопределенности как во внешней среде, так и внутри компаний. Это ведет к тому, что появляется значительное число так называемых «открытых» проектов. В отличие от традиционных проектов, при инициации «открытых» заказчик не способен и не стремится четко зафиксировать требования к конечному продукту и ограничения по срокам и бюджету. Основные участники «открытого» проекта готовы к тому, что при его реализации эти требования будут уточняться и станут вноситься соответствующие изменения в планы реализации проекта. Управление «открытыми» проектами требует от менеджера применения более широкого и гибкого инструментария и методов управления (например, подготовка и принятие решений в условиях неопределенности, управление изменениями, рисками, коммуникациями, финансово-экономическое моделирование).
Основные тенденции развития исследований в области проектного менеджмента, вызванные практическими потребностями бизнеса, включают следующие:
• специализацию методологии и инструментов проектного менеджмента;
• более тесную связь проектного менеджмента с процессами управления бизнесом в целом.
Значительно развивается отраслевая специализация методологии и инструментария проектного менеджмента. Ведущие мировые специалисты в области проектного менеджмента Рассел Арчибальд (Rassel Archibald), Линн Краффорд (Lynne Crawford) и др. опубликовали работы, закладывающие основу единой классификации проектов и подходов к проектному менеджменту [Crawford, 2004].
В рамках исследований Института управления проектами США (PMI) разработаны и опубликованы специализированные стандарты по управлению проектами в государственном секторе [PMBOK, 2004], в строительстве, в оборонной сфере, в автомобильной промышленности.
Интеграция проектного менеджмента в единую систему методов и инструментов управления бизнесом нашла отражение в развитии методологии и разработке стандартов управления на уровне программ развития и портфелей проектов, а также в разработке интегрированных моделей оценки зрелости компании в области проектного менеджмента.
Основные области исследований и развития теории проектного менеджмента можно отнести к трем направлениям [Shenhar, 2004]:
• Интеграция проектного менеджмента и стратегического управления.
• Развитие традиционных методов и инструментов управления на уровне отдельных проектов.
• Повышение эффективности работы команды и ключевых участников проекта.
В исследованиях, связанных с интеграцией проектного менеджмента и стратегического управления в компании, проекты рассматриваются как основной инструмент достижения стратегических целей компании, а ответственность и полномочия менеджера проекта связывают с достижением ее бизнес-целей. Данные исследования затрагивают вопросы согласования целей и критериев успеха, сформулированных на уровне стратегии, портфеля проектов и отдельных проектов. Исходя из этого определяются и требования к организационной структуре, роли участников (включая высшее руководство компаний) и процессам управления на всех уровнях целеполагания.
Активно развивается направление исследований и разработок, связанных с руководством проектной деятельностью на корпоративном уровне (project governance). Оно включает в себя создание адекватной организационной структуры, принятые в организации процедуры и правила управления проектами, программами и портфелями проектов, административно-организационную поддержку реализации проектов и принятие решений по проектам на уровне высшего руководства.
Исследования в области развития методов и инструментов управления в отдельных проектах направлены на увеличение эффективности управленческих процессов за счет повышения точности оценок параметров отдельных работ в планировании проекта в целом в условиях роста неопределенности и рисков проектов. Примером нового подхода к планированию и контролю исполнения проектов, который приобрел широкую популярность в последние годы, стал метод критических цепочек (Critical Chain Project Management), разработчики которого попытались переосмыслить и комплексно учесть при постановке целей и планировании различные факторы (от организационного поведения участников до перераспределения ответственности за риски).
В исследованиях, направленных на повышение эффективности работы команды и ключевых участников проекта, основное внимание уделяется вопросам мотивации и взаимодействия участников в рамках кросс-функциональных, распределенных команд. В рамках данных исследований также рассматриваются вопросы лидерства, повышения квалификации, мотивации и карьерного роста менеджеров проектов.
2.2. Профессиональные ассоциации в области управления проектами
Важную роль в развитии профессионального управления проектами играют международные и национальные профессиональные ассоциации. Деятельность профессиональных ассоциаций в области управления проектами направлена как на развитие методологии проектного менеджмента, так и на пропаганду и содействие практическому применению проектных методов управления в различных секторах экономики, государственной и социальной сферах. Для достижения данных целей ассоциации выполняют широкий спектр функций, включая:
• сбор, обобщение и распространение передового опыта в области управления проектами;
• научно-исследовательскую деятельность в области управления проектами;
• разработку стандартов, учебно-методической литературы;
• определение требований к компетенции специалистов в области управления проектами и сертификацию специалистов;
• определение требований к системе управления проектами в организациях, оценку и сертификацию систем управления;
• проведение конференций и семинаров и многое другое.
Наиболее известными в мире ассоциациями являются Международная ассоциация управления проектами (IPMA) и Институт управления проектами США (PMI). Большим авторитетом также пользуются национальные ассоциации управления проектами Японии (PMAJ), Великобритании (APM), Германии (GPM), Австралии (AIPM) и других стран.
International Project Management Association, IPMA
Международная ассоциация управления проектами (IPMA) образована в 1965 г. с целью обмена опытом в области профессионального управления проектами на международном уровне и зарегистрирована в Швейцарии. IPMA является некоммерческой организацией, и построена по принципу объединения национальных ассоциаций в области управления проектами из различных стран. Управляющим органом IPMA является Совет делегатов стран – участниц ассоциации. На конец 2011 г. членами организации стали национальные ассоциации из 55 стран мира, представляющие Европу, Азию, Америку, Австралию и Африку. Количество стран, входящих в IPMA, постоянно увеличивается.
Россию, которая уже более 20 лет является членом Международной ассоциации управления проектами, в IPMA представляет национальная Ассоциация управления проектами СОВНЕТ.
Основные виды деятельности IPMA включают:
• разработку требований к компетентности специалистов в области управления проектами ICB (IPMA Competence Baseline);
• разработку и поддержку по всему миру 4-уровневой системы сертификации специалистов в области управления проектами 4-L–C;
• разработку модели оценки проектов по качеству результатов и системы управления IPMA Project Excellence model и проведение ежегодной процедуры оценки и выбора лучших проектов в нескольких номинациях;
• разработку модели оценки зрелости компаний в области управления проектами IPMA-DELTA и системы сертификации организаций;
• научные исследования и публикации в области управления проектами;
• проведение ежегодных всемирных конгрессов по управлению проектами, серий семинаров и учебных курсов.
Ассоциация управления проектами СОВНЕТ
Ассоциация управления проектами СОВНЕТ основана в 1990 г. и представляет собой некоммерческое партнерство, объединяющее специалистов в области управления проектами с целью развития и продвижения профессионального управления проектами в России.
Целями Ассоциации СОВНЕТ являются:
• широкое внедрение методов и средств управления проектами в различных отраслях экономики, видах бизнеса, социальной инфраструктуры и областях государственной и общественной жизни на территории Российской Федерации;
• развитие профессионализма и повышение качества управления проектами в России и в мире;
• оказание организационной, методической и информационной поддержки членов ассоциации в развитии и применении профессионального управления проектами;
• развитие и совершенствование теоретических основ и практических методов в области управления проектами;
• расширение числа профессиональных специалистов по управлению проектами, занятых в различных отраслях экономики, социальной инфраструктуре и областях общественной жизни на территории Российской Федерации;
• разработка, совершенствование, пропаганда и внедрение современных методов и инструментальных средств управления проектами;
• организация и методическое обеспечение различных форм профессионального обучения и обмена опытом, повышения квалификации, подготовки и переподготовки специалистов в области управления проектами;
• осуществление добровольной профессиональной сертификации организаций и специалистов по управлению проектами в соответствии с установленными национальными и международными требованиями;
• осуществление добровольной аккредитации учебных центров и других учебных заведений, осуществляющих подготовку и обучение специалистов в области управления проектами в соответствии с установленными национальными и международными требованиями к добровольной профессиональной сертификации компетентности специалистов;
• организация и проведение мероприятий, способствующих укреплению творческих контактов и профессиональных взаимосвязей ученых и практиков в области управления проектами на территории России и за рубежом;
• оказание практической помощи организациям в вопросах применения методологии управления проектами, а также их партнерам, в том числе из зарубежных стран, в осуществлении совместных проектов на основе профессионального управления проектами;
• содействие взаимовыгодному международному сотрудничеству с Международной ассоциацией управления проектами IРМА, а также с другими зарубежными организациями и компаниями, заинтересованными в развитии управления проектами.
Ассоциацией СОВНЕТ разработаны национальные требования к компетентности специалистов в области управления проектами (NCB) [НТК, 2010], которые прошли валидацию IPMA на предмет соответствия ICB. На базе национальных требований к компетентности осуществляется сертификация специалистов по международным стандартам.
Project Management Institute, PMI
Институт управления проектами (PMI) был основан в 1969 г. в США как некоммерческая организация, объединяющая специалистов в области управления проектами. Членство в PMI является индивидуальным, ассоциация насчитывает более 300 тыс. человек из 170 стран мира. В различных государствах и городах члены PMI объединяются в отделения для обмена опытом и распространения знаний в области управления проектами. В России отделения PMI функционируют в Москве, Санкт-Петербурге, Екатеринбурге и других городах.
Члены PMI объединяются в группы по интересам (Special Interest Groups, SIGs), деятельность которых концентрируется в отдельных областях проектного менеджмента (например, управление рисками).
Основные виды деятельности PMI:
• разработка и популяризация стандартов проектного менеджмента (широкая линейка стандартов, основным из которых является PMBOK);
• сертификация специалистов по управлению проектами;
• оценка качества и регистрация программ обучения в области управления проектами (Registered Education Provider, REP PMI);
• проведение ежегодных конгрессов в США, Европе, Азии;
• научные исследования и публикации в области управления проектами;
• оценка и награждение лучших проектов.
Линейка стандартов PMI по управлению проектами включает не только один из наиболее популярных в мире стандартов The Guide to the PMBOK (Project Management Body of Knowledge), но и стандарты по управлению программами, портфелями проектов, методологические стандарты и отраслевые адаптации стандарта по управлению проектами.
ISO/TC 258 Project, Programme and Portfolio Management
Заметную роль в области стандартизации в управлении проектами начинает играть технический комитет, созданный Международной организацией по стандартизации – ISO.
Технический комитет ISO/TC 258 Project, Programme and Portfolio Management занимается разработкой серии специализированных международных стандартов в области управления проектами, программами и портфелями проектов. Объединяет представителей национальных организаций по стандартизации из различных стран мира, в том числе из России. В комитет входят также представители IPMA и PMI.
Одним из первых в новой серии международных стандартов по управлению проектами ISO должен стать стандарт ISO 21500 Guidance on Project Management, выход которого был запланирован на 2012 г.
В России при Федеральном агентстве по техническому регулированию и метрологии (РОССТАНДАРТ) создан подкомитет по разработке стандартов в области управления проектами. Подкомитет «Менеджмент проектов» входит в состав технического комитета «Стратегический и инновационный менеджмент» и курирует разработку стандартов в области управления проектами на национальном уровне. Первые стандарты в данной области включают следующие:
• ГОСТ Р 54869-2011: Проектный менеджмент. Требования к управлению проектом.
• ГОСТ Р 54871-2011: Проектный менеджмент. Требования к управлению программой.
• ГОСТ Р 54870-2011: Проектный менеджмент. Требования к управлению портфелем проектов.
2.3. Международная сертификация специалистов по управлению проектами
Международная сертификация специалистов по управлению проектами – процесс определения соответствия:
• профессиональных знаний, опыта и навыков кандидата установленным требованиям к специалисту по управлению проектами;
• деятельности кандидата этическому кодексу менеджера проекта.
Сертификат является подтверждением опыта и профессионализма специалиста в области управления проектами независимым, авторитетным органом.
Преимущества сертифицированных специалистов по управлению проектами:
• международное признание квалификации и компетентности;
• персональное преимущество для роста карьеры;
• повышение профессионального рейтинга и цены предоставляемых ими услуг.
Преимущества компаний, имеющих сертифицированных специалистов по управлению проектами:
• обеспечение потребности организации в квалифицированных специалистах в области управления проектами;
• повышение эффективности работы организаций, использующих услуги сертифицированных управляющих проектом;
• повышение рейтинга и конкурентоспособности компании за счет наличия профессионалов в управлении проектами.
Среди международных программ сертификации по управлению проектами можно выделить две наиболее значимые:
сертификацию по стандартам Международной ассоциации по управлению проектами (IPMA);
сертификацию по стандартам американского Института управления проектами (PMI).
Сертификация по стандартам Международной ассоциации по управлению проектами (IPMA)
Четырехуровневая сертификация специалистов в области управления проектами IPMA разработана исходя из следующих принципов:
• Сертификационная программа IPMA включает четыре уровня сертификации, в каждом из которых предъявляются свои требования к опыту и компетентности кандидата.
• Основой системы сертификации являются международные требования к компетентности специалистов по управлению проектами ICB и международные требования к процедуре сертификации.
• На основании ICB каждая национальная ассоциация разрабатывает и утверждает Национальные требования к компетентности (National Competence Baseline, NCB), которые должны быть ратифицированы IPMA для проведения сертификации, а также соответствующую международным требованиям процедуру сертификации.
• Сертификация осуществляется на национальном уровне уполномоченным сертификационным органом национальной ассоциации.
• Данные по сертифицированным специалистам предоставляются и хранятся в IPMA. Сертификат признается на международном уровне во всех странах, входящих в IPMA.
Система сертификации IPMA основана на международных требованиях к компетентности специалистов по управлению проектами (International Competence Baseline, IBC). Система сертификации предназначена для определения соответствия профессиональных знаний, опыта и навыков кандидатов установленным требованиям, предъявляемым к специалистам в области управления проектами. Сертификационная программа IPMA включает четыре уровня, к каждому из которых разработаны свои требования соответствия. В зависимости от уровня сертификации специалисту может быть присвоено одно из следующих званий:
• Директор проекта (Project Director, IPMA Level А): способен управлять портфелем проектов или программой, а не только отдельным единичным проектом, с использованием соответствующих методологии и инструментов.
• Старший менеджер проекта (Senior Project Manager, IPMA Level B): способен управлять сложным проектом, координировать несколько подпроектов в рамках одного проекта.
• Менеджер проекта (Project Manager, IPMA Level C): способен управлять проектом ограниченной сложности. Это указывает на то, что в дополнение к своим умениям применять знания в управлении проектом он также продемонстрировал соответствующий уровень опытности.
• Специалист по управлению проектами (Project Manager Associate, IPMA Level D): способен применять знания в области управления проектом и может быть привлечен к участию в проекте в качестве одного из членов команды управления, но его общих знаний недостаточно для выполнения более сложных задач.
Далее приведены основные требования к знаниям, компетенции и опыту специалистов, подлежащих подтверждению в ходе сертификации.
Директор проекта (Project Director, IPMA Level А) должен:
• быть способен управлять всеми проектами компании, или проектами ее отделения, или всеми проектами программы;
• иметь минимум 5-летний опыт управления комплексными проектами и программами, из которых кандидат не менее 3 лет был ответственен за руководство, координацию и управление портфелем проектов;
• уметь осуществлять руководство координацией и контролем всех проектов компании или ее отделения;
• иметь портфель конкретных стратегических предложений по общему управлению в компании;
• принимать участие в подготовке персонала, задействованного в управлении проектами и управляющих проектами;
• нести ответственность за реализацию управления проектами, разработку руководящих и нормативных материалов, а также применение основных методов и средств.
Старший менеджер проекта (Senior Project Manager, IPMA Level B) должен:
• быть способным самостоятельно управлять сложными проектами;
• иметь минимум 5-летний опыт управления проектами, из которых не менее 3 лет в качестве ответственного за руководство и управление сложными проектами;
• уметь осуществлять руководство координацией и контролем всех проектов компании или ее отделения;
• иметь портфель конкретных стратегических предложений по общему управлению в компании;
• принимать участие в подготовке персонала, задействованного в управлении проектами и управляющих проектами;
• нести ответственность за реализацию управления проектами, разработку руководящих и нормативных материалов, а также применение основных методов и средств.
Менеджер проекта (Project Manager, IPMA Level C) должен:
• быть способным самостоятельно управлять несложными проектами и помогать управляющему сложными проектами во всех функциональных областях управления проектами;
• иметь минимум 3-летний опыт управления проектами в качестве руководителя в функциональных областях несложного проекта;
• нести ответственность за осуществление несложного проекта;
• руководить небольшими группами персонала по управлению проектом;
• применять методы, средства и инструментарий по управлению проектами;
• быть способным работать в качестве руководителя группы специалистов, входящей в команду сложного проекта, и нести ответственность за соответствующие параметры проекта.
Специалист по управлению проектами (Project Manager Associate, IPMA Level D) должен:
• обладать знаниями во всех областях управления проектами (и быть способным применять их в некоторых областях как специалист);
• обладать широким спектром знаний в управлении проектами и быть способным применять эти знания на практике;
• быть способным выступать в качестве члена команды проекта в любой функциональной области по управлению проектами.
Требования, предъявляемые к специалистам по управлению проектами разных уровней сертификации, приведены в табл. 2.1.
Таблица 2.1
Требования, предъявляемые к специалистам по управлению проектами разных уровней сертификации IPMA
Общая схема этапов сертификационного процесса для разных уровней сертификации представлена в табл. 2.2.
Таблица 2.2
Общая схема этапов сертификационного процесса для разных уровней сертификации IPMA
Сертификация осуществляется уполномоченными сертификационными органами в странах – членах IPMA. Сертификация может осуществляться как на базе ICB, так и на базе национальных требований к компетенции специалистов, разработанных в соответствии с требованиями IPMA. IPMA ведет общий реестр сертифицированных специалистов и гарантирует, что сертификаты, выданные в одной стране, действительны в любой другой стране.
Сертификация по стандартам американского Института управления проектами (PMI).
Система сертификации PMI основана на стандарте PMBOK.
Уровни сертификации включают следующие позиции:
• Профессиональный менеджер проекта.
• Сертифицированный специалист по управлению проектами (Certified Associate in Project Management, CAPM).
Профессиональный менеджер проекта (Project Management Professional, PMP)
Сертификация PMP требует наличия теоретических знаний в сфере управления проектами и подтверждения практического опыта в применении этих теоретических знаний.
На момент подачи заявки кандидат должен соответствовать следующим критериям: иметь высшее образование со степенью не ниже бакалавра и не менее 4500 ч работы в области управления проектами по пяти группам процессов. Количество часов в заполняемых формах подтверждения опыта должно в сумме составлять 4500 ч, а даты проектов должны показывать, что кандидат имеет не менее трех лет (36 непересекающихся месяцев) опыта управления проектами в течение шести лет до подачи заявки.
Если на момент подачи заявки у кандидата нет высшего образования, но есть диплом о полном среднем образовании, то он должен подтвердить не менее 7500 ч работы в области управления проектами в восьмилетний период до подачи заявки.
Для каждого проекта, в котором участвовал кандидат, заполняется отдельная форма подтверждения опыта. Помимо данных о проекте соискатель должен указать примерное количество часов, потраченных им на проекте в одной или более группах процессов (в сумме по всем проектам кандидат должен иметь опыт во всех группах процессов). Данное описание должно содержать перечень конкретных управленческих процедур, которые выполнял претендент в качестве менеджера проектов, структурированных в рамках пяти основных процессов (инициация, планирование, исполнение, контроль, завершение).
Кандидат также должен иметь не менее 35 ч обучения в области управления проектами, он может указывать любое обучение в области управления проектами независимо от даты обучения. Кроме того, кандидат должен подписать и соблюдать кодекс профессиональной этики менеджера проекта.
Завершающий этап получения статуса PMP – экзамен-тест, разработанный для объективной оценки знания кандидата в области проектного менеджмента. Экзамен на степень PMP проходит в международных центрах Prometric, которые расположены по всему миру. В России на данный момент существует два таких центра – в Москве и Санкт-Петербурге. На весь экзамен отводится 4 астрономических часа, в течение которых необходимо ответить на 200 вопросов. Кандидат должен выбрать правильный ответ из четырех предложенных вариантов. Большинство вопросов предполагает детальное знание стандартов PMI (PMBOK). Однако есть вопросы, предполагающие наличие у кандидата практического опыта. Начиная с 2006 г. экзамен можно сдавать на русском языке. Чтобы получить статус РМР, необходимо правильно ответить примерно на две трети вопросов.
Сертифицированный специалист по управлению проектами (Certified Associate in Project Management, CAPM)
Этот сертификат предназначен для специалистов, которые имеют знания в области управления проектами, но не имеют еще достаточного практического опыта. САРМ – это практик в управлении проектами, продемонстрировавший основные знания, а также умение применять в проектах инструменты и методики проектного управления. Как член команды проекта САРМ обычно обращается за руководством, наставлениями и одобрением к более опытным практикам управления проектами.
САРМ обычно выполняет такие задачи, как:
• помощь в оценке планов управления проектом;
• предложение индикаторов производительности и резервов;
• помощь в уточнении требований к проекту, допущений и ограничений;
• поддержка при административном и финансовом завершении.
Чтобы получить степень САРМ, кандидат должен соответствовать требованиям к образованию и опыту, предъявляемым PMI, и продемонстрировать соответствующий уровень понимания и знания управления проектами, подтвержденный экзаменом на степень сертифицированного специалиста в управлении проектами. Экзамен по форме аналогичен экзамену на степень PMP, но состоит из 150 вопросов и длится 3 ч.
На момент подачи заявки соискатель должен отвечать следующим требованиям: иметь высшее образование со степенью не ниже бакалавра и не менее 1500 ч работы в области управления проектами по пяти группам процессов. Если на момент подачи заявки кандидат не имеет высшего образования, но имеет диплом о полном среднем образовании, он должен подтвердить не менее 2500 ч работы в области управления проектами за трехлетний период до подачи заявки. Также кандидат должен иметь не менее 23 ч обучения в области управления проектами.
В настоящее время PMI ввел сертификацию специалистов по управлению программами.
2.4. Оценка зрелости организаций в области управления проектами
IPMA-DELTA
Международная ассоциация управления проектами (IPMA) разработала модель оценки зрелости организаций в области управления проектами DELTA. В основу данной модели положена концепция организационной компетентности в области управления проектами, которая предполагает анализ не только индивидуальной компетентности сотрудников и руководителей компании в области управления проектами, но и анализ созданной в компании системы управления проектами, включая нематериальные активы и ценности. Модель DELTA состоит из трех модулей: I – «Индивидуумы», P – «Проекты», O – «Организация». Оценка организации на уровень зрелости в области управления проектами выполняется на основании оценок каждого из трех модулей и взаимосвязей между ними.
В основе модуля I лежит стандарт ICB 3.0, определяющий требования к компетентности персонала. Наличие в компании сертифицированных менеджеров проектов является важной составляющей уровня зрелости организации. Требования DELTA предполагают, что сотрудники компании (руководители и члены команд проектов) могут провести самооценку на основе разработанного вопросника.
Модуль P позволяет оценить качество управления проектами компании и степень достижения результатов. Оценка по данному модулю базируется на модели оценки проектов IPMA Project Excellence.
Модуль О предназначен для оценки общей компетентности организации в области управления проектами, включая связь со стратегией, руководство проектами на уровне высшего звена менеджмента, культуру управления проектами, процессы планирования, принятия решений, анализа и отчетности, систему накопления знаний, систему подбора и развития персонала в области управления проектами, связанные с реализацией проектов системы управления. Данная оценка выполняется независимыми асессорами IPMA.
Система оценки и сертификации IPMA-DELTA вызвала глубокий интерес у российских компаний и государственных органов. Часть компаний уже прошла сертификацию. Ожидается, что данная сертификация придаст новый импульс развитию и применению на практике методов проектного менеджмента, поскольку позволяет компаниям провести целостный и объективный анализ состояния собственной зрелости в области управления проектами, соотнести собственный уровень с общемировой практикой, выработать стратегию развития собственной системы управления проектами.
ОРМЗ
Американский Институт управления проектами (PMI) также предлагает собственную модель оценки зрелости организации в области управления проектами OPM3 (Organizational Project Management Maturity Model). OPM3 включает базу знаний по «лучшим практикам» в области управления проектами и вопросник для оценки состояния организации с точки зрения применения данных практик. В основе базы знаний лежат стандарты PMI по управлению проектами, программами и портфелями проектов. На основании данной модели организация может провести самооценку и разработать план развития собственной системы управления проектами.
Резюме
Развитие дисциплины проектного менеджмента можно представить в виде спирали, объединяющей три взаимосвязанных процесса: разработка и накопление практического опыта (лучшие практики), обобщение и стандартизация передового опыта, расширение областей применения и адаптация стандартизированных подходов.
Происходит существенное расширение областей применения проектного менеджмента как в коммерческих компаниях, так и в государственных организациях. Проектно-ориентированные методы управления применяются как для управления на уровне отдельных государственных проектов, так и на уровне целевых программ.
Организации переходят к интегрированным системам управления проектами, программами, портфелями проектов.
Важную роль в развитии профессионального управления проектами играют международные и национальные профессиональные ассоциации, среди которых на международном уровне выделяются:
• Международная ассоциация управления проектами IPMA (International Project Management Association).
• Институт управления проектами США PMI (Project Management Institute).
Россия уже более 20 лет является членом Международной ассоциации управления проектами. Россию в IPMA представляет Ассоциация управления проектами СОВНЕТ.
Все большую значимость и популярность приобретают международные сертификации специалистов в области управления проектами, среди которых можно выделить две наиболее значимые:
• сертификацию по стандартам IPMA;
• сертификацию по стандартам PMI.
В последние годы также развиваются модели оценки зрелости организаций в области управления проектами, включая систему оценки и сертификации IPMA-DELTA и модель OPM3.
Ключевые термины
Руководство проектной деятельностью (project governanace) – включает создание адекватной организационной структуры, принятые в организации процедуры и правила управления проектами, программами и портфелями проектов, административно-организационную поддержку реализации проектов и принятие решений по проектам на уровне высшего руководства.
Международная сертификация специалистов по управлению проектами – процесс определения соответствия: профессиональных знаний, опыта и навыков кандидата установленным требованиям к специалисту по управлению проектами; деятельности кандидата этическому кодексу менеджера проекта.
Контрольные вопросы
1. Каковы основные тенденции развития дисциплины проектного менеджмента?
2. Каким образом расширяется сфера применения проектного менеджмента?
3. В чем заключается изменение роли менеджера проекта?
4. Какие профессиональные ассоциации в области управления проектами Вы знаете?
5. Каковы основные цели и задачи профессиональных ассоциаций в области управления проектами?
6. Какие существуют основные типы сертификаций в области управления проектами? В чем их различия?
7. Назовите основные модели оценки зрелости организаций в области управления проектами. Какие параметры оцениваются данными моделями?
Литература
1. Дополнительную информацию по деятельности IPMA можно получить на сайте IPMA:
2. Дополнительную информацию по деятельности Ассоциации управления проектами СОВНЕТ можно получить на сайте:
3. Дополнительную информацию по деятельности PMI можно получить на сайте:
4. Полковников А. В. Проектный менеджмент: базовые подходы и международные стандарты // Вестник технического регулирования. 2006. № 9. С. 4–14.
5. Управление проектами: Основы профессиональных знаний, Национальные требования к компетентности специалистов (NCB – SOVNET National Competence Baseline Version 3.0). М.: ЗАО «Проектная ПРАКТИКА», 2010.
6. Crawford L., Hobbs J. B., Turner J. R. Project Categorization Systems and Their Use in Organizations: An Empirical Study, Innovations, Project Management Research, 2004. Newtown Square, Pennsylvania, USA: Project Management Institute. 2004. Р. 65–82.
7. Construction Extension to the PMBOK Guide. 3rd ed. Newtown Square, Pennsylvania, USA: Project Management Institute, 2007.
8. Government Extension to the PMBOK Guide. Newtown Square, Pennsylvania, USA: Project Management Institute, 2003.
9. Shenhar Aaron J., Dov Dvir. Project Management Evolution: Past History and Future Research Directions, Innovations, Project Management Research 2004, PMI.
Глава 3. Базовые понятия и определения управления проектами
Изучив материал данной главы, вы узнаете:
• что понимается под проектом в методологии управления проектами;
• что такое объекты и субъекты управления проектами;
• какие группы процессов и функциональные области рассматриваются при управлении проектами.
3.1. Определение проекта
В различных источниках (учебниках, статьях, стандартах) можно найти множество различных определений проекта, которые, впрочем, не противоречат, а, скорее, дополняют друг друга. Однако наиболее известным является следующее определение [PMBOK, 2004]:
«Проект – это временное предприятие, предназначенное для создания уникальных продуктов или услуг».
«Временное» означает, что у любого проекта есть начало и непременно наступает завершение, когда достигаются поставленные цели, либо возникает понимание, что эти цели не могут быть достигнуты. «Уникальных» означает, что создаваемые продукты или услуги существенно отличаются от других аналогичных продуктов и услуг. В частности, нет одинаковых месторождений полезных ископаемых и разработка любого месторождения уникальна. Уникальность продуктов или услуг проекта обуславливает необходимость последовательного уточнения их характеристик по мере выполнения проекта.
Более полное определение проекта звучит так: «Проект – целенаправленное, заранее проработанное и запланированное создание или модернизация физических объектов, технологических процессов, технической и организационной документации для них, материальных, финансовых, трудовых и иных ресурсов, а также управленческих решений и мероприятий по их выполнению».
Управление проектами – методология (говорят также – искусство) организации, планирования, руководства, координации трудовых, финансовых и материально-технических ресурсов при помощи современных методов, техники и технологии управления для достижения определенных результатов по составу и объему работ, стоимости, времени и качеству.
Под объектами управления проектами понимаются проекты, программы и портфели проектов.
Субъектами управления проектами являются менеджеры проекта со стороны заказчика и исполнителя, а также команда управления проектом/ команда проекта.
Важно понимать, что при оценке успешности управления проектом используется концепция «треугольника управления проектом», т. е. тройственного ограничения «качество (содержание работ проекта) – сроки – затраты». Соответственно проект считается успешным в том случае, если были выдержаны требования по времени, стоимости и качеству.
При управлении проектом создается временная организационная структура, называемая организационной структурой проекта. Необходимо также учитывать тип организационной структуры компании, в рамках которой реализуется проект: функциональная, проектная или матричная. Матричная организационная структура, в свою очередь, подразделяется на слабую, сбалансированную и жесткую матрицы. Каждая организационная структура предполагает свои особенные подходы к формированию команды проекта.
3.2. Процессы управления проектом
Общепринятым на современном этапе подходом к управлению проектами является процессный подход.
Процесс – это ряд взаимосвязанных действий и операций, выполняемых для достижения заранее определенных продуктов, результатов или услуг. Процессы управления проектом выполняются командой проекта и обычно бывают двух типов.
1. Процессы управления проектом, общие для большинства проектов, как правило, нацелены на выполнение общей задачи. Такой задачей может быть инициация, планирование, исполнение, мониторинг и управление, а затем и закрытие проекта. Эти процессы взаимодействуют между собой сложным образом, это нельзя полностью объяснить в документе или с помощью рисунков. Взаимодействие процессов может также затрагивать содержание, стоимость, расписание проекта и т. д. Данные элементы называются областями знаний.
2. Процессы, ориентированные на продукт, определяют и создают продукт проекта. Они обычно определяются через жизненный цикл проекта и меняются в зависимости от области приложения. Процессы управления проектами и процессы, ориентированные на продукт, накладываются друг на друга и взаимодействуют в ходе выполнения проекта. Например, содержание проекта не может быть определено без понимания основ того, как производить указанный продукт.
Управление проектом – это интегративное действие. Интеграция управления требует, чтобы все процессы проектов и продуктов были должным образом выстроены и связаны с другими процессами для облегчения их координации. Эти взаимодействия между процессами часто требуют согласования требований и целей проекта. В рамках большого и сложного проекта могут происходить процессы, которые надо будет повторить несколько раз, чтобы определить и выполнить требования участников проекта и достичь согласия относительно результатов. Непринятие мер в течение одного процесса обычно влияет на этот процесс и другие связанные процессы. Например, изменение содержания почти всегда влияет на стоимость проекта, но может как повлиять, так и не повлиять на дух команды или качество продукта. Какие именно компромиссы будут приняты – зависит от конкретного проекта и от особенностей организации. Успешное управление проектом включает активное управление этими взаимодействиями, чтобы выполнять все требования спонсоров, заказчиков или других участников проекта.
Необходимые группы процессов являются указаниями по применению правильных знаний и навыков в управлении проектами в течение проекта. Кроме того, процессы управления проектом для определенного процесса применяются итеративно, причем многие процессы повторяются и пересматриваются в ходе проекта. Менеджер и команда проекта несут ответственность за определение того, какие процессы должны быть задействованы, кто и с какой степенью точности будет исполнять эти процессы, чтобы достичь нужных целей проекта.
Согласно Руководству к своду знаний по управлению проектами [PMBOK, 2004], выделяют пять групп процессов управления проектом, необходимых для любого проекта: они обладают четкими зависимостями и выполняются в одной и той же последовательности в каждом проекте. Они не зависят от областей приложения или отрасли. Отдельные группы процессов, а также входящие в них процессы неоднократно повторяются при выполнении проекта.
Перечислим эти группы процессов:
1. Процессы инициирования проекта – принятие решения об авторизации проекта.
2. Процессы планирования – определение и фиксация целей, планирование действий, необходимых для достижения целей и содержания, ради которых был предпринят проект.
3. Процессы исполнения – объединение трудовых и других ресурсов для выполнения плана.
4. Процессы мониторинга и контроля – регулярная оценка развития проекта, осуществление мониторинга для обнаружения отклонения от плана, при необходимости проведение корректирующих воздействий для достижения целей проекта.
5. Процессы завершения – формализация приемки продукта, услуги или результата, подведение проекта к правильному завершению.
Диаграмма взаимодействия процессов (рис. 3.1) дает общее представление об основных зависимостях и взаимодействиях между группами процессов. Отдельные процессы могут определять и ограничивать использование входов для получения выходов данной группы процессов. Группа процессов включает составные процессы управления проектами, которые связаны соответствующими входами и выходами, т. е. результат одного процесса становится входом другого. Например, группа процессов мониторинга и управления не только наблюдает и управляет работами, производимыми во время группы процессов, но также наблюдает и управляет всеми действиями по проекту. Группа процессов мониторинга и управления должна также обеспечивать обратную связь для применения корректирующих или предупреждающих действий, чтобы проект не выходил за рамки плана управления проектом или чтобы план управления проектом должным образом изменялся. Также вероятны многие другие взаимодействия между группами процессов. Группы процессов – это не то же самое, что фазы проекта. Если большие или сложные проекты могут быть разбиты на отдельные фазы или подпроекты, такие, например, как анализ осуществимости, разработка идеи, проектирование, создание прототипа, производство, испытание и т. д., то все группы процессов будут применяться к каждой фазе или подпроекту.
Группа процессов инициации
Группа процессов инициации состоит из процессов, способствующих формальной авторизации начала нового проекта или фазы проекта. Процессы инициации часто выполняются вне рамок проекта и связаны с организационными, программными или портфельными процессами, которые и обеспечивают входы для группы процессов инициации. Тем самым границы проекта могут размываться. Например, перед началом операций в рамках группы процессов инициации документируются практические нужды или требования организации. Осуществимость нового предприятия может быть установлена путем оценки альтернатив и выбора наилучшей из них. Разрабатываются четкие описания целей проекта, куда включается и указание причин, почему данный проект является лучшим вариантом, удовлетворяющим требованиям. В документацию по данному решению также входит базовое описание содержания проекта, результатов поставки, длительности проекта, а также прогноз требуемых ресурсов для анализа инвестиций организации. Рамки проекта могут быть уточнены путем документирования процессов выбора проекта. Ответственность руководства в рамках организации определяется местом проекта в стратегическом плане организации. В многофазных проектах последующие фазы также включают в себя процессы инициации; это делается для оценки допущений и решений, принятых во время начальных процессов разработки устава проекта и предварительного описания содержания проекта.
Рис. 3.1. Общий обзор взаимодействий между группами процессов (по [РМВОК, 2004])
В ходе процесса инициации уточняются первоначальное описание содержания и ресурсы, которые организация планирует вложить. На этом этапе также выбирается менеджер проекта, если он еще не назначен, и документируются исходные допущения и ограничения. Эта информация заносится в устав проекта, и если он одобряется, проект официально авторизуется. Хотя команда управления проектом может участвовать в написании устава, одобрение и финансирование происходят вне границ проекта.
Подключение заказчиков и других участников проекта во время инициации обычно способствует сотрудничеству, успешной приемке результатов поставки и в конечном итоге – удовлетворению требований заказчиков и других участников проекта.
В группу процессов инициации входят следующие процессы управления проектами.
1. Разработка устава проекта. Этот процесс связан прежде всего с авторизацией проекта или его фазы (в многофазном проекте). Это процесс, необходимый для формулирования практических нужд и документального оформления нового продукта, услуги или иного результата, который должен удовлетворять этим требованиям. С помощью устава проект привязывается к текущей работе организации, а также осуществляется авторизация проекта. Составление устава и авторизация проводятся вне рамок проекта подразделением, управляющим организацией, программой или портфелем. В многофазных проектах в ходе этого процесса оцениваются или исправляются решения, принятые в предыдущем процессе разработки устава проекта на предыдущей фазе.
2. Разработка предварительного описания содержания проекта. Это процесс, необходимый для предварительного общего описания проекта с использованием устава проекта и других входов процессов инициации. Данный процесс направляет и документирует требования к проекту и результатам поставки, требования к продукту, границы проекта, методы приемки и общее управление содержанием. В многофазных проектах этот процесс оценивает или уточняет содержание проекта для каждой фазы.
Группа процессов планирования
Команда управления проектом использует группу процессов планирования и составляющие ее процессы и взаимодействия для планирования и управления успешным проектом в интересах организации. Цель группы процессов планирования – собрать информацию из нескольких источников, различных по уровню полноты и доверия. В процессе планирования разрабатывается план управления проектом. Эти процессы также обнаруживают, определяют и дорабатывают содержание и стоимость проекта и составляют расписание для операций, предпринятых в рамках проекта. По мере того как появляется новая информация по проекту, будут выявляться или исчезать дополнительные зависимости, требования, риски, возможности, допущения и ограничения. Из-за присущей управлению проектами многомерности в ходе проекта неоднократно возникает необходимость в дополнительном анализе, а значит, и в возврате к уже утвержденным процессам. В ходе выявления и осознания новых характеристик и информации, касающихся проекта, может возникнуть необходимость в доработках. Значительные изменения, происходящие во время жизненного цикла проекта, приводят к необходимости пересмотра одного или нескольких процессов планирования и, возможно, некоторых процессов инициации. Это затрагивает также и частоту итераций процессов планирования. Например, план управления проектом, разработанный в качестве выхода группы процессов планирования, будет фокусироваться на изучении всех аспектов содержания, технологий, рисков и затрат. Обновления, возникшие в связи с одобренными изменениями в течение исполнения проекта, в значительной степени влияют на отдельные части плана управления проектом, обновления которого обеспечивают большую точность в отношении требований к расписанию, затратам и ресурсам для достижения заданного содержания проекта в целом. Обновления могут ограничиваться операциями и проблемами, связанными с выполнением отдельной фазы. Такую постепенную детализацию плана управления проектом часто называют «планированием методом набегающей волны», подчеркивая этим, что планирование в этом случае представляет собой итеративный и непрерывный процесс. При планировании команда проекта должна вовлекать в этот процесс всех участников (в зависимости от их влияния на проект и его результаты), так как у них имеются навыки и знания, которые могут способствовать разработке плана управления проектом и вспомогательных планов.
Так как процесс обратной связи и уточнения не может продолжаться бесконечно, установленные организацией процедуры определяют, когда планирование заканчивается. На эти процедуры может влиять сущность проекта, установленные границы проекта, соответствующие операции по мониторингу и управлению, а также условия, в которых будет исполняться проект. Взаимодействие между процессами в рамках группы процессов планирования зависит от характера проекта. Например, в некоторых проектах не будет никакого или почти никакого риска до тех пор, пока основная часть планирования не завершится. В этот момент команда проекта может осознать, что стоимость и расписание проекта составлены очень агрессивно, а риск на самом деле значительно выше, чем считалось ранее. Результаты итераций документируются как уточнения к плану управления проектом.
В нижеприведенном списке указываются процессы, к которым команда проекта должна обратиться, чтобы решить нужно ли их выполнять, и если да, то кто это должен сделать. В группу процессов планирования входят следующие процессы управления проектами.
1. Разработка плана управления проектом. Процесс, необходимый для определения, подготовки, координации и интеграции всех вспомогательных планов в план управления проектом. План управления проектом становится первичным источником информации по планированию, исполнению, мониторингу и управлению, а также закрытию проекта.
2. Планирование содержания. Процесс, необходимый для создания плана управления содержанием проекта и определения иерархической структуры работ.
3. Определение содержания. Процесс, необходимый для разработки подробного описания содержания проекта, на основании которого впоследствии будут приниматься решения по проекту.
4. Создание иерархической структуры работ (ИСР). Процесс, необходимый для разделения основных результатов поставки проекта и работ проекта на более мелкие элементы, которыми легче управлять.
5. Определение состава операций. Процесс, необходимый для идентификации конкретных операций, которые следует выполнить для получения различных результатов поставки проекта.
6. Определение взаимосвязей операций. Процесс, необходимый для определения и документирования взаимосвязей между операциями.
7. Оценка ресурсов операций. Процесс, необходимый для оценки типа и количества ресурсов, необходимых для выполнения каждой плановой операции.
8. Оценка длительности операций. Процесс, необходимый для оценки количества рабочих периодов, которые потребуются для завершения отдельных плановых операций.
9. Разработка расписания. Процесс, необходимый для анализа последовательности, длительности операций, требований к ресурсам и ограничений на сроки с целью создания расписания проекта.
10. Стоимостная оценка. Процесс, необходимый для разработки приблизительных значений стоимости ресурсов, необходимых для выполнения операций проекта.
11. Разработка бюджета расходов. Процесс, необходимый для суммирования оценок стоимости отдельных операций или пакетов работ для оценки базового плана по стоимости.
12. Планирование качества. Процесс, необходимый для определения стандартов качества, которые соответствуют проекту, и средств достижения этих стандартов.
13. Планирование человеческих ресурсов. Процесс, необходимый для определения и документирования ролей в проекте, ответственности и отчетности, а также создания плана управления обеспечением проекта персоналом.
14. Планирование коммуникаций. Процесс, необходимый для определения потребностей участников проекта в информации и коммуникациях.
15. Планирование управления рисками. Процесс, необходимый для определения подходов к планированию и выполнению операций по управлению рисками проекта.
16. Идентификация рисков. Процесс, необходимый для определения того, какие именно риски могут повлиять на проект, а также для документирования их характеристик.
17. Качественный анализ рисков. Процесс, необходимый для установления приоритетов рисков с целью их дальнейшего анализа или действий путем оценки и совмещения их вероятности и воздействия.
18. Количественный анализ рисков. Процесс, необходимый для количественного анализа воздействия определенного риска на общие цели проекта.
19. Планирование реагирования на риски. Процесс, необходимый для разработки вариантов и операций для повышения возможностей и снижения угроз целям проекта.
20. Планирование покупок. Процесс, необходимый для определения, что, как и когда следует приобрести.
21. Планирование контрактов. Процесс, необходимый для документирования требований к продуктам, услугам и результатам, а также для поиска потенциальных продавцов.
Группа процессов исполнения
Группа процессов исполнения состоит из процессов, используемых для осуществления работ, означенных в плане управления проектом для выполнения требований проекта. Команда проекта должна определить, какие из процессов нужны для конкретного проекта. Данная группа процессов включает в себя координацию людей и ресурсов, а также интеграцию и исполнение операций проекта в соответствии с планом управления проектом. Кроме того, в этой группе процессов идет работа с содержанием проекта, в который вносятся одобренные изменения.
Обычно при исполнении имеют место отклонения, приводящие к корректировке планов. Эти отклонения могут затрагивать длительность операций, наличие и эффективность ресурсов, а также непредусмотренные риски.
Независимо от того, повлияют такие отклонения на план управления проектом или нет, они могут потребовать анализа, результаты которого повлекут за собой запрос на изменение. Если этот запрос будет одобрен, то это может привести к изменению плана управления проектом и, возможно, утверждению нового базового плана. Подавляющая часть бюджета проекта пойдет на выполнение группы процессов исполнения, куда входят следующие процессы управления проектами.
1. Руководство и управление исполнением проекта. Процесс, необходимый для управления различными организационными и техническими интерфейсами, имеющимися в проекте, для выполнения работ, предусмотренных в плане управления проектом. Результаты поставки представляются как выходы выполненных процессов, указанных в плане управления проектом. По мере выполнения проекта собирается информация о завершении подготовки результатов поставки и о том, какие именно работы завершены. Эта информация становится входом для процесса отчетности по исполнению.
2. процесс обеспечения качества. Процесс, необходимый для применения плановых систематических операций по проверке качества, – например, аудит или независимая экспертиза, – чтобы удостовериться, что в проекте используются все необходимые процессы для выполнения требований.
3. Набор команды проекта. Процесс, необходимый для получения человеческих ресурсов, нужных для выполнения проекта.
4. Развитие команды проекта. Процесс, необходимый для повышения компетенции и взаимодействия членов команды для улучшения исполнения проекта.
5. Распространение информации. Процесс, необходимый для обеспечения своевременного доступа участников проекта к нужной им информации.
6. Запрос информации у продавцов. Процесс, необходимый для получения информации, расценок или предложений.
7. Выбор продавцов. Процесс, необходимый для изучения предложений, выбора из потенциальных продавцов и заключения письменного контракта с продавцом.
Группа процессов мониторинга и управления
Группа процессов мониторинга и управления состоит из процессов, выполняемых для правильного исполнения проекта, так чтобы возможные проблемы были обнаружены вовремя и в случае необходимости могли быть предприняты корректирующие действия для управления исполнением проекта.
Команда проекта должна определить, какие из процессов нужны для конкретного проекта. Главное достоинство этой группы процессов в том, что ход исполнения проекта регулярно контролируется и оценивается, и это позволяет выявить отклонения от плана управления проектом. В группу процессов мониторинга и управления входят также управление изменениями и рекомендации относительно предупреждающих действий в связи с возможными проблемами. В группу процессов мониторинга и управления входят:
1. Мониторинг соответствия текущих операций проекта плану управления проектом и базовому плану исполнения проекта.
2. Влияние на факторы, которые нарушают общее управление, для того чтобы внедрялись только одобренные изменения.
Постоянный мониторинг дает команде проекта представление о состоянии проекта и выделяет участки, которым нужно дополнительное внимание. Группа процессов мониторинга и управления не только наблюдает и управляет работами, производимыми в течение группы процессов, но также наблюдает и управляет всеми действиями по проекту.
В многофазных проектах группа процессов мониторинга и управления также обеспечивает обратную связь между фазами проекта с целью применения корректирующих или предупреждающих действий, чтобы проект не вышел за рамки плана управления проектом. Когда отклонения ставят под угрозу цели проекта, приходится возвращаться к соответствующим процессам управления из группы процессов планирования в соответствии с уточненной моделью цикла «планирование – исполнение – проверка – воздействие».
Результатом такого анализа может стать рекомендация скорректировать план управления проектом. Например, если операция не завершена к намеченной дате, то может потребоваться изменение действующего плана обеспечения персоналом, введение сверхурочных работ, поиск компромисса решений между выполнением целей проекта и его бюджетом. В группу процессов мониторинга и управления входят следующие процессы.
1. Мониторинг и управление работами проекта. Процесс, необходимый для сбора, измерения и распространения информации об исполнении проекта и оценки измерений и тенденций для влияния на улучшение процессов. Он включает мониторинг рисков, что позволяет обеспечить выявление рисков на ранних стадиях, после чего составляется отчет об их состоянии и приводятся в исполнение соответствующие планы реагирования на риски. Мониторинг включает в себя отчеты о текущем состоянии, оценку прогресса и прогнозирование. Отчеты об исполнении предоставляют информацию об исполнении проекта по таким показателям, как содержание, расписание, стоимость, ресурсы, качество и риски.
2. Общее управление изменениями. Процесс, необходимый для управления факторами, создающими изменения, чтобы последние были благотворными. Он необходим также для отслеживания внесения изменений и для управления одобренными изменениями, в том числе временем их обработки. Этот процесс выполняется в течение всего проекта – от инициации до закрытия.
3. Подтверждение содержания. Процесс, необходимый для формализации приемки завершенных результатов поставки проекта.
4. Управление содержанием. Процесс, необходимый для управления изменениями в содержании проекта.
5. Управление расписанием. Процесс, необходимый для управления изменениями в расписании проекта.
6. Управление стоимостью. Процесс влияния на факторы, создающие отклонения, и управление изменениями бюджета проекта.
7. Процесс контроля качества. Процесс, необходимый для мониторинга определенных результатов проекта с целью определения их соответствия принятым стандартам качества и выработки путей устранения причин неудовлетворительного исполнения.
8. Управление командой проекта. Процесс, необходимый для отслеживания деятельности членов команды, обеспечения обратной связи, решения проблем и координации изменений с целью улучшения исполнения проекта.
9. Отчетность по исполнению. Процесс, необходимый для сбора и распространения информации об исполнении. Эта информация включает в себя отчеты о текущем состоянии, оценку прогресса, а также прогнозирование.
10. Управление участниками проекта. Процесс, необходимый для управления коммуникациями с целью удовлетворения требований участников проекта и решения вместе с ними возникающих проблем.
11. Наблюдение и управление рисками. Процесс, необходимый для отслеживания выявленных рисков, мониторинга остаточных рисков, выявления новых рисков, выполнения планов реагирования на риски и оценки их эффективности в течение жизненного цикла проекта.
12. Администрирование контрактов. Процесс, необходимый для управления контрактом и взаимоотношениями между продавцом и покупателем, для изучения и документирования действий продавца и, в соответствующих случаях, для управления контрактными отношениями с внешним покупателем проекта.
Группа завершающих процессов
В группу завершающих процессов входят процессы, используемые для формального завершения всех операций проекта или фазы проекта, передачи завершенного продукта другим лицам или закрытия остановленного проекта. Когда эта группа процессов выполнена, она подтверждает, что во всех группах процессов должным образом совершены определенные процессы для закрытия проекта или фазы проекта, и формально устанавливает, что проект или окончены.
В группу завершающих процессов входят следующие процессы управления проектами.
1. закрытие проекта. Процесс, необходимый для завершения всех операций всех групп процессов, чтобы формально закрыть проект или фазу проекта.
2. закрытие контрактов. Процесс, необходимый для завершения и урегулирования каждого контракта, в том числе завершения действующих контрактов и закрытия каждого контракта, затрагивающего проект или фазу проекта.
Группы процессов управления проектом связаны целями, которые перед ними поставлены. Выход одного процесса обычно является входом для другого процесса или результатом поставки проекта. Группа процессов планирования предоставляет группе процессов исполнения документированный план управления проектом и описание содержания проекта, а также часто вносит изменения в план управления проектом по ходу проекта.
Необходимо также отметить, что группы процессов редко являются дискретными или однократными событиями; как правило, это накладывающиеся друг на друга действия, осуществляемые с той или иной интенсивностью в течение жизненного цикла проекта. На рис. 3.2 изображено взаимодействие группы процессов, а также показан уровень наложения в различные периоды осуществления проекта. Если проект разделен на фазы, группы процессов взаимодействуют в рамках фазы проекта и могут также пересекать границы фаз.
В табл. 3.1 показано распределение (в соответствии со стандартом РМВОК, 2004) 44 процессов управления проектами на пять групп процессов управления проектом и девять областей знаний по управлению проектами.
Рис. 3.2. Взаимодействие между группами процессов в проекте (по [РМВОК, 2004])
Таблица 3.1
Соответствие между процессами управления проектами, группами процессов управления проектами и областями знаний
Материал, представленный в данной главе, основан на стандарте РМВОК, который получил наибольшее распространение в разных странах мира, в том числе и в России. Понимание и четкое следование базовым правилам методологии управления проектами позволяет успешно реализовывать проекты в различных сферах человеческой деятельности, где бы они ни осуществлялись.
Резюме
Существует множество определений понятия «проект», которые, впрочем, не противоречат, а дополняют друг друга. Базовыми понятиями управления проектами, помимо собственно «проекта», являются также объекты управления проектами, субъекты управления проектами, процессы управления проектами, тройственное ограничение управления проектами (треугольник управления проектами). В современной трактовке управление проектами рассматривается как совокупность процессов, задаваемая пересечением групп процессов управления проектом (инициация, планирование, исполнение, контроль, завершение) и функциональных (предметных) областей управления проектами (управление интерграцией проекта, содержанием, сроками, стоимостью, качеством, человеческими ресурсами, коммуникациями, рисками, поставками и контрактами).
Ключевые термины
Группа процессов управления проектом – логическое объединение управленческих входов, инструментов и методов, и выходов проекта. В группы процессов управления проектами входят процессы: инициации, планирования, исполнения, мониторинга и управления, а также завершения. Группы процессов управления проектами не являются фазами проекта.
Жизненный цикл проекта – набор обычно последовательных фаз проекта, количество и состав которых определяется потребностями управления организации или организаций, участвующих в проекте. Жизненный цикл можно документировать с помощью методологии.
Заинтересованная сторона – лицо или организация (например, потребитель, спонсор, исполняющая организация или общественность), которые активно вовлечены в проект либо на чьи интересы могут позитивно или негативно повлиять исполнение или завершение проекта. Заинтересованная сторона также может оказывать влияние на проект и его результаты.
План управления проектом – утвержденный формальный документ, в котором указано, как проект будет исполняться, как произойдет его мониторинг и управление им. План может быть обобщенным или подробным, а также может включать один или несколько вспомогательных планов управления и другие документы по планированию.
Контрольные вопросы
1. Каковы отличительные признаки проекта?
2. Что понимается под управлением проектами?
3. Что такое «треугольник управления проектами»?
4. Какова структура процессов управления проектами согласно РМВОК?
5. Какова взаимосвязь между группами процессов управления проектами?
6. Какие процессы входят в группу процессов планирования проекта?
Литература
1. Баркалов С. А., Воропаев В. И., Секлетова Г. И. и др. Математические основы управления проектами: учеб. пособие / под ред. В. Н. Буркова. М.: Высшая школа, 2005.
2. Грей К. Ф., Ларсон Э. У. Управление проектами: учебник. М.: Дело и Сервис, 2007.
3. Дитхелм Г. Управление проектами: в 2 т. М.: Бизнес-Пресса, 2004.
4. Мазур И. И., Шапиро В. Д., Ольдерогге Н. Г., Полковников А. В. Управление проектами. М.: Омега-Л, 2009.
5. Милошевич Д. Набор инструментов для управления проектами. М.: Ай-Ти-Пресс; ДМК, 2006.
6. Полковников А. В., Дубовик М. Ф. Управление проектами (полный курс МВА). М.: Эксмо, 2011.
7. Романова М. В. Управление проектами: учеб. пособие. М.: ИД «ФОРУМ»; ИНФРА-М, 2007.
8. Тернер Дж. Р. Руководство по проектно-ориентированному управлению. М.: Изд. дом Гребенникова, 2007.
9. Управление проектами: основы профессиональных знаний. Национальные требования к компетентности специалистов. М.: ЗАО «Проектная ПРАКТИКА», 2010.
10. Ципес Г. Л., Товб А. С. Проекты и управление проектами в современной компании. М.: ЗАО «Олимп – Бизнес», 2009.
11. PMBOK Guide. 4th ed. Newton Square, Pennsylvania, USA: Project Management Institute, 2008.
Глава 4. Современное состояние методологии управления проектами
Изучив материал данной главы, вы узнаете:
• что такое методология управления проектами и какова ее структура;
• каковы основные методологические подходы к управлению проектами;
• какие профессиональные стандарты используются в качестве методологической базы при управлении проектами.
4.1. Методология управления проектами: определение и структура
Методология как предмет исследования в советские времена стала рассматриваться лишь в 1960-1970-е годы. До этого считалось, что вся методология заклю чена в марксистско-ленинском учении и всякие разговоры о какой-либо еще «методологии» вредны и опасны. Несмотря на это, методология науки благодаря трудам П. В. Копнина, В. А. Лекторского, В. И. Садовского, В. С. Швырева, Г. П. Щедровицкого, Э. Г. Юдина и других авторов стала раз виваться. Но прежде всего необходимо обратиться к классическим, энциклопедическим, определениям рассматриваемого понятия.
«Методология (от «метод» и «логия») – учение о структуре, логической организации, методах и средствах деятельности».
«Методология – система принципов и способов организации и построения теоретической и практической деятельности, а также учение об этой системе».
В соответствии со стандартом PMBOK под методологией понимается система практик, методов, процедур и правил, используемых в определенной сфере деятельности.
Таким образом, приходится констатировать, что, с одной стороны, определение методологии обширно и многозначно, с другой – несколько сужено, доведено до уровня набора практик. Зачастую наблюдается так называемая «возгонка» терминов: вместо слова «инструмент» употребляется «метод», вместо «метода» – «методика», а «методику» заменяют «методологией». Нередко такие «методологии» являются набором частных и случайных решений, оказавшихся полезными в силу специфических черт какого-либо проекта или компании. Далее будем называть их частными методологиями управления проектами.
Не будет преувеличением сказать, что в профессиональной среде управления проектами отношение к методологии крайне неоднозначно, что, на взгляд автора, определяется, во-первых, размытостью самого понятия, а во-вторых, традиционным представлением о том, что методология практически целиком относится к науке, к научной деятельности, хотя научная деятельность является лишь одним из специфических видов человеческой деятельности наряду с искусством, религией и философией. Все остальные профессиональные виды деятельности человека относятся к практической деятельности. На них также должно распространяться понятие методологии, в том числе понятие методологии практической деятельности. По мнению автора, в современную эпоху развития человечества, сопровождаемую такими явлениями, как информатиза ция общества, глобализация экономики, изменение роли науки в обществе и т. д., методологию следует трактовать в организационно-деятельностной парадигме.
Под методологией управления проектами предлагается понимать совокупность подходов, методов и моделей управления проектами, программами и портфелями проектов, отраженных в профессиональных стандартах управления проектами глобального, международного, национального, отраслевого и корпоративного уровня, а также в различных научных и практических источниках, организующих теорию и практику управления проектами с целью достижения заданного результата.
Основными элементами структуры методологии управления проектами являются:
1. Методологические подходы к управлению проектами, сформулированные ведущими исследователями в сфере управления проектами:
• логико-структурный;
• системный;
• интегрированный.
2. Методы управления проектами:
• структуризации;
• сетевого планирования;
• метод освоенного объема и многие другие методы, применяемые в различных областях знаний управления проектами.
3. Модели управления проектами:
• модели зрелости организационного управления проектами;
• сетевые и другие модели.
4. Стандарты управления проектами, программами и портфелями проектов различного уровня (глобального, международного, национального, отраслевого).
5. Частные (корпоративные и отраслевые) методологии управления проектами.
Далее будут подробно рассмотрены вышеперечисленные элементы методологии управления проектами.
4.2. Методологические подходы к управлению проектами
Логико-структурный подход к управлению проектами
Логико-структурный подход (ЛСП) к управлению проектами предложен в работах В. В. Познякова [Позняков, 2007]. Подход весьма эффективен на всех фазах жизненного цикла проекта, особенно при идентификации, разработке и мониторинге проекта, и широко используется в разнообразных проектах, осуществляемых многими международными, правительственными, коммерческими организациями. ЛСП основывается на таких темах, как проблемы организации, анализ заинтересованных сторон, определение целей проекта и необходимых ресурсов, определение основных индикаторов успешности проекта, анализ рисков. ЛСП помогает принять одно из самых сложных стратегических решений – должен ли проект реализовываться сейчас или через какое-то время. Данный подход не противопоставляется другим современным методам, он эффективно их дополняет по ряду важнейших аспектов управления проектами, в частности, уделяя особое внимание таким вопросам, как:
• четкое определение целей и содержания проекта на основе всестороннего анализа решаемых проблем, учета основных условий реализации, интересов вовлеченных сторон, а также рисков и гипотез, заложенных в проекте;
• принятие четко выраженных, количественно и качественно измеряемых показателей успешности реализации и завершения проекта (программы);
• четкое однозначное определение того, за что должен отвечать руководитель, члены группы управления и другие участники в процессе достижения поставленных задач и почему;
• выделение ключевых элементов проекта и определения их взаимосвязи, так чтобы это способствовало облегчению анализа, реализации и оценки;
• перенос акцента при оценке проекта с вопроса «кто виноват?» на вопрос «каков наиболее реалистический курс дальнейшей работы?».
В большинстве организаций процедуры ЛСП, формы и содержание документов детально регламентированы и встроены в общие процессы разработки и реализации проектов, использующие широко известные методы управления проектами. При этом ЛСП в целом или отдельные его составляющие могут применяться многократно на разных этапах разработки и реализации проекта. Следует отметить, что в различных организациях часто используются различные структуризации работ, терминологии, формы документов, связанных с разработкой и реализацией проектов. Например, близкие по содержанию и назначению документы по разработке проектов могут называться предложением по проекту, отчетом по подготовке проекта, ТЭО и др. Несмотря на эти расхождения, можно выделить следующие основные этапы ЛСП:
1. Анализ заинтересованных сторон.
2. Анализ проблем.
3. Анализ целей.
4. Формулировка основных предположений и факторов риска.
5. Определение показателей прогресса реализации и степени достижения целей проекта.
6. Составление логико-структурной схемы проекта (ЛСС).
7. Дальнейшая разработка проекта.
8. Система управления проектом.
9. Мониторинг, отчетность, оценка проекта.
1. Анализ заинтересованных сторон. Включает идентификацию отдельных лиц, групп, организаций, интересы которых может затронуть проект, определение их основных ключевых проблем, столкновения интересов, ограничений и возможностей (институциональный анализ).
Задачи данного этапа решаются путем изучения имеющихся материалов, проведения дополнительных исследований, контактов и обсуждений с заинтересованными сторонами.
Одним из существенных факторов успеха проекта является поведение и потенциал участвующих в проекте организаций.
Для проведения анализа участия каждой из заинтересованных в проекте организаций может предприниматься институциональная оценка, инструментом которой является SWOT-анализ, путем проведения исследования организации по четырем аспектам:
• сильные стороны – внутренние положительные качества;
• слабые стороны – внутренние отрицательные качества;
• возможности – внешние факторы, улучшающие перспективы;
• угрозы – внешние факторы, способные подорвать будущий успех.
2. Анализ проблем. На этом этапе осуществляется формулировка проблем, определение их причинно-следственных связей и построение древа проблем. Последнее представляет собой иерархическое расположение проблем, и для его построения важно привлечь основные заинтересованные стороны. Из предварительно сформулированных проблем каждому участнику анализа предлагается выбрать одну в качестве центральной, т. е. такую проблему, которую он считает центром всей проблематичной ситуации, и представить свои предложения в письменной форме.
В своем первоначальном выборе центральной проблемы каждая из заинтересованных сторон будет руководствоваться своим собственным интересом в проекте и своими собственными проблемами.
Обсуждение всего спектра центральных проблем следует вести до тех пор, пока участники встречи не достигнут соглашения по одной центральной проблеме. Она и станет исходным пунктом построения древа проблем.
При рассмотрении второй проблемы, связанной с ней, поступают следующим образом:
• если проблема является причиной, она помещается уровнем ниже;
• если проблема является следствием, она помещается уровнем выше;
• если проблема не является ни причиной, ни следствием, она помещается на тот же самый уровень.
По мере разрастания древа оставшиеся проблемы добавляются к нему по тому же принципу. Повторный анализ проблем может привести к появлению на более поздней стадии иной центральной проблемы, что, однако, не делает анализ менее обоснованным.
3. Анализ целей. Исходя из построенного древа проблем, строится древо целей проекта, достижение которых позволит решить выявленные проблемы. При этом выделяют следующие уровни (названия в разных организациях могут быть разными):
• общая цель(и) – цель проекта (программы) более высокого уровня, вклад в который данный проект предназначен внести;
• цель(и) проекта – вклад проекта в достижение общей цели путем использования результатов проекта;
• результаты проекта – те значимые выходные продукты, которые получат пользователи проекта по его завершении;
• действия – действия, необходимые для преобразования ресурсов в результаты проекта;
• общая цель (цель проекта более высокого уровня, вклад в который данный проект предназначен внести) – улучшение условий ведения бизнеса, совершенствование управления общественным сектором;
• цель проекта (вклад проекта в достижение общей цели путем использования результатов проекта) – содействие развитию рынка недвижимости, повышение качества работы службы кадастра;
• результаты (что получат пользователи) – ускорение и улучшение обработки информационных потоков.
При формулировании целей важно обеспечить их:
• реальность – возможность достижения в рамках заданных ресурсов и ограничений (финансовых, физических, временных и др.);
• определенность – условия того, что цели проекта достигнуты благодаря проекту, а не по другим причинам;
• измеримость – возможность количественной оценки при приемлемой затрате средств и усилий.
Важно четко разграничить цели, результаты и действия и соответственно определить области ответственности, в частности, менеджеров проекта. При их определении исходят из их управляемости со стороны менеджера проекта, что, в свою очередь, зависит от предположений, заложенных в проект, и присущих ему рисков. Менеджер проекта несет ответственность за эффективное использование ресурсов и достижение результатов и не может нести прямую ответственность, например, за использование предоставляемых проектом услуг. Но он может осуществлять в течение определенного периода мониторинг связанных с этим рисков и допущений, и тогда имеет смысл включить необходимость указанного мониторинга в формулировку результатов проекта.
Действия и необходимые ресурсы при проведении ЛСП определяются укрупненно в виде основных компонентов проекта и групп ресурсов, и их детализация проводится при дальнейшей разработке проекта.
На этом этапе тесно связанные друг с другом цели объединяются в группы и решается вопрос о включении их в содержание проекта.
После анализа целей проект должен быть готов для проведения детального планирования, в результате чего может потребоваться уточнение принятых ранее формулировок целей, действий ресурсов.
4. Формулировка основных предположений и факторов риска. Для успешной реализации проекта и оценки его результатов важно четко сформулировать основные предположения и факторы риска, не поддающиеся контролю со стороны менеджмента проекта и способные оказать серьезное отрицательное влияние на выполнение проекта. Анализ и разработка соответствующих мер противодействия проводятся при помощи известных методов анализа рисков.
5. Определение показателей прогресса реализации и степени достижения целей проекта. Для эффективного управления ходом реализации проекта и оценки степени достижения его целей необходимо определить соответствующие показатели, способы и источники информации для их измерения. Показатели должны отражать такие характеристики, как качество, количество и время.
Следует следить за тем, чтобы отобранные показатели были связаны с конкретными целями, чтобы они действительно свидетельствовали, достигнута цель или нет. Необходимо чтобы те, кто занимается планированием, и те, кто осуществляет проект, имели одинаковые представления о целях обеспечения их реальности, конкретности и измеримости.
В организациях, которые имеют большой опыт выполнения проектов, для близких по содержанию проектов разрабатываются перечни рекомендуемых показателей.
6. Составление логико-структурной схемы проекта (Лсс). На основании результатов, полученных на предыдущих этапах, составляют логико-структурную схему проекта. Она представляется в виде таблицы с четырьмя строчками и четырьмя колонками. В левой колонке располагаются сверху вниз общие цели, цели проекта, результаты, действия. В следующей, слева направо, колонке – показатели достижения соответственно общих целей и т. д., в третьей – методы и источники измерения показателей и в последней располагаются основные предположения и риски. Рекомендуется вначале заполнить первую и четвертую колонки, а потом вторую и третью. ЛСС позволяет дать краткое и легко обозримое представление сложных проектов, их целей, основных компонентов и связей между ними, необходимых ресурсов, важных для успеха проекта предположений и рисков, а также определения области ответственности руководителей проекта. ЛСС является основой для дальнейшей разработки проекта, а вторая и третья колонки, в частности, используются для построения системы мониторинга и оценки проекта.
7. Дальнейшая разработка проекта. После составления ЛСС можно приступать к дальнейшей разработке проекта, которая станет детализацией решений, принятых при составлении ЛСС. Здесь решаются традиционные вопросы планирования проектов, такие как составление графиков работ, определение необходимых ресурсов, разработка бюджетов, определение характеристик эффективности проекта (экономической, коммерческой и др.), определение источников и способов финансирования, проектирование организационных схем управления, разрабатываются планы закупок, выбираются способы управления рисками и др.
При решении этих вопросов используются хорошо известные в национальной и международной практике методы и подходы, такие как составление различных по глубине агрегирования структур необходимых работ, календарное планирование, методы разработки бюджетов, определения эффективности проектов, методы управления рисками и др.
Объем и детальность разработки определяются характером и масштабом проекта, а также регламентирующими документами по разработке проектов, принятыми в той или иной организации. Например, в организациях, финансирующих сравнительно небольшие проекты, объем документов планирования, как правило, невелик. Это могут быть заявка на инвестирование, часто в свободной форме, предложение об инвестировании, концепция проекта, бизнес-план, ТЭО. В случае, когда финансируются масштабные и сложные по характеру проекты, планирование охватывает широкий круг аспектов и требует больших усилий. В основе применяемых при этом подходов (в частности, для инвестиционных проектов) лежат хорошо известные методики ЮНИДО, соответствующие национальные и корпоративные руководства.
8. Система управления проектом. Формируется на ранних фазах жизненного цикла проекта и во многом определяется его предметной областью, масштабом, составом участников, окружением. Для крупных и средних проектов характерна многоуровневость системы управления с разделением на стратегическое и оперативное управления. При этом стратегическое управление обычно осуществляется высшими уровнями ведомственного, корпоративного управления или специально созданными координационными советами, особенно в случае сложных проектов с большим количеством участников. Оперативное управление осуществляется группой управления проектом (ГУП). Среди используемых организационных решений для ГУП можно отметить следующие:
• использование консультантов (консультационных компаний);
• передачу функций ГУП одному из действующих подразделений исполняющей проект организации или вышестоящего органа в дополнение к существующим их обязанностям. При этом могут использоваться различные варианты матричной организации управления проектом;
• создание новой структуры с административным подчинением одному из ведущих участников проекта;
• передачу функций ГУП другой ГУП, которая уже ведет близкие по характеру проекты и имеет необходимый опыт;
• разделение функций ГУП между исполняющим ведомством (подразделением) с поручением ему функций, связанных с содержательной частью проекта, и одной из действующих и опытных ГУП с поручением ей специфических управленческих функций.
9. Мониторинг, отчетность, оценка проекта. Мониторингу проекта уделяется особое внимание, и он осуществляется на всех уровнях управления проектом, где также могут привлекаться независимые эксперты. Особо жесткому контролю подвергаются процессы закупок и расходования средств и соответствия запланированных целей проекта текущей ситуации.
При построении системы мониторинга исходят из целей проекта, структуры работ, определенных в ЛСС показателей достижения целей, показателей выполнения конкретных мероприятий по устранению ранее выявленных проблем и др. Периодичность контроля и отчетности зависит от уровня управления, состояния проекта, его характера и для рассматриваемых проектов может варьироваться от одного раза в неделю до одного раза в год. Используются различные формы отчетности, содержащие основные финансовые и физические показатели, определенные в логико-структурной схеме, графиках работ и расходования средств. Кроме этого регулярно проводятся обзоры хода выполнения проекта путем совместного обсуждения основными заинтересованными сторонами положения дел, оценки состояния реализации проекта и выработки планов дальнейших действий.
Мерами по регулированию хода проекта могут быть как совместные мероприятия по решению возникших проблем, так и изменение целей проекта (реструктуризации проекта) или его преждевременное закрытие и аннулирование неизрасходованных средств в случае нецелесообразности дальнейшего продолжения проекта.
Одним из средств контроля за подготовкой и реализацией проекта является регулярное проведение оценок проекта, обычно после конца подготовки, в середине и после завершения. Основной целью при этом является определение соответствия состояния проекта его целям. При окончании подготовки проекта независимая оценка помогает определить обоснованность его целей и соответствие уровня разработки выбранным целям. Промежуточные оценки дают возможность определить, сохраняется ли актуальность целей проекта и соответствует ли состояние проекта этим целям. После окончания проекта в ходе оценки определяется степень достижения целей, основные проблемы реализации, анализируются основные причины этих проблем, формулируются рекомендации для будущих проектов близкого характера. Оценки осуществляются специальными подразделениями ведущих участников проекта на основе документов мониторинга, дополнительных исследований или специальных миссий.
В ходе оценки используются различные критерии. Так, в организациях ЕС используются такие критерии, как адекватность, экономичность, продуктивность, эффективность, воздействие, экономическая и финансовая жизнеспособность. Могут применяться более обобщенные критерии. На основе оценки этих показателей каждому проекту присваивается одно из значений рейтинга: удовлетворительно, неудовлетворительно, крайне неудовлетворительно.
В целом, ЛСП представляет реальный интерес для стратегического управления проектами, но он должен рассматриваться только в качестве дополнения к другим компонентам методологии управления проектами.
Интегрированный подход к управлению проектами
Интегрированный подход к управлению проектами сформулирован в работах Г. Л. Ципеса. В соответствии с данным подходом постановка задачи создания интегрированной системы управления проектами (СУП) требует первоочередного внимания к тому набору функций, которые будет обеспечивать такая СУП. Интегрированная СУП рассматривается как организационная и программно-техническая среда, предоставляющая менеджеру инструменты выработки и реализации сбалансированных управленческих решений, охватывающих разные уровни и стадии управления проектом на всех фазах его жизненного цикла, позволяющие обеспечить эффективность управления и координацию выполнения работ по проекту.
В каждой компании существуют определенные, иногда значительные, особенности управления проектами. Эти различия в рамках СУП отражаются на уровне формирования конкретных управленческих процедур, маршрутов документов, используемых инструментов и т. д. Сходные принципы построения, концепция интегрированной СУП могут быть сведены к ряду основных вариантов решений, которые составляют основу общей для самых разных предприятий методики проектирования СУП конкретного предприятия. Таким образом, СУП представляет собой комплексную интеграционную технологию.
Как самостоятельные (имеющие самостоятельную ценность для будущего владельца) продукты можно рассматривать и целый ряд локальных результатов, достигаемых в процессе создания и внедрения СУП. К ним относятся:
1. Концепция автоматизированной системы управления проектом, в рамках которой определяются:
• основные элементы СУП (субъекты управления, объекты управления, процессы управления);
• формализованная функциональная модель СУП верхнего уровня, описывающая основные стадии и этапы управления;
• конкретные задачи СУП в части реализации функций управления;
• объем автоматизации функций управления, в том числе в составе различных очередей системы, а также средства автоматизации как в составе общих для предприятия ИТ-решений, так и специализированные пакеты программ;
• основные требования к обеспечивающим компонентам СУП – к техническому, программному, информационному, методологическому и организационному обеспечению.
2. Организационное обеспечение системы управления проектом, включающее описание регламентов взаимодействия участников проекта, процедур управления различными этапами проекта, детальных инструкций по исполнению процедур и шаблонов управленческих документов, а также положений о временных органах проектного управления и соответствующих должностных инструкций.
Схема работ по созданию СУП содержит этапы, традиционные для разработки информационных систем, – обследование, разработку концепции, выбор программных продуктов, работы по интеграции, обучение персонала. Специфика этих работ проявляется главным образом в объекте обследования, используемых моделях и при смещении внимания в сторону организационного обеспечения. Работы всех этапов создания СУП могут быть в значительной степени формализованы – вплоть до использования стандартизованных бланков анкет, методик формирования моделей и шаблонов документов (это, в частности, является задачей и наполнением упомянутой выше методики проектирования СУП).
В области развития методов оценки корпоративного управления проектами Г. Л. Ципес также видит два направления:
• применение комплексных оценок эффективности отдельных проектов по отклонениям и по стратегическим критериям для оценки эффективности реализации проектов;
• разработку типовой модели оценки эффективности деятельности проектно ориентированной компании (подразделения) на основе набора специфических ключевых показателей эффективности.
Главными особенностями проектов, в частности внутренних проектов развития, являются их стандартная структура и стандартные ограничения. Именно стандартные ограничения по времени, стоимости реализации и по качеству результатов могут быть использованы для построения обобщенного показателя, характеризующего эффективность проведения внутренних проектов компании через оценку возникающих отклонений. Данные показатели эффективности предлагают объективную оценку успешности выполнения внутренних проектов, на основе которых можно разработать подходы, развивающие методы оценок проектов по отклонениям, модели комплексных оценок, учитывающих, с одной стороны, всесторонний анализ отклонений, и с другой – соответствие проектов стратегии развития компании.
В области построения комплексных оценок проекта по отклонениям Г. Л. Ципес предлагает универсальную модель описания стратегий изменений и учета фактических изменений в проекте. Модель имеет три измерения, соответствующие основным «измерениям» проекта, – ресурсы, сроки исполнения, характеристики продукта, являющегося результатом выполнения проекта. Отклонения по каждому из этих измерений оцениваются с точки зрения тяжести их последствий – плановые потери, допустимые, нежелательные, недопустимые потери. Сформулирован общий принцип построения метрик для оценки отклонений как весов конкретных мероприятий, при помощи которых реализуются те или иные изменения. Веса определяются посредством соотнесения мероприятия одной из областей потерь.
На основе анализа большого количества проектов для каждого измерения выстроены типовые метрики отклонений, характерных для этого типа проектов, – манипулирование ресурсами, временными параметрами, результатами проекта. Предложены правила определения комплексной оценки отклонений PD как средневзвешенной оценки по трем метрикам.
Здесь значения D
(отклонение по времени), D
(отклонение по стоимости) и D
(отклонение по качеству продукта) определяются по пятибалльной шкале в зависимости от тяжести последствий отклонений. Веса метрик (K
, K
, K
) выбираются исходя из того, насколько критичным для данного проекта (для исполнителя и/или заказчика) является тот или иной вид отклонений, и играют роль дополнительных параметров, значения которых определяются для каждого проекта индивидуально в зависимости от допустимой (оптимальной) стратегии изменений в этом проекте.
Значения измерителей (частные отклонения) могут рассчитываться на основании специальных шкал, позволяющих классифицировать отклонения с точки зрения тяжести их последствий, например:
0 – без потерь;
1 – плановые потери (учтены в плане управления проектом);
2 – допустимые потери (незначительные незапланированные затраты);
3 – нежелательные потери (значительные незапланированные затраты);
5 – недопустимые потери (незапланированные затраты, которые являются неприемлемыми для одного или нескольких участников проекта).
Предложенная модель оценки эффективности проекта позволяет учитывать мнения всех заинтересованных сторон.
Внутренние проекты компании осуществляются в соответствии с принятыми в этой компании правилами и стандартами управления проектами. Независимо от уровня знаний проектного управления процесс внедрения проекта в любой организации включает несколько стандартных стадий (инициализация, планирование, выполнение, контроль, завершение). Каждая из стадий предполагает выполнение определенных функций, связанных с управлением временными и стоимостными параметрами проекта, с управлением рисками, контрактами, качеством и т. д. Именно к этим стадиям и функциям и должно быть привязано использование оценки эффективности и получение фактических значений.
Интегрированный подход сосредоточен на поиске методологических подходов к построению системы управления проектами на уровне организации, что фактически и задает ограничение данного подхода.
Системный подход к управлению проектами
Наиболее обобщенным методологическим подходом является подход, сформулированный В. И. Воропаевым [Баркалов и др., 2005]. В основе предложенного им системного подхода лежит системная модель управления проектами.
Причинами разработки системной методологии управления проектами и программами (УПП) стали:
• отсутствие полного системного понимания всего спектра вопросов, касающихся управления проектами и программами;
• отсутствие системной, единой концепции УПП, надлежащим образом структурирующей знания, функции, процессы, процедуры и т. д.;
• необходимость определения технологической взаимосвязи и последовательности решения задач УПП;
• необходимость обеспечения эффективной интеграции всех элементов дисциплины управления проектами;
• необходимость развития методов и инструментов УПП, обусловленных потребностями новых и традиционных областей приложений УПП;
• сложности взаимодействия и взаимопонимания между экспертами и практиками в области управления проектами в силу многообразия технологий и терминологий в различных профессиональных сферах и литературе по УПП.
Системная модель и ее свойства послужили основой для разработки системной методологии УПП.
Свойства системной модели:
• системная модель управления проектом представляет собой свернутое древо избыточного множества задач и процедур, которые теоретически могут осуществляться при управлении различными объектами;
• каждый процесс (задача) системной модели управления проектом однозначно определяется компонентами выбранных уровней системной модели, логично связанных между собой;
• иерархичность структуры объектов управления, основой которой является структура работ объектов управления (WBS);
• иерархичность и реляционные взаимосвязи между субъектами управления, представляемые организационной схемой проекта (OS);
• иерархичность организационной структуры проекта (OBS), включающей команду проекта и команду управления проектом;
• иерархичность структуры задач и процедур управления проектами (TBS) от отдельных процедур и элементарных задач до совокупности комплексов задач систем управления разного назначения;
• многоаспектность задач управления проектами, зависящих от субъекта и объекта управления. Например, управление проектами для инвестора характеризуется своим набором задач со своими критериями оценки решений, ограничениями и неизвестными. Все это требует разработки и применения специальных методов и технологий решения задач. Эта же особенность относится и к другим ключевым участникам управления проектами: заказчикам, генконтракторам, генподрядчикам и др.
Управление крупными проектами, тем более программами, осуществляется с помощью разработанных систем УПП. Успешное функционирование таких систем при управлении проектами и программами определяется заложенной в них методологией. Для получения эффективной системы управления методология УПП должна использоваться на всех этапах ее разработки. Это:
• концептуальное проектирование;
• проектирование функциональных и обеспечивающих частей;
• проектирование системы коммуникаций и документации;
• разработка элементов: модели, методы, алгоритмы, программы и нормативно-методическое обеспечение (руководство пользователям, корпоративные и системные стандарты, методики, инструкции).
Представленная системная методология может использоваться:
• как методологический инструментарий для генерации и системного проектирования целостной интегрированной системы управления крупными проектами;
• для разработки стандартов и нормативных документов по УПП;
• для разработки программных средств по УПП;
• для разработки мультипроектных (корпоративных) систем управления;
• как структура древа знаний по УПП, которая положена в основы делового обучения, образования и сертификационных программ для специалистов по УПП.
4.3. Классификация стандартов в области управления проектами
На сегодняшний день управление проектами является одной из самых хорошо структурированных и стандартизованных областей менеджмента, доказательством чего является целое семейство профессиональных стандартов, описывающих различные аспекты управления проектами. Основными разработчиками стандартов управления проектами являются Институт управления проектами США – PMI (Project Management Institute), Международная ассоциация управления проектами – IPMA (International Project Management Association), Японская ассоциация управления проектами – PMAJ (Project Management Association of Japan), Международная организация по стандартизации – ISO (International Standard Organization), Агентство по ИТ и телекоммуникациям Великобритании – CCTA (Central Computer and Telecommunication Agency). Существующие стандарты можно классифицировать следующим образом:
• стандарты управления монопроектами (PMBOK (PMI), ISO 10006 (ISO), PRINCE2 (CCTA), P2M (PMAJ));
• стандарты управления программами (Standard for Program Management (PMI), P2M (PMAJ));
• стандарт управления портфелем проектов (Standard for Portfolio Management (PMI));
• стандарты описания компетенций менеджера проекта (PMCDF (PMI), ICB Version 3.0 (IPMA), НТК (Российская ассоциация управления проектами СОВНЕТ), GAPPS);
• стандарты организационного управления проектами (ОРМ3 (PMI)).
Результаты сравнительного анализа стандартов управления проектами, программами и описания компетенций по управлению проектами приведены в табл. 4.1–4.3.
Таблица 4.1
Сравнительный анализ международных стандартов по управлению проектами
Таблица 4.2
Сравнительный анализ международных стандартов по компетенциям в управлении проектами
Что касается управления портфелем проектов, то на сегодняшний день известен единственный стандарт, разработанный Институтом управления проектами США (PMI), который называется Standard for Portfolio Management (SPfM). SPfM определяет организационный контекст управления портфелем, основных участников, жизненный цикл и процессы, которые подразделяются на две основные группы (процессы выравнивания портфеля и процессы мониторинга и контроля).
Все перечисленные стандарты увязываются в единую систему стандартом, который позволяет диагностировать и совершенствовать зрелость организации в области управления проектами, программами и портфелями проектов, – стандартом ОРМ3 (Organizational Project Management Maturity Model), разработанным PMI. Под зрелостью организации понимается степень проникновения проектного подхода, включая методы, средства, процессы формального, классического, управления проектами в практику работы организации. В свою очередь, уровень зрелости организации в стандарте ОРМ3 определяется в трех измерениях: управление проектами, управление программами, управление портфелями проектов.
Таблица 4.3
Сравнительный анализ международных стандартов по управлению программами
Таким образом, структура методологического обеспечения корпоративной системы управления проектами может быть представлена в виде пирамиды со следующими уровнями (рис. 4.1):
1) стандарты организационного управления проектами, определяющие подходы к оценке и наращиванию зрелости компании в области управления проектами, программами и портфелями проектов (OPM3);
2) стандарты управления портфелями проектов (SPfM);
3) стандарты управления программами (SPgM, P2M);
4) стандарты, определяющие компетенции в управлении проектами (PMCDF, PM ICB, НТК, GAPPS);
5) стандарты управления проектами (PMBOK, ISO 10006, P2M, PRINCE2).
Рис. 4.1. Методологическая пирамида управления проектами, программами и портфелями проектов
Резюме
Под методологией управления проектами понимается совокупность подходов, методов и моделей управления проектами, программами и портфелями проектов, отраженных в профессиональных стандартах управления проектами глобального, международного, национального, отраслевого и корпоративного уровня, а также в различных научных и практических источниках, организующих теорию и практику управления проектами с целью достижения заданного результата.
Основными элементами структуры методологии управления проектами являются методологические подходы к управлению проектами (логико-структурный, системный, интегрированный, методы и модели управления проектами, стандарты управления проектами, программами и портфелями проектов различного уровня (глобального, международного, национального, отраслевого), а также частные (корпоративные и отраслевые методологии) управления проектами.
Ключевые термины
Методология (от «метод» и «логия») – учение о структуре, логической организации, методах и средствах деятельности; система принципов и способов организации и построения теоретической и практической деятельности, а также учение об этой системе; в соответствии со стандартом PMBOK под методологией понимается система практик, методов, процедур и правил, используемых в определенной сфере деятельности.
Методология управления проектами – совокупность подходов, методов и моделей управления проектами, программами и портфелями проектов, отраженных в профессиональных стандартах управления проектами глобального, международного, национального, отраслевого и корпоративного уровня, а также в различных научных и практических источниках, организующих теорию и практику управления проектами с целью достижения заданного результата.
Контрольные вопросы
1. Каковы составляющие методологии управления проектами?
2. Как можно классифицировать профессиональные стандарты управления проектами?
3. В чем состоит логико-структурный подход к управлению проектами?
4. Какие стандарты по управлению монопроектом вы знаете?
5. Расскажите о системной модели управления проектами В. И. Воропаева.
Литература
1. Баркалов С. А., Воропаев В. И., Секлетова Г. И. и др. Математические основы управления проектами: учеб. пособие / под ред. В. Н. Буркова. М.: Высшая школа, 2005.
2. Ильина О. Н. Методология управления проектами: становление, современное состояние и развитие. М.: ИНФРА-М; Вузовский учебник, 2011.
3. Мазур И. И., Шапиро В. Д., Ольдерогге Н. Г., Полковников А. В. Управление проектами. М.: Омега-Л, 2009.
4. Новиков А. М., Новиков Д. А. Методология. М.: СИНТЕГ, 2007.
5. Позняков В. В. Логико-структурный подход в управлении проектами. М.: УЦ Газпром, 2007.
6. Полковников А. В., Дубовик М. Ф. Управление проектами (полный курс МВА). М.: Эксмо, 2011.
7. Управление проектами: основы профессиональных знаний. Национальные требования к компетентности специалистов. М.: ЗАО «Проектная ПРАКТИКА», 2010.
8. Ципес Г. Л., Товб А. С. Проекты и управление проектами в современной компании. М.: ЗАО «Олимп – Бизнес», 2009.
9. ICB – IPMA Competence Baseline, Version 3.0. IPMA Editorial Committee. IPMA, 2006.
10. Managing Successful Projects with PRINCE2 2009 Edition. – Office of Government Commerce. London, UK, The Stationery Office, 2009.
11. OPM3 Organizational Project Management Maturity Model. Newton Square, Pennsylvania, USA: Project Management Institute, 2003.
12. P2M. A Guidebook of Project and Program Management for Enterprise Innovation, Revision 3. Project Management Association of Japan, 2005.
13. PMBOK Guide. 4th ed. Newton Square, Pennsylvania, USA: Project Management Institute, 2008.
14. PMCDF Project Management Competency Development Framework. 2nd ed. Newton Square, Pennsylvania, USA: Project Management Institute, 2007.
15. Practice Standard for Earned Value Management. Newton Square, Pennsylvania, USA: Project Management Institute, 2005.
16. Practice Standard for Risk Management. Newton Square, Pennsylvania, USA: Project Management Institute, 2009.
17. Practice Standard for Work Breakdown Structure. Newton Square, Pennsylvania, USA: Project Management Institute, 2006.
18. The Standard for Portfolio Management. Newton Square, Pennsylvania, USA: Project Management Institute, 2008.
19. The Standard for Program Management. Newton Square, Pennsylvania, USA: Project Management Institute, 2008.
Раздел II. Стратегическое управление проектными системами
Глава 5. Стратегическое управление проектами: базовые понятия и концептуальные основы
Изучив данную главу, вы узнаете:
• что такое системный подход в управлении проектами;
• что такое стратегическое управление проектами;
• как связать стратегию компании с проектами.
5.1. Системный подход как основа стратегического управления проектами
Термины и определения теории систем в проектной сфере
Проект, программа, портфель проектов, процессы, средства и механизмы управления ими порознь и в целом – это системные образования, которые в дальнейшем изложении будем называть проектными системами.
Определим некоторые понятия теории систем и покажем, как они проявляются в рассматриваемой сфере.
Среди многих опеределений системы можно выделить весьма лаконичное: «система – совокупность объектов, обладающая интегративным свойством» (Скляров, Жилин). Интегративное свойство – это свойство, которым обладает лишь система в целом, но не ее элементы, оно также называется свойством эмерджентности. Например, рабочие, объединенные в бригаду, могут выполнить работу, которую они не сделают каждый по отдельности. Здание выполняет функции, которые отсутствуют у отдельных его частей, рассмотренных порознь.
А. А. Богданов отмечал, что «целое больше суммы частей» вследствие организованности. Ф. Энгельс в «Анти-Дюринге» приводит высказывание Наполеона: «Два мамелюка безусловно превосходили трех французов; 100 мамелюков были равноценны 100 французам; 300 французов обыкновенно одерживали верх над 300 мамелюками, 1000 французов всегда разбивали 1500 мамелюков». Причиной этого Наполеон считает дисциплину, что, как правильно заметил Д. М. Жилин, «близко к понятию организованности». Но именно высокая степень организованности и достигается при использовании проектного подхода.
При рассмотрении проектной единицы (проект, программа, портфель) в качестве системы можно определить ее как комплекс компонентов, действия и отношения которых принимают характер взаимодействия для получения сфокусированного полезного результата (адаптировано по Анохину). Полезный результат – это цель любого проекта, программы, портфеля проектов.
Система обладает такими свойствами [Жилин, 2010], как:
• отграниченность или обособленность комлекса объектов, образующих систему;
• открытость – наличие связей с внешней средой;
• множественность составляющих объектов, совокупность которых необходима для появления интегративного свойства;
• взаимосвязанность компонентов, которая и способствует формированию интегративного свойства.
Эти свойства системы в явном виде присущи проектам и другим проектным образованиям. Проект – обособлен, открыт, состоит из множества компонентов (элементов), находящихся во взаимосвязи.
Элемент системы
Как отмечалось, система состоит из элементов (объектов, компонентов) (рис. 5.1). Элемент – неделимая (исходя из целей анализа и управления) наименьшая часть системы. Элемент системы характеризуется определенным законом функционирования:
y(t) = F(x(t)),
где x(t) – входной сигнал (вещество, энергия, информация); y(t) – выходной сигнал, может быть представлен различными функциональными характеристиками элемента; F – закон преобразования входного сигнала x(t) в выходной y(t).
Оператор F преобразует независимые переменные в зависимые и отражает изменения состояния элемента системы во времени.
Рис. 5.1. Функционирование элемента системы
Проект как система состоит из элементов, например, пакетов работ, имеющих результаты – выходы, которые служат входами в другие пакеты работ. В программах, если их рассматривать в качестве систем, выходы одних проектов являются поставками или входами для других. Связь проектов в портфеле более тонкая: она проявляется через распределение общих ресурсов (например, денег) между проектами портфеля и взаимосвязь проектов.
Каждый из упомянутых выше проектных элементов, преобразуя входы в выходы, выполняет в соответствующей системе свою функцию.
Элементы системы характеризуются качеством, которое проявляется через свойства. Свойства количественно описываются параметрами. Набор значений отдельных параметров определяет состояние объекта. Отдельные работы проекта (или проекты в программе) обладают такими свойствами, как долговременность, дороговизна, неопределенность и др. Параметры – продолжительность выполнения, затраты ресурсов, вероятность технического или коммерческого успеха и др. Совокупность значений различных параметров определяет состояние объекта, например, пакета работ в проекте или отдельного проекта в программе.
Виды связей в проектных системах
Связь в системе – это то, что преобразует выход одного компонента во вход другого. В системах различают структурные и причинно-следственные связи. Структурные связи подразделяются на статические и динамические [Жилин, 2010].
Статическая связь в проектных системах проявляется посредством нормативной документации, устанавливающей связь между процессами, а также WBS, RBS, OBS и других структурных построений. Статические связи реализуются также в планировании и формировании показателей проектов. Так, плановые сроки, ресурсы и результаты определяют статические связи между разделами плана, так как в этом случае фиксируются их значения и предполагается, что «так может быть» при реализации проекта.
Динамическая связь возникает, когда информация на выходе одних процессов поступает на вход других. Например, информация, созданная в процессе инициации проекта, передается в процесс планирования. Динамическая связь подтверждает жизнеспособность статической и актуализирует ее.
Еще один пример статической и динамической связи в управлении проектами. В процессе планирования проекта устанавливается связь между структурой работ и структурой ресурсов (сколько и какие ресурсы необходимы для выполнения конкретных работ) – это статическая связь. Когда проект начинает исполняться, происходит фактическое поступление ресурсов в подпространства проекта – работы, выделение энергии, массы ресурсов и информации. Связь между ресурсами и работами становится динамической.
Причинно-следственные связи проявляются в разных аспектах. Например, такая связь происходит при практической реализации проектов, когда задержка результатов одних работ (причина) не позволяет начать другие работы (следствие). Причинно-следственные связи между показателями образуются также, когда при исполнении проекта возникнет ситуация, при которой необходимые ресурсы не поступили в полном объеме, и поэтому сроки завершения работ увеличились, цены на ресурсы повысились – возросли затраты и т. д. Изменение параметров одних объектов (причина) ведет к изменению параметров других объектов (следствие).
Структура
Структура – это совокупность элементов, образующих систему, и связей между ними. Системы с большим количеством неоднородных связей являются сложными.
Эффективное управление сложной социально-экономической системой, какой является проект, невозможно без понимания ее структуры. Структуру характеризуют четыре основных аспекта (рис. 5.2):
• многоуровневость или иерархичность;
• мультидисциплинарность;
• многофазность;
• мультисистемность.
Многоуровневость или иерархичность – «вертикальное» рассмотрение проекта, состоящее из элементов, находящихся в определенном соподчинении. Иерархичностью характеризуются работы проекта, организация, риски, ресурсы и др.
Мультидисциплинарность – «горизонтальное» рассмотрение проекта, показывающее наличие на каждом уровне иерархии ряда функциональных и естественно-научных (производственных) направлений, различающихся характером используемых знаний, технологий, средств и предметов труда.
Многофазность – наличие этапов развития элементов горизонтали, предполагающих их переход из начальных состояний на более развитый уровень по мере движения во времени.
Мультисистемность – наличие в проектах определенного количества подсистем, каждая из которых характеризуется многоуровневостью, мультидисциплинарностью и многофазностью.
Рис. 5.2. Структура проектной системы
Источник: [Мир управления проектами, 1993].
Структурообразующие связи между элементами системы, как уже отмечалось, могут иметь разный характер. Можно рассмотреть также вариант распространения влияния информации на входе в проектную систему между элементами (рис. 5.3). Для системы проекта А информация сразу поступает на все элементы и одномоментно распространяется по всей системе. Например, это новые цены на ресурсы, используемые во всех работах, измененения в законодательстве и другие входные сигналы, вносящие изменения в процессы соответствующих элементов. В системе проекта В информация первоначально поступает одному элементу, влияет на его выход, далее поступает на вход связанного с ним следующего элемента и т. д.
Рис. 5.3. Типы взаимосвязей элементов в структуре проектной системы [Анфилатов, Емельянов, Кукушкин, 2002]
Среда проекта
Среда – множество объектов вне данной системы, влияющих на систему. Проект находится в среде, которая оказывает на него влияние. Причем частью среды является так называемая надсистема (или «старшая» система, суперсистема), часть которой – сам проект.
Для национальных проектов это федеральное правительство, для региональных проектов – соответствующие региональные органы, для корпоративных проектов – компания.
Задача заключается в том, чтобы понять взаимоотношения проекта со средой. Эти взаимоотношения реализуются посредством внешних связей. Определение внешних связей необходимо, с одной стороны, для относительного отделения системы (проекта) от среды, с другой – для установления взаимодействия с этой средой.
Цели
Цель – это желаемое состояние или набор состояний, которые должны быть достигнуты в определенный период функционирования системы.
Цель определяется «старшей» системой, для которой данная система является элементом.
Можно рассмотреть цели двух видов: цель-результат и цель-направление. Цель-результат – это конкретное количественно выраженное желаемое состояние. Цель-направление не имеет количественного фокуса и предполагает движение к новому качественному состоянию. Оно может иметь многоплановую ориентацию, которую трудно выразить конкретными и точными (с узким интервалом значений) показателями [Анфилатов и др., 2002].
К формулировке целей предъявляются определенные требования: измеримость, конкретность, достижимость, согласованность, гибкость, приемлемость. Для проекта «старшая» система определяет цели через требования к результатам, срокам, ресурсоемкости. Цели проекта выражаются при помощи определения уровней соответствующих показателей, в целом характеризующих желаемое качество проекта, понимаемое как совокупность его существенных свойств.
Системный подход к управлению проектами в значительной степени заключается в рассмотрении проекта как элемента суперсистемы и его взаимодействия со средой.
Процесс как элемент системы управления проектами
Процесс – от лат. «processus» – продвижение. Согласно Большому энциклопедическому словарю процесс – а) последовательность, смена явлений, состояний в развитии чего-нибудь; б) совокупность последовательных действий для достижения результата.
Согласно теории систем процессом называется изменение качества объекта во времени или совокупность состояний системы, упорядоченных по параметру времени.
С позиций проектного подхода процесс – это элемент системы управления проектами. Согласно PMBOK
управление проектами состоит из 42 процессов, объединенных в 5 групп. Там же отмечено, что процесс – комплекс действий и деятельности, осуществляемых для достижения предопределенного результата, продукта или услуги. Процесс характеризуется входом, техникой, инструментами и результатирующим выходом.
Таким образом, процесс в управлении проектами можно определить как комплекс действий для получения последовательных состояний в решении определенной функциональной задачи по созданию уникального результата, продукта или сервиса.
Процессы управления проектами связаны между собой и представляют систему, в которой выход (результат) одного процесса является входом (информационным условием начала) другого (рис. 5.4). Процесс преобразует вход в выход в соответствии со своим функциональным предназначением.
Рис. 5.4. Процесс как преобразование входа в выход
Можно выделить прямые и обратные связи между процессами, а также связи непосредственные и опосредованные (рис. 5.5). Например, информация процесса А передается процессу B, который не может работать без этой информации, – связь прямая. В то же время результаты процесса B могут учитываться в процессе А – связь обратная. Между процессами А и B нет других процессов – связь непосредственная. Те же связи между процессами B и С. Связь между процессами А и С осуществляется через процесс B – она опосредованная. Очевидно, что сбой в одном процессе ведет к сбою в других процессах.
Рис. 5.5. Взаимосвязь процессов управления проектами
Показатели как элементы проектной системы
Системный подход к управлению проектами проявляется также в учете взаимосвязей показателей проекта: объемов работ (при требуемом качестве – Q), сроков выполнения (T) и количества потребляемых ресурсов (R). Эти показатели могут характеризовать требования к проекту, а также его фактические результаты.
Рассмотрим матрицу взаимосвязи показателей проекта (рис. 5.6) [Аньшин, 2011].
Как можно заметить, данная матрица является симметричной. На ее основе могут быть определены относительные показатели:
• R/Q – ресурсоемкость;
• R/T – ресурсоинтенсивность;
• Q/T – периодоотдача;
• Q/R – ресурсоотдача;
• T/R – ресурсопериодичность;
• T/Q – периодоемкость.
Рис. 5.6. Матрица взаимосвязи показателей проекта
Показатель ресурсоемкости (R/Q) – количество потребленных ресурсов в расчете на единицу объема произведенных работ по проекту (например, количество бетона на 1 километр дорожного полотна; количество рабочих (человек или человеко-часов) на 1 кв. метр строящегося здания) (обратный показатель – ресурсоотдача – характеризует объем работ или продукции на единицу потребленного ресурса).
Показатель ресурсоинтенсивности (R/T) – количество потребленных ресурсов в расчете на единичный временной период внутри общего периода разработки проекта (например, потребление ресурсов в расчете на один день, неделю, месяц при общей длительности проекта один год) (обратный показатель – ресурсопериодичность – длительность периода проекта, необходимого для «освоения» единицы ресурса).
Периодоотдача (Q/T) – объем работ в расчете на единичный период внутри общего периода разработки проекта (например, количество километров законченного дорожного полотна в расчете на один день; количество кв. метров жилья за один год при реализации долговременной программы жилищного строительства при реализации проекта создания нового города) (обратный показатель – периодоемкость – характеризует период, необходимый для производства единиы работ проекта).
Рассмотренные коэффициенты выполняют роль связей (структурных, динамических и причинно-следственных) между элементами в системе показателей проекта, если в качестве этих показателей рассматривать результаты (а первоначально – требования) проекта (объем законченных работ с учетом их качества, время его разработки и количество затраченных ресурсов). Зависимости между показателями через коэффициенты не так очевидны, как кажется на первый взгляд. Сложность взаимосвязей обусловлена тем, что, анализируя взаимосвязь между парой любых перечисленных показателей, нужно всегда учитывать, как ведет себя третий показатель.
Рассмотрим коэффициент ресурсоемкости проекта (R/Q). Его рост при заданных сроке и объеме работ по сравнению с планом означает снижение эффективности использования ресурсов. Но рост ресурсоемкости будет оправдан, если ставится цель сокращения сроков проекта. В этом случае увеличение количества ресурсов, направленных в проект, не приведет к увеличению общего объема работ, но проект будет выполнен раньше. При этом показатель ресурсоинтенсивности также будет расти.
R/T – при заданном объеме работ рост ресурсоинтенсивности по сравнению с планом означает снижение эффективности, но он может быть оправдан при необходимости увеличения объемов работ за период. При этом ресурсоемкость (R/Q) не должна увеличиваться при прочих равных условиях.
Q/T – при заданном объеме ресурсов снижение данного показателя по сравнению с планом означает снижение эффективности. Оно может произойти по причине увеличения сроков, а также при снижении объемов работ. Снижение показателя периодоотдачи может быть оправданно при уменьшении объема ресурсов по сравнению с планом. При этом снижается ресурсоинтенсивность. Рост ресурсоемкости – отрицательная тенденция.
Системная модель управления проектами
Системная модель управления проектами разработана проф. В. И. Воропаевым [Математические основы управления… 2005].
Данная модель позволяет представить управление проектами в комплексном и структурированном виде.
Модель содержит три укрупненных блока: субъекты управления, объекты управления, процесс управления. Каждый из этих блоков состоит из нескольких частей.
• Субъекты управления:
? участники проекта (Z);
? команда управления проектом (L).
• Объекты управления:
? проекты и программы (Q);
? фазы жизненного цикла объектов управления (C).
• Процесс управления:
? уровни управления (T);
? функциональные области управления (S);
? стадии процесса управления (F).
Рассмотренные части блоков могут быть представлены развернутым комплексом элементов.
Участники проекта (Z):
инвестор Z1, заказчик Z2, генконтрактор Z3, генподрядчик Z4, исполнители Z5, соисполнители Z6, прочие Z7.
Команда управления проектом (L):
менеджер проекта L1, члены команды L2, функциональные менеджеры проекта L3.
Проекты и программы (Q):
проекты Q1, программы и портфели Q2, организации Q3, системы Q4.
Фазы жизненного цикла объектов управления (C):
концепция C1, разработка C2, реализация C3, завершение C4.
Уровни управления (T):
стратегический (весь жизненный цикл) T1, годовой T2, квартальный T3, месячный T4, декадный T5, суточный T6, сменный T7.
Функциональные области управления (S):
управление
• предметной областью S1;
• по временным параметрам S2;
• стоимостью S3;
• качеством S4;
• рисками S5;
• персоналом S6;
• коммуникациями S7;
• контрактами S8;
• изменениями S9;
• прочие S10.
Стадии процесса управления (F):
инициация F1, планирование F2, организация и контроль выполнения F3, анализ и регулирование F4, закрытие F5.
Все блоки и элементы модели находятся в тесной взаимосвязи и взаимозависимости (рис. 5.7).
Рис. 5.7. Системная модель управления проектами
На основе системной модели может быть осуществлена вертикальная, горизонтальная и смешанная интеграции элементов с целью постановки требуемых задач управления проектами.
Вертикальная интеграция – позволяет описать задачи, решение которых предполагает взаимодействие уровней (блоков) модели. Например, весь комплекс задач, необходимых инвесторам проекта, может быть представлен записью: (Z1, L, Q, C, T, M, S, F).
Горизонтальная интеграция – определяет комбинации элементов отдельного уровня модели. Например, задача, предполагающая рассмотрение всех процессов управления проектом, может быть описана как: (F1, F2, F3, F4), задача рассмотрения функциональных областей управления расписанием, стоимостью, человеческими ресурсами, контрактами: (S2, S3, S6, S8).
Смешанная (горизонтально-вертикальная) интеграция – наиболее востребована практикой. Здесь комбинации строятся одновременно как между элементами отдельных уровней, так и внутри них. Например, комплексная задача контроля и регулирования всех функциональных областей управления проектом на стадии его реализации может быть выражена записью: (F3, F4, S1, S2, S3, S4, S5, S6, S7, S8, S9, C3).
В целом системная модель может быть полезной в задачах проектирования систем управления крупными проектами, включая концептульное проектирование, разработку нормативно-методической документации, создание комплексов программных средств, системы обучения специалистов.
Реализация системного подхода в проектной сфере в рассмотренных выше аспектах способствует созданию системы стратегического управления проектами.
Общая компоновка проектной системы
Для описания проектной системы, как уже отмечалось, необходимо определить ее компоненты, связи между ними и связи с внешней средой.
Проектная система – это взимосвязанный комплекс компонентов, функционирующий в контролируемом внешнем окружении (рис. 5.8).
Компоненты проектной системы – это:
• цели организации;
• целевые установки проектных единиц и сами эти единицы (пакеты работ, проекты, программы, портфели);
• требования к проектным единицам;
• ресурсы;
• результаты;
• управляющий блок, включающий информационные системы, методологии и стандарты, проектные активы.
Рис. 5.8. Проектная система: общая компоновка
Рассмотрим логику взаимосвязей во внутреннем круге, изображенном на рис. 5.8. Проекты инициируются для достижения целей, возникающих в тех или иных организационных образованиях. Это могут быть министерства и ведомства федерального правительства или региона, фонды, компании. Определяя свои цели и пути их достижения, данные организации рассматривают проекты в качестве средства, позволяющего получить необходимый результат.
Далее возникает целевая установка (видение, миссия, собственно цели; подробное рассмотрение в п. 5.2) самого проекта (программы), имеющего специфическое предназначение. Из целевых установок вытекают требования по осуществлению определенного объема работ, их качеству, срокам, затратам. Для выполнения проектных требований необходимо использование соответствующих ресурсов. Ресурсы поступают на входы работ и проектов и преобразуются в результаты, которые, в свою очередь, также обладают системными свойствами, – на выходе.
Инициирующая проект организация, анализируя полученные результаты, а также при изменении своих собственных целей, корректирует целевые установки проекта.
Важным элементом проектной системы является управляющий блок. Этот блок формирует методологию проектного управления, информационные системы, осуществляет обучение и оценку персонала и другие функции. Описанная проектная система находится во взаимодействии с внешним окружением. Проектная система должна контролировать это окружение, т. е. его структуризацию, анализ, коммуникации и управление проектными единицами, с учетом данных аспектов.
Функционирование компонентов проектной системы реализуется с помощью рассмотренных выше процессов и связей между ними.
5.2. Стратегическое управление проектами
Понятия стратегического менеджмента в управлении проектами
В основе стратегического управления проектами лежит общая методология стратегического менеджмента, которая адаптируется к процессу управления проектами и имеет свои особенности. Можно рассмотреть два аспекта: стратегический менеджмент самостоятельно существующих проектов (спортивные и культурные мероприятия, политические форумы, научно-технические, строительные и другие объекты) и проектов в составе организаций (коммерческие, некоммерческие, государственные организации).
Стратегический менеджмент самостоятельных проектов
Как следует из названия рассматриваемой области менеджмента, ключевым является понятие «стратегия». Сам термин имеет военное происхождение. Он исходит от греч. слов «stratоs» – войско и «аgo» – веду. Кстати, нужно отметить, что одними из первых проектов, с которыми столкнулось человечество, были военные операции. Поэтому в некотором смысле можно сказать, что стратегические задачи впервые решались в военных проектах и стратегический менеджмент брал свое начало именно в них. Крупные операции являлись даже в большей степени программами, чем просто проектами, они требовали координации действий многих фронтов и армий, обеспечения боеприпасами, горючим, транспортными средствами, продовольствием, медикаментами и другими ресурсами. Не случайно одним из первых глубоко исследовал стратегию теоретик войны Карл фон Клаузевиц. Он отделил стратегию от тактики. Тактика, по Клаузевицу, – это организация и ведение отдельных боев, а стратегия – увязка их с общей целью войны. Он определил элементы стратегии, но выступал за целостное ее рассмотрение, отмечая, что «если бы кто-нибудь вздумал вопросы стратегии толковать по этим элементам, то это была бы самая неудачная мысль, какая только может прийти в голову, ибо чаще всего в конкретных военных операциях эти элементы самым тесным и сложным образом сплетаются между собою» [Клаузевиц, 2010]. Данное соображение Клаузевица в полной мере справедливо к созданию и реализации стратегии современных проектов в любых сферах их реализации.
В теории менеджмента имеется несколько определений стратегии, в которых рассматриваются разные элементы стратегического процесса.
Стратегия – один из нескольких наборов правил принятия решений относительно поведения организации; системная концепция, связывающая и направляющая рост сложной организации; направления, в соответствии с которыми компания будет расти и развиваться. Стратегия – средства достижения результатов, цели представляют собой результаты (Ансофф, 1999, с. 159–161). Стратегия – это план, интегрирующий главные цели организации, ее политику и действия в некое согласованное целое (Минцберг, Куинн, Гошал, 2001, с. 23). Иногда стратегия определяется посредством элементов или направлений: товарно-рыночное инвестирование, предложение потребительской ценности, активы и компетенции и др. [Аакер, 2007, с. 21–26].
Большинство этих понятий при соответствующей корректировке можно применить и к проектам. Обобщая их, можно определить стратегию проекта как способ достижения его целей с учетом миссии и видения проекта.
Создание стратегии проекта предполагает решение трех основных задач:
• определение миссии и статегического видения;
• определение целей;
• разработку функциональных стратегий как способов достижения целей.
Применительно к проекту миссия – это то, ради чего затевается проект, его предназначение, та польза, которую он принесет, в самом общем ее рассмотрении. Миссия может быть определена для проектов самых различных уровней и масштабов: от национального до компании и даже проектов отдельных лиц.
Миссия проекта должна отличаться от миссии актива, который будет функционировать после завершения проекта. В проекте должны быть разработаны уникальные решения, связанные с созданием актива. Миссия проекта как раз и заключается в создании таких решений. Проект должен обеспечить уникальность решений – в этом его миссия.
Для иллюстрации данного тезиса приведем ситуацию, когда первоначально рассматриваются несколько альтернативных конкурирующих проектов. Допустим, в конце концов для разработки должен быть выбран один проект. Менеджер каждого конкурирующего проекта должен разработать план и указать, в чем состоит уникальность и эффективность именно его проекта. Предположим, что эти проекты имеют разные свойства, такие как экономичность, сроки, технические параметры. Причем каждое проектное предложение имеет свои особенности: один проект позволит дешево произвести продукт, другой может быть завершен в рекордно короткие сроки, третий позволит получить уникальные технические характеристики. Миссия первого проекта – «Мы обеспечиваем экономичные технические решения», второго – «Мы обеспечиваем опрежение конкурентов по срокам», третьего – «Мы создаем уникальные технические решения». В данном случае миссия формулируется для заказчиков проекта.
Стратегическое видение – это долгосрочный желаемый образ будущего, стремление чего-то достичь; то, куда следует идти. Есть афоризм, приписываемый Джонатану Свифту: «видение – это искусство увидеть невидимое».
Видение проекта – это образ будущего, каким его представляют владельцы, участники и основные стейкхолдеры. Типична ситуация, когда у каждой из перечисленных категорий и отдельных лиц существует свое видение. Поэтому возникает задача достижения консенсуса и подготовки единого заявления о видении проекта или программы.
Учитывая, что проект по своей сути – это прогнозная субстанция будущего, т. е. он вообще не существует на момент формирования видения, то «вольности» в предсказании того, что будет представлять собой проект на момент его завершения, могут быть достаточно велики.
Когда разрабатывается видение проекта, его следует формировать по следующим основным направлениям:
• окружение, в котором будет существовать созданный в проекте актив; окружение весьма многоаспектно: политическая система, внешнеполитическое окружение, различного рода доктрины государства, в том числе военная; финансовые ресурсы, конкретные люди и т. д.;
• технические и производственные решения, которые будут существовать к моменту завершения проекта;
• технические и производственные средства разработки проекта;
• методы организации работ;
• ресурсы, которые будут использованы в процессе разработки проекта.
В методологии стратегического менеджмента есть понятие «визионерский глаз, используемое при формировании видения [Маурик, 2002]. Это метафора, которую можно применить и к проекту, т. е. рассмотреть «визионерский глаз» проекта.
«Визионерский глаз» проекта (рис. 5.9) смотрит вперед и видит то, к чему мы стремимся в проекте. Глаз связан со зрительным нервом, который посылает сигнал в мозг, анализирующий и вырабатывающий отношение к тому, что видит глаз. Если теперь от физиологии перейти в область стратегии проекта, то речь пойдет об анализе будущей картины, о выработке целей, планов и действий по их достижению.
Рис. 5.9. «Визионерский глаз» проекта [Маурик, 2002]
Цели проекта – это конкретные результаты, которых хочет добиться инициатор проекта с учетом мнений стейкхолдеров.
Вместе с тем цель – это критерий успеха или неудачи. С этих позиций можно говорить об элементах цели: показателе, способе измерения и задаче (Ансофф). Показатель характеризует критерий, по значению которого судят об успехе проекта. Способ измерения показателя – прием, при помощи которого исчисляется показатель (среднее значение, темп роста). Задача – направление изменения показателя, которое хотелось бы получить (минимизация, стабилизация, максимизация и др.).
Можно говорить о системе и иерархии целей проекта. Цели могут быть рыночными, инновационными, финансовыми и др. (П. Друкер). Возможно выделение целей разных уровней, т. е. они могут выстраиваться в определенной иерархии. Например, рентабельность капитала проекта может быть целевым показателем, на который влияют оборачиваемость активов, рентабельность продаж, мультипликатор капитала.
В теории сбалансированных показателей, например, выделяются показатели: финансовые, работы с клиентами, операционной деятельности, обучения и развития персонала. Они могут быть рассмотрены на различных уровнях: корпорации, бизнес-единиц, отдельных работников. Такое преобразование показателей и переход от показателей верхних уровней к более низким называется каскадированием.
В некоторых проектах ставятся весьма амбициозные и сложные цели. Например, в проекте «Аполлон» была обозначена цель полета человека на Луну и возвращения на Землю. С учетом технологий начала 60-х годов прошлого века задача казалась нерешаемой. Она была представлена с позиций «обратного ракурса», т. е. определения комплекса и последовательности задач, которые нужно решить для достижения главной цели. Иными словами, сначала был рассмотрен процесс обратного движения от конечной цели к промежуточным (метафора – как бы последовательные прыжки лягушки в обратном направлении; на приведенном ниже графике – сверху вниз), а затем, наоборот, – от настоящего к будущему (снизу вверх) (рис. 5.10).
Рис. 5.10. «Прыжки лягушки» как образ структуризации во времени целей проекта [Маурик, 2002]
Функциональные стратегии проекта
Разные цели и аспекты реализации проекта требуют применения соответствующих подходов и концепций, а в целом способов, которые определяют содержание так называемых функциональных (деловых) стратегий. Это следующие основные стратегии:
• маркетинговая стратегия проекта – концепция продвижения проекта навстречу потребителю (в том числе заказчику) на разных фазах его жизненного цикла;
• финансовая стратегия проекта – концепция привлечения денежных средств для реализации проекта;
• инвестиционная стратегия проекта – концепция вложения денежных средств для создания активов проекта;
• инновационная стратегия проекта – концепция использования, создания и внедрения новшеств в проекте;
• ресурсная стратегия проекта – концепция обеспечения проекта необходимыми ресурсами;
• стратегия рисков – концепция определения допустимого уровня рисков в сопоставлении с вознаграждением за риск, планов и ответных действий при активации рисковых событий;
• операционная стратегия – концепция практического осуществления проекта, производственных действий, найма и увольнения персонала, закупок, партнерства и др.
Особенности стратегического менеджмента проектов в компании
Схематично место проектов в стратегическом управлении компанией представлено на рис. 5.11.
Рис. 5.11. Место проектов в стратегическом процессе организации
Как видно из рис. 5.11, проекты осуществляются для реализации стратегий компании. Эти проекты при их завершении создают возможность проведения изменений, ведущих к формированию нового состояния организации. В свою очередь, это новое состояние приведет к определенным результатам (выгодам, бененфитам) для компании в целом. Через обратную связь результаты могут корректировать цели на следующем этапе развития.
Учитывая, что проекты вытекают из необходимости реализации стратегий организации, рассмотрим общие моменты их взаимосвязи, а также структурные и продуктивно-рыночные аспекты формирования проектов (рис. 5.12).
Рис. 5.12. Стратегический аспект структуры проектов компании
Проекты, ориентированные на стратегию
Рассмотрим стратегические подходы, ведущие к определенным проектам и идеям их формирования [Аакер, 2007]:
• стратегическое видение;
• динамическое видение;
• стратегический дрейф;
• стратегические намерения;
• стратегическая гибкость.
Подход стратегического видения
В соответствии с данным подходом компания определяет долгосрочный желаемый образ, к которому она стремится. Этот образ фиксируется на определенный промежуток времени. Если компания ориентируется на долгосрочное видение, то она должна представлять последовательность проектов, которые будут запускаться в разные годы периода, для которого это видение существует. Проекты, реализующие данную стратегию, являются, с одной стороны, долгосрочными, а с другой – представляют некоторую цепочку во времени (рис. 5.13). Они должны обладать свойством дополнительной синергии.
Рис. 5.13. Цепочка проектов стратегического видения
Недостаток данной стратегии – ошибочное видение, недоучет изменения среды функционирования компании.
Подход динамического видения
Подход основан на прогнозе смены парадигм в будущем. Проекты действующей парадигмы являются основными, но в преддверии новой парадигмы упреждающе запускаются новые проекты, которые как бы набегают на действующие. Их можно назвать «перекрывающей волной» проектов (рис. 5.14).
Рис. 5.14. «Перекрытие» проектов динамического видения
Подход стратегического дрейфа
В данном случае компания оперативно реагирует на появляющиеся возможности, приносящие доход. Проекты возникают по мере выявления таких возможностей. Поскольку возможности могут быть самыми различными, то же касается и проектов. В большей степени проекты в такой ситуации окажутся краткосрочными и во многом слабо связанными друг с другом. По сути, данные проекты являются проектами быстрого реагирования.
Подход стратегических намерений
Подход дополняет стратегию стратегического видения. В основе стратегии лежит амбициозная цель, на достижение которой направлены усилия всех сотрудников компании. Особенности подхода состоят в:
• инновационности развития;
• конкретизации видения во времени;
• понимании содержания успеха и способа его достижения.
Проекты стратегических намерений должны быть релевантными стратегии, быть ориентированными на соответствующий временной горизонт, отличаться инновационностью.
Подход стратегической гибкости
Данный подход возникает в связи с неопределнностью и ненадежностью прогнозов. Одним из известных способов снижения риска при неопределенности является диверсификация. При использовании этого подхода компания диверсифицирует свою деятельность по разным направлениям бизнеса. Компания начинает заниматься разными видами экономической деятельности, работать на разных рынках и т. д. Соответственно появляются проекты «гибкой диверсификации», при этом требуются различные компетенции для их разработки и коммерциализации. Возникает угроза распыления инвестиционных ресурсов и появления неудачных проектов вследствие отсутствия опыта, ресурсов, глубокого понимания бизнес-направления.
Бизнес-структурные проекты
В зависимости от привлекательности рынков и силы бизнеса различных бизнес-единиц компании проекты могут обеспечивать различный темп роста бизнеса, по-разному влиять на конкурентную позицию этих единиц.
Проекты роста
Проекты левого верхнего угла матрицы McKinsey (матрицы General Electric) (табл. 5.1), а также проекты, развивающие позицию «звезды», в матрице Бостонской консалтинговой группы (табл. 5.2).
Проекты «звезды» развивают продукт, по которому компания имеет высокую долю на рынке и рынок которого растет высокими темпами. Проекты левого верхнего угла матрицы McKinsey характеризуются высокой (средней) рыночной привлекательностью и высокой (средней) силой бизнеса. Наличие таких проектов определяет хорошие перспективы дальнейшего роста бизнес-единиц компании.
Таблица 5.1
Матрица McKinsey
Таблица 5.2
Проектная интерпретация матрицы бостонской консалтинговой группы
Проекты удержания позиций
Проекты, являющиеся ответом на вызов конкурентов или/и ухудшения действия факторов внутренней и внешней среды.
Проекты восстановления
В ряде случаев и в отдельные периоды компании резко снижают инвестиции в те или иные направления деятельности. Это может привести к утрате конкурентных позиций. В случае появления новых возможностей может возникнуть необходимость их восстановления. Проекты восстановления могут возникать при смене собственников, изменении бизнес-стратегии.
Проекты «сбора урожая»
Малые проекты, применяющиеся в поддержание требуемого уровня денежных потоков.
Продуктивно-рыночные проекты
Данная группа проектов вытекает из способов роста активов, поведения компании на рынках, создания новых продуктов.
Рассмотрим три типа роста активов: органический, экстернальный (внешний), интегративный. Органический рост происходит за счет создания новых активов (физическое создание новых мощностей). Экстернальный связан с присоединением к компании уже существующих активов, что реализуется посредством слияний, поглощений, создания совместных предприятий и других форм. Интегративный рост связан со вступлением компании на временной основе в альянсы и инновационные сети с целью создания новшеств на основе временного объединения своих инновационных и производственно-технологических компетенций с другими компаниями и разработки на этой основе новых продуктов и процессов (как правило, на предконкурентной стадии, но не только).
Для иллюстриции возникающих при этом проектов рекомендуется использовать куб, стороны которого представляют тип экономического роста, характер рыночного продвижения и способ развития продуктов (предлагается модификация матрицы Ансоффа посредством добавления к ней третьего измерения) (рис. 5.15) [Аньшин, 2011]. Куб можно разделить на 12 малых кубиков (при двух позициях на двух осях и трех – на одной).
Рис. 5.15. Продуктивно-рыночный куб проектов
Например, кубик (2.1.1) представляет комплекс проектов расширения присутствия на старом рынке с новым продуктом на основе органического роста, кубик (2.1.2) рассматривает проекты также для старого рынка и нового продукта, но на основе слияний и поглощений, а кубик (2.1.3) – то же, но на основе интегративного роста.
5.3. Методика КУРО формирования стратегического «меню» проектов
Для комплекса проектов, которые далее подвергаются рассмотрению и отбору для разработки, может быть использована специальная методика – КУРО (проекты-компенсаторы, усилители, реализаторы, отражатели) [Аньшин, 2011].
Общая идея методики заключается в движении от процесса декомпозиции целей компании в разрезе цепочек создания ценности (рис. 5.16) к определению целевых разрывов и проектов по их преодолению в упомянутых цепочках (рис. 5.17).
Рис. 5.16. Декомпозиция целей в разрезе цепочек создания ценности
Рис. 5.17. Разрывы компетенций и проекты
Таблица 5.3
Сводная таблица методики КУРО
Важной частью методики КУРО является проведение модифицированного SWOT-анализа.
Модификация SWOT-анализа касается следующих моментов:
• использования метода Дельфи при формировании SWOT-составляющих с балльным оцениванием их значимости;
• привязки SWOT-составляющих к элементам цепочки создания ценностей;
• формирования проектов по наиболее значимым SWOT-составляющим в разрезе элементов цепочки создания ценностей.
Можно рассмотреть следующие шаги методики:
1. Для проведения SWOT-анализа необходимо сформировать пул экспертов, которые имеют достаточно глубокое представление о компании, перспективах ее развития по отдельным направлениям деятельности, процессам и звеньям цепочки создания ценности.
2. Эксперты могут работать изолированно (метод Дельфи) или совместно (метод мозговой атаки).
3. Перед каждым экспертом ставится задача сформулировать составляющие силы, слабости, возможностей и угроз.
4. Информация экспертов обобщается и составляется сводная SWOT-таблица.
5. Сводная SWOT-таблица доводится до каждого эксперта. Эксперты должны дать оценку в баллах (например, по 100-балльной шкале) каждой позиции силы, слабости, возможностей и угроз.
6. Ранжирование элементов SWOT-позиций по результатам экспертизы, выявление наиболее критичных и существенных.
7. Разработка экспертами проектов по каждой SWOT-позиции в разрезе цепочек создания ценности с использованием процедуры метода Дельфи, включая балльную оценку проектов экспертами:
• слабые SWOT-позиции – проекты-компенсаторы (К);
• сильные SWOT-позиции – проекты-усилители (У);
• SWOT-позиции «возможности» – проекты-реализаторы (Р);
• SWOT-позиции «угрозы» – проекты-отражатели (О);
8. Обобщение информации по проектам и создание пула (меню) проектов для последующего рассмотрения при формировании портфеля проектов.
Резюме
Проекты, программы и портфели проектов – это системные образования. Они состоят из элементов, связи между которыми имеют структурный и причинно-следственный характер.
Управление проектами состоит из ряда процессов, которые являются его компонентами, находящимися во взаимодействии. Выходы одних процессов служат входами других, что определяет в том числе системный характер управления проектами.
Результаты проекта также находятся во взаимосвязи, что иллюстрируется матрицей взаимосвязей показателей проекта.
Разработка стратегии проекта предполагает формирование видения, миссии и функциональных стратегий, важнейшие из которых – маркетинговая, финансовая, инвестиционная, ресурсная и операционная.
Проекты являются средством реализации бизнес-стратегии компании.
Тип этой стратегии влияет на проектную структуру организации. Можно выделить ряд групп проектов организации: проекты, ориентированные на стратегию; бизнес-структурные проекты продуктивно-рыночные проекты.
Ключевые термины
Проектная единица как система – комплекс компонентов, взаимодействия и взаимоотношения которых принимают характер взаимодействия для получения сфокусированного полезного результата.
Связи в проектной системе – это то, что преобразует выход одного компонента во вход другого.
Процесс в управлении проектами – комплекс действий для получения последовательных состояний в решении определенной функциональной задачи по созданию уникального результата, продукта или сервиса.
Матрица взаимосвязей показателей проекта – аналитический инструмент, представляющий квадратную матрицу, в строках которой приведены показатели объема работ, сроков и ресурсов проекта; в столбцах – эти же показатели.
Стратегия проекта – способ достижения целей с учетом миссии и видения проекта.
Видение проекта – образ будущего, каким его представляют владельцы, участники и основные стейкхолдеры.
Миссия проекта – то, ради чего затевается проект, его предназначение, та польза, которую он принесет, в самом общем ее рассмотрении.
Цели проекта – конкретные результаты, которые хочет получить инициатор проекта.
Контрольные вопросы
1. Что такое системный подход к управлению проектами?
2. Какие особенности проекта позволяют судить о нем как о системе?
3. Какие бывают связи в проектах и для чего необходимо их учитывать?
4. Как связаны процессы управления проектами?
5. Какие относительные показатели можно сформировать на основе системной матрицы взаимосвязей?
6. Проиллюстрируйте примерами зависимости между показателями системной матрицы взаимосвязей.
7. Что такое миссия проекта?
8. Что такое видение проекта?
9. Приведите примеры функциональных стратегий проекта.
10. Приведите примеры стратегий организации и проектов, реализующих эти стратегии.
Литература
1. Аакер Д. Стратегическое рыночное управление. СПб.: Питер, 2007.
2. Анохин П. К. Философские аспекты теории функциональных систем. М.: Наука, 1978.
3. Ансофф И. Новая корпоративная стратегия. СПб.: Питер, 1999.
4. Анфилатов В. С., Емельянов А. А., Кукушкин А. А. Системный анализ в управлении. М.: Финансы и статистика, 2002.
5. Аньшин В. М. Конспект лекций по курсу «Стратегическое управление портфелем проектов и программой» (читается автором на магистерской программе «Управление проектами: проектный анализ, инвестиции, технологии реализации»).
6. Богданов А. А. Тектология – всеобщая организационная наука. М.: Экономика, 1989.
7. Большой энциклопедический словарь. 2-е изд. М.: Большая советская энциклопедия; СПб.: Норинт, 2002. С. 971.
8. Жилин М. А. Теория систем. Опыт построения курса. М.: Книжный дом «ЛИБРОКОМ», 2010.
9. Клаузевиц К. О войне. М.: АСТ, 2010.
10. Математические основы управления проектами / под ред. В. Н. Буркова. М.: Высшая школа, 2005.
11. Маурик Д. Эффективный стратег. М.: ИНФРА-М, 2002.
12. Минцберг Г., Куинн Дж. Б., Гошал С. Стратегический процесс. СПб.: Питер, 2001.
13. Мир управления проектами / под ред. Х. Решке, Х. Шелле. М.: Аланс, 1993.
14. Энгельс Ф. Анти-Дюринг. Гл. 12 // Маркс К., Энгельс Ф. Собр. соч. 2-е изд. Т. 20. М.: Госполитиздат, 1961.
15. A Guidebook of Project & Program Management for Enterprise Innovation (P2M). Vol. II. S. Ohara, Published by Project Management Association of Japan, 2005.
16. Cleland D. I., Ireland L. R. Project Management: Strategic Design and Implementation. 5th ed. McGraw-Hill Companies, 2006.
Глава 6. Система управления проектами в организации
Изучив данную главу, вы сможете:
• оценивать целесообразность и преимущества внедрения системы управления проектами для определенного предприятия с учетом специфики его проектной деятельности;
• определять выгоды, которые приносит внедрение системы управления проектами сотрудникам организации с учетом их роли в проектной деятельности;
• спланировать проект внедрения системы управления проектами как сложное организационное изменение;
• разработать структуру методологии управления проектами для предприятия;
• реализовать мероприятия по выбору платформы для информационной системы управления проектами и организовать внедрение выбранного программного продукта;
• определить положение проектного офиса в организационной структуре, сформировать список функций проектного офиса с учетом уровня зрелости предприятия в области проектного управления.
6.1. Причины внедрения системы управления проектами в организации
Предприятие, независимо от сферы деятельности и поставленных перед ним стратегических целей, нацелено на успешное функционирование на рынке в течение всего периода планирования. Следовательно, руководству предприятия необходимо не только обеспечить эффективное операционное функционирование, но и заложить механизм развития. Стратегические цели компании достигаются за счет развития долгосрочных отношений с клиентами, использования технологий, повышающих качество обслуживания потребителей и сокращающих издержки, а также развития человеческого капитала в организации. Инструментом реализации значимых изменений в деятельности предприятия является проект. С точки зрения достижения стратегических целей предприятия недостаточно успешного выполнения отдельных проектов, перед компаниями стоят более масштабные задачи по формированию портфеля проектов с учетом стратегии их развития, регулярному мониторингу проектной деятельности для своевременного принятия решений по проектам в портфеле.
Руководители, признающие важность проектного менеджмента для результативного управления предприятием, инициируют внедрение системы управления проектами для решения следующих задач:
1. Обеспечение прозрачности проектной деятельности. Если предприятие характеризуется небольшим объемом проектной деятельности, например, выполняется 5–7 проектов одновременно, на которые в совокупности приходится незначительный объем расходов, то контроль статуса проектов не очень критичен и трудозатратен для руководства – проекты можно поручить проверенным менеджерам, за которыми нужен минимальный контроль. Однако при увеличении числа проектов, выполнение которых для компании важно, для мониторинга статуса их реализации и своевременных предупреждающих и корректирующих воздействий нужно внедрить соответствующие масштабу проектных работ процедуры планирования, отчетности по проектам. Внедряемые процедуры должны обеспечить получение «общей картины» всей проектной деятельности для более детального погружения в статус отдельных проектов, «индикаторы здоровья» которых вызывают беспокойство. Внедрение единых и одинаково понимаемых всеми сотрудниками компании принципов распределения полномочий и ответственности в проектной деятельности также необходимо для повышения эффективности взаимодействия сотрудников. Если операционная деятельность характеризуется постоянно обозначенным кругом функциональных обязанностей сотрудников, которые указаны в должностных инструкциях и положениях о подразделениях, то задачи в рамках проектной деятельности по своей природе уникальны и выражены в том числе во временном назначении на проектные роли (руководитель проекта, заказчик проекта, член проектный команды и т. д.). Чтобы облегчить коммуникации по проекту и сделать работу сотрудников более эффективной за счет понимания, что ожидает от их деятельности менеджмент и каковы принципы оценки их вклада в проект, необходимо зафиксировать в нормативных документах предприятия ролевые модели в проектной деятельности, функции ролей, полномочия участников, критерии оценки эффективности участников проектной деятельности.
2. Уменьшение зависимости успешности проекта от персоналии руководителя проекта. С одной стороны, в условиях кадрового голода в части профессиональной рабочей силы на рынке труда, и с другой стороны, постоянно растущих аппетитов со стороны работника, обладающего хотя бы минимальными знаниями и навыками, для работодателя крайне актуальной становится задача по повышению уровня знаний в сфере проектного управления у сотрудников, которым поручают управление проектами предприятия, а также по уменьшению зависимости успеха отдельного проекта от увольнения, болезни, отпуска руководителя проекта. Проекты не должны выполняться только «на таланте» отдельных менеджеров, когда работодатель становится заложником ситуации: «потеряешь руководителя проекта – потеряешь проект». Ведь естественное желание любого сотрудника предприятия – повышение своей значимости в глазах руководства, в том числе за счет владения информацией по проекту. Система управления проектами на предприятии должна регламентировать обязательные к применению процессы по управлению проектом, которые будут выполнять все руководители проектов, уменьшая, таким образом, количество невынужденных управленческих ошибок. Кроме того, должно проводиться документирование важной для проекта информации, чтобы иметь возможность поручить проект, в случае крайней необходимости, другому менеджеру проектов с минимальными потерями.
3. Накопление внутри компании опыта и знаний по успешной реализации проектов. Каждый выполненный проект должен остаться не только в личном багаже опыта участников проекта, но и послужить накоплению базы знаний компании. Риски, перешедшие в проблемы в ходе проекта, общий состав работ, который пришлось выполнить для получения качественного продукта, выводы о надежности тех или иных поставщиков и подрядчиков могут оказаться полезными в других проектах. Опыт выполнения проекта будет более ценен, если компания реализует типовые проекты, например, сотовый ритейлер выполнит большое количество аналогичных проектов по переформатированию своих точек продаж. Типовые иерархические структуры работ, графики потребности в различных ресурсах, графики поставки материалов должны обновляться с учетом опыта выполнения типовых проектов для минимизации количества будущих ошибок в новых проектах.
4. Внедрение инструментов эффективного управления ресурсами, участвующими в проектной деятельности. Если на предприятии много одновременно выполняемых проектов и потребности в ресурсах для их реализации значимы в общем объеме деятельности компании, то вопрос об обеспечении проектов ресурсами становится напрямую связанным с вопросом финансовой успешности компании. Например, неправильная оценка необходимых человеческих ресурсов для выполнения проектных работ, приводящая к открытию лишних вакансий в подразделениях, влечет к увеличению ФОТ. Если проектно-ориентированная компания, получающая прибыль за счет внешних заказчиков, будет неправильно оценивать свои затраты на выполнение работ, то проекты станут убыточными, приводя к убыточности компании в целом.
5. Повышение точности финансового планирования посредством учета результатов реализации проектов. В случае если проекты для компании являются внутренними, то еще на этапе инициации проекта нужно оценивать и включать в критерии успешности проектов целевые значения ключевых показателей эффективности, которые будут меняться в процессе выполнения проекта. Например, проект по внедрению системы перекрестных продаж должен повысить доходы за счет увеличения объема продаж определенному сегменту клиентов. Подобное увеличение доходов должно учитываться при финансовом планировании.
Таким образом, система управления проектами должна быть связана с процессами по управлению ресурсами предприятия – как человеческими, так и финансовыми, и вклад проектов должен учитываться при планировании как расходов, так и доходов.
6. Укрепление имиджа компании как надежного партнера в области проектной деятельности. В случае если компания выполняет проекты для внешних заказчиков или же привлекает инвесторов для финансирования проектной деятельности, то немаловажным фактором успешности при взаимодействии с партнерами и инвесторами будет готовность предприятия доказать свою состоятельность при выполнении взятых на себя проектных обязательств. В качестве такого доказательства может выступать сертификация компании на определенный уровень зрелости по управлению проектами по общепризнанным методикам оценки уровня зрелости компании в области проектного управления.
Перечисленные преимущества формализации проектной деятельности могут быть получены за счет внедрения системы управления проектами (СУП) в организации.
Система управления проектами, как и любая управленческая система на предприятии, состоит из трех компонентов: нормативной регламентной базы, документирующей обязательные шаги процесса; информационной системы, выступающей в качестве хранилища данных и автоматизирующей процессы; персонала, контролирующего соблюдение процессов и развивающего их по мере повышения зрелости системы. В системе управления проектами три составляющие:
• Методология управления проектами – документированные процессы по управлению проектами, методы и процедуры, которые должны быть использованы сотрудниками предприятия при участии в проектной деятельности.
• Информационная система управления проектами (ИСУП) – специализированное программное обеспечение для управления проектами, выступающее в качестве инструментария для планирования и контроля за параметрами проектов, обмена информацией между участниками проекта, получения отчетности по проектам.
• Проектный офис – подразделение компании или назначенная группа сотрудников, контролирующая исполнение методологии управления проектами и соблюдение регламентов по работе с ИСУП, занимающаяся развитием знаний и навыков персонала в области проектного менеджмента.
6.2. Организационные изменения при внедрении СУП
Внедрение СУП на предприятии является организационным проектом с ИТ-составляющей (в части внедрения ИСУП). Организационный характер проекта обусловлен тем, что он должен изменить принципы управления и взаимодействия в организации в части управления проектной деятельностью.
Организационные изменения при внедрении СУП весьма существенны. При внедрении СУП неизбежен переход от функциональной системы управления к матричной с выделением роли руководителя проекта, которому должны быть делегированы определенные полномочия, в том числе по управлению проектной командой. При этом на руководителя проекта будет возлагаться ответственность не только за успешную реализацию проекта, но и за исполнение обязательных процедур по управлению данным проектом. При внедрении проектного подхода рекомендуется учитывать, что перераспределение полномочий в компании должно осуществляться постепенно, т. е. от функциональной структуры лучше переходить сначала к слабой матрице, чтобы персонал не испытывал лишнего напряжения от «стремительного возрастания количества начальников».
Прозрачность при организации проектной деятельности, являющаяся преимуществом внедрения СУП для руководства, может вызывать скрытое сопротивление со стороны других участников проекта. Поэтому очень важно при внедрении СУП «продать» идею о тех выгодах от ее использования, которые получат все участники проектной деятельности. Например, объяснить руководителям проекта, что при неизбежности постоянного контроля за выполнением проектов у них появляются определенные полномочия по принятию решений; функциональные руководители за счет «продажи» своих сотрудников в проекты будут получать в бюджет своего подразделения дополнительные финансы и смогут распределять их не только между сотрудниками, участвующими в проекте, но и между теми сотрудниками, которым приходится брать на себя больший объем функциональных обязанностей за счет отвлечения в проект части исполнителей подразделения.
Как любое организационное преобразование, внедрение СУП требует вложений ресурсов (трудозатрат сотрудников, финансов на закупку лицензий ПО и аппаратного обеспечения, консалтинговые услуги, тренинги для персонала), и зачастую встает вопрос о его финансово-экономическом обосновании. Самая надежная база для оценки финансовой эффективности внедрения СУП – повышение доли успешных проектов после введениядрения при условии, что организация выполняет типовые проекты. По статистике, полученной российскими консалтинговыми компаниями при исследованиях, введение СУП позволяет на 20 % сократить сроки выполнения проектов, на 6 % – расходование ресурсов, но для каждого предприятия интересны свои данные, а не абстрактные цифры, усредненные по организациям различных отраслей экономики. В ходе внедрения СУП желательно получить «родную» для предприятия статистику о том, какие издержки терпит компания ввиду некачественного управления проектами, в том числе данные по:
• проценту неуспешных проектов, которые не принесли выгод предприятию, ради которых затевались, и затратам на неуспешные проекты;
• количеству дополнительных затрат, вызванных ошибками в планировании и неоцененными рисками;
• убыткам, которые терпит предприятие из-за запоздалого вывода на рынок новых продуктов и услуг, создаваемых в результате проекта.
Однако существование подобной статистики по проектной деятельности уже предполагает достаточно высокий уровень зрелости предприятия в области проектного управления.
Зачастую на начальных этапах внедрения СУП в компаниях нет даже реестра проектов, по которому можно было оценить хотя бы число одновременно выполняемых проектов, тем более нет статистики по числу успешных проектов, по количеству ресурсов, которые требуются для выполнения проектов. В таком случае обещание измеряемого по принятым правилам финансового эффекта от внедрения СУП может быть чрезмерной авантюрой. При этом есть смысл признать, что преимущества от внедрения проектного подхода на предприятии на начальных уровнях зрелости проектного управления будут скорее качественного характера. Оценить успешность или неуспешность внедрения СУП для функционирования предприятия можно будет, основываясь на степени удовлетворенности сотрудников результатами внедрения, с учетом роли сотрудников в управлении компанией.
1. Руководство компании начнет получать оперативную информацию о статусе проектов, будет понятна занятость функциональных подразделений в проектной деятельности. Руководители сэкономят время на осуществление мониторинга проектной деятельности.
2. Руководители проектов получат необходимые им полномочия, при этом будет исключена дублирующаяся отчетность перед заинтересованными в проекте руководителями, упростится задача по эскалации проблем на вышестоящие уровни управления на предприятии.
3. Всем участникам проектной деятельности станет ясна система мотивации за участие в проектах, повысится статус участия в проектных командах. При планировании занятости сотрудников будут признаваться не только функциональные задачи, но и занятость в проектах.
До начала внедрения СУП нужно очень тщательно выявить ожидания в первую очередь руководства от тех преимуществ в управлении, которые необходимо получить от проектного подхода, и сделать внедрение СУП ориентированным на быстрое предоставление тех инструментов управления, которые нужны руководству.
Проект по внедрению системы управления проектами является высокорисковым по следующему ряду причин:
1. Внедрение СУП встретит сопротивление функциональных руководителей. Так как СУП перераспределяет и упорядочивает систему принятия решений по проектам (кто полномочен инициировать проект, какие ресурсы должны быть выделены на проект, какие проекты и в каком объеме будут финансироваться, какие исполнители и внешние компании будут принимать участие в проектах), то она затрагивает интересы функциональных руководителей на всех уровнях управления в организации. Предлагаемые организационные преобразования могут вызывать сопротивление в том числе статусных сотрудников компании, которые будут критиковать предлагаемые изменения, саботировать использование предлагаемых управленческих процедур.
2. Внедрение СУП (как внутренний проект) будет восприниматься внутри компании как проект с низким приоритетом. Данный риск особенно значим для проектно-ориентированных организаций. Все ключевые сотрудники задействованы во внешних проектах, приносящих краткосрочный финансовый эффект, но без их компетентного участия во внедрении СУП и поддержки со стороны ключевых сотрудников новые процессы в области проектной деятельности могут остаться лишь на бумаге.
3. Внедрение новых методов управления не будет обеспечено постоянной поддержкой руководства. Начинать проект по внедрению СУП без поддержки руководства однозначно не рекомендуется, так как все вышеперечисленные организационные преобразования не приобретут должного официального статуса и административного ресурса. Однако отсутствие моментального эффекта от внедрения СУП, чрезмерные ожидания могут вызвать потерю интереса со стороны топ-менеджмента.
6.3. Этапы внедрения системы управления проектами на предприятии
При планировании внедрения СУП нужно использовать апробированные в западных и российских компаниях подходы к реализации организационных изменений:
1. Чтобы процесс стал исполняться, должны быть выделены сотрудники, контролирующие соблюдение регламентов по данному процессу и эскалирующие проблемы на руководство.
2. Руководство должно поддерживать происходящие преобразования не только с формальной точки зрения (утверждать новые процедуры и наказывать за их несоблюдение), но и быть лидером во внедрении новых подходов (соблюдать внедряемые подходы в каждодневной работе, убеждать сотрудников на практических примерах в преимуществах новой системы управления).
3. При формировании процессов «как должно быть» нужно максимально использовать устоявшиеся в компании успешные практики для выполнения данного процесса. Ведь уже внедренные успешные практики учитывают специфику деятельности компании и привычны участникам процесса.
4. До автоматизации процесс должен быть формализован и понятен его участникам.
5. Запрос информации от участников процесса должен проводиться только в том случае, если полученная информация используется для тех или иных решений. Назначение сбора информации должно быть понятно участникам процесса.
6. Любое организационное преобразование должно по возможности быстро приносить выгоды предприятию, иначе будет потеряна административная поддержка проводимых изменений.
С учетом перечисленных подходов рекомендуется организовать внедрение СУП с помощью реализации семи этапов (рис. 6.1).
Этап 1. Организация проекта внедрения СУП. Должна быть сформирована команда проекта, спланированы работы и выделены ресурсы для внедрения СУП.
Этап 2. Обследование проектной деятельности. Необходимо идентифицировать имеющиеся практики организации проектов, узкие места при их реализации. Проводится оценка уровня зрелости компании для того, чтобы после внедрения СУП оценить, какие улучшения были действительно получены.
Этап 3. Разработка методологии управления проектами. Необходимо разработать комплект нормативных документов, описывающих процессы по управлению проектной деятельностью, которые в дальнейшем должны будут исполняться всеми участниками проектной деятельности.
Этап 4. Внедрение информационной системы управления проектами. Нужно выбрать программное обеспечение для автоматизации процессов по управлению проектами, настроить программное обеспечение, разработать регламенты и инструкции для пользователей.
Этап 5. Формирование проектного офиса. Должны быть назначены сотрудники, ответственные за поддержку и координацию проектной деятельности, определено положение проектного офиса в организационной структуре предприятия.
Этап 6. Апробация СУП на пилотных проектах. Для проверки новых для компании инструментов и методов управления проектами, разработанных на предыдущих этапах, рекомендуется несколько типовых для компании проектов реализовать в СУП, чтобы убедиться в удобстве и полезности предлагаемых процедур.
Этап 7. Развертывание СУП на всю проектную деятельность. Должен быть составлен реестр проектов, проектных инициатив, все проекты должны быть переведены в новую систему управления при поддержке проектного офиса.
Этапы внедрения СУП не равноценны по длительности и ресурсоемкости. Они не обязательно выполняются жестко последовательно: часть этапов могут выполняться одновременно, например, организация проекта внедрения СУП и обследование, автоматизация проектной деятельности и формирование проектного офиса. Однако в любом случае выполнение всех этапов – обязательно. Возможно, вместо «классической» ИСУП может быть Excel. Проектный офис будет сформирован посредством возложения на одного из сотрудников дополнительных функций по ведению реестра проектов и контролю формирования проектных документов. Однако все составляющие СУП должны быть созданы и соответствовать друг другу по содержательному наполнению с учетом объемов проектной деятельности и специфики проектов в конкретной организации.
Далее более подробно рассмотрим три составляющие СУП, а именно: методологию управления проектами, ИСУП и проектный офис.
Рис. 6.1. Дорожная карта внедрения СУП —7 этапов
6.4. Методология управления проектами для организации
Методология управления проектами в организации представляет собой утвержденный пакет внутренних нормативных документов, в которых описаны процессы по управлению проектной деятельностью в компании и отражена совокупность практик, методов, процедур и правил. Такая методология обычно строится на базе методов проектного управления международных стандартов управления проектами, зарекомендовавших себя как совокупность «лучших практик» в дисциплине проектного менеджмента. Однако в каждой организации должна использоваться своя, уникальная методология, которая разработана с учетом специфики проектной деятельности предприятия, его организационной структуры и принципов принятия решений, уровня зрелости проектной деятельности.
Как правило, в крупных и средних компаниях есть внутренние стандарты по документированию процессов, с учетом которых нужно будет разрабатывать иерархию и структуру документов, описывающих и проектную деятельность.
Структура внутренних нормативных документов будет определяться также исходя из того, какими объектами управления решено формализовать управление: только проектами, проектами и программами или же проектами, программами и портфелем программ и проектов.
Рассмотрим случай, когда принято решение о стандартизации процессов управления всеми тремя объектами управления в области проектной деятельности: проектом, программой и портфелем. Возможна следующая иерархия проектных документов.
Уровень 1-й:
• Политика по управлению проектной деятельностью. Цель данного документа – описать роль и место проектного управления в управляющих процессах предприятия, определить, по каким критериям деятельность можно отнести к проектной, описать основные принципы управления проектами, программами и портфелем, а также организационную структуру управления проектной деятельностью и элементы системы управления проектами.
• Положения о коллегиальных органах, уполномоченных принимать решения в области проектной деятельности, о подразделениях, осуществляющих координацию и поддержку проектов (о проектном офисе).
Уровень 2-й:
• Регламенты по управлению проектами, программами, портфелем программ и проектов. Регламенты будут содержать карту и описание процессов.
Уровень 3-й:
• Шаблоны документов, которые используются в ходе процессов по управлению проектной деятельностью.
• Технологические схемы по выполнению процессов по управлению проектной деятельностью в ИСУП.
Иерархия документов вполне может быть упрощена, т. е. методология может состоять только лишь из одного регламента по управлению проектами, где шаблоны документов будут приложениями в рамках регламента. В данном случае в этом единственном регламенте нужно описать разделы, которые в более сложной структуре внутренних нормативных документов (ВНД) были бы в ВНД 1-го уровня.
До разработки регламентной базы рекомендуется договориться внутри команды внедрения СУП, в которую входят ключевые заинтересованные лица во внедрении СУП и методологи – разработчики ВНД, о том, какой из международных стандартов в сфере управления проектами станет основой для разработки регламентной базы при описании ролевой модели, областей знаний и списка процессов по управлению проектами. Выбор того или иного стандарта не означает, что нельзя использовать в дополнение те или иные аспекты из других стандартов.
В методологию по управлению проектами рекомендуется включить следующие разделы:
1. Основные понятия проектного управления, такие как «проект», «управление проектами», «этап», «веха», «календарный план проекта».
Не рекомендуется включать в данный раздел описание ролей (для этого будет отведена отдельная глава), описание артефактов, документов, общеизвестных терминов, не специфичных для УП (бизнес-процесс, информационные технологии, система). Аббревиатуры название подразделений организации лучше оформить в виде списка сокращений и вынести в конец методологии.
2. Роли в проектном управлении можно разделить на две группы: постоянные и временные участники.
Постоянные участники проектной деятельности выполняют определенные функции в части управления любым из проектов компании. К таким участникам можно отнести:
• Проектный комитет – коллегиальный орган, принимающий решения о целесообразности реализации проектов. К функциям данного комитета может относиться согласование запросов на значимые изменения проектов, распределение ресурсов между проектами, установка приоритетов по проектам, разрешение конфликтов между проектами, проектной и операционной деятельностью, назначение руководителей на наиболее критичные для предприятия проекты.
• Проектный офис – подразделение, являющееся центром развития и внедрения проектного управления в компании и осуществляющее общий контроль за реализацией проектов предприятия. К функциям проектного офиса может относиться формирование организационных стандартов управления проектами, обеспечение их соблюдения, выполнение функций секретариата проектного комитета.
• Обеспечивающие подразделения, отвечающие за отдельные процессы, связанные с обеспечением проектной деятельности, например, финансовый отдел, выполняющий финансово-экономическую оценку проектных инициатив, учитывающий расходы и прибыль от проектной деятельности при финансовом планировании.
Временные роли в проектной деятельности получают сотрудники компании в рамках конкретного проекта. Назначение на роль в проекте означает возложение определенных полномочий и обязанностей в контексте данного проекта.
Среди временных ролей, которые обязательно должны быть включены в проектную деятельность, можно выделить следующие:
• Заказчик. Типовой минимальный список функций: согласование целей, критериев успешного выполнения проекта, требований к продукту проекта, согласование запросов на изменения в проекте; подготовка предложений о приостановке или прекращении проекта вследствие нецелесообразности или невозможности дальнейшего выполнения; приемка результатов работ, включая промежуточные.
• Руководитель проекта. Типовой минимальный список функций: обеспечение успешного выполнения проекта; организация разработки документов, определяющих цели, задачи, требуемые результаты, общий план выполнения и бюджет проекта; планирование, организация и контроль выполнения работ по достижению целей проекта с требуемыми качеством, затратами и в запланированный срок; своевременная подготовка содержательной части конкурсной и договорной документации по проекту; назначение задач проектной команде (отдельным ее участникам) и контроль за их выполнением; требование от всех участников проектной команды выполнения работ по проекту и своевременной отчетности о текущей ситуации в порученной зоне ответственности; проведение переговоров с внешними компаниями, привлеченными для реализации проекта, и координация работ с подрядчиками и поставщиками; отслеживание рисков проекта и разработка планов реагирования на риски; инициация запросов на изменение содержания, сроков и бюджета проекта; регулярное и своевременное предоставление отчетности о ходе выполнения проекта.
• Куратор проекта. Типовой минимальный список функций: утверждение проектных документов; выделение ресурсов для выполнения проекта, контроль за ходом выполнения проекта; согласование изменений основных параметров проекта; административная поддержка проекта; разрешение конфликтов, эскалированных со стороны руководителя проекта, заказчика.
В список временных ролей также включают участника/исполнителя в проекте, руководителя рабочей группы в составе проектной команды, команду подрядчика, администратора проекта.
3. Классификатор проектов. Классификация разрабатывается, во-первых, для проведения аналитики по общему списку проектов компании с учетом их классификационных признаков. Например, чтобы получить сводную картину по проектам, какое количество ресурсов уходит на проекты развития тех или иных регионов; в проектах с привлечением каких подрядчиков наибольшие отклонения по срокам. Во-вторых, классификация нужна для того, чтобы с учетом значений классификационных признаков проекта использовать специфичные схемы управления данным проектом, описав их в методологии. Например, инновационные проекты требуют более тщательного управления рисками; проекты, заказчиками которых выступают несколько функциональных подразделений, должны управляться посредством управляющего комитета, в состав которого будут включаться функциональные руководители подразделений. Количество аналитических признаков, по которым можно группировать проекты, может быть произвольным, но на практике классификация более чем по 10 признакам является избыточной. Примеры классификационных признаков:
• по стратегической важности проекта (можно присвоить значения А – высший приоритет должны быть выполнены, даже если будет необходимо увеличить количество ресурсов на выполнение; В – стандартные проекты; С – низкий приоритет, проект выполняется только в случае простоя ресурсов);
• по стоимости;
• по жесткости сроков проекта (без возможности сдвига сроков, например, проекты по строительству олимпийских объектов в Сочи, или с возможностью сдвига сроков);
• по длительности (краткосрочный, долгосрочный);
• по уровню участия (по количеству вовлеченных подразделений);
• по опыту исполнения проекта (типовой или инновационный);
• по направлению деятельности (в зависимости от содержания результатов, например, маркетинговый, ИТ, строительный, проект по слиянию и поглощению и т. д.);
• внутренний/внешний проект (выполняется для внешнего или внутреннего заказчика).
4. Процессы управления проектами, упорядоченные по фазам жизненного цикла. Данный раздел является ключевым в нормативной базе. В нем должна быть представлена общая схема процессов по управлению проектами и дано описание каждого процесса (рис. 6.2).
В целом к описанию процессов по управлению проектами можно дать следующие практические рекомендации:
1. Процессы должны быть привязаны к последовательным этапам административного жизненного цикла проекта, который обычно состоит из четырех этапов:
• инициация (процессы, основным результатом которых является оформленное решение о выполнении/невыполнении проекта в компании);
• планирование (процессы по составлению планов проекта, их согласованию и утверждению и получению ресурсов в распоряжение руководителя проекта на основании утверждения проектных документов);
• реализация (процессы по выполнению работ, сдаче результатов работ заказчику, мониторингу работы подрядчиков и проектной команды, отчетности перед заказчиком и куратором проекта о выполнении проекта, управление изменениями в проекте);
Рис. 6.2. Пример карты процессов управления проектами с разбиением по фазам жизненного цикла проекта
• завершение (процессы по оценке успешности проекта, формированию извлеченных уроков, передаче документов в архив компании).
Перечисленные четыре этапа жизненного цикла проекта универсальны и не зависят от сферы деятельности компании.
2. Процессы по возможности должны быть выстроены последовательно, так как последовательная цепочка процессов дает однозначное понимание логики их выполнения.
3. Должна быть заложена возможность контроля выполнимости процесса, т. е. в конце процесса должен быть представлен документ или результат. В противном случае соблюдение процессов нельзя будет проверить силами проектного офиса и невозможно гарантировать, что методология управления проектами соблюдается.
4. Процессы должны быть детализированы в одинаковой степени при описании. Ни в коем случае не надо пытаться сделать количество процессов равным количеству процессов по управлению проектами в PMI PMBOK, например. Не все процессы PMI PMBOK имеют результат, который следует оформлять отдельным проектным документом.
Традиционно при описании процессов используют следующую структуру:
• назначение процесса;
• владелец процесса;
• участники процесса;
• документы на входе процесса;
• документы на выходе процесса;
• подпроцессы;
• описание последовательности шагов процесса или подпроцессов.
Описание процесса также сопровождается диаграммой процесса.
Те проектные документы, которые формируются при выполнении процессов по управлению проектами, должны быть снабжены шаблонами проектных документов в составе методологии.
Регламентная база по управлению проектной деятельностью должна обновляться по мере повышения уровня зрелости организации в области управления проектами. По мере внедрения методов управления проектами будут регламентироваться и вводиться в действие следующие процессы:
• управление пулом ресурсов с учетом занятости сотрудников в проектной и функциональной деятельности;
• мотивация сотрудников с учетом результатов реализации проектов;
• управление программами;
• управление портфелем проектов.
6.5. Информационная система управления проектами как средство автоматизации процессов управления проектами компании
Информационная система управления проектами – внедренное в организации программное обеспечение, используемое для автоматизации проектной деятельности в соответствии с методологией управления проектами, а также комплект сопроводительной документации по работе с данным программным обеспечением.
Существует отдельная ниша на рынке программного обеспечения: инструментарий для автоматизации управления проектами. Подобных программных продуктов довольно много, они отличаются по функциональным и техническим возможностям и соответственно по стоимости.
К базовому функционалу, поддерживаемому значительным числом информационных систем управления проектами, относится автоматизация следующих функций:
• Составление иерархической структуры работ, состава операций в проекте, разработка календарного расписания проекта с учетом взаимосвязей операций, длительности операций, календарей; расчет критического пути проекта; ввод фактических сроков работ, сохранение нескольких версий базового плана проекта, сравнение текущего календарного графика с базовым календарным графиком.
• Ведение справочника ресурсов (различные системы могут поддерживать или все виды ресурсов, включая машины и материалы, или только отдельные виды ресурсов, например, человеческие ресурсы или финансы), назначение ресурсов на операции проектов, анализ потребности в ресурсах на проектах, ввод фактического расходования ресурсов, в том числе табелей учета рабочего времени исполнителей, план-факт анализ расходования ресурсов.
• Ведение реестра рисков по проекту, назначение ответственных за управление рисками, планирование мер реагирования на риски.
• Получение различных видов отчетов по проектам, в том числе с использованием дополнительных аналитических справочников, обеспечение информационного обмена между участниками проекта.
• Поддержка мультипроектного управления, в том числе с точки зрения приоритетности проектов при распределении ресурсов.
• Ведение архива проектной документации.
Приведенный список функционала является основополагающим, многообразие настроек по каждой из функций зависит от конкретного программного продукта. В дополнение к перечисленным функциям в отдельных программных продуктах присутствуют расширенные возможности, например, анализ по освоенному объему, анализ рисков по методу Монте-Карло и т. д. Для того чтобы выбрать программный продукт для автоматизации проектной деятельности на конкретном предприятии, изначально нужно сформировать требования к данному программному продукту.
Требования к программному обеспечению по управлению проектами составляются исходя из уровня зрелости проектного управления, текущей ситуации с развитием ИТ в организации, объема проектной деятельности. При выборе основы для управления проектами рекомендуется проанализировать следующее:
• Внедрена ли на предприятии ERP-система? Если да, то есть смысл в первую очередь рассматривать модули по управлению проектами под внедренную ERP-платформу Если ERP-система не внедрена, то при выборе программного обеспечения логично ориентироваться на отдельные специализированные на автоматизации проектной деятельности программные продукты.
• Каковы требования к количеству рабочих мест в ИСУП? Какие группы пользователей будут работать в ИСУП? Помимо руководителей проектов и администраторов проектов в ИСУП могут быть выделены следующие роли с учетом ролевой модели, изложенной в методологии управления проектами:
? члены проектной команды, которые в системе отчитываются о выполнении проектных работ, трудозатратах на выполнение работ, имеют доступ к проектной документации;
? функциональные руководители, выступающие в качестве владельцев ресурсов, которые в ИСУП назначают исполнителей на работу из числа своих подчиненных, просматривают отчеты о загрузке исполнителей в проектах;
? руководство, пользующееся отчетами с «общей картиной» проектной деятельности;
? сотрудники проектного офиса, контролирующие полноту и своевременность внесения данных в ИСУП проектными командами, получающие аналитические отчеты из ИСУП.
Помимо количества пользователей, которые будут работать в ИСУП, нужно учитывать территориальное расположение предприятия и соответственно физическое местоположение пользователей ИСУП, ИТ-инфраструктуру предприятия, чтобы в результате все пользователи имели необходимый доступ к ИСУП.
• Каковы функциональные требования к ИСУП, исходя из методологии управления проектами? Чем более зрелая организация в сфере управления проектами, тем большее количество процессов в сфере проектной деятельности нужно будет автоматизировать. На начальном уровне зрелости ИСУП можно использовать только для сбора общего реестра проектов и контроля сроков. Более того, на начальных уровнях зрелости в области УП рекомендуется ограничить количество пользователей ИСУП, оставив только сотрудников проектного офиса и собственно руководителей проектов. Если же предприятие уже готово к детальному управлению ресурсами, более того, есть задача по автоматизации процессов в области управления портфелем, то и функциональные требования к ИСУП будут принципиально другими.
Вышеперечисленные требования рекомендуется предоставить для анализа вендорам и консалтинговым компаниям, которые предлагают решения в области автоматизации проектной деятельности на различных платформах.
После формирования требований к ИСУП рекомендуется провести оценку предложений по автоматизации на базе различных платформ и выбор платформы для ИСУП.
Для выбора программного обеспечения рекомендуется изучить предложения, разработанные поставщиками того или иного программного продукта, на соответствие предъявленным базовым требованиям к ИСУП, сформированным на предыдущем шаге. Конечно же, помимо соответствия предъявленным базовым требованиям при выборе платформы для ИСУП будет учитывать и стоимость внедрения и поддержки ИСУП на базе той или иной платформы.
При оценке стоимости внедрения ИСУП на базе различных платформ необходимо учитывать следующие составляющие стоимости внедрения и поддержки ИСУП:
• стоимость самих лицензий на ПО с учетом количества и ролей пользователей;
• стоимость аппаратного обеспечения, которое будет необходимо закупить для установки и поддержки работоспособности ИСУП;
• стоимость внедрения (возможно, будет принято решение о внедрении ИСУП силами внутренней ИТ-службы предприятия);
• стоимость обучения пользователей (опять-таки возможен вариант, что обучение будет проводиться командой внедрения СУП);
• стоимость технической поддержки.
Анализируя предложения по платформам для автоматизации проектной деятельности, многие компании рассматривают возможность использования решения на базе Microsoft Project, что вполне логично, ведь согласно аналитическим отчетам российских, европейских и американских компаний самое распространенное программное обеспечение по управлению проектами – решение на базе Microsoft Project.
Бесспорные достоинства Microsoft Project:
• наличие большого списка функций для автоматизации проектного управления;
• широкая распространенность данного решения, что упрощает задачу по обмену планами-графиками работ с подрядчиками и внешними заказчиками, уменьшает стоимость обучения, упрощает задачу по поиску консультантов по внедрению и специалистов для поддержке ИСУП в ходе промышленной эксплуатации;
• простота и понятность интерфейса;
• доступная ценовая политика на лицензии.
Однако не нужно думать, что решение Microsoft – единственно правильный выбор, так как предприятиям есть смысл рассматривать при внедрении ИСУП решения и от других производителей.
После выбора платформы для ИСУП на основании разработанных требований проводится разработка детальной технической спецификации, которая описывает все необходимые настройки, выполняемые в ИС. В техническом задании на настройку ИСУП обязательно должны присутствовать следующие разделы:
• Списки справочников в системе и список объектов, для которых используются данные справочники. Например, в системе будет вестись справочник подрядчиков, и он будет связан работами проекта в ИСУП, чтобы можно было указать, на какую работу назначен какой подрядчик.
• Список экранных и отчетных форм, которые будут использоваться для ввода и просмотра данных в системе.
• Профили ролей пользователей в системе, набор функций, которые доступны пользователям с данной ролью в системе, и набор объектов, к которым пользователи будут иметь доступ на чтение, редактирование.
Например, роль руководителя проекта в ИСУП характеризуется тем, что пользователи, которым присвоена данная роль в ИСУП, смогут иметь доступ на запись к тем проектам, где они указаны как руководители проектов, смогут просматривать, но не редактировать список ресурсов, смогут назначать ресурсы на работы своих проектов, но не изменять характеристики ресурсов и т. д. Комплект функций, которые могут быть доступны тем или иным профилям, зависит от платформы.
По детальному техническому заданию осуществляется настройка прототипа ИСУП и демонстрация прототипа команде внедрения СУП. Прототип нужен для того, чтобы команда внедрения СУП могла убедиться, что ИСУП поддерживает процессы по управлению проектами, заложенными в методологию управления проектами. По результатам демонстрации прототипа возможны уточнения или дополнения ранее предъявленных функциональных требований и, следовательно, корректировка детального технического задания на настройку ИСУП и самого прототипа.
Настроенная ИСУП должна сопровождаться «классической» необходимой документацией (руководство пользователя и руководство технического администратора) и регламентами работы с ИСУП по ролям участников проектной деятельности.
Руководства пользователей должны быть не только по стандартной функциональности, но и по тем функциям, которые были модернизированы в ходе настройки ИСУП под методологию управления проектами предприятия.
Регламенты работы в ИСУП – принципиальное условие успешного внедрения ИСУП как инструмента планирования и контроля проектной деятельности предприятия. Дело в том, что для соблюдения в ИСУП единых принципов ведения проектов нужно четко прописать необходимый порядок работы пользователей в системе, чтобы обеспечить регулярный информационный обмен между заинтересованными лицами в проекте, требования к детальности планов и фактических данных, периодичности актуализации данных. Регламент работы в ИСУП – это не руководство пользователя, в котором говорится о том, какие манипуляции можно провести в ИС, чтобы добиться того или иного результата. Регламент работы в ИСУП однозначно описывает, кто, в какой момент и какую информацию должен ввести в ИС, и требования к полноте этой информации. Например, в регламенте для руководителя проекта по работе в ИСУП должен содержаться примерно следующий набор действий для фазы планирования:
• После подписания приказа о старте проекта администратор проектного офиса информирует посредством электронного сообщения руководителя проекта о присвоении шифра проекта и о создании пустого проекта в ИСУП с определенным названием.
• Руководитель проекта должен на этапе планирования разработать календарный график проекта, при этом в календарном графике работы ближайшего квартала должны быть детализированы таким образом, чтобы длительность работ была не больше двух недель, не реже чем на каждый месяц должны быть запланированы вехи, которые будут включены в базовый календарный план, на каждую работу должен быть назначен один ответственный из справочника сотрудников в ИСУП.
• После разработки календарного расписания проекта руководитель проекта должен распечатать базовый календарный план по вехам из ИСУП, согласовать его в соответствии с методологией управления проектами, отсканировать подписанный документ, выложить в библиотеку проектных документов и уведомить проектный офис о том, что необходимо зафиксировать базовый календарный план с ИСУП на основании подписанного документа.
Как видно из примера, регламент работы в ИСУП должен обеспечивать единообразие планирования и контроля проектов всеми руководителями проектов для обеспечения получения сводной отчетности.
Для приемки ИСУП в эксплуатацию рекомендуется провести испытания настроенной ИСУП на контрольном примере. При этом, учитывая, что тестируется не разработанное с нуля под заказчика ПО, а настроенная платформа, нужно обращать особое внимание на то, насколько в ИСУП учтены функциональные требования, насколько понятна и удобна в использовании сопроводительная документация.
В ходе приемки ИСУП в эксплуатацию в соответствии с процедурами, принятыми в компании, ИСУП передается группе технического сопровождения предприятия на поддержку наравне с прочим программным обеспечением, которое используется в организации для автоматизации деятельности.
При вводе ИСУП в эксплуатацию проводится обучение пользователей работе в ней. Данное мероприятие будет выполняться одновременно с запуском пилотных проектов в СУП, до того как руководителям пилотных проектов нужно будет начать оперативное управление вверенными им проектами в соответствии с методологией управления проектами и с использованием ИСУП. Обучение руководителей проектов также будет проводиться в ходе развертывания СУП для всех руководителей проектов и участников проектной деятельности, которые будут участвовать в информационном обмене по проектам.
По мере повышения уровня зрелости проектного управления, аналогично ситуации с развитием методологии управления проектами, функционал ИСУП будет расширяться. Кроме того, постоянно пополняемый архив проектной документации должен стать одним из источников знаний для сотрудников, использование которого позволит учитывать опыт предыдущих проектов при планировании новых.
6.6. Функции проектного офиса компании при внедрении и развитии системы управления проектами
Для того чтобы разработанная методология управления проектами и ИСУП использовались при ведении проектов, необходимо на регулярной основе выполнять мероприятия по контролю за соблюдением методологии и актуализации данных в ИСУП, проводить обучение участников проектной деятельности, совершенствовать процессы управления проектами, организовывать обмен опытом между участниками проектов, обеспечивать руководство сведениями о статусе реализации проектов, эскалировать проблемы в проектной деятельности. Вышеперечисленные задачи, выполнение которых необходимо для внедрения проектного подхода на предприятии, возлагаются на подразделение или группу сотрудников, которая называется проектным офисом. Более лаконично можно определить, что проектный офис – это подразделение или группа сотрудников предприятия, которая осуществляет координацию предписанных к нему проектов.
Подчиненность проектного офиса определятся с учетом списка подразделений, проектную деятельность которых предполагается координировать. Если при внедрении СУП предполагалось, что она распространяется только на проекты одного подразделения, например ИТ-службу, то и подразделение «Проектный офис ИТ» должно подчиняться руководителю ИТ-службы. Руководитель подразделения будет иметь в своем подчинении структурную единицу, задачи которой – предоставление независимой от руководителей проектов информации о статусе реализации проектов, организация обучения руководителей проектов данного подразделения, ведение архива проектной документации данного подразделения.
Если же СУП распространяется на всю проектную деятельность предприятия, то, чтобы избежать рисков ангажированности деятельности проектного офиса на интересы какого-либо одного из подразделений, рекомендуется подчинять проектный офис непосредственно первому лицу компании.
Следует также отметить, что в качестве проектного офиса в ряде случаев обозначают группу управления отдельным проектом, в состав которой входят руководитель проекта, администратор проекта, руководители рабочих групп проекта. Подобный проектный офис не рассматривается в рамках СУП как центр внедрения проектной деятельности, а расчитан только лишь на один проект. Такие типы проектных офисов, созданных под задачи управления отдельными проектами, значимыми для компании и нетипичными для ее постоянной деятельности, например, проектный офис внедрения ERP-системы на базе платформы SAP ERP, не будут рассматриваться в контексте внедрения СУП. Однако нужно отметить, что проектные офисы данного типа могут создаваться под выполнение отдельных проектов параллельно с функционированием проектного офиса подразделения или всей компании. Однако функционировать такие проектные офисы обязаны согласно методологии управления проектами, принятой в компании при внедрении СУП. Под конкретный проект могут использоваться дополнительные методы оперативного управления помимо прописанных в методологии проектной деятельности компании, но это не отменяет необходимости соблюдения подходов, обязательных для всех проектов.
Рис. 6.3. Положение проектного офиса в организационной структуре предприятия
При описании функций, которые потенциально может выполнять проектный офис, для начала хотелось бы отметить, что уровень развития проектного офиса напрямую коррелирует со зрелостью общего менеджмента в компании и проектного управления, в частности. Поэтому состав функций проектного офиса будет дополняться по мере функционирования СУП в организации и развития самого проектного офиса как центра компетенции в управлении проектами (рис. 6.3).
Развитие проектного офиса включает несколько ступеней, характеризующихся определенными признаками, по которым можно оценить, на какой ступени зрелости проектный офис находится сейчас и в каких направлениях он может развиваться, повышая свою зрелость. Прежде всего эволюция проектного офиса связана с «наращиванием мощи», т. е. с расширением набора функций, которые он выполняет. Условно можно выделить четыре ступени развития проектного офиса, на которых его функции претерпевают качественный скачок.
Ступень I. Формирование
На этой ступени идет процесс формирования проектного офиса как структурной единицы компании: разрабатываются регламенты и должностные инструкции, набирается штат, пишутся положения, регламентирующие деятельность проектного офиса. Помимо регламентации собственной деятельности проектный офис собирает информацию по проектам, ведущимся в компании, формализует процессы управления проектами, внедряет информационную систему для календарного планирования проектов и определяет предварительную структуру базы знаний, которая в дальнейшем будет использоваться для более эффективного управления проектами.
Цель проектного офиса на первой ступени зрелости – закрепить свои позиции, добиться, чтобы существующие регламенты управления проектами действительно работали. Поэтому ключевой функцией на этой ступени развития является отладка регламентов и процессов управления проектами, контроль за соблюдением методологии. Необходимо также проинформировать сотрудников компании о создании нового подразделения, поддерживающего проектную деятельность.
После того как проектный офис утвердит свою позицию в организации, завоюет доверие и уважение со стороны руководства и сотрудников, наладит процессы управления проектами и работа пойдет «как часы», можно говорить о переходе на следующую ступень зрелости.
Как долго проектный офис каждой конкретной компании будет находиться на первой ступени зрелости, зависит от многих факторов, но в среднем этот период занимает от полугода до года.
Ступень II. Накопление опыта и ресурсный учет
На этой ступени зрелости проектный офис расширяет свое влияние в компании за счет наращивания своих функций. Помимо поддержания актуальности методологии управления проектами, а также контроля за ее соблюдением проектный офис путем тесного взаимодействия с руководителями и администраторами проектов добивается своевременной актуализации графиков проектов в информационной системе, регулярно получает отчеты о статусе проектов, что позволяет ему формировать «общую картину» по проектам, вести документированный архив.
Кроме того, на второй ступени происходит формирование и структурирование базы знаний проектного офиса, собираются «извлеченные уроки», полезная информация о типовых услугах, условиях договоров с подрядчиками.
Однако ключевой функцией проектного офиса на данной ступени является контроль за распределением ресурсов в проектах. Для этого проектный офис формирует корпоративный пул ресурсов персонала, который может быть привлечен к участию в проектах.
Сам проектный офис, как правило, не полномочен назначать ресурсы на проекты, однако он может осуществлять информационную поддержку в принятии решений, так как обладает достоверными данными о распределении ресурсов.
Если проектный офис располагает достоверной и актуальной информацией о распределении ресурсов в проектах и о ситуации по проектам в целом, его зрелость можно считать достаточной для перехода на следующую – третью – ступень.
Ступень III. Накопление и передача опыта
На этой ступени зрелости проектный офис занимается прогнозно-аналитической деятельностью, в рамках которой осуществляется формирование нормативных оценок для планирования проектов.
Также в рамках формирования общей базы знаний создаются типовые иерархические структуры работ (ИСР), реестр типичных рисков по проектам, отслеживается удовлетворенность заказчика. С целью ознакомления с лучшими практиками ведения проектов проектный офис может регулярно проводить встречи по обмену опытом.
К другим полезным функциям проектного офиса на третьей ступени зрелости относятся:
• проведение плановых аудитов проектов;
• инициация аудитов критичных проектов;
Следует отметить, что на третьей ступени проектный офис уже обладает достаточно высоким уровнем зрелости, и переход на следующую ступень связан прежде всего с необходимостью введения в компании портфельного управления. При этом важно учитывать, что для перехода проектного офиса на четвертую ступень зрелости, помимо собственно развития проектного офиса, необходимо еще и развитие (возможно, реструктуризация) самой компании и готовность менеджмента к использованию формализованного подхода для стратегического управления. Однако если компания ведет мало проектов, внедрение принципов портфельного управления не является обязательным.
Ступень IV. Стратегическое управление портфелем
Ключевой функцией проектного офиса на этой ступени является внедрение и оптимизация портфельного управления. Проектный офис служит центром экспертизы для обеспечения принятия решений по управлению портфелем.
Говорить о классическом управлении портфелем проектов можно, если оно осуществляется для обеспечения стратегии развития предприятия и при управлении портфелем используются профессиональные инструменты менеджмента, а не только интуиция руководства и «здравый смысл».
Проектный офис, уровень развития которого соответствует четвертой ступени, востребован не во всех компаниях. Как уже было отмечено ранее, компания и менеджмент должны быть готовы к внедрению портфельного управления. В компании должны быть сформированы определенные предпосылки для развития портфельного управления, такие как формализованная стратегия, метрики для оценки проектов на соответствие стратегии, определенная культура принятия управленческих решений, прозрачность методов управления.
В дальнейшем проектный офис может совершенствоваться в рамках четвертой ступени, но это не означает отказа от реализации и развития функций, приобретенных на первых трех ступенях зрелости.
Резюме
Систему управления проектами нужно воспринимать как комплексное решение для внедрения проектного подхода на предприятии. Именно система, в которой предусмотрена регламентация процессов, их автоматизация, а также выделение персонала, контролирующего исполнение процессов и обеспечивающего их усовершенствование, способна обеспечить признание значимости проектного подхода для реализации стратегии организации и уменьшить риск невыполнения отдельных проектов и всего портфеля проектов организации за счет:
• обеспечения сбалансированности портфеля при его формировании (соответствие стратегии, выявление всех взаимозависимостей, минимизация конфликтов по ресурсам);
• регулярного мониторинга при реализации портфеля и принятия превентивных мер по предотвращению реализации рисков и снижению влияния реализовавшихся рисков;
• согласованного принятия решения по изменениям в проектах с учетом взаимосвязи по содержанию, срокам и ресурсам с другими проектами.
Ключевые термины
Корпоративная методология управления проектами – документированные процессы по управлению проектами, методы и процедуры, которые должны быть использованы сотрудниками предприятия при участии в проектной деятельности.
Информационная система управления проектами – специализированное программное обеспечение для управления проектами, выступающее в качестве инструментария для планирования и контроля параметров проектов, обмена информацией между участниками проекта, получения отчетности по проектам.
Проектный офис – подразделение в компании или назначенная группа сотрудников, контролирующая исполнение методологии управления проектами, соблюдение регламентов по работе с ИСУП, занимающаяся развитием знаний и навыков персонала в области проектного менеджмента.
Контрольные вопросы
1. При каком объеме проектной деятельности для предприятия становится целесообразно внедрять систему управления проектами?
2. Какие преимущества получает организация за счет внедрения системы управления проектами?
3. Какие данные о проектной деятельности предприятия могут быть полезны при финансово-экономическом обосновании внедрения системы управления проектами?
4. Какие положительные изменения принесет внедрение системы управления проектами руководителям проектов?
5. Какие три компонента составляют систему управления проектами?
6. Какие этапы внедрения системы управления проектами должны быть предусмотрены в ходе внедрения? Можно ли пренебречь выполнением тех или иных этапов?
7. Должны ли при разработке методологии управления проектами для организации учитываться внутренние стандарты данного предприятия по документированию процессов?
8. Какие основные разделы должны войти в методологию управления проектами?
9. Зачем нужна классификация проектов в методологии?
10. Какие документы должны быть разработаны при внедрении ИСУП помимо руководств пользователя для обеспечения единообразного использования ИСУП при планировании и контроле проектов всеми участниками проектной деятельности в организации?
11. Какие основные функции возлагаются на проектный офис?
12. Какие ступени развития проектной деятельности можно выделить?
13. Сколько проектных офисов может функционировать в организации?
Литература
1. Арчибальд Р. Управление высокотехнологичными программами и проектами / пер. с англ. М.: ДМК Пресс, 2002.
2. Кендалл И., Роллинз К. Современные методы управления портфелями проектов и офис управления проектами: Максимизация ROI. М.: ЗАО «ПМСОФТ», 2004.
3. Мазур И. И., Шапиро В. Д. Управление проектами: учеб. пособие для вузов. М.: Омега-Л, 2009.
4. Kerzner H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling. 8th ed. N.Y.: John Willey and Sons, 2003.
5. LeRoy Ward J. Project Management Terms: A Working Glossary. 2nd ed. ESI International, 2000. November 1.
Глава 7. Управление портфелем проектов
Изучив данную главу, вы узнаете:
• что такое портфель проектов;
• в чем состоят особенности управления портфелем проектов;
• из каких процессов состоит управление портфелем проектов;
• какой инструментарий можно использовать в процессе оценки и отбора проектов;
• как осуществить постановку управления портфелем в компании;
• как организовать управление портфелем проектов.
7.1. понятие портфеля проектов
Для достижения поставленных целей и реализации стратегий компании необходимо принимать соответствующие инвестиционные бизнес-решения, требующие использования различного рода ресурсов. Эти инвестиционные бизнес-решения направлены на развитие разных сторон и направлений деятельности компании. Однако поскольку объем ресурсов, выделенных на цели инвестирования, ограничен, нужно так распределить их по отдельным направлениям, чтобы получить максимальный долгосрочный эффект.
Таким образом, сначала необходимо разрезать «инвестиционный пирог» на части, соответствующие предполагаемой ценности отдельных направлений развития для компании. С этой целью используются различные приемы инвестиционного анализа. Далее возникает вопрос об организационной форме осуществления инвестиций по указанным направлениям.
Упомянутые бизнес-решения могут быть проведены в жизнь в различных организационных формах, в том числе посредством создания проектов и программ (рис. 7.1). Появление проектов и программ связано с особенностями и зрелостью организации, реализующей инвестиции. Таким образом, сначала принимается решение об инвестировании по тому или иному направлению, а затем – о возможности использования проектов и программ как способа организации инвестиционного процесса.
Рис. 7.1. Организация инвестиционного процесса
В рассматриваемом нами контексте предполагается, что в компании используется проектно-ориентированное управление, которое проявляется [Gareis, 2005] в том, что:
• управление посредством проектов понимается как способ организации деятельности;
• проекты и программы используются как временные организационные единицы;
• проектное управление является специфическим бизнес-процессом;
• возможности проектного управления поддерживаются офисом управления проектами, группой портфельного управления, пулом экспертов;
• используется парадигма управления, которая характеризуется командной работой, проектной ориентацией, делегированием полномочий и другими чертами.
Проектно-ориентированное управление может быть использовано в организациях самых различных сфер деятельности, и совсем необязательно, чтобы в организации бизнес как таковой состоял из проектов. Например, компания по производству продуктов питания, используя традиционные методы управления непосредственно текущей производственной деятельностью, может применять проектно-ориентированное управление деятельностью, связанной с развитием: созданием новых продуктов, процессов, организационных изменений и т. д. (рис. 7.2).
В проектно-ориентированной организации значительная часть инвестиций (имеются в виду так называемые реальные инвестиции) по определению реализуется в проектной форме. Поэтому рассматривая комплекс этих инвестиций с организационной точки зрения, можно представить их как совокупность проектов.
Рис. 7.2. Проектно-ориентированное управление деятельностью компании
Как уже отмечалось, объем инвестиционных ресурсов компании ограничен. Данные ресурсы должны использоваться для развития, ориентирами которого являются видение будущего и цели, обусловленные этим видением и определяющие вехи развития бизнеса.
Таким образом, компания должна определить требуемый объем ресурсов для достижения целей и пропорции их распределения по отдельным проектам, реализация которых и позволит достигнуть упомянутых целей. Вопрос заключается в том, чтобы правильно определить эти проекты и объемы инвестиционных ресурсов по каждому из них.
Если исходить из предположенной выше ограниченности инвестиционных ресурсов, то можно понять, что направление бо?льших ресурсов на одни проекты будет означать направление меньших ресурсов на другие проекты, а в отдельных случаях какие-то проекты останутся вовсе без ресурсов и не смогут быть начаты или доведены до завершения. Возникает вопрос: а позволит ли имеющаяся структура проектов и распределения ресурсов между ними обеспечить достижение поставленных целей в заданные сроки? Ответить на этот вопрос зачастую непросто, учитывая большое количество альтернативных вариантов, а значит, проектов.
Таким образом, можно говорить о совокупности имеющихся или планируемых проектов, связанных целями и ресурсами компании, называемой портфелем проектов.
Определение, имеющееся в Стандарте по управлению проектами, изданном Институтом управления проектами (PMI), предполагает, что портфель – это совокупность проектов или/и программ и других работ, которые объединены для обеспечения эффективного управления достижением целей бизнеса. Причем отмечается, что компоненты портфеля не обязательно должны быть напрямую связанны между собой [The Standard for Portfolio…, 2008]. Есть другие определения, например, определение, данное британским Office of Goverment Commerce: «портфель – совокупность инвестиций организации или ее сегмента в изменения, необходимые для достижения стратегических целей» [Portfolio, Programme and Project…, 2008]. Приведенные определения хорошо дополняют друг друга, рассматривая организационные формы (проекты и программы) и инвестиции в изменения.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
notes
Примечания
1
Управление проектом. Основы проектного управления: учебник / под ред. проф. Л. М. Разу. М.: КНОРУС, 2006; Мазур И. И., Шапиро В. Д., Ольдерогге Н. Г. Управление проектами. М.: Омега-Л, 2006; Романова М. В. Управление проектами. М.: ИД «ФОРУМ»; ИНФРА-М, 2007; Ларсон Э. У., Грей К. Ф. Управление проектами. М.: Дело и Сервис, 2013.
Купить на ЛитРес
Комментарии
Отправить комментарий