Изучив данную главу, вы сможете:
• оценивать целесообразность и преимущества внедрения системы управления проектами для определенного предприятия с учетом специфики его проектной деятельности;
• определять выгоды, которые приносит внедрение системы управления проектами сотрудникам организации с учетом их роли в проектной деятельности;
• спланировать проект внедрения системы управления проектами как сложное организационное изменение;
• разработать структуру методологии управления проектами для предприятия;
• реализовать мероприятия по выбору платформы для информационной системы управления проектами и организовать внедрение выбранного программного продукта;
• определить положение проектного офиса в организационной структуре, сформировать список функций проектного офиса с учетом уровня зрелости предприятия в области проектного управления.
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.