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

Поликарпов А.А.

Выпускник группы MBA CIO-60B

Школа IT-менеджмента

РАНХиГС при Президенте РФ

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

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

Глава 1. Теоретическая часть

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

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

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

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

Несмотря на то, что можно предположить тождественность методов управления во всех структурах, функционирующих с использованием средств государства, существует некоторое отличие для так называемых госкомпаний. Это компании, в структуре владения которых государство занимает 50 и более процентов. Несмотря на общие черты в управлении, закупки как основополагающий элемент в реализации проектов реализуются в таких компаниях не по 44ФЗ, а по 223ФЗ. Этот закон позволяет большую свободу действий и в, частности, позволяет совершать закупки по принципам time&material, то есть, в отличие от 44ФЗ, оплата подрядчикам может производиться до предоставления окончательного результата проекта. В настоящем дипломе будут рассмотрены аспекты применения закупок, регулируемых этим законом, в проектной деятельности госкомпании.

1.3. Проектный подход, отличия от процессного подхода, методологии

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

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

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

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

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

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

1.4. Отличие проектного управления в госкомпаниях

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

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

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

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

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

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

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

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

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

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

В общем случае для управления проектами применяется ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом», однако для разработки программных продуктов может применяться и ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств». Методология определяет фазы проекта и процессы управления, характерные для проектов, связанных с разработкой информационных систем и их внедрением в организации-заказчике.

В случае с референсным проектом по внедрению системы электронного документооборота применялся собственный подход организации «Ростех», выработанный на основании ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств» и ГОСТ Р ИСО/МЭК 15288-2005 "Процессы жизненного цикла систем", закрепленный в виде внутреннего нормативного документа – регламента выполнения проекта. Различие между этими стандартами состоит в том, что в ГОСТ 15288-2005 некоторые процессы вынесены в одну общую группу «Процессы предприятия», а в ГОСТ Р ИСО/МЭК 12207-2010 выделяет группы реализации, поддержки, организационного обеспечения проекта и повторного применения программных средств. Оба стандарта выводят в отдельные группы (и зоны ответственности) группы процессов соглашения (закупки и поставки), технические процессы (все аспекты технической эксплуатации ПО) и процессы проекта (управление проектом). Таким образом, деление процессов на группы согласно этим стандартам подходит государственным организациям по принципам функционального дробления. Учитывая планы применения конечного программного продукта и характер изменения требований к нему, а также возможного масштабирования для применения во все большем числе организаций из состава госкорпорации «Ростех», внедрение практик, описываемых в данных стандартах, было сочтено уместным.

Глава 2. Практическая часть

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

2.1. Инициирование и дизайн проекта

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

2.2. Планирование проекта

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

2.3. Исполнение проекта

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

2.4. Контроль реализации проекта

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

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

2.5. Закрытие проекта

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

Глава 3. Референсный проект

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

Заключение

4.1 Управление ИТ-проектом в госкомпании

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

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

4.2 Предпосылки разработки регламента

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

4.3 История разработки регламента

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

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

4.5 Краткое описание опыта работы по регламенту

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

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