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

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

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

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

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

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

Область знаний/группа процессов Группа инициации Группа планирования Группа исполнения Группа контроля Группа закрытия
Управление интеграцией Четкость критериев успеха Охват плана управления проектом
  • Количество изменений
  • Периодичность обнаружения отклонений

Уровень достижения целей проекта
Управление содержанием
  • Объем требований к продукту
  • Объем содержания проекта

Управление расписанием Сроки всего проекта Отклонение по срокам
Управление стоимостью Бюджет всего проекта Отклонение по бюджету
Управление качеством Запланированное качество Фактическое качество
Управление персоналом Запланированный уровень квалификации в команде Фактический уровень квалификации собранной команды
Управление коммуникациями Скорость решения вопросов
Управление рисками Полнота анализа рисков и разработки мер Потери по неизвестным рискам
Управление поставками Широта выбора поставщиков Оптимальность выбора поставляемого решения с точки зрения цена/качество
Управление ожиданиями Полнота определения заинтересованных сторон Уровень влияния всех заинтересованных сторон на проект (не только спонсора)

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

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

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

Перечень связей

Связи по группе инициации

  1. Четкость критериев успеха -> "+" Охват плана управления проектом
  2. Четкость критериев успеха -> "-" Уровень влияния всех заинтересованных сторон
  3. Полнота определения заинтересованных сторон -> "+" Охват плана управления проектом
  4. Полнота определения заинтересованных сторон -> "+" Объем требований к продукту

Связи по группе планирования

  1. Объем требований к продукту -> "+" Объем содержания проекта
  2. Объем содержания проекта -> "+" Сроки проекта
  3. Объем содержания проекта -> "+" Бюджет проекта
  4. Охват плана управления проектом -> "+" Полнота анализа рисков и разработки мер
  5. Полнота анализа рисков и разработки мер (с задержкой) -> "-" Потери по неизвестным рискам
  6. Запланированное качество -> "+" Сроки проекта
  7. Запланированное качество (с задержкой) -> "+" Фактическое качество
  8. Бюджет проекта -> "+" Запланированное качество
  9. Бюджет проекта -> "+" Запланированный уровень квалификации в команде
  10. Бюджет проекта -> "+" Широта выбора поставщиков
  11. Запланированный уровень квалификации в команде -> "+" Фактический уровень квалификации в команде
  12. Широта выбора поставщиков -> "+" Оптимальность выбора поставщиков
  13. Срок проекта (с задержкой) -> "+" Потери по неизвестным рискам

Связи по группе руководства

  1. Фактический уровень квалификации в команде -> "+" Скорость решения вопросов
  2. Фактический уровень квалификации в команде -> "+" Оптимальность выбора поставщиков
  3. Скорость решения вопросов -> "-" Отклонение по срокам
  4. Оптимальность выбора поставщиков (с задержкой) -> "+" Фактическое качество
  5. Скорость решения вопросов -> "+" Периодичность обнаружения отклонений

Связи по группе контроля и мониторинга

  1. Уровень влияния заинтересованных сторон -> "+" Количество изменений
  2. Количество изменений -> "+" Отклонение по срокам
  3. Периодичность обнаружения отклонений -> "-" Отклонение по срокам
  4. Периодичность обнаружения отклонений -> "-" Отклонение по бюджету
  5. Периодичность обнаружения отклонений -> "+" Фактическое качество
  6. Потери по неизвестным рискам -> "+" Отклонение по срокам
  7. Потери по неизвестным рискам -> "+" Отклонение по бюджету
  8. Потери по неизвестным рискам -> "-" Фактическое качество
  9. Отклонение по срокам -> "-" Уровень достижения целей проекта
  10. Отклонение по бюджету -> "-" Уровень достижения целей проекта
  11. Фактическое качество -> "+" Уровень достижения целей проекта

Связи по группе закрытия

  1. Уровень достижения целей проекта -> "+" Четкость критериев успеха (чем дальше в проекте, тем яснее процесс сдачи)

Итого 34 связи.

Кликабельно для скачивания в SVG:
Системный подход в анализе проектов

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

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

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

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

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

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

В заключение

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

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

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

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

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

Автор:

Источник

Оставить комментарий