Как понятие проекта раздулось до полной потери смысла и что с этим делать? ч.3

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

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

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

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

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

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

В 1969 г. в Технологическом институте Джорджии была основана некоммерческая организация PMI, которая занялась разработкой стандартов управления проектами. В то время PMI еще активно сотрудничала с швейцарской Международной Ассоциацией Управления Проектами IPMA. IPMA занималась развитием компетенций проектных менеджеров, а PMI стандартизацией свода знаний по управлению проектами. Вершиной еще сравнительно совместной их работы можно считать изданное в 2004 г. Третье издание Руководства к своду знаний по управлению проектами, военный вариант которого был гармонизирован с дисциплиной системной инженерии (“Extension to: A Guide to the Project Management Body of Knowledge (PMBOK® Guide) First Edition Version 1.0,” 2003).

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

В 1995 IPMA создал свою модель компетенций ICB, а в 2002 г. PMI выпустил свой фреймворк компетентности проектных менеджеров PMCDF. А уж про то, что проектный менеджер во многом вышел из методов и практик системной инженерии, который описывала INCOSE, и PMI и IPMA предпочли забыть, ни одного упоминания про существование системной инженерии в основных публикациях PMI до 2012 г. (Oehmen J. et al., 2012) не встретить.

Международная кооперация в этой области пала под натиском желания наживы, точно так же, как это произошло с компьютерами парой десятилетий раньше, когда идеи С. Джобса победили идеи Д. Энгельбарта. Когда изначальная команда разработчиков системноинженерного стандарта ISO 15288:2005 по управлению жизненным циклом систем декларировала в 2001 г. своей целью «сохранение знаний и практик, накопленных стареющим поколением инженеров и руководителей за десятилетия реализации масштабных проектов для поколения молодых», она не знала, что к 2005 г., в год выпуска первой версии стандарта, все эти знания станут по множеству причин невостребованными и начнется активный пересмотр и критическое переосмысление дисциплины (Svejvig and Andersen, 2015).

СССР во многом был изолирован от происходящего по двум причинам - достать нужную литературу было почти невозможно, на конференции и конгрессы никого не выпускали, но самое главное - из-за особого отношения руководства СССР к гуманитарным наукам российские исследователи попросту не владели риторикой и практиками академического письма и не могли писать в соответствии с мировыми стандартами публикаций (Короткина, 2014). А без донесения своих мыслей мы развивались в изоляции, что, однако, до середины 80-х не сильно влияло на общий уровень подготовки, см. (“В.Батоврин -- заметки о системной инженерии в СССР.”) и в СССР была своя сильная школа подготовки инженерных руководителей.

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

Помимо компьютерных программ для составления календарных графиков появились трекеры, системы коллаборации (Star S. L., Ruhleder K., 1996), и маркетинговые отделы, которые продвигали эти продукты, позиционировали их как инструменты проектного управления, потому что это помогало продавать. Компании и организации закупали ПО и вкладывались в ИТ-инфраструктуру, разрабатывали под все это свою методологию управления проектами, и закрепляли, институционализировали таким образом это новое состояние дел. Если за дело брались хорошие методологи с большим практическим опытом, то получалось хорошо (Urban-Galindo and Ripailles, 2019), однако чаще созданием методологий и построением автоматизированных систем занимались люди с университетским уровнем подготовки и со средним опытом, и тогда ландшафты решений получались далеко не такими красивыми.

Поверх этих двух базовых трендов повлияло еще и распространение небольших фреймворков типа Getting Things Done Аллена, 8D reports, Toyota A3, fishbone diagramming и прочие методы решения проблем (issue resolution), в которых "проектом" называлась совместная работа рабочей группы по решению проблемы, а то и вовсе некое не элементарное действие одного человека. Разрастание ИТ-систем привело к появлению команд, которые занимались доработкой ПО и поддержкой серверов, и эта работа тоже стала называться «проектами», хотя и без конца и начала. И это размывание содержания понятия продолжалось до тех пор, пока не достигло современного понимания, когда есть некая потенциально ничем не ограниченная разработка ПО или даже цифровых устройств, про которую уже и не скажешь, что она является проектом, потому что ни цели ни ограничений по срокам уже и нету.

Все смешалось в кучу, например, в докладе Microsoft DevOps Report (Microsoft and Sogeti, 2021) есть рекомендация, что необходимо отказаться от проектного менеджмента и создавать цифровые продукты в рамках "продуктовых команд". Но если посмотреть в суть этой рекомендации, то окажется, что под "разработкой продуктовыми командами" авторы доклада подразумевают обычное управление программами проектов, которое всегда входило в дисциплину проектного менеджмента, возьмите вы хоть PMI OPM3 хоть Axelos P3M3.

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

Первым возможным объяснением является неаккуратное применение процессов адаптации, tailoring. Суть их заключается вот в чем. Как уже сказано выше, описанные в том же руководстве к своду знаний по управлению проектами практики являются рекомендованными для проектов с бюджетом больше 20 млн. долларов США, длительностью больше 12 месяцев, численностью персонала свыше 200 человек и довольно сложным и уникальным результатом. Но если бюджет будет 15 млн. вместо 20, длительность 10 месяцев вместо 12, штат 150 человек, а результатом проекта является модифицированный на 25% уже существующий продукт компании, то можно какие-то практики использовать неформально, какие-то шаги пропустить, а формы не заполнять. Все на усмотрение проектного менеджера и команды управления проектом. Но кто определил, где проходит граница, ниже которой адаптация теряет смысл? Как понять, какой инструмент и как применять? Это знание может приходить только из опыта, и в какой-то момент рынку просто не хватило достаточного количества квалифицированных специалистов, и появилось множество неправильных внедрений проектного менеджмента и некорректного применения инструментов, что заметно подпортило репутацию дисциплины. Это объяснение из разряда: «Слышал я эти ваши Битлз, фальшивят, картавят.» - «Да откуда?» «А мне Мойша напел.»

Вторым объяснением является проблема позитивистского подхода и сложность практик управления составом и управления конфигурациями вообще. Напомню, что основным положением дисциплины, сформировавшейся на начало 2000-х, было то, что описания в виде проектных планов, спецификаций, документов и структур данных могут полностью представлять создаваемую или модифицируемую систему и работы по ее разработке и воплощению. И тут возникает проблема - крупные системы наподобие нефтяной платформы, самолета, завода, состоят из пяти-шести миллионов составных частей. Если описание должно отражать мир, то у каждой части должно быть свое уникальное имя, а активный словарь человека не превышает пяти тысяч слов. В результате при разработке требуется серьезная терминологическая работа и инструментальная поддержка, обеспечивающая корректность создаваемых описаний. А т.к. многие потребительские товары, особенно автомобили, имеют множество опций, которые выбирают покупатели, то количество вариантов исполнений может легко превышать несколько миллионов и даже миллиардов. И получается, что современный проектный менеджмент требует создания огромной и трудоемкой инфраструктуры, переобучения людей и перестройки мышления руководства. На Западе эти процессы шли десятилетия, практики и инструменты осваивались постепенно. Но когда вперед рванули развивающиеся страны, и одновременно производства и разработка ушли из традиционных центров компетенций в США, Германии, Франции, Швеции, то и компетенции во многом были утрачены и собственники были не готовы так серьезно вкладываться в перестройку своих бизнесов. И эта проблема наблюдалась не только в развивающихся странах, но и по всему миру.

Список основных проблем управления инженерными программами по (Oehmen J. et al., 2012):

• Борьба с пожарами — запаздывающее исполнение программы.
• Нестабильные, нечеткие и неполные требования.
• Недостаточная согласованность и нескоординированность производственной кооперации.
• Практики оптимизированы локально и не учитывают работу предприятия в целом.
• Нечёткие роли, ответственность за исполнение и ответственность за результат.
• Запущенная культура программы, невнимание к компетенциям и знаниям команды.
• Недостаточное планирование программы.
• Неправильно выбранные показатели, системы показателей и KPI.
• Недальновидное управление рисками.
• Плохое управление закупками и контрактацией.

Третьим объяснением является распространение программно-насыщенных систем (software-intensive systems) и тотальное распространение проектов реинжиниринга и перестройки уже существующих систем и комплексов систем, т.н. brownfield systems (Walden, 2019). Проблема с разработкой программно-насыщенных систем с существенной составляющей программного обеспечения в работах проекта заключается в нематериальности ПО. Очень сложно построить какую-то систему мониторинга, которая бы давала достаточно информации для понимания почему ПО работает и почему не работает. И это существенная особенность, отличающая разработку ПО от проектирования «железных» систем (Pentland, 2018). Слишком сложные взаимодействия плохо задокументированных систем ломают любые предположения, оценки и планы и не позволяют напрямую использовать классические методы проектного управления.

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

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

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

Но не является ли то, что кажется закатом дисциплины, зарождением чего-то нового? Правильно ли мы классифицируем наблюдаемый феномен? Нет ли альтернативной, более полезной концептуализации происходящего? Как объяснить успешные примеры освоения проектного менеджмента (Мицуфуджи Акио, 2021) (Rebovich, 2011)? Вкладывали ли проектные менеджеры старой школы в разработанные стандарты тот смысл, который мы сейчас из них вычитываем? (Lenfle and Loch, 2010) («Мифический Waterfall») (Geraldi, 2012)

Я решил стать проектным менеджером, когда увидел одного из них в действии. Это был швейцарец, которого послал нам головной офис. Мы тогда забуксовали с запуском проекта на целый месяц и он прилетел нам помочь. В первые же пару дней он сдвинул с места все работы, которые, нам казалось, встали намертво. Он решал кучу вопросов прямо на ходу, задавая правильные вопросы правильным людям. При этом пользовался он тремя инструментами — салфетками в столовой, где он проводил половину времени, разговаривая с участниками проекта за чашкой кофе; флип-чартом в переговорных комнатах; и калькулятором. Никогда до этого не видел, чтобы человек так много считал. Когда я спросил его почему он так много считает он ответил: «Без цифр в планах и отчетах проектный менеджмент — это разновидность корпоративной астрологии.» Сейчас, спустя много лет, я не могу с ним не согласиться. Цифры-цифры-цифры, вот что важно. И один из симптомов того, что с проектным менеджментом что-то не так — это недостаток цифр в прогнозах, отчетах и оценках.

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

Какие различения важно провести, чтобы начать правильно обсуждать проектный менеджмент? В первую очередь надо четко осознать, что проектный менеджмент является коллективной деятельностью. Коллективная деятельность во-первых, по большей части не рефлексивная, неосознанная, автоматическая, это знает любой, кто делал внедрение корпоративных систем или писал регламенты. А так как проекты уникальны, то эта неосознанная автоматическая деятельность часто "ломается" из-за необычных обстоятельств или необходимости принять нетиповое решение. Одна из важных задач, которую решает проектный менеджер — это восстановить нормальный ход дел после такой "поломки". И, наконец, поскольку проект является инвестицией, мы сталкиваемся с властью, политикой и подотчетностью. Эти три фактора проектной деятельности определяют необходимый круг понятий, без которых сложно объяснить, что же происходит сейчас, к чему это все может привести и что надо сделать, чтобы избежать неблагоприятного развития событий.

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

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

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

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

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

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

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

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

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

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

Команда управления проектом — ближайшие соратники и единомышленники проектного менеджера, на которых он может положиться при принятии решений.

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

Ресурсы — всё, что необходимо для реализации проекта и что является предметом учета, планирования и контроля в проекте.

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

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

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

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

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

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

Источники:

• В.Батоврин. Заметки о системной инженерии в СССР. 2013
• Extension to: A Guide to the Project Management Body of Knowledge (PMBOK® Guide) First Edition Version 1.0, 2003.
• Geraldi, J. et al. Gantt charts revisited: A critical analysis of its roots and implications to the management of projects today. 2012.
• Lenfle, S. et al. Lost roots: How project management came to emphasize control over flexibility and novelty. 2010.
• Microsoft, Sogeti, Azure Annual DevOps Report - Enterprise DevOps Reporе 2020-21.
• Oehmen J. et al. The guide to lean enablers for managing engineering programs. 2012.
• Pentland, B.T. Bleeding Edge Epistemology: Practical Problem Solving in Software Support Hot Lines, 2018.
• Rebovich, Jr. et al. Patterns of Success in Systems Engineering: Acquisition of IT-Intensive Government Systems. 2011
• Star S. L. et al.. Steps toward an ecology of infrastructure: Design and access for large information spaces 1996
• Svejvig, P. et al. Rethinking project management: A structured literature review with a critical look at the brave new world. 2015
• Urban-Galindo, et al. PLM at GROUPE PSA 2019.
• Walden, D.D. Brownfield Systems Development: Moving from the Vee Model to the N Model for Legacy Systems. 2019
• Короткина, И.Б. Грамотность научного текста: концептуальные расхождения между Россией и Западом и их последствия. 2014
• Кун, Т. Объективность, ценностные суждения и выбор теории. 1996
• Мифический Waterfall
• Мицуфуджи Акио, Мозер Брайан, Хардинг Алан С. Интеграция управления программой и системной инженерии. 2021