Как понятие проекта раздулось до полной потери смысла и что с этим делать?
Тезис
Несмотря на распространение идей, понятий, инструментов и методов проектного управления, само содержание дисциплины утрачено, а профессия проектного менеджера постоянно деградирует. Понятие проекта потеряло важнейший компонент своего изначального смысла — мобилизацию и реорганизацию ресурсов для достижения цели, из-за чего мы потеряли целое пространство рассуждений о путях достижения поставленных целей. Нам надо восстановить исходное значение понятия проект и перестать играть в словесные игры и запутывать друг друга. Только так мы сможем четко понимать, где проходит граница ответственности проектных менеджеров, за что они отвечают и способны ли они нести возложенную на них ответственность.
Аннотация
Проект является комплексом взаимосвязанных мероприятий, который направлен на пошаговое воплощение единого замысла, при этом на время исполнения проекта мобилизуются ресурсы одной или нескольких организаций в их уникальной комбинации. Отсутствие любой из значимых характеристик — замысла, временной мобилизации ресурсов или специальной организации этих ресурсов по отличным от основной деятельности правилам и практикам, — приводит к появлению вырожденных проектов.
Проблема современного состояния дисциплины в том, что таких вырожденных по одной или даже нескольким характеристикам “проектов” стало слишком много. Обсуждение вырожденных проектов в логике классической дисциплины проектного менеджмента является бессмысленным, потому что вырожденные проекты не являются объектом исследования и управления этой дисциплины.
Однако многочисленные попытки применять ее методы, инструменты и практики к управлению вырожденными проектами и анализировать результаты с почти неизбежным выводом о неэффективности проектного управления и т.н. “водопадного метода” создают неверное представление о ее возможностях, сценариях применения и уничтожают профессию проектного менеджера.
В этой статье предлагается к обсуждению понятийный аппарат, с помощью которого можно понять границы ситуаций, в которых проектный менеджмент применим и может быть полезен. Приводятся аргументы, что без определения границ применимости мы как профессионалы проектного управления обречены на дальнейшую деградацию профессии.
Эпиграф
Цзы Лу спросил: «Вэйский правитель намеревается привлечь Вас к управлению государством. Что Вы сделаете прежде всего»?
Учитель ответил: «Необходимо начать с исправления имен».
Цзы Лу спросил: «Вы начинаете издалека. Зачем нужно исправлять имена?»
Учитель сказал: «Как ты необразован, Ю! Благородный муж проявляет осторожность по отношению к тому, чего не знает. Если имена неправильны, то слова не имеют под собой оснований. Если слова не имеют под собой оснований, то дела не могут осуществляться. Если дела не могут осуществляться, то ритуал и музыка не процветают. Если ритуал и музыка не процветают, наказания не применяются надлежащим образом. Если наказания не применяются надлежащим образом, народ не знает, как себя вести. Поэтому благородный муж, давая имена, должен произносить их правильно, а то, что произносит, правильно осуществлять. В словах благородного мужа не должно быть ничего неправильного».
Переломов Л. С. Конфуций:” Лунь юй”. — Восточная литература, 1998.
Проект как мобилизация ресурсов под задумку и план действий
Если мы разберем определения, то увидим, что проект подразумевает выделение под него ресурсов и наличие планов работ, которыми будут заниматься эти ресурсы. Еще для проекта обязательна задумка, замысел, или, как пишут в начальном разделе технического задания, “Цели и задачи”.
Рассмотрим определение термина “проект” в основных стандартах.
A project is a temporary endeavor undertaken to create a unique product, service, or result. (PM BOK Guide)
A project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case. (PRINCE2)
Проект — это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. (Руководство к своду знаний по управлению проектами)
В первую очередь видим, что “проект” — это разновидность “предприятия”, “организации”. Очевидно, что “предприятие” (“организация”), в сочетании с указанием его “временности” указывает не на юридическое лицо, владеющее собственностью, не на фирму или учреждение, а на что-то другое. Даль дает такое определение:
“Предпринимать — затевать, решаться исполнить какое-либо новое дело, приступать к совершенью чего-либо значительного. … Лесепс предпринял перекоп Суезского перешейка. … Предприятие, что предпринимается, самое дело. Такое предприятие требует огромных средств.”
Это точно перекликается со значением endeavor ‘try hard to do or achieve something, exert oneself’. Поднатужиться, в общем, собрать все возможные ресурсы и запустить какой-то бизнес, какое-то направление деятельности. Другими словами, проект — это деятельность, бизнес. Любой бизнес с одной стороны требует организации, правил координации, принципов принятия решений, а с другой стороны бизнес — это всегда какие-то ресурсы. Нельзя заниматься бизнесом без денег, оборудования, людей и технологий.
И тут всплывает уточнение, что проект — это временное предприятие. То есть ресурсы выделяются откуда-то в проект, их там организуют каким-то образом, необходимым для создания уникальных продуктов, услуг или результатов, и затем возвращают эти ресурсы куда-то обратно. Проект — это временный бизнес, ограниченный от регулярного; ресурсы под ведение которого привлекаются, мобилизуются на время реализации проекта. Запомним оба эти пункта — и то, что проект является делом, бизнесом, со своей организацией и то, что ресурсы под это дело, бизнес откуда-то привлекаются и вкладываются в проект. Ресурсы привлекаются под идею, замысел, логику и расчеты, никто не дает людей и деньги просто так.
В этой статье я покажу, что несмотря на распространение идей, понятий, инструментов и методов проектного управления, само содержание дисциплины утрачено, а профессия проектного менеджера постоянно деградирует. Понятие проекта потеряло важнейший компонент своего изначального смысла — мобилизацию и реорганизацию ресурсов для достижения цели, из-за чего мы потеряли целое пространство рассуждений о путях достижения поставленных целей. Нам надо восстановить исходное значение понятия проект и перестать играть в словесные игры и запутывать друг друга. Только так мы сможем четко понимать, где проходит граница ответственности проектных менеджеров, за что они отвечают и способны ли они нести возложенную на них ответственность.
Если провести анализ резюме, вакансий, посмотреть реально словоупотребление термина “проект”, то мы без труда увидим, что:
а) проект зачастую никак не отделяется от основной деятельности. Под него не создают отдельного подразделения, юрлица, выделенной рабочей группы; не прописывают отдельные процессы и порядки ведения дел и принятия решений. Зачастую под проект не выделяется отдельного счета и даже строки бюджета, кода финансового учета — а представить себе бизнес без своих денег немыслимо. Я уже не говорю о том, что выделенные в проект сотрудники часто продолжают заниматься тем же самым, по тем же процессам, на тех же рабочих местах. Словом, для них ничего не меняется, ни в каком другом деле и начинании они не участвуют. Как была их деятельность без начала и конца, так и осталась.
б) никаких ресурсов под проект не привлекается и никакого “совершения чего-то значительного” в нем не происходит. Часто проектом называют просто реализацию каких-то действий по какому-то плану, иногда и не очень-то работоспособному и продуманному. То, что раньше называлось мероприятием, понимаемым как “организованное действие или совокупность действий, имеющих целью осуществление чего-нибудь”, стало “проектом”. По большому счету, провести мероприятие означает “принять меры”, то есть краткосрочно решить проблему, заткнуть “дыру”, без попыток долгосрочного разрешения проблемы и устранения причины возникновения какой-то нежелательной ситуации.
в) и, раз никаких ресурсов в такой вырожденный проект не выделяется, возвращать обратно под отчет о том, что было сделано, ничего не надо. В результате сам проект не рассматривается как инвестиция. А где нет инвестиций, там нет и существенного интереса собственников, менеджеров и начальства, нет влияния, полномочий и настоящей ответственности проектного менеджера. Единое ответственное лицо, говорите? Нет, скорее уж “стрелочник”, без права на ошибку.
Хоть напрямую это говорится и пишется довольно редко, “проект” как бизнес подразумевает какой-то изложенный явно замысел, концепцию того “как дело делать будем”, будь то получение коммерческой выгоды, создание общественного блага или решение социальных проблем. Даль говорит так: “проект — задуманное, предположенное дело, и самое изложение его на письме или в чертеже”. Часто ли вы видите в проектах вокруг изложение этой самой концепции? По моим наблюдениям, в большинстве случаев концепции либо нет совсем либо она слабенькая и не выдерживает критики.
Такие непроработанные в плане замысла предприятия четко обозначены насмешливым словом “прожект”, а человека, который их продвигает, зовут “прожектером”. Прожект — это нереалистичное начинание, несбыточный и необоснованный проект. И эта нереалистичность и несбыточность может порождаться двумя группами причин. Либо несбыточностью самого замысла из-за отсутствия путей достижения целей, доступных технологий и материалов. Либо из-за невозможности собрать потребные для воплощения реалистичного и хорошо просчитанного замысла ресурсы. Примером первого вида прожектов является заселение Марса, при том при всем, что мы даже пустыни не можем заселить, хотя в Сахаре не надо носить скафандр, воды в Мировом океане достаточно, а долететь до терраформируемого участка можно на обычном самолете за пару часов, а не несколько месяцев плыть в невесомости на тесном космическом корабле, питаясь консервами. Я уж не говорю про эвакуацию больных и раненых, экономику доставки пассажиров и грузов и прочие технические и организационные моменты. Примером второй типа прожектов являются метрополитены в Нижнем Новгороде, Новосибирске, Самаре, Екатеринбурге, Казани или линии скоростных автобусов во Владивостоке, Воронеже или Хабаровске. Понятно, что замыслы везде есть, они хорошо просчитаны, но ресурсы под эти проекты привлечь невозможно.
Проектный замысел и способность его воплотить, оформленная в виде комплекта проектных планов — это необходимое условие для проведения мобилизации ресурсов, привлечения их в проект под какую-то организационную схему, описанную в этих планах.
Важно еще понимать один момент. Изначально то же руководство по своду знаний по управлению проектами четко обозначало свой объект управления, исследований и анализа — это были проекты, с бюджетом больше 20 млн. долларов США, длительностью год и больше, численностью временной организации более 200 человек, с десятками подрядчиков и поставщиков. Это четко объясняется в главном руководстве по подготовке к профессиональной сертификации по проектному менеджменту [1], а также закреплено в документах Минобороны США, см., например, инструкции по заполнению отчетности по ходу программ проектов [2]. Понятное дело, если вам как проектному менеджеру, дают в распоряжение бюджет полтора миллиарда рублей, то и спрос за это будет соответствующий, у вас появится и ответственность и полномочия.
Такие существенные вложения порождают потребность в комплаенсе, подконтрольности и подотчетности проектного менеджера, а поскольку 200 человек контролировать в одиночку невозможно, то возникает и команда управления проектом и временная организация, со своими процессами, практиками и правилами доказательства обоснованности затрат и достаточности достигнутых результатов.
И первое направление размывания понятия проекта идет по линии уменьшения вышеуказанных численных границ. Если бюджет будет 10 млн. долларов, команда будет 100 человек, а длительность проекта 10 месяцев, то можно ли сказать, что это тоже проект и к нему применимы соответствующие практики, инструменты и методы? Да, с оговорками, ответили практики, и появился термин “адаптация”, tailoring. То есть, организации поменьше мы тоже можем рассматривать как проекты, но требования к планированию, контролю и управлению мы снижаем.
А дальше реализовался сценарий про семь шапок из одной шкуры — проекты становились все меньше, пока не теряли незаметно одну из ключевых характеристик. Из-за недостатка ресурсов и времени они достигали все меньшего, меньшие изменения и небольшие ресурсы уже не требовали существенной перестройки организации и ее отделения от основного бизнеса, замысел сужался, становился все более техническим (мы просто делаем веб-сайт, а не создаем направление eCommerce, что вы) и, наконец, исчезал.
Проекты вырождались, и проектные менеджеры вырождались вместе с ними. И это происходило, похоже, везде. Один мой знакомый в 2020 г. проходил собеседование в крупной американской корпорации и сказал интервьюеру, что он хотел бы быть проектным менеджером. На что топ-менеджер, который его собеседовал, с удивлением ответил: “Ты же крутой чувак, ты реально хочешь сидеть в экселевских таблицах и сводить бюджеты и графики работ? Тебе надо идти менеджером продукта!”
Комплаенс, подконтрольность, подотчетность, равно как и само управление организационным изменением, возникающим при запуске проекта, массово ушли из обсуждений проектного менеджмента, и про них не спрашивают даже на собеседовании.
Итак, проектный менеджмент подразумевает привлечение существенных ресурсов в ранее не используемой комбинации ради реализации задумки, с учетом некоторого плана и логики достижения конечного результата под личную ответственность проектного менеджера, который управляет временно созданной организацией.
Попробуем эти рассуждения на прочность. Если нет замысла, то работа организации разваливается, все начинают заниматься понятными им кусками деятельности, без сборки итогового результата. Если нет плана или ресурсов, то получается прожект как некое нереалистичное начинание, под которое невозможно привлечь достаточное для его воплощения количество ресурсов или замысел которого даже потенциально нельзя реализовать имеющимися или потенциальными технологиями. Нереалистичность замысла, недостаточность доступной ресурсной базы, отсутствие протоколов, правил и порядка доступа к ресурсам — все это серьезные препятствия реализации проекта.
И наоборот, при наличии замысла, ресурсов и логичных планов проект может запуститься, если попадает в стартовое окно возможностей. Если в проекте отсутствует поднадзорность и доказательства целевого расходования средств, то никакого количества ресурсов не хватит для достижения цели.
Итак, мы разобрали, что есть три вырожденных случая проектов — рабочие группы, мероприятия и комитеты. Полноценный проект рождается при сочетании замысла, ресурсов, привлеченных под его реализацию и временной организации, созданной под заданные цели, задачи, контекст и условия. Как появилось такое понимание проекта и как мы его утратили?
История формирования и размывания понятия проекта
Сейчас под проектом подразумевают некую “движуху” с неопределенным исходом. Но уже к концу 19 века, как мы видим из словаря Даля, сформировалось более-менее современное понимание проекта. В какой последовательности к нам приходило осознание проекта как “комплекса взаимосвязанных мероприятий, который направлен на пошаговое воплощение единого замысла, при этом на время исполнения проекта мобилизуются ресурсы одной или нескольких организаций в их уникальной комбинации”? Как и почему это понимание выродилось до “движухи”?
Из предыдущей части понятно, что в проектной деятельности есть три части — подготовка к мобилизации, мобилизация и подведение итогов и результатов мобилизации. Непосредственно проектом называется то, что происходит после мобилизации, например, в виде совещания по запуску проекта, и до формального закрытия и подведения итогов.
А вот управление проектом как дисциплина охватывает и предпроект и его закрытие, всю деятельность по подготовке и исполнению проекта, включая подведение его итогов. И проектного менеджера могут назначить еще до того, как проект сформирован в достаточной степени для его запуска, например, перед первым совещанием по запуску проекта.
Проработанный в достаточной степени для целей создания временной организации и начала работ по проекту замысел появляется только после второго совещания по запуску, но руководитель этой временной организации, проектный менеджер, может появиться и раньше, с самого начала основания проекта.
Еще раз обращу внимание на этот важный момент, который многие начинающие не до конца понимают — запуск проекта в первую очередь означает создание временное организации, которая основывается под цели и обоснование целевого выделения ресурсов. Совсем не просто так документ, который основывает эту организацию, в Руководстве к своду знаний по управлению проектами назван “Уставом проекта”, Project Charter. Это устав новой организации, которая будет существовать, пока не будут достигнуты цели проекта либо учредителем не будет признано, что достичь целей невозможно.
Проектный менеджмент описывает практики, инструменты и методы создания такой организации, управления ее деятельностью и объясняет, как правильно ликвидировать, закрывать эту организацию, не оставляя невыполненных обязательств, незавершенных договоров или неполных проектных архивов и баз знаний.
Показательные моменты становления дисциплины проектного менеджмента и его утраты
До начала 20 века проекты почти всегда были исключительно государственными или около государственными инициативами — начиная от строительства кораблей и освоения индийских и американских колоний и заканчивая прокладкой трансатлантического телеграфного кабеля. Начиная с 1950-х проектный менеджмент начинают осваивать частные компании и наступает эпоха глубокого разделения труда и специализации, в 1954 году появляется профессия проектного менеджера, аналогично тому, как за сто лет до этого выделилась профессия наемного менеджера. В начале 2000-х проектный менеджмент становится распределенным, проникает во многие части организаций и предприятий, появляется множество инструментов автоматизации этой работы, и к 2020-м мы пришли с крайне размытым пониманием того, что же такое проектный менеджмент организаций.
История становления дисциплины
Хотя первое крупносерийное судостроение было организовано в 14 веке в Венецианском Арсенале, все же массовая и длительная потребность в проектах как осознанного создания результата под специфические цели возникла в эпоху Великих географических открытий 15–17 вв. [4]. Специально под дальние плавания спроектировали каракки и каравеллы, которые потом сменились галеонами. Команды кораблей носили ружья и пистолеты, а сами корабли вооружались пушками. Постоянно совершенствовались средства навигации и методы картографии, подготовка и выучка корабельных команд. Реализация множества таких технических и организационных проектов дала возможность европейским морским державам контролировать захваченные колонии и стремительно богатеть [5].
В 17 веке европейские морские державы создают семь Ост-Индских компаний, которые выкачивают ресурсы из колоний, происходит консолидация огромных ресурсов. В результате формируются первые национальные государства с едиными системами мер и весов и с государственной статистикой как управленческим инструментом для сбора налогов и анализа положения дел на местах. Попутно с этим появляются первые предприниматели-капиталисты, люди не аристократического происхождения, но с большими деньгами и собственностью.
В это время происходит активный перенос и освоение судостроительных проектов и практик навигации между странами, например Петр I проходил стажировку в Голландской Ост-Индской компании в 1697 году.
Очень условно, к 1850 году произошла основная консолидация ресурсов, которая была оформлена Венской системой международных отношений и появлением империй — Британской в 1876 г., Германской в 1871 г., Французской в 1852 г. К этому же моменту закончились Англо-Американские войны, прошла колонизация и освоение Дикого запада, в самом разгаре была Калифорнийская золотая лихорадка, а с 1870 г. до конца века в США был Позолоченный век и появились бароны-разбойники (Рокфеллер, Мелон, Карнеги, Морган, Вандербильт).
Как следствие консолидации ресурсов появился избыток денег и установилось понятие денег как капитала. В 1859 г. К. Маркс издает “К критике политической экономии”, а в 1867 г. издает “Капитал”. Избытком денег потребовалось грамотно распоряжаться, а дети баронов-разбойников часто не обладали должной хваткой, и появились профессиональные администраторы и школы их подготовки, master of business administration. The Wharton School была основана в 1881 г., Tuck School of Business в 1900 г., Harvard Graduate School of Business Administration в 1908 г. Менеджмент стал порождать формальный документооборот, в т.ч. и для целей управления проектными инвестициями.
Важно понимать, что до середины 19 века крупный частный бизнес не существовал, первое определение что же такое корпорация дал Верховный суд США в 1819 г. До этого были условные госкомпании: Ост-Индская компания, Венецианский арсенал, Голландские верфи, которые жили по принципу: “Что значит у вас деньги кончились? Вы что, не знаете, где казна находится?” С появлением менеджмента возникло принятие решений на основе капитала, капитализации и прибыли, а не монаршей воли.
Сменилась управленческая концептуализация — проект стал рассматриваться как инвестиция, приводящая к росту капитала, а не как государственная надобность, которую надо выполнить любой ценой.
Частные железнодорожные компании активно развивали практики удаленного контроля и управления и создали к началу 20 века стандартные бланки, формы, отчеты и, главное — папки с подшивками документов и файловые кабинеты с картотечной системой [6]. Папка с подшивками документов произвела переворот в администрировании бизнеса и позволила корпорациям вчистую выигрывать конкуренцию у малого бизнеса.
Появились телеком компании, например, Лаборатории Белла, и первые вычислительные технологии, табуляционные машины, которые производила IBM. Но, несмотря на то, что степень формализации административной деятельности продолжала расти, проектная деятельность все еще не отделялась от текущей хозяйственной деятельности компаний, учет был общий. И самое главное — действие и мышление не было разделено в ранних корпорациях, администратор писал планы работ для себя, проектные документы почти не использовались для координации сами по себе, администратор пояснял их и комментировал, каждый раз создавая правильный контекст.
Знания в проектах не были формализованы, развивались и исчезали вместе со своими носителями. Проектная документация еще не содержала в себе весь нужный для ее понимания контекст, документ не был самостоятельной единицей информации и был почти бесполезен без его автора. Эпоха проектирования еще не наступила.
Ревущие двадцатые принесли с собой логический позитивизм, разработанный в Венском кружке и семиотику как науку о коммуникативных системах и знаках, которые мы используем в процессе общения. И эти открытия легли в основу технологий создания формальных систем знаний.
Стали распространяться стандартизованные нотации для записи проектных замыслов — конструкторских чертежей и проектных планов. Международная электротехническая комиссия была образована в 1906 г., ANSI в 1918 и в 1931 г. они объединились. Комитет по стандартизации немецкой промышленности был организован в 1917 г., а Комитет по стандартизации при Совете труда и обороны СССР в 1925 г.
Инженерные и управленческие знания стали записываться особым, проверяемым способом. Вдобавок к национальной стандартизации появилась и международная. Первые согласованные условия международной торговли выпустила новообразованная Международная торговая палата в 1923 году. В этом документе, который получился после трехлетнего исследования обычаев делового оборота в 13 странах, специалисты зафиксировали шесть наиболее часто используемых терминов — FAS, FOB, C&F, CIF, Ex Ship и Ex Quay.
Термин “проект” обрел оба современных значения — и как дизайн, конструкция, устройство, и как экономически обоснованный способ производства работ по воплощению задуманного дизайна, конструкции. План-график и бюджет проектной деятельности подчинился примату эффективности, апологетом которой был не особо успешный администратор, но крайне успешный консультант и инфобизнесмен Генри Гантт, успешно распространявший свой научный менеджмент.
Однако кроме Генри Гантта был еще и Генри Форд, человек, который впервые придумал производить “изделие” (product) — типовую штуку, которую можно производить и продавать большими объемами. Чтобы продавать свой Форд Модель Т, он создал сеть гарантийных мастерских, подготовил производство запчастей, наладил вертикально-интегрированное производство с настоящим Госпланом внутри корпорации. Необычайный успех Форд Модели Т привел к не только к популяризации конвейера, но и к распространению стандартизации, унификации и развитию поточного производства изделий.
Благодаря этому стал возможен воспроизводимый трансфер технологий, например, Форд перенес производство моделей Форд-А и Форд-АА на Горьковский автомобильный завод. Действие и мышление стали разъединяться — проектировщики могли уже вообще не участвовать в строительстве заводов и производстве изделий и все время проводить внутри конструкторских бюро. Формальная запись знаний позволяла неограниченно углублять специализацию и увеличивать производительность умственного труда, строить планы и писать отчеты с любым уровнем детализации. Было ощущение, что репрезентация действительности в документах были не особо хуже личного опыта, а если так, то зачем месить грязь ногами на очередной великой стройке? Что-то аналогичное происходит сейчас в развитом мире в рамках создания цифровых двойников, организации цифрового проектирования и безлюдных производств [7].
Следующий скачок развития проектного менеджмента произошел во время Второй мировой войны, когда возникла необходимость производить комплексы изделий — на изделие самолет устанавливалось изделие пулемет, изделие авиационная пушка, изделие радиостанция, изделие радарная установка и все эти элементы должны были корректно взаимодействовать, быть увязаны между собой, хотя и проектировались разными конструкторскими бюро и изготавливались на разных заводах.
Появились главные конструкторы, самые опытные инженеры, которые отвечали за то, чтобы комплекс в целом выполнял возложенные на него задачи и отвечал целям его создания. Плюс ко всему, многие такие комплексы, которые стали называть “системами”, производились во множестве исполнений, например, бомбардировщик Б-17 выпускался в 39 вариантах комплектации и выпускался тысячами. Чтобы заказать изготовление и доставку правильного количества правильных деталей и потом собрать запланированное количество самолетов нужных моделей, потребовалось разработать практики управления составом и конфигурацией систем, управлением версиями и инженерными изменениями. Зародилась системная инженерия и дисциплина управления программами проектов [8].
В 1959 г. Пол Гэддис из компании “Вестингхауз Электрик” пишет статью “The Project Manager” в Harvard Business Review и многие бизнесмены осознают, что проекты стали настолько сложны, что ими должны руководить не главные конструктора и главные инженеры, а специально обученные люди — проектные менеджеры, которые будут отвечать не только за реализацию инженерного замысла, но из за экономическую составляющую проекта, за все аспекты проектирования, изготовления, строительства и сооружения.
Развитие семиотики и лингвистики Ч. Моррисом и Н. Хомски, постоянное обсуждение и применение самых свежих теоретических построений с инженерами применительно к реальным проектам и проблемам в местах наподобие Здания 20 [9, с. 20], приводит к становлению основы для радикального усиления интеллекта Возникает и осознается ключевая посылка проектного управления — мир можно представить в виде текста и моделей. Пиком этого скачка была “The Mother of All Demos” (под Demo, демонстрацией подразумевается классический формат презентации инноваций, представленная Дугласом Энгельбартом в 1968 г.
Проектный менеджер с усиленным интеллектом, имеющий системные модели и цифровое представление объекта строительства на долгие десятилетия стал мечтой и целью, к которой стремились тысячи ученых, инженеров и бизнесменов. Но мир, похоже, в своей цифровой революции свернул не туда [10].
С 60-х и до конца 90-х проектный и программный менеджмент совместно с системной инженерией активно развиваются; появляются не просто формальные представления, но и машиночитаемые и автоматически исполняемые способы записей проектных планов в виде календарно-сетевых графиков и таблиц с бюджетами, и даже проектных замыслов [11].
Во множестве инженерных стандартов развивается понятие интероперабельности и кажется вот-вот и проблема полностью автоматизированного управления проектами из единого центра будет решена — замысел будет записан машиночитаемым методом, проектный офис создаст планы, под которые будет проведена мобилизация ресурсов. Но как и большинству других утопических начинаний [12] и [13]. Наступает зима инженерных онтологий [14]. Некоторые исследователи стали это признавать уже в начале 2000-х [15], а уж в 2010-х это стало понятно почти всем [16].
Переломный 1968 г. или история спада дисциплины
Но как произошло вырождение дисциплины? По обычному пути размывания понятий, ослаблению причинно-следственной логики, которое неизбежно возникает, если какая-то тема становится популярной и начинает приносить деньги, славу и уважение.
В 1969 г. в Технологическом институте Джорджии была основана некоммерческая организация PMI, которая занялась разработкой стандартов управления проектами. В то время PMI еще активно сотрудничала с швейцарской Международной Ассоциацией Управления Проектами IPMA. IPMA занималась развитием компетенций проектных менеджеров, а PMI стандартизацией свода знаний по управлению проектами. Вершиной еще сравнительно совместной их работы можно считать изданное в 2004 г. Третье издание Руководства к своду знаний по управлению проектами, военный вариант которого был гармонизирован с дисциплиной системной инженерии [17].
Сверхпопулярность проектного менеджмента, однако, привела к тому, что в эту область пришли люди, настроенные не на развитие дисциплины, а на зарабатывание денег. PMI по факту перестала быть некоммерческой организацией, стала зарабатывать на продаже стандартов и сертификации и снижать планку. Руководства к своду знаний по управлению проектами от версии к версии пухли и становились все менее четкими и конкретными, а сертификационный экзамен сократился с шести часов до четырех.
В 1995 IPMA создал свою модель компетенций ICB, а в 2002 г. PMI выпустил свой фреймворк компетентности проектных менеджеров PMCDF. А уж про то, что проектный менеджер во многом вышел из методов и практик системной инженерии, который описывала INCOSE, и PMI и IPMA предпочли забыть, ни одного упоминания про существование системной инженерии в основных публикациях PMI до 2012 г. [18] не встретить.
Международная кооперация в этой области пала под натиском желания наживы, точно так же, как это произошло с компьютерами парой десятилетий раньше, когда идеи С. Джобса победили идеи Д. Энгельбарта. Когда изначальная команда разработчиков системноинженерного стандарта ISO 15288:2005 по управлению жизненным циклом систем декларировала в 2001 г. своей целью “сохранение знаний и практик, накопленных стареющим поколением инженеров и руководителей за десятилетия реализации масштабных проектов для поколения молодых”, она не знала, что к 2005 г., в год выпуска первой версии стандарта, все эти знания станут по множеству причин невостребованными и начнется активный пересмотр и критическое переосмысление дисциплины [19].
СССР во многом был изолирован от происходящего по двум причинам — достать нужную литературу было почти невозможно, на конференции и конгрессы никого не выпускали, но самое главное — из-за особого отношения руководства СССР к гуманитарным наукам российские исследователи попросту не владели риторикой и практиками академического письма и не могли писать в соответствии с мировыми стандартами публикаций [20]. А без донесения своих мыслей мы развивались в изоляции, что, однако, до середины 80-х не сильно влияло на общий уровень подготовки, см. [21], [22] и в СССР была своя сильная школа подготовки инженерных руководителей.
Кроме распада международной кооперации и превращения практических стандартов в коммерческие продукты, на дисциплину проектного менеджмента наступала цифровизация, которая уже шла не в том направлении и точно также была нацелена на шальные инвестиционные деньги и массовые продажи, а не на оптимальную поддержку аппарата и приемов мышления.
Помимо компьютерных программ для составления календарных графиков появились трекеры, системы коллаборации [23], и маркетинговые отделы, которые продвигали эти продукты, позиционировали их как инструменты проектного управления, потому что это помогало продавать. Компании и организации закупали ПО и вкладывались в ИТ-инфраструктуру, разрабатывали под все это свою методологию управления проектами, и закрепляли, институционализировали таким образом это новое состояние дел. Если за дело брались хорошие методологи с большим практическим опытом, то получалось хорошо [24], однако чаще созданием методологий и построением автоматизированных систем занимались люди с университетским уровнем подготовки и со средним опытом, и тогда ландшафты решений получались далеко не такими красивыми.
Поверх этих двух базовых трендов повлияло еще и распространение небольших фреймворков типа Getting Things Done Аллена, 8D reports, Toyota A3, fishbone diagramming и прочие методы решения проблем (issue resolution), в которых “проектом” называлась совместная работа рабочей группы по решению проблемы, а то и вовсе некое не элементарное действие одного человека. Разрастание ИТ-систем привело к появлению команд, которые занимались доработкой ПО и поддержкой серверов, и эта работа тоже стала называться “проектами”, хотя и без конца и начала. И это размывание содержания понятия продолжалось до тех пор, пока не достигло современного понимания, когда есть некая потенциально ничем не ограниченная разработка ПО или даже цифровых устройств, про которую уже и не скажешь, что она является проектом, потому что ни цели ни ограничений по срокам уже и нету.
Все смешалось в кучу, например, в докладе Microsoft DevOps Report [25] есть рекомендация, что необходимо отказаться от проектного менеджмента и создавать цифровые продукты в рамках “продуктовых команд”. Но если посмотреть в суть этой рекомендации, то окажется, что под “разработкой продуктовыми командами” авторы доклада подразумевают обычное управление программами проектов, которое всегда входило в дисциплину проектного менеджмента, возьмите вы хоть PMI OPM3 хоть Axelos P3M3.
Смысл проектного менеджмента окончательно потерян в дебрях терминов, программных реализаций понятий, методов и подходов и бесконечных методологиях и обучающих курсах. «Все эти пять характеристик: точность предсказаний, их непротиворечивость, область применимости, отсутствие избыточности в понятийном аппарате и полезная интерпретация фактов — стандартные критерии оценки адекватности теории», по [26]. По всем этим пяти характеристикам в свое время дисциплина проектного менеджмента была весьма неплоха. Что же явилось причиной упадка дисциплины и потери ею точности и предсказательной силы? Откуда пошла избыточность понятийного аппарата и куда делась полезная интерпретация фактов?
Первым возможным объяснением является неаккуратное применение процессов адаптации, tailoring. Суть их заключается вот в чем. Как уже сказано выше, описанные в том же руководстве к своду знаний по управлению проектами практики являются рекомендованными для проектов с бюджетом больше 20 млн. долларов США, длительностью больше 12 месяцев, численностью персонала свыше 200 человек и довольно сложным и уникальным результатом. Но если бюджет будет 15 млн. вместо 20, длительность 10 месяцев вместо 12, штат 150 человек, а результатом проекта является модифицированный на 25% уже существующий продукт компании, то можно какие-то практики использовать неформально, какие-то шаги пропустить, а формы не заполнять. Все на усмотрение проектного менеджера и команды управления проектом. Но кто определил, где проходит граница, ниже которой адаптация теряет смысл? Как понять, какой инструмент и как применять? Это знание может приходить только из опыта, и в какой-то момент рынку просто не хватило достаточного количества квалифицированных специалистов, и появилось множество неправильных внедрений проектного менеджмента и некорректного применения инструментов, что заметно подпортило репутацию дисциплины. Это объяснение из разряда: “Слышал я эти ваши Битлз, фальшивят, картавят.” — “Да откуда?” “А мне Мойша напел.”
Вторым объяснением является проблема позитивистского подхода и сложность практик управления составом и управления конфигурациями вообще. Напомню, что основным положением дисциплины, сформировавшейся на начало 2000-х, было то, что описания в виде проектных планов, спецификаций, документов и структур данных могут полностью представлять создаваемую или модифицируемую систему и работы по ее разработке и воплощению. И тут возникает проблема — крупные системы наподобие нефтяной платформы, самолета, завода, состоят из пяти-шести миллионов составных частей. Если описание должно отражать мир, то у каждой части должно быть свое уникальное имя, а активный словарь человека не превышает пяти тысяч слов. В результате при разработке требуется серьезная терминологическая работа и инструментальная поддержка, обеспечивающая корректность создаваемых описаний. А т.к. многие потребительские товары, особенно автомобили, имеют множество опций, которые выбирают покупатели, то количество вариантов исполнений может легко превышать несколько миллионов и даже миллиардов. И получается, что современный проектный менеджмент требует создания огромной и трудоемкой инфраструктуры, переобучения людей и перестройки мышления руководства. На Западе эти процессы шли десятилетия, практики и инструменты осваивались постепенно. Но когда вперед рванули развивающиеся страны, и одновременно производства и разработка ушли из традиционных центров компетенций в США, Германии, Франции, Швеции, то и компетенции во многом были утрачены и собственники были не готовы так серьезно вкладываться в перестройку своих бизнесов. И эта проблема наблюдалась не только в развивающихся странах, но и по всему миру.
Список основных проблем управления инженерными программами по [18]:
- Борьба с пожарами — запаздывающее исполнение программы.
- Нестабильные, нечеткие и неполные требования.
- Недостаточная согласованность и нескоординированность производственной кооперации.
- Практики оптимизированы локально и не учитывают работу предприятия в целом.
- Нечеткие роли, ответственность за исполнение и ответственность за результат.
- Запущенная культура программы, невнимание к компетенциям и знаниям команды.
- Недостаточное планирование программы.
- Неправильно выбранные показатели, системы показателей и KPI.
- Недальновидное управление рисками.
- Плохое управление закупками и контрактацией.
Третьим объяснением является распространение программно-насыщенных систем (software-intensive systems) и тотальное распространение проектов реинжиниринга и перестройки уже существующих систем и комплексов систем, т.н. brownfield systems [27]. Проблема с разработкой программно-насыщенных систем с существенной составляющей программного обеспечения в работах проекта заключается в нематериальности ПО. Очень сложно построить какую-то систему мониторинга, которая бы давала достаточно информации для понимания почему ПО работает и почему не работает. И это существенная особенность, отличающая разработку ПО от проектирования “железных” систем [28]. Слишком сложные взаимодействия плохо задокументированных систем ломают любые предположения, оценки и планы и не позволяют напрямую использовать классические методы проектного управления.
Итак, для применения проектного менеджмента нужна адаптация процессов управления проектами, которые не очень ясно как делать. У компаний может не быть необходимой инфраструктуры и обученных людей, а сама дисциплина требует постоянной терминологической работы и значительной перестройки мышления, в том числе топ-менеджеров и собственников, заведомо не готовых посвятить большое количество времени на изучение чего-то принципиально нового. Накопленный багаж легаси-систем и требования обратной совместимости чрезвычайно усложнили и без того сложную проектную логику, а отказаться от brownfield и создать новый комплекс систем экономически нецелесообразно и крайне рискованно для бизнеса.
Результатом является применение практик проектного управления для комплексов работ, который с точки зрения дисциплины проектного менеджмента является вырожденным проектом, т.к. у него отсутствует какая-то из важнейших характеристик — замысел, временная организация и мобилизация ресурсов. Организации и предприятия стали массово управлять вырожденными проектами и теряют способность управлять подлинными проектами. Да что там говорить, автор неоднократно сталкивался в консалтинге с ситуацией, когда руководители не способны увидеть и оформить предпринимаемый ими проект или программу проектов и распознают только какие-то части проектов и программ, никак не связывая эти части между собой. Еще больше проблем возникает, когда компания пытается выстроить общую архитектуру работ по всем программам и проектам, чтобы корректно распределить ресурсы, людей и сформировать правильные границы ответственности.
В теории все портфели, программы и проекты должны выстраиваться в строгое дерево, но мало у кого действительно получается договориться по поводу иерархии портфелей, программ и проектов. Мы потеряли целое пространство рассуждений о проектах — ведь если мы не можем сформировать корректную структуру и подчиненность проектных инициатив, то не можем поместить каждый конкретный проектный план в нужный контекст обсуждения, и, соответственно, не можем принять согласованных решений. В результате проектный менеджмент не разгружает руководство, а создает им дополнительные проблемы. И, конечно, руководство не хочет платить за то, чтобы проблем у них становилось больше. Ситуация выглядит почти безвыходной.
Но не является ли то, что кажется закатом дисциплины, зарождением чего-то нового? Правильно ли мы классифицируем наблюдаемый феномен? Нет ли альтернативной, более полезной концептуализации происходящего? Как объяснить успешные примеры освоения проектного менеджмента [29] [30]? Вкладывали ли проектные менеджеры старой школы в разработанные стандарты тот смысл, который мы сейчас из них вычитываем [31] [32] [33]?
Определения и мыслительный аппарат
Я решил стать проектным менеджером, когда увидел одного из них в действии. Это был швейцарец, которого послал нам головной офис. Мы тогда забуксовали с запуском проекта на целый месяц и он прилетел нам помочь. В первые же пару дней он сдвинул с места все работы, которые, нам казалось, встали намертво. Он решал кучу вопросов прямо на ходу, задавая правильные вопросы правильным людям. При этом пользовался он тремя инструментами — салфетками в столовой, где он проводил половину времени, разговаривая с участниками проекта за чашкой кофе; флип-чартом в переговорных комнатах; и калькулятором. Никогда до этого не видел, чтобы человек так много считал. Когда я спросил его почему он так много считает он ответил: “Без цифр в планах и отчетах проектный менеджмент — это разновидность корпоративной астрологии.” Сейчас, спустя много лет, я не могу с ним не согласиться. Цифры-цифры-цифры, вот что важно. И один из симптомов того, что с проектным менеджментом что-то не так — это недостаток цифр в прогнозах, отчетах и оценках.
Но прежде чем в следующих статьях этой серии перейти к цифрам, надо разобраться с пониманием, с кругом понятий, который необходим для разбирательства с вырожденными и полноценными проектами. У швейцарского руководителя проектов это понимание было и ему не требовались инструменты, по крайней мере для нашего несложного проекта. Достаточно было записной книжечки и флипчарта. А если бы этого понимания не было, то никакой программный пакет бы ему не помог. Ниже я буду использовать термины, но термины не важны, важно понимание. Понимание — это попадание наших наблюдений в “клеточки” понятий, распознавание ситуаций, паттернов и применение соответствующей логики, рассуждений и действий. Если мы смотрим на протокол собрания и видим пункт, который мы классифицируем как требование заказчика, то дальше наши действия предопределены. Нам надо внести этот пункт в систему управления требованиями, расписать план работ по реализации этого требования, провести анализ, выполнить это требование и проверить правильно ли мы все сделали. Дисциплина определяет наши действия.
Какие различения важно провести, чтобы начать правильно обсуждать проектный менеджмент? В первую очередь надо четко осознать, что проектный менеджмент является коллективной деятельностью. Коллективная деятельность во-первых, по большей части не рефлексивная, неосознанная, автоматическая, это знает любой, кто делал внедрение корпоративных систем или писал регламенты. А так как проекты уникальны, то эта неосознанная автоматическая деятельность часто “ломается” из-за необычных обстоятельств или необходимости принять нетиповое решение. Одна из важных задач, которую решает проектный менеджер — это восстановить нормальный ход дел после такой “поломки”. И, наконец, поскольку проект является инвестицией, мы сталкиваемся с властью, политикой и подотчетностью. Эти три фактора проектной деятельности определяют необходимый круг понятий, без которых сложно объяснить, что же происходит сейчас, к чему это все может привести и что надо сделать, чтобы избежать неблагоприятного развития событий.
Круг понятий проектного менеджмента
Повседневные практики — рутинные, неосознанные действия, с помощью которых люди добиваются нужного результата и к которым автоматически все подстраиваются. Например, повседневные практики общения в мессенджерах или повседневные практики сбора подписей на листе согласования проекта договора.
Фрейм — структурный контекст повседневного взаимодействия, наши знания и ожидания от ситуации. Фрейм совещания, например, формирует наши ожидания от поведения участников, и если вдруг у собеседника по Zoom доносится бытовой разговор, то мы сразу думаем, что это не подходит к ситуации, находится вне контекста. Аналогично, если человек во время обсуждения достает телефон и начинает смеяться, становится непонятно, осознает ли он что сейчас вообще происходит. Для результативной работы крайне важно создавать и выдерживать правильный фрейм, для чего проектный менеджер делит проект на этапы, фазы, стадии и для каждой из них формирует систему фреймов.
Ситуация — состояние дел, воспринимаемое в определенном фрейме. Например, уход заказчика из проекта после очередного совещания с позиций фрейма “все пропало” воспринимается как трагедия и кризис. Если ситуацию перефреймировать как переговоры, то все что мы видим — это смена позиции другой стороны и тогда нам совершенно ясно, что надо делать, никакого кризиса нет.
Мисфрейм, непонятки — потеря понимания и ориентации из-за того, что текущий фрейм не дает нам подсказок по дальнейшим действиям. Например, обычно вежливый и сдержанный человек срывается на вас, кричит и требует непонятного. Или правительство объявляет локдаун и вам надо за неделю перенастроить все процессы на удаленную работу. Задачей проектного менеджера является устранить мисфрейм, фреймировать ситуацию, обычно привлекая внимание к тому, в каком этапе, стадии находится проект или какую следующую контрольную точку необходимо пройти и что для этого надо сделать.
Проблема — ситуация, с которой решено что-то сделать, чтобы она больше не повторялась. При этом, например, она могла долгое время не быть проблемой и ничего могло не меняться. Например, компания много лет периодически задерживает выплату зарплаты, но вдруг в какой-то момент решает, что больше так продолжаться не может. Или каждый проект закрывается “со скрипом” и заказчики требуют потом многочисленных доработок до тех пор, пока исполнительный директор не стукнет, наконец, кулаком по столу и не потребует решить вопрос. Проблема часто является причиной запуска уже проработанного проекта либо запускает проработку проекта.
Этапы, стадии, контрольные точки — строительные блоки проекта, основной объект внимания проектного менеджера. Особая форма проектных задач, мероприятий, которая состоит из задач исполнителей (т.е., является суммарной задачей) и некоторых решений, например, о порядке предъявления на испытания, объеме сдаваемой документации, определении обязательств заказчика и исполнителя. Контрольная точка является вырожденным случаем этапа, стадии или другой крупной проектной задачи, у которой задана только дата окончания, предъявления результатов. Сдача этапов, стадий и закрытие контрольных точек часто сопровождается хотя бы некоторой формой защиты, аналогичной защите при закрытии проекта. Поэтому часто такие задачи тоже называют проектами.
Проект — комплекс взаимосвязанных мероприятий, который направлен на пошаговое воплощение единого замысла, при этом на время исполнения проекта мобилизуются ресурсы одной или нескольких организаций в их уникальной комбинации. Проект строится из этапов, стадий и контрольных точек, и главной задачей проектного менеджера является постоянная подгонка этапов и контрольных точек друг к другу как проектируемых и создаваемых инженерных конструкций. Методы проектного менеджмента в этом смысле имеют инженерную природу.
Проектная деятельность — все работы по созданию временной организации, выполнению работ проекта и закрытию временной организации. Проектная деятельность построена на дисциплинах проектного менеджмента и организационного проектирования (орг.дизайна).
Мобилизация — деятельность по привлечению ресурсов в проект, которая происходит по определенным правилам взаимодействия с властью, которая распоряжается необходимыми ресурсами.
Рамки проекта — поле деятельности, в границах которого можно применять мобилизованные в проект ресурсы и не быть наказанным за их нецелевое использование.
Команда управления проектом — ближайшие соратники и единомышленники проектного менеджера, на которых он может положиться при принятии решений.
Власть, проектный комитет, спонсор — владельцы ресурсов, которые санкционируют создание временной организации, контролируют ее деятельность и целевое использование ресурсов и могут приостановить ее работу либо поменять проектного менеджера.
Ресурсы — все, что необходимо для реализации проекта и что является предметом учета, планирования и контроля в проекте.
Подотчетность — правила и процедуры привлечения проектного менеджера или участников проекта к ответственности за нецелевое использование ресурсов, выделенных в проект.
Координация — форма организации взаимодействия участников проекта, включая власть, команду управления проекта, стейкхолдеров, поставщиков и подрядчиков, при которой у участников проекта нет разногласий по поводу проектных целей и в которой проектный менеджер согласует совместные коллективные действия участников.
Коллаборация, кооперация — форма организации взаимодействия участников проекта, при которой у участников проекта разные цели и задачи, вплоть до конфликтующих, и в которой проектный менеджер организует передачу результата между участниками по определенному проектными планами маршруту. Задачи обеспечения кооперации и коллаборации не могут решаться одновременно, проектный менеджер при выполнении этапа или прохождении контрольной точки выбирает только одну из них.
Выводы и дискуссия
Из-за близости смыслов в обсуждении часто путается “проектная деятельность” и “проекты”. Строгость обсуждений часто не выдерживается и в результате понятие проекта чрезмерно раздулось и потеряло содержание. В особенности опасной для дисциплины тенденцией является потеря знаний и технологий работы со строительными блоками проектов — этапами, фазами, инкрементами, итерациями, барьерами принятия решений (project gates) и контрольными точками. Если раньше им уделялось большое внимание, то сейчас такие строительные блоки часто воспринимаются просто как списки задач или суммарные задачи, что в корне противоречит их транзакционной природе и зыбким и дискуссионным границам.
Для сохранения и развития дисциплины проектного менеджмента важно восстановить знания и технологии работы с этапами, фазами, инкрементами и итерациями (проектными или транзакционными задачами, activities), а не работать с ними как с вырожденными проектами, которыми они не являются. Практики работы с транзакционными задачами являются самой проработанной технологией обеспечения эффективной координации и коллаборации в проектах, особенно в сложных brownfield проектах по модернизации и доработкам программно-насыщенных систем. В статье предлагается минимально необходимый понятийный минимум для обсуждения методических проблем и задач управления проектами, связанных с тематикой транзакционных задач.
Однако, сам феномен распространения вырожденных проектов, которые соответствуют проектным задачам в классическом проектном менеджменте, ставит перед исследованием вопрос. А не должен ли у дисциплины проектного менеджмента появиться второй объект исследования и управления, помимо проекта как временной организации, которая создается под цели — проектная задача? Не надо ли изучать их отдельно? Ответу на этот вопрос и будет посвящено мое дальнейшее исследование.
Литература и источники
[1] P. Rita Mulcahy, PMP exam prep. RMC publications, 2009.
[14] «Онтологии и SysMoLan». https://ailev.livejournal.com/1449992.html (просмотрено дек. 15, 2021).
[32] «Мифический Waterfall». http://reqcenter.pro/waterfall-myths/ (просмотрено окт. 19, 2021).
