//
вы читаете...
Управление проектами

Результат – крупным планом

Суть продуктно-ориентированного подхода к планированию проста: каждый этап проекта и любая выполняемая в нем работа (задача) должны вести к заранее определенному результату. Но красота этого метода постигается в процессе разработки плана проекта, который будет разительно отличаться от «обычного» плана.

Это сродни японской практике написания еженедельного отчета «авансом», в понедельник. Японцам остается лишь отработать неделю так, чтобы в пятницу не пришлось переделывать отчет. Глубоко.

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

 Продуктно-ориентированный подход

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

«Цельный» продукт проекта обязательно состоит из компонентов. К моменту разработки плана уже должны быть рассмотрены различные варианты реализации проекта, и выбран один вариант. Это – замысел проекта. Замысел представляет собой определенный набор действий, и набор этот – неслучайный. Каждое значимое движение в проекте должно давать определенный результат, а совокупность этих промежуточных результатов дает заказчику продукт проекта.

Например, если мы начинаем проект по разработке нового продукта, и выбранный вариант реализации (замысел проекта) – разработка собственными силами, то в укрупненной разбивке проект может выглядеть так:

Табл. 1. Пример описания результатов этапов проекта

Этап

Результат

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

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

«Комплект технологической документации, первый промышленный образец».

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

Таким образом, в плане проекта (в табличном представлении) помимо привычных глазу колонок (№ п/п, Задача, Исполнитель, Срок, Бюджет) может появиться и такая, как «Клиент» или «Кто принимает результат». Само собой, колонка «Результат» в продуктно-ориентированном плане проекта также должна быть заполнена.

В методологии проектного управления американского Института управления проектами (PMI), знакомой нам как PMBoK, содержится определение содержания проекта как совокупности работ и результатов:

Содержание проекта = Работы + Результаты

Запомнить эту формулу (С = Р + Р) несложно. Сам принцип также прост: каждая работа проекта ведет к результату; работы без результата не должны попадать в проект.

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

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

 PBS, WBS, ИСР…

Когда мы разбивали продукт проекта на его составляющие, мы строили так называемую PBS[1]. PBS может иметь несколько уровней вложения. PBS проекта постановки КСУП (Корпоративной системы управления проектами) может выглядеть так:

Пример построения PBS проекта постановки КСУП

Пример построения PBS проекта постановки КСУП

В зависимости от специфики проекта PBS можно строить на основе деления проекта на этапы или на основе разбиения продукта проекта на составляющие. Выбор подхода – за вами.

Сразу хотелось бы обратить внимание на самую первую «ветку» PBS: управление проектом. Недостаточно опытные руководители проекта на этапе планирования не выделяют время на управление. В то же время именно сюда можно отнести время на периодические встречи проектной команды, отчетные встречи с заказчиком, решение вопросов взаиморасчетов за выполненные этапы и время на закрытие проекта. Не выделяя в структуре проекта блок управления, руководитель проекта может не включить в план проекта эти задачи, просто «имея их в виду». Однако согласитесь, что, например, блок задач «Управление этапами» с результатами «Подписанные акты» и «Полученная оплата» в плане не помешают.

Из PBS несложно получить WBS[1] (распространенная русскоязычная аббревиатура – ИСР, иерархическая структура работ). Каждый конечный «листик» на ветвях PBS либо уже является задачей, либо может быть разбит на несколько подзадач.

Всегда возникает вопрос: до какого уровня детализации разбивать задачи? Ответ прост: до уровня деления, понятного исполнителю. Если исполнителю не нужно объяснять, какую последовательность действий нужно выполнить, чтобы получить описанный результат, то разбивать задачу, как правило, не нужно. Детализация может потребоваться в длительных задачах для промежуточного контроля, для более точной оценки трудозатрат на выполнение работ, а также в случае, если задачу выполняют несколько исполнителей и необходимо четко обозначить зону ответственности каждого из них.

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

 Секреты мастерства (или еще несколько аббревиатур)

Выполнение проекта всегда связано с некоторой неопределенностью. Ближайшие шаги видны нам более ясно, чем последующие. В этой ситуации попытка описать все работы проекта с одинаковой степенью детализации – занятие чаще бесполезное. Для решения этой проблемы придумали так называемый «метод набегающей волны». Детали в плане появляются «волнами», по мере продвижения в проекте. Сначала подробно описывается первый этап, остальные – в общих чертах. По мере снятия неопределенности детализируются второй, третий этап и так далее. Этот метод не универсальный и не подходит для многих проектов (например, в области строительства или инжиниринга), но в этих областях и степень неопределенности ниже. Если же дело касается освоения нового регионального рынка, то продвижение ощупью (при понимании конечной цели) будет более безопасной тактикой, чем попытка повторить успешный опыт покорения другого региона. В такой области, как разработка программного обеспечения, где степень неопределенности очень высока, существуют специальные методы итеративной разработки (например, методология SCRUM).

Много ошибок допускается при структурировании списка задач (построении ИСР). Некоторые задачи напрасно повторяются под синонимичными наименованиями в разных блоках работ, другие попадают не туда. Для корректного построения структурированных списков консультанты компании McKinsey пользуются проверенным принципом MECE[2]. Задачи списка не должны повторять друг друга. При этом совокупность задач должна обеспечивать «полное накрытие», без пробелов, как лоскутное одеяло.

Здесь будет уместно вспомнить о соответствии задач критериям SMART[3].  Цели должны быть конкретными; должно быть четко определено, что должно быть достигнуто и к какому времени. Результаты должны быть измеримы посредством четких метрик качества, количества и цены. Задачи должны соответствовать компетентности команды (реальным знаниям, опыту, рабочей нагрузке и т.д). Цели должны быть достижимыми, но требующими усилий. Дата обзора достижения целей должна быть согласована.

Итак, типичные ошибки при построении ИСР сводятся к следующим:

  • Пропуск стадии структуризации (построения PBS)
  • Включение в проект работ из текущей деятельности
  • Использование функций, не ведущих к результату
  • Неполный охват содержания проекта
  • Повторение элементов структуры
  • Излишняя или недостаточная детализация
  • Не учитываются «неосязаемые» конечные продукты
  • Не учитываются процессы управления проектом и управленческие продукты

Навыки планирования являются ключевыми в компетентности проект-менеджера. Нередко планированию уделяется недостаточно времени. Мы бросаемся «выполнять» проект, поскольку выгода от выполнения задач очевидна, а план – всего лишь план… Планировать вроде как и некогда.

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

Впервые опубликовано в журнале «Финансовый директор», №4 (2009)

[1] WBS – Work Breakdown Structure (англ.) – иерархическая структура работ, ИСР. Иногда употребляется сокращение СДР – структура декомпозиции работ.

[2] MECE — Mutually Exclusive, Collectively Exhaustive (англ.) – взаимно исключающие, совместно исчерпывающие.

[3] SMART – Specific, Measurable, Attainable, Realistic, Trackable (англ.) – конкретный, измеримый, достижимый, реалистичный, контролируемый.


[1] PBS – Product breakdown structure (англ.) – Иерархическая структура продукта. Иногда под PBS понимается Иерархическая структура проекта.

Реклама

About Виктор Степанов

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

Обсуждение

Trackbacks/Pingbacks

  1. Уведомление: Обучение проектному подходу | Виктор Степанов - Декабрь 19, 2013

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Ищете ответы?

business-models CIGS CIGSlim pmbok PMO velcom Базовый курс управления проектами Изовак Инвестиционный меморандум КСУП Обучение действием базовый курс бизнес-ангел бизнес-модели бизнес-модель бизнес-обучение бизнес-план венчур венчурный бизнес заказчик инвестиции инвестор интересы исследование команда проекта коммуникации консалтинг корпоративная система управления проектами кризис куратор маркетинг меморандум миф мотивация обоснование проекта обучение руководителей проектов отзыв отчеты письма план проекта подрядчик портфель проектов принцип раскрытия программа продажа бизнеса проект проект-менеджер проектно-зависимый проектно-ориентированный проектное управление проектный офис проектный подход прямые инвестиции результаты проекта риск риск-менеджмент роль рынок труда связи семинар скрытый клиент совмещение ролей солнечная энергетика спонсор стартап стейкхолдеры стимулирование стратегический инвестор стратегический портфель стратегия тренинг управление проектами управление рисками финансовый инвестор эксперт
%d такие блоггеры, как: