Назад к списку

Проектная сессия: упаковка проекта от концепта – до ресурсов и жизнеспособного продукта 

Как часто мы сводим управление проектами – к банальному распределению ресурсов, чисто технической задаче. 

При этом, оставляя за кадром – идею проекта, ожидаемые эффекты, продукт, требования заинтересованных сторон. 

Сюжет данной Проектной сессии адаптирован к запросам Свердловского областного фонда поддержки предпринимательства (СОФПП), который создает условия и обеспечивает ресурсами сторонние проекты. 

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

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

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


А это - наша банда! 

  • Алексей Яцына, мастер игропрактики, консультант по стратегиям и организационному проектированию, модератор, соавтор Rapid-Foresight, со-организатор Форсайт-флота 2012-2017
  • Даниил Мазуровский, директор регионального представительства АСИ по УрФО
  • Татьяна Иванова, исполнительный директор Президентской программы (ПП) Бизнес-школы УрФУ, председатель Ассоциации выпускников ПП Свердловской области
  • Алла Ковтунова, директор Центра Развития управленческих компетенций Бизнес-школы УрФУ
  • Лариса Малышева, директор МВА-Центра Бизнес-школы УрФУ, д.э.н., проф., IPMA(D) 


Популярные подходы PMP и PMI не дают ответа на вопрос – кому и для чего нужен проект, что он изменит в мире, в эффективности компании, судьбе менеджера проекта, в жизни … 

Если мы хотим получить связный, логически выстроенный проект, отвечающий потребностям заинтересованных сторон с согласованными целями и показателями, нам нужна сквозная технология, начинающаяся с проблем заинтересованных сторон, включающая идею проекта, и завершающаяся планированием всех видов ресурсов для получения жизнеспособной версии продукта (MVP – Minimum Viable Product). 

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

Далее я предлагаю следующий алгоритм рассуждений. 

  1. Формулировка гипотезы, т.е. идеи 
  2. Поиск заинтересованных сторон (Субъектов), чьи проблемы идея может разрешить 
  3. Построение карты проблемного поля для поиска причин появления проблем 
  4. Построение Карты целей для устранения проблем 
  5. Постановка целей проекта на основе критериев SMART 
  6. Разработка Карты решений 
  7. Переход от Карты решений к дереву задач и календарному графику
  8. Расчет ресурсов 
  9. Проверка гипотезы с помощью MVP 

Рассмотрим подробнее. 

1.Формулировка гипотезы, т.е. идеи 

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

  • Что это (Название) 
  • для чего (Ключевая Цель) 
  • для кого (Субъект) 
  • что делает (Решения) 
  • как (Приоритеты) 
  • для кого (Субъекты) 
  • с какими результатами (Показатели)

Например: 

  • Центр развития социального предпринимательства (ЦРСП)
  • Для повышения качества жизни
  • незащищенных слоев населения
  • финансирует проекты, 
  • в соответствие с приоритетами, 
  • для социальных предпринимателей 
  • на определенную сумму, например, дающую конверсию 1:5 


2.Поиск заинтересованных сторон (Субъектов), чьи проблемы идея может разрешить

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

Например, в случае с ЦРСП, стейкхолдеры следующие. 

Таблица. 1  

3.Построение карты проблемного поля для поиска причин появления проблем

Карта проблемного поля позволяет выстроить причинно-следственные связи, которые в нашем контексте – аналогичны временнЫм, и нужны нам для определения последовательности решений.

Вверху размещают ключевую проблему – которая объективно существует и количественно измерима. Далее – сверху вниз – проводится развертывание проблем, стрелками формируется проблемное поле, при этом стрелки соединяют причину и следствие и направлены снизу – вверх, от причины – к следствию. 

Анализ завершается корневой проблемой, т.е. первопричиной. Именно с нее и начнутся решения. Рис. 1 

4.Построение Карты целей для устранения проблем 

Переход от проблем к целям, технически, выполняется просто. Нужно провести инверсию. 

Например: нехватка – достаточность, отсутствие – наличие… 

Или так: высокий – понизить, низкий – увеличить. 

Если Карта проблем декомпозируется сверху – вниз, т.е. от следствий к причинам, то Карта целей – наоборот. Внизу размещается корневая цель, вверху – ключевая. 

Конфигурация Карты целей соответствует конфигурации Карты проблемного поля. 

Рис. 2 

5.Постановка целей проекта на основе критериев SMART 

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

Для любой системы, цели задаются внешней средой. 

Внешние заинтересованные стороны влияют на постановку целей, а менеджер и команда – на их достижение. Таблица состоит из пяти колонок. Первые четыре относятся к внешней среде, и только 5-я – к проекту. В первой колонке – перечень заинтересованных сторон. Во 2-й – степень их влияния на проект. В 3-й – требования заинтересованных сторон, взятые из Карты целей, в 4-й – измеренные по критерию SMART. 

Конечно, показатели нужно запрашивать у заинтересованных сторон и на этом этапе уточнять. 

Таблица 2 

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

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

В нашем примере, менеджером может являться представитель Фонда поддержки предпринимательства. 

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

Таким образом, на данном этапе мы определили цели по критериям SMART и менеджера проекта. 

6.Разработка Карты решений 

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

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

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

Решения – это потенциальные задачи, этапы или проекты, а цели внутри границ проекта – это вехи, т.е. контрольные точки. 

Рис. 3 

7.Переход от Карты решений к дереву задач и календарному графику 

Фактически, Карта решений представляет собой Сетевой график. Достаточно развернуть Карту решений на 90 градусов, и в прямоугольниках мы увидим задачи, соединенные причинно-следственными связями, что аналогично связям по времени. 


Рис. 4

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

Рис. 5 

8.Расчет ресурсов 

Каждая задача сопровождается расходом ресурсов. Ресурсы измеряются трудовыми и материальными затратами. В программе Microsoft Office можно задать ресурсы и их стоимость, что приведет к расчету бюджета прямых затрат на проект. 

Рис. 6 

9.Проверка гипотезы с помощью MVP 

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

Если в требованиях были ограничения по бюджету, то на этом шаге мы можем их проверить. 

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

И, наконец, самое время вернуться к первоначальной гипотезе и ее проверить. 

Получился ли у нас в результате 

  • Центр развития социального предпринимательства (ЦРСП) 
  • Для повышения качества жизни
  • незащищенных слоев населения
  • финансирует проекты, 
  • в соответствие с приоритетами, 
  • для социальных предпринимателей
  • на определенную сумму, например, дающую конверсию 1:5  

Яндекс.Метрика