1.   Время перемен (вместо введения)

Мир изменился! «Устойчивый, предсказуемый, простой, определенный мир» (SPOD) уступил место «Нестабильному, неопределенному, сложному, неоднозначному миру» (VUCA). Что это означает для проектной деятельности? Если ответить кратко — мы переходим в проектный мир. Становится все сложнее определять границу между операционной и проектной деятельностью компании на основе тех понятий и знаний, которые заложены в существующих стандартах. Пришло время отказаться от стандартов управления проектами, основанных на процессных подходах.

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

2.   Недостатки стандартов управления проектами на базе «процессного подхода»

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

Но к чему это привело?

• Ментальный диссонанс: «Процессный» — «Проектный»

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

• Универсальность процессов вынуждает очень высоко подняться над практикой

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

• Отсутствует четкое разделение между «Продуктом/Результатом» — «Проектом» — «Управлением»

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

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

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

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

Таблица 1

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

Перед тем как рассмотреть новые определения терминов «Проект» и «Управление проектом», приведем несколько общих положений, относящихся к самому понятию «определение», которые дают нам право пересмотра их определений.

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

3.1.       Новое определение «Проекта»

Слово ПРОЕКТ употребляется в русском языке в следующих смыслах:

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

Далее мы рассматриваем четвертый вариант – Проект как Деятельность.

Приведем ряд определений «Проекта» из существующих стандартов:

• «Свод знаний по управлению проектами» (PMI, 1987): Некоторое предприятие с изначально установленными целями, достижение которых определяет завершение проекта.
• PMBOK[1]: Временное предприятие, направленное на создание уникального продукта, услуги или результата.
• IPMA: Целенаправленное ограниченное во времени мероприятие, направленное на создание уникального продукта или услуги.
• P2M: Обязательство создать ценность, основанную на миссии проекта, которая должна быть выполнена в определенный период, в рамках согласованного времени, ресурсов и условий эксплуатации.
• ГОСТ Р 54869-2011: Комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений.
• ISO 21500: Уникальный набор процессов, состоящих из скоординированных и управляемых задач с начальной и конечной датами, предпринятых для достижения цели. Достижение цели проекта требует получения результатов, соответствующих определенным заранее требованиям, в том числе ограничения на получения результатов, таких как время, деньги и ресурсы.
• ISO 15288: Попытка действий с определенными начальной и конечной датами, предпринимаемая для создания продукта или услуги в соответствии с заданными ресурсами и требованиями.

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

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

Позволяют ли эти свойства качественно выделить Проект из Деятельности? В современной практике уже нет! Надо искать новый существенный признак. И таким признаком, выделяющим проект из общей деятельности, может выступить «Неопределенность».

Автор предлагает следующее новое определение «Проекта»:

Новые существенные свойства для выделения проектов из общей деятельности:

• повышенная неопределенность
• специализированные инструменты
• специализированные методы

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

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

Расшифруем новые существенные свойства.

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

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

Внешние причины (вне зоны влияния субъекта, запускающего проект)

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

Внутренние причины

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

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

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

Что дает нам новое определение Проекта?

1. Позволяет каждому Субъекту (Компании, Организации, Госоргану), занимающемуся любой деятельностью, разграничить ее на операционную и проектную с учетом своей ситуации, причем это справедливо и для проектных организаций, где операционная деятельность – это проекты.
2. Позволяет внутри Проекта четко разделить деятельность по созданию Результата, по обеспечению создания Результата и по управлению этими деятельностями, причем с понятным пересечением вспомогательных процессов Родительской компании и Проекта.
3. Позволяет выделить два направления совершенствования проектной деятельности:
   превращение часто выполняемых проектов в «операционную» деятельность, путем снижения неопределенности;
   • накопление знаний и умений (инструментов и методов), позволяющих выполнять нестандартные для компании проекты.
4. Обеспечивает интересный и полезный эффект для Проектного сообщества. Оно позволяет исключить большинство провальных проектов из ответственности «управления проектами». Если кто-то, управляя «Проектом» (как он его называет) применял методы стандартного операционного менеджмента, то, извините, это был вовсе не Проект и не стоит бросать тень на «управление проектами» как на область знаний.
5. Открывает новый этап для развития управления проектами – разработка и описание инструментов и методов, работающих в условиях повышенной неопределенности (хватит описывать процессы с их входами и выходами, необходимо учить людей как выполнять необходимые проекту функции в условиях неопределенности).

3.2.       Новое определение «Управления проектом»

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

Вот десять пунктов, собранных воедино из разных источников:

1. Уметь определять факторы окружающей среды, влияющие на объект управления.
2. Уметь выявлять существующие проблемы, работать с целями и ценностями, с учетом имеющихся ограничений.
3. Получить знания об объекте управления, но только те, которые необходимы с точки зрения достижения поставленных целей.
4. Уметь прогнозировать, т.е. экстраполировать в будущее линии саморазвития объекта.
5. Уметь проектировать, т.е. создавать линию необходимого развития с точки зрения поставленных целей.
6. Знать свои возможности, свои ресурсы, свои средства, знать сможем ли мы произвести такие управляющие воздействия, чтобы изменить естественную траекторию на искусственную.
7. Уметь построить программу воздействий, которая обеспечит движение объекта в нужном направлении, создать и потом ликвидировать необходимую организационную структуру, поддерживающую выполнение этой программы, уметь правильно коммуницировать со всеми участниками деятельности и документировать свою деятельность.
8. Уметь выстраивать эффективную систему мониторинга (контролировать только то, что необходимо для принятия решений).
9. Уметь принимать правильные решения, даже в условиях неопределенности и иметь на это право, уметь превращать принятые решения в задачи, доносить их до исполнителей и обеспечивать их исполнение.
10. И главное — уметь мыслить, т.е. постоянно оценивать и корректировать свою (управленческую) деятельность в связке с текущим движением объекта управления и с учетом его окружения, уметь решать то, что вчера казалось нерешаемым.

Эти умения можно свернуть в «Полную функцию управления»:

1. Планирование (включая: изучение и оценку внешней среды [1], изучение объекта управления [3,4], согласование внешних целей и ограничений [2], утверждение допущений [2], разработку планов [5,6,7])
2. Создание условий (организационная работа [6,7])
3. Постановка задач [9] (включая первичный запуск того, что создано в орг. работе)
4. Мониторинг и контроль [8] (Мониторинг — процесс получения и расчета необходимых параметров; Контроль — процесс сравнения полученных параметров с их актуализированными нормативными значениями)
5. Мышление, анализ и прогнозирование [10] (мыследеятельность по постоянной подстройке системы управления: выявление причин отклонения, анализ причин отклонений, прогнозирование ситуации, поиск решений, оценка и аргументация решений)
6. Принятие решений [9] (самостоятельно в рамках полномочий, с привлечением соответствующих ЛПР)
7. Управленческие воздействия [10]
8. Коммуникация [7]
9. Документирование управленческой деятельности [7]

И на базе «Полной функции управления» уже можно сформулировать новое определение «Управления проектом» и описать Проект как систему.

Для справки приведем существующее определение из действующей версии PMBOK: Управление проектом — это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту.

Автор предлагает следующее новое определение «Управления проектом»:

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

Важный момент — «Управление проектом» состоит из трех направлений, которые необходимо обязательно учитывать:

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

4.   ПРоект кАК СИСтема (модель «ПРАКСИС»[2])

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

Здесь мы приведем только понятие Системы.

Система – некая целостность, выделенная[3] из единого мира с определенной целью и выполняющая в этом мире вполне определенную функцию.

Описываться система может несколькими, связанными между собой, способами[4]:

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

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

В основе модели лежит известный управленческий цикл Деминга (Рисунок 1).

Рисунок 1. Управленческий цикл Деминга и его представление в PMBOK

В свое время Эдвард Деминг дополнил цикл управления качеством Уильяма Шухарта, превратив его в универсальный управленческий цикл. Автор предлагает дополнить управленческий цикл Деминга и превратить его в цикл управления проектом (Рисунок 2). Напомню, что дополнение будет основано на «Полной функции управления», описанной выше.

Рисунок 2. Цикл управления проектом, на основе «Полной функции управления»

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

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

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

4.2.       Системная модель Проекта

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

На Рисунке 3 Проект представлен в виде Системы на базе управленческого цикла.

Рисунок 3. Проект как Система (модель ПРАКСИС)

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

• «1. Планирование управленческого цикла» поставляет информацию для «2. Создание условий для работы Команды проекта».
• «2.Создание условий для работы Команды проекта» проектирует, организует и обеспечивает «9. Процессы жизненного цикла создания Результата».
• «9. Процессы жизненного цикла создания Результата» поставляет информацию для «4. Мониторинг».

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

Следующий уровень описания системы (см. п.4) – это функциональное представление. Оно состоит из трех частей:

• функции элементов Системы Проект (внутри границы);
• функции элементов Родительской системы (окружение);
• функции предметной области для создания Результата проекта (внутри элемента №9).

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

Пример описания функций Системы Проект и Родительсткой системы (окружение проекта) приведен в Таблице 2.

Таблица 2

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

Пример описания функций предметной области (строительный проект, группа «Контрактация»):

• Разработка контрактной схемы для Проекта.
• Разработка комплексной программы закупок Проекта.
• Формирование списка рисков текущего Проекта и распределение их по контрактной схеме.
• Заключение контрактов (анализ рынка контрагентов; подготовка ТЗ/ТТ; подготовка коммерческих условий; конкурсные процедуры; переговоры; подписание).
• Контроль за соблюдением контрактных условий.
• Внесение изменений в контракты (доп. соглашения).
• Претензионная работа.
• Замена подрядчиков.
• Судебная работа.
• Закрытие контрактов.

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

Оставшиеся три уровня описания системы (см. п.4)

• процессное представление;
• морфологическое представление (организованность);
• субстратное представление (материал — люди),

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

4.3.       Структура стандарта управления проектами на базе модели ПРАКСИС

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

Стандарт должен описывать

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

Все эти требования способен выполнить предлагаемый Стандарт. На Рисунке 4 представлена структура Стандарта управления проектами на базе модели ПРАКСИС.

Рисунок 4. Структура Стандарта управления проектами на базе модели ПРАКСИС

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

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

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

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

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

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

Неотъемлемой частью предлагаемого Стандарта является База Знаний, которая состоит из трех частей:

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

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

• Преодолеть сложность изучения существующих стандартов. В новом Стандарте для начала работы Менеджеру Проекта достаточно знания общего менеджмента и ряда специализированных инструментов, предоставляемых самим Стандартом.
• Облегчить внедрение стандарта в практику компании. Внедрение самого Стандарта не требует никакой ломки существующих процессов и длительного времени. Достаточно определить некоторые простые правила, исходя из существующей в компании ситуации. Эти правила предписываются самим Стандартом. Так как Стандарт построен по принципу «самосовершенствования», на начальных стадиях трудоемкость его применения минимальна, его эффективность будет нарастать по мере использования.
• Не только повышать эффективность часто выполняемых проектов, но и быть эффективным для уникальных (нетиповых для компании) проектов. Стандарт изначально ориентирован на уникальные проекты, стандартизация происходит по мере повторения однотипных проектов.
• Преодолеть споры «Agile – Водопад» и «Менеджер Проекта больше Менеджер или Технарь».

5.   Преспективы

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

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

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

6.   Рекомендованная литература по системному мышлению

• Евгений Ксенчук, «Системное мышление. Границы ментальных моделей и системное видение мира»;
• Джамшид Гараедаги, «Системное мышление. Как управлять хаосом и сложными процессами. Платформа для моделирования архитектуры бизнеса»;
• Г.П. Щедровицкий, «Оргуправленческое мышление. Идеология, методология, технология. Курс лекций»;
• Анатолий Левенчук, «Системное мышление».

[1] Это и последующие определения взяты из действующих на текущий момент времени версий указанных стандартов.

[2] ПРАКСИС (греч, praxis) — дело, действие.

[3] Выделенная – означает «имеющая границу» во внешнем мире.

[4] Представление по Г.П. Щедровицкому (СМД). Но есть и другие, например, из системной инженерии: в виде Компонент – Модулей – Размещений.