Цикл "Шесть Сигм, с чем его едят". Статья №7. Алгоритм DMAIC. Шаг DEFINE. Часть 5.

Ну, вот мы и добрались до последнего блока алгоритма DEFINE: Проектная документация

В методике Шесть Сигм нет, как таковой, какой-то отдельной специальной супер-пупер документации. Лишь то, что обычно требуется для нормального полноценного управления проектом.

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

В общем, выглядит все поле документации в полном объеме примерно так:

Разумеется, это далеко не единственный вариант, и он не претендует на истину в последней инстанции. Но указанный на картинке вариант работает в львиной доле случаев.

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

Но обо всем по порядку.

ОТЧЕТНАЯ ДОКУМЕНТАЦИЯ НА ЭТАПЕ DEFINE

Собственно, работа по проекту только началась, поэтому реально отчитываться пока толком не о чем. Поэтому на данном этапе происходит утверждение основных показателей проекта. В среднем этап DEFINE занимает от 2 до 4 недель, по результатам которых и происходит первая отчетная встреча лидера проекта с Заказчиком проекта. (Никто не мешает делать чаще).

Что мы там показываем. 

1. Презентация проекта/Текущая ситуация. (Обязательный элемент)

К этому времени обычно успевают собрать базовую статистику по проблеме, поэтому уже можно оценить, подтверждается она или нет (да, бывает, что проекты останавливаются уже тут). Насколько все серьезно? Чем, с точки зрения лидера группы стоит заниматься. Мы рассматривали ранее с вами Дерево Ключевых показателей. Вот именно о них и речь, какие будем брать в работу и что хотим взять Проектным показателем. Далее варианты:

• Заказчик полностью согласен

• Заказчик вносит коррективы

• Заказчик не согласен полностью, и лидер проекта возвращается к исходникам

Есть и еще варианты, но не будем о грустном.

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

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

2. План работ. (Обязательный элемент)

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

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

Пара практических советов. Будете строить этот план, стройте его с конца. От дедлайна и обратно. Таким образом, убьете двух зайцев: будете понимать к какому сроку какой этап надо сделать и почему; будете понимать, что вам нужно, чтобы запустился следующий этап. И второе. Когда построите план, отрежьте от каждого этапа примерно 40-50% и отмерьте полученные промежутки, начиная со стартовой точки проекта. И постарайтесь далее успевать именно в полученные сроки, а не в спланированные изначально. 

Причины этому расписывать довольно долго, и к Сигме они не относятся. Просто так у вас будут существенно большие шансы сделать проект вовремя. 

• Оперативный план на текущий месяц. Обычно он рождается после общего планирования, а не до или вместо, как любят делать. Вот это уже детальный план работ на этап с разбивкой по срокам, исполнителям и так далее. Порекомендовать здесь можно инструмент RACI. Но подойдет и любой другой планировщик. 

3. Экономика проекта. (Обязательный элемент, кто бы чего ни говорил)

Вот тут часто начинается плач Ярославны от начинающих и не очень лидеров проектов. «А как это считать? Я еще даже данные толком не собрал», «Поставлю сейчас цифры, за них же отвечать придется», «Я не понимаю, как дефекты перевести в деньги… а еще косвенные выгоды их как считать? Да и мало ли что мне может понадобиться в проекте». Эта и прочая подобная чепуха побуждает лидеров проектов всеми правдами и неправдами пропускать или перекинуть на кого-либо первичный экономический расчет проекта.

А экономическое обоснование проекта важно сразу по ряду причин:

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

• Частенько получается так, что вопрос наличия/отсутствия финансового обоснования проекта перетекает в вопрос наличия/отсутствия бюджета проекта. А мы все, как минимум, догадываемся, что лучше иметь бюджет и не потратить, чем не иметь его и встрять мертво где-нибудь на середине проекта.

• И наконец, проанализировав потенциальную выгоду от проекта, мы понимаем, что это и есть та максимальная сумма, за которую ни при каких условиях нельзя выйти по затратам в проекте. Вот вообще, никак. Потому что проект должен окупаться за время проекта +- полгода. Это аксиома как в Бережливом производстве, так и в Сигме. И для процесса DMAIC это закон (в отличие от того же DMADV, где это не всегда так). 
  

Есть и другие причины, почему надо считать экономику проекта, но основные назвал. И да, никто не мешает подключать финансистов к расчетам экономики. Только это не значит, что надо на них все спихнуть и забыть. Вместе сели и посчитали.

4. Оценка эффективности проекта. (На этапе DEFINE не нужен, далее рекомендуется, но зависит от Заказчика)

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

На этапе DEFINE этот блок особой роли не играет, ибо «стрижка только начата». 

СТАРТОВАЯ ДОКУМЕНТАЦИЯ

1. Устав проекта (опционально)

Прежде чем двигаться дальше по проекту, нужно на берегу договориться о неких правилах и общем видении ситуации. Как раз для этого формируется устав проекта. 

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

Документ подписывается всеми заинтересованными сторонами в проекте.

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

2. Бюджет, график и финансовое обоснование проекта. (Я считаю, что обязательны все три, но каждому свое).

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

Я считаю такой подход пагубным. Что у нас обычно получается при ситуации отсутствия бюджетирования проекта?

Две крайности:

• Не бюджетировали = нет бюджета. Тебе что-то надо в проекте? Иди потрудись и добудь. А дальше бедный Лидер носится и «выбивает ресурсы». При этом неминуемо страдает проект. Несмотря на то, что это самая частая ситуация, она не самая страшная. Страшнее вторая крайность.

• Нет бюджета = нет ограничений. В ситуации, когда все ресурсы доступны, и никто их не ограничил, у лидера создается подсознательное ощущение: 

 

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

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

• собирать столько встреч, сколько нужно,

• тем составом, который нужен,

• проводить встречи в целом более эффективно

• и не позволять себе тратить ресурсы компании в никуда.

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

ОПЕРАТИВНАЯ ДОКУМЕНТАЦИЯ В ПРОЕКТЕ

1. Самодиагностика. (Настоятельно рекомендуется, но, в целом, опционально).

Смотрим пункт 4 из отчетной документации, только делаем еженедельно и сами для себя. Вот и все. Состояние показателей, проценты выполнения планов, общего и оперативного, использованный бюджет и т.д. Для отслеживания «успеваемости» по плану можно порекомендовать такой инструмент как Температурная диаграмма.

Выглядит так: 

Пользоваться просто: по горизонтали задачи в проекте, по вертикали перерасход времени по сравнению вот с тем «урезанным» на 40-50% планом. Попали в желтую зону, вы еще в графике, но начали есть запасы. Попали в красную – значит, уже опаздываете.

Можно это все не делать. Но не удивляйтесь потом, что чего-то забыли или не успели.

Если будут комментарии про этот инструмент, сделаю детальный обзор. А пока мы не о том собрались.

2. Повестки и протоколы встреч (обязательно)

Объединю в один блок, так как два этих документа ходят только парой, как «мы с Тамарой».

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

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

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

3. Оперативный план работ (обязательно)

Штука важная, штука нужная, штука недооцененная. Что часто встречается на практике? Куча ежедневников у всех участников. Каждый что-то туда записал (кто его знает что), разошлись. А потом начинаются чудеса несогласованности видения результатов, методов и прочего.

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

Из полезных прикладных инструментов, можно выделить инструменты:

• RACI для планирования и контроля задач лидером группы

• офисную Хейдзунку (или Канбан-доску) для оперативного управления группой. Только не берите Agile-овские поделки. Они в этом плане ущербны, ибо с ходу режут почти всю именно управленческую составляющую. Только полная офисная Хейдзунка по всем правилам дает максимальную эффективность оперативного управления коллективом.

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

БЛОК ВИЗУАЛИЗАЦИИ

1. Доска проекта. (Обязательно для задачи вовлечения персонала).

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

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

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

2. Штабная комната.

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

Зачем нужно? Да все просто:

• чтобы не кочевать, как цыгане по Бессарабии, из помещения в помещение

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

• правила на стенах позволяют легче контролировать дисциплину и порядок

• да и удобнее в одном и том же помещении собираться.
  

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

Так что ограничимся этим:

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

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

И ура! Мы закончили DEFINE. С чем вас и поздравляю!!! 

Ссылки на предыдущие статьи цикла "Шесть Сигм, с чем его едят":

Статья №1 Основные положения Шесть Сигм

Статья №2. Принцип решения проблем в Шесть Сигм. Алгоритмы проектов.

Статья №3. Алгоритм DMAIC. Шаг DEFINE. Часть 1.

Статья №4. Алгоритм DMAIC. Шаг DEFINE. Часть 2.

Статья №5. Алгоритм DMAIC. Шаг DEFINE. Часть 3.

Статья №6. Алгоритм DMAIC. Шаг DEFINE. Часть 4.