Добрый день, читатели хаба «Управление проектами». Достаточно широко известно, что с точки зрения системного подхода «всех историй не так много», и они называются архетипами (паттернами). Хороший материал в случае проектов можно найти например здесь. Данный же пост представляет собой попытку в жанре записок на салфетках:
- Представления различных параметров гипотетического проекта (в вакууме) в виде единой causal loop diagram,
- Некоторого исследования диаграммы, что же получилось.
Дабы не мудрствовать лукаво, за основу будет взят последний PMBoK (он уже не стесняется говорить о гибких методиках, но ничего существенного, правда).
Параметры системы на рассмотрение
Сразу говорю — любое выделение системы субъективно. Любой другой выделил бы другие параметры, что вполне допустимо. С одной стороны хочется рассмотреть как можно больше параметров, с другой — не захламлять исследование несущественным. Главное в данной задаче будем считать охват всех областей знаний, по которым управляется проект.
| Область знаний/группа процессов | Группа инициации | Группа планирования | Группа исполнения | Группа контроля | Группа закрытия |
|---|---|---|---|---|---|
| Управление интеграцией | Четкость критериев успеха | Охват плана управления проектом |
|
Уровень достижения целей проекта | |
| Управление содержанием |
|
||||
| Управление расписанием | Сроки всего проекта | Отклонение по срокам | |||
| Управление стоимостью | Бюджет всего проекта | Отклонение по бюджету | |||
| Управление качеством | Запланированное качество | Фактическое качество | |||
| Управление персоналом | Запланированный уровень квалификации в команде | Фактический уровень квалификации собранной команды | |||
| Управление коммуникациями | Скорость решения вопросов | ||||
| Управление рисками | Полнота анализа рисков и разработки мер | Потери по неизвестным рискам | |||
| Управление поставками | Широта выбора поставщиков | Оптимальность выбора поставляемого решения с точки зрения цена/качество | |||
| Управление ожиданиями | Полнота определения заинтересованных сторон | Уровень влияния всех заинтересованных сторон на проект (не только спонсора) |
Итого 22 параметра. Если есть несогласие с тем, что выделено, дальнейшее чтение возможно пользы не принесет, увы.
Связи между параметрами
В принципе, неважно с какого конца начинать рассказ о системе. Для каждой связи будет указан характер влияния одного параметра на другой, то есть каждой дуге будет приписан "+" (увеличение одного влечет увеличение второго) или "-" (увеличение первого влечет уменьшение второго), две палочки будут означать задержку. Все 22*21 взаимосвязей, естественно, рассматриваться не будут, как и выделение параметров — выделение связей вопрос субъективный. Главное ухватить те связи, которые позволят объяснить то, что нужно делать чтобы проект был успешным (или что не нужно делать чтобы невзначай его не провалить).
- Четкость критериев успеха -> "+" Охват плана управления проектом
- Четкость критериев успеха -> "-" Уровень влияния всех заинтересованных сторон
- Полнота определения заинтересованных сторон -> "+" Охват плана управления проектом
- Полнота определения заинтересованных сторон -> "+" Объем требований к продукту
Связи по группе планирования
- Объем требований к продукту -> "+" Объем содержания проекта
- Объем содержания проекта -> "+" Сроки проекта
- Объем содержания проекта -> "+" Бюджет проекта
- Охват плана управления проектом -> "+" Полнота анализа рисков и разработки мер
- Полнота анализа рисков и разработки мер (с задержкой) -> "-" Потери по неизвестным рискам
- Запланированное качество -> "+" Сроки проекта
- Запланированное качество (с задержкой) -> "+" Фактическое качество
- Бюджет проекта -> "+" Запланированное качество
- Бюджет проекта -> "+" Запланированный уровень квалификации в команде
- Бюджет проекта -> "+" Широта выбора поставщиков
- Запланированный уровень квалификации в команде -> "+" Фактический уровень квалификации в команде
- Широта выбора поставщиков -> "+" Оптимальность выбора поставщиков
- Срок проекта (с задержкой) -> "+" Потери по неизвестным рискам
Связи по группе руководства
- Фактический уровень квалификации в команде -> "+" Скорость решения вопросов
- Фактический уровень квалификации в команде -> "+" Оптимальность выбора поставщиков
- Скорость решения вопросов -> "-" Отклонение по срокам
- Оптимальность выбора поставщиков (с задержкой) -> "+" Фактическое качество
- Скорость решения вопросов -> "+" Периодичность обнаружения отклонений
Связи по группе контроля и мониторинга
- Уровень влияния заинтересованных сторон -> "+" Количество изменений
- Количество изменений -> "+" Отклонение по срокам
- Периодичность обнаружения отклонений -> "-" Отклонение по срокам
- Периодичность обнаружения отклонений -> "-" Отклонение по бюджету
- Периодичность обнаружения отклонений -> "+" Фактическое качество
- Потери по неизвестным рискам -> "+" Отклонение по срокам
- Потери по неизвестным рискам -> "+" Отклонение по бюджету
- Потери по неизвестным рискам -> "-" Фактическое качество
- Отклонение по срокам -> "-" Уровень достижения целей проекта
- Отклонение по бюджету -> "-" Уровень достижения целей проекта
- Фактическое качество -> "+" Уровень достижения целей проекта
Связи по группе закрытия
- Уровень достижения целей проекта -> "+" Четкость критериев успеха (чем дальше в проекте, тем яснее процесс сдачи)
Итого 34 связи.
Кликабельно для скачивания в SVG:
Disclaimer: Это одна из возможных историй взаимовлияния проектных параметров. Каждый может составить свою (с бриджем и моделями).
Некоторые исследования
Что бросается в глаза сразу — у параметра «полнота определения заинтересованных сторон» нет входящей стрелки. Это означает, что (в случае таких связей), что «первый удар от ворот», то есть начальное значение — является определяющим для системы. Если бюджет, сроки и объемы утверждены с теми сторонами, которые были, то дальше любые новые стороны будут уже изменением или риском. А ведь заинтересованной стороной может быть даже самый заурядный новый тип пользователя конечного продукта.
Далее. Из данной диаграммы следует, что проект — это планирование, а затем управление изменениями рисками (в духе Де Марко прямо и его рассказов о генерале Паттоне), потому что объем требований к продукту устанавливается изначально (а всё остальное — дельта к срокам, бюджету и качеству). Приверженцы гибких методик могут не соглашаться с таким видением, но проект есть проект — сначала требования, затем результат, иначе это услуга.
Теперь менее тривиальное. Завязка критериев успеха (их уточнение) в зависимости от прогресса приводит к дальнейшему увеличению прогресса, в том числе имея «побочным» продуктом снижение проектных рисков (опосредованно через перепланирование), хоть и с задержкой.
Касательно планирования. Справа много стрелок, но все они с положительной связью (до параметров отклонений). В данном случае, особо содержательных выводов на них не сделаешь, кроме того как что «лучше быть богатым и здоровым, чем бедным и больным». Хотя если присмотреться, можно увидеть, что от бюджета зависит очень многое. И чем он выше, тем больше шансов на минимальные отклонения. Не потому что излишки, а потому что в этом случае проект обладает ресурсами, которые позволяют эти самые отклонения снижать. Однако увлекаться этим тоже не стоит, так как имеется и противовес — срок проекта, увеличение длительности которого позволяет говорить о наличии большего числа рисков (или большего их влияния).
В заключение
Данный пост — пример того, как можно исследовать проекты, но не гипотетические, а конкретные. Параметры конечно же следует выбирать по ситуации. А вот со связями дело другое — чем больше их рассмотреть, тем лучше, потому что они определяют выход в большей степени, чем сами параметры.
Чтобы же находить паттерны, необходимо также рассматривать и разрывы: например между запланированным и фактическим качеством, и рассматривать также то, что влияет на разрыв (например, это могут быть временные затраты на их устранение). Такие связи рассматривать также возможно, но диаграмма и так получилась весьма похожей на паутину, поэтому выкладки такого рода отсутствуют.
Совсем отсебятина
Вполне вероятно, для кого-то я ничего нового не сказал — ни диаграммой, ни постом, но надеюсь, я напомнил о хорошем инструменте повышения эффективности. Очень, если честно, устал читать истории провалов в хабе. Да и сценарии у них схожие… «все казалось всё таким прекрасным, а потом как бы на сносях я» ((с) Бутусов), или, если конкретнее, изначальные оценки оказались не соответствующими рыночному предложению. И в подобном я всегда вижу недостатки планирования. Конечно, жизнь богаче любого плана, поэтому надо иметь не только план, который следует испытывать реальностью, но и… план Б, который следует включать в случае провала основного плана.
Системный же подход позволяет помоделировать будущее достаточно несложным способом. В том виде в каком он есть он не дает конкретных цифр, но дает возможность сделать выводы о том, во что предстоит ввязаться, и чего стоит ожидать от проекта.
Автор: S_A
