ГЛАВА 3

Характеристики проекта. Сложность, уникальность, ограничения

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

Сенека

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

• ПРОЕКТ — это временное предприятие, направленное на создание уникального продукта, услуги или результата. PMBOK-7.
• ПРОЕКТ — это уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам. ISO/TR 10006:1997.
• ПРОЕКТ — это уникальная совокупность взаимосвязанных действий (работ) с определенными датами начала и окончания, предназначенных для успешного достижения общей цели. Australian National Standard for PM.
• ПРОЕКТ — это уникальная совокупность скоординированных действий (работ) с определенными точками начала и окончания, предпринятая индивидуумом или организацией для достижения определенных целей с установленными сроками, затратами и параметрами выполнения. BS 6079-1:2000.

И так далее и тому подобное. В общем, мы решили: раз уж у всех есть свое определение, почему бы нам не сформулировать свое? И вот определение из ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом».

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

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

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

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

Таким образом, нужны все три элемента.

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

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

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

Таблица 3.1. Пример определения проекта для небольшой компании

Па­ра­мет­ры про­ек­тов*	Улуч­ше­ние	Не­боль­шой про­ект	Сред­ний про­ект и вы­ше
Дли­тель­ность ре­а­ли­за­ции про­ек­та	<3 ме­ся­ца	≥3 ме­ся­ца	≥3 ме­ся­ца
За­тра­ты на услу­ги и ра­бо­ты, без НДС	<100 тыс. долл.	От­сут­ст­ву­ет**	≥100 тыс. долл.
Кол-во не­по­средст­вен­но во­вле­чен­ных бло­ков пред­при­я­тия	=1	>1
По­ка­за­те­ли из­ме­не­ний	Про­цес­сы не ме­ня­ют­ся или ме­ня­ют­ся не­зна­чи­тель­но	Про­цес­сы су­щест­вен­но из­ме­ня­ют­ся
Рис­ки ре­а­ли­за­ции	Не­вы­со­кие	Сред­ние или вы­со­кие

* Необходимо выполнение не менее двух условий для перевода проектной задачи в проект.

** Возможно наличие затрат на единоразовые активности (закуп лицензий, оборудование и так далее).

 

Этот набор критериев может быть и совсем коротким (табл. 3.2).

Таблица 3.2. Пример критериев для регионального банка

№ п / п	Наи­ме­но­ва­ние кри­те­рия	Ха­рак­те­рис­ти­ки кри­те­рия
1	Уни­каль­ность (но­виз­на)	Тре­бу­ет­ся внед­ре­ние но­вой ин­фор­ма­ци­он­ной сис­те­мы / про­дук­та / услу­ги с по­лу­че­ни­ем эф­фек­та
2	Стейк­хол­де­ры	В ре­а­ли­за­ции про­ек­та участ­ву­ют бо­лее че­ты­рех под­раз­де­ле­ний треть­е­го уров­ня. В круп­но­бюд­жет­ных про­ек­тах — од­но под­раз­де­ле­ние треть­е­го уров­ня
3	Дли­тель­ность про­ек­та	Бо­лее 6 ме­ся­цев
4	Ре­зуль­тат про­ек­та	Из­ме­ри­мое, ося­за­емое, под­тверж­да­е­мое ко­неч­ное со­бы­тие, ко­то­рое долж­но быть по­лу­че­но при за­вер­ше­нии про­ек­та

Для выделения инициативы в проект необходимо соответствие всем четырем критериям.

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

Таблица 3.3. Проект, портфель и программа

	Про­ект	Про­грам­ма	Порт­фель
Цель	Кон­крет­ный про­дукт	По­лу­че­ние вы­год	Вы­пол­не­ние стра­те­гии
Со­став	Бло­ки ра­бот	Про­ек­ты и опе­ра­ци­он­ная де­я­тель­ность	Про­грам­мы, про­ек­ты, опе­ра­ци­он­ная де­я­тель­ность
Вре­мен­ны́е рам­ки	Жест­ко опре­де­лен­ный срок окон­ча­ния	При­мер­ный срок окон­ча­ния	Нет сро­ка окон­ча­ния
Ос­нов­ной при­ори­тет управ­ле­ния	Оп­ти­ми­за­ция сро­ков за­трат, ре­сур­сов и тре­бо­ва­ния за­каз­чи­ка	Оп­ти­ми­за­ция вы­год	Оп­ти­ми­за­ция пу­тей до­сти­же­ния стра­те­ги­чес­ких це­лей ком­па­нии

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

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

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

Сравнение проектного, программного и портфельного подходов

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

Важно понимать, что программный и портфельный виды управления — это высшая математика проектного подхода. На сотню организаций, внедривших проектный подход, приходится всего несколько, которые доходят выше. И это очень жаль, потому что, согласно исследованиям (PMI Pulse of Profession 2021), попытка запустить слишком много проектов — самая большая проблема управления проектами для многих организаций. А управление портфелем должно как раз приоритизировать и отбирать самые важные проекты.

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

Так что вернемся еще к одной характеристике, которая очень важна, — ограничениям. Без них не нужно проектное управление.

Вы знаете, что это за здание (рис. 3.3)?

У этого храма очень интересная история. Строительство началось еще в 1882 году. В 1883-м руководить стройкой был приглашен знаменитый архитектор Антонио Гауди, и вплоть до смерти в 1926 году он занимался ею. Он успел достроить крипту, частично фасад и одну из 100-метровых колоколен. После смерти Гауди руководство работами принял на себя его ближайший соратник Доменек Сугранес. Ему тоже не удалось закончить строительство, но были возведены три дополнительные колокольни. Во время гражданской войны в Испании в 1938 году строительство прервалось и возобновилось только в 1952-м. И продолжается по сей день. Ожидаемая дата окончания — 2030 год.

Я часто задаю своим студентам вопрос: можно ли назвать это проектом? И ответ, который не все угадывают, — конечно же, нет. Потому что нет главного ограничения — по срокам.

На самом деле строительство храмов часто ведется подобным образом. Чтобы это увидеть, не обязательно ездить в Барселону. Недавно я был в Кирове — точно так же там восстанавливают Спасский собор, разрушенный во времена СССР (рис. 3.4).

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

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

Яркий пример — Международный экспериментальный термо­ядерный реактор (ITER; рис. 3.5). Его задача заключается в демонстрации возможности коммерческого использования термоядерной реакции синтеза и решении физических и технологических проблем, которые могут встретиться на этом пути. Когда он будет построен, у человечества появится принципиально новый источник чистой электроэнергии.

Проект (хотя правильнее назвать его мегапроектом) начал разрабатываться в середине 1980-х. В 1992 году было подписано четырехстороннее (ЕС, Россия, США, Япония) межправительственное соглашение о разработке инженерного проекта ITER, который был завершен в 2001 году. Проектирование реактора было полностью закончено, и в 2005-м выбрано место для его строительства — исследовательский центр «Кадараш» на юге Франции, в 60 километрах от Марселя. Подготовка строительной площадки началась в январе 2007 года. В 2010-м стартовало строительство. В 2020 году — сборка реактора. Запуск планируется на 2025-й, но, скорее всего, сроки сдвинут.

В итоге мегапроект будет длиться около 40 лет. Но это действительно проект. Здесь используется соответствующий подход. Есть все, что мы с вами будем изучать: руководитель проекта, планы, контрольные точки и прочее.

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

В связи с этим давайте посмотрим на важную модель, которая называется «Треугольник ограничений» (рис. 3.6). Еще ее называют «Железный треугольник» или «Тройственное ограничение».

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

Лингвистическое отступление. Вообще, слово «содержание» очень любопытное. Это перевод английского scope. Оно обозначает все работы и результаты, которые должны быть получены в проекте. То есть одно английское слово scope переводится аж четырьмя разными русскими словами: «содержание проекта», «объем проекта», «рамки проекта», «границы проекта» (это все скоуп). Нет! Даже пятью — еще есть «периметр проекта». Часто, кстати, его сейчас так и пишут: «скоуп» — и все.

Если вам стало обидно за русский язык — не расстраивайтесь. Есть и обратный пример. Простое слово «проект» на англий­ский может переводиться тоже четырьмя словами:

• Документация для создания какого-либо продукта; эскизный проект; технический проект. Английский термин — design.
• Проект как черновая версия документа — draft.
• Проект как идея, задумка — idea.
• Проект как деятельность — project.

 

Исходя из принципа треугольника, все три аспекта соединены между собой в трех углах. Геометрически этот закон управления проектом может быть проиллюстрирован так: если потянуть один из отрезков (например, сроки), то, согласно правилам геометрии, изменятся и остальные. В русском языке этот закон отражен в известной поговорке «Мы сделаем вам быстро, качественно и недорого — выберите два из трех». Важная особенность связей между параметрами — их нелинейность и слабая предсказуемость. Особенно часто это проявляется в IT-проектах: одно небольшое изменение, например объема путем добавления нескольких новых требований, может вызвать непропорциональное увеличение бюджета и (или) сроков выполнения проекта.

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

Вроде хорошая модель. Правильная. Но есть нюанс. Посмотрим на то, как по-разному изображают треугольник (рис. 3.7).

Видите? Четыре ограничения, пять ограничений, шесть ограничений… Так что уже достаточно давно понятно, что это не треугольник. У руководителей проектов появилась даже такая шутка: «Если сломать треугольник, качество просочится наружу». Она как раз о том, что качество — важное ограничение.

Так что в какой-то момент стало ясно, что «Треугольник ограничений» — модель очень полезная, но для реальной практики слишком простая. У проекта может быть много разных ограничений, из них самое важное — сроки. Как мы видели выше, если нет ограничения по срокам, то и проектное управление не нужно. Но в реальности это не треугольник, а N-угольник. И исходя из наложенных на проект ограничений формулируются критерии его успешности (или неуспешности).

Обычно проект считается успешным, если он завершен:

• в полном объеме;
• в рамках бюджета;
• в установленные сроки;
• с заданным уровнем качества;
• при удовлетворении заказчика.

В разных проектах может быть разное представление об успешности: где-то превышение срока на день — это полный провал, а где-то некритично. На месяц, конечно, превышать не надо, но на два-три дня допустимо. А вот если бы мы при подготовке Олимпийских игр сказали: «Мы немного не успеваем, давайте на два-три дня открытие перенесем», нас бы совсем никто не понял. Та же история и с бюджетом — где-то превышение на два-три миллиона рублей некритично, а к кому-то и прокуратура может прийти за такое.

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

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

Отправить