Системный подход в анализе проектов

Добрый день, читатели хаба «Управление проектами». Достаточно широко известно, что с точки зрения системного подхода «всех историй не так много», и они называются архетипами (паттернами). Хороший материал в случае проектов можно найти например здесь. Данный же пост представляет собой попытку в жанре записок на салфетках:

1. Представления различных параметров гипотетического проекта (в вакууме) в виде единой causal loop diagram,
2. Некоторого исследования диаграммы, что же получилось.

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

Параметры системы на рассмотрение

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

Итого 22 параметра. Если есть несогласие с тем, что выделено, дальнейшее чтение возможно пользы не принесет, увы.

Связи между параметрами

В принципе, неважно с какого конца начинать рассказ о системе. Для каждой связи будет указан характер влияния одного параметра на другой, то есть каждой дуге будет приписан "+" (увеличение одного влечет увеличение второго) или "-" (увеличение первого влечет уменьшение второго), две палочки будут означать задержку. Все 22*21 взаимосвязей, естественно, рассматриваться не будут, как и выделение параметров — выделение связей вопрос субъективный. Главное ухватить те связи, которые позволят объяснить то, что нужно делать чтобы проект был успешным (или что не нужно делать чтобы невзначай его не провалить).

Кликабельно для скачивания в SVG:

Disclaimer: Это одна из возможных историй взаимовлияния проектных параметров. Каждый может составить свою (с бриджем и моделями).

Некоторые исследования

Что бросается в глаза сразу — у параметра «полнота определения заинтересованных сторон» нет входящей стрелки. Это означает, что (в случае таких связей), что «первый удар от ворот», то есть начальное значение — является определяющим для системы. Если бюджет, сроки и объемы утверждены с теми сторонами, которые были, то дальше любые новые стороны будут уже изменением или риском. А ведь заинтересованной стороной может быть даже самый заурядный новый тип пользователя конечного продукта.

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

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

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

В заключение

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

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

Совсем отсебятина

Вполне вероятно, для кого-то я ничего нового не сказал — ни диаграммой, ни постом, но надеюсь, я напомнил о хорошем инструменте повышения эффективности. Очень, если честно, устал читать истории провалов в хабе. Да и сценарии у них схожие… «все казалось всё таким прекрасным, а потом как бы на сносях я» ((с) Бутусов), или, если конкретнее, изначальные оценки оказались не соответствующими рыночному предложению. И в подобном я всегда вижу недостатки планирования. Конечно, жизнь богаче любого плана, поэтому надо иметь не только план, который следует испытывать реальностью, но и… план Б, который следует включать в случае провала основного плана.

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

Автор: S_A

Источник