Лекция 2. Инициация проекта и устав. Базовый курс.

Лекция 2. Инициация проекта и устав. Базовый курс.

В прошлом блоке мы договорились, что проект начинается с идеи. Так вот, настало время разобраться, что происходит между «идеей» и «поехали». Звучит скучно, но именно на этом этапе решается, жить проекту или умереть. Больше половины провалов закладывается здесь — в первые две недели — когда никто толком не определился, что мы вообще делаем и зачем. И вот здесь начинается первый парадокс управления проектами: на стадии инициации у проекта максимальная ценность и максимальная неопределённость. Каждое решение, принятое сейчас, стоит копейки, а влияет на миллионы. Передвинуть стену на этапе чертежа — дёшево и легко. Передвинуть стену на этапе построенного здания — это снос, демонтаж и переделка. Поэтому на старте нужно думать медленно, а действовать — потом, быстро. Мы же обычно делаем наоборот: стартуем на скорости света, а потом долго и мучительно разгребаем.

Начнём с самого первого вопроса, который менеджер проектов должен задать заказчику: «Зачем?». Не «что» и не «как» — сначала «зачем». Какую проблему решает этот проект? Какую боль снимает? Что изменится в жизни компании или клиента, когда проект будет завершён? Пока вы не получите внятный ответ на этот вопрос, вы даже не можете оценить, нужен ли проект вообще. У меня была история: заказчик хотел «систему автоматизации склада». Мы начали задавать вопросы — и выяснилось, что на складе 20% времени товар ищут руками по бумажным накладным. Человек хотел купить дорогую систему, а проблема решалась простыми стеллажами и маркировкой. Мы продали ему не систему, а полку и этикетки — и он остался счастливее, чем с системой за три миллиона. Вот что бывает, когда задаёшь «зачем» вместо «что».

Цель проекта должна быть умной — с этим сталкивались все, и все морщатся от этой аббревиатуры SMART. Но давайте без снобизма: она действительно работает, просто надо перестать её ненавидеть. Конкретная — не «улучшить продажи», а «увеличить конверсию сайта с 1% до 2%». Измеримая — чтобы можно было в конце сказать «да, получилось» или «нет, не получилось», а не спорить. Достижимая — реальная, с учётом ресурсов. Релевантная — соответствующая более крупным целям компании. Ограниченная во времени — с чётким сроком. Если цель нельзя сформулировать по SMART, значит, вы ещё не поняли, зачем проект нужен, и до устава ему как до Луны.

Важнейший документ инициации — устав проекта. По-английски project charter. Это не талмуд на сто страниц, не пугайтесь. Хороший устав — это две-четыре страницы, в которых написано самое главное: обоснование проекта, цель, содержание — а точнее его границы, руководитель проекта, его полномочия, ключевые заинтересованные стороны, сроки, бюджет, допущения и ограничения. Устав — это, по сути, «конституция проекта». Всё, что написано в уставе, — база для всех дальнейших решений. Всё, чего в уставе нет, — источник будущих споров. Попробуйте вспомнить проект, где не было устава: сколько было споров по поводу того, что входит в работу, а что нет? Я думаю, много. Устав нужен не для бюрократии, а чтобы у вас было, на что опереться, когда начнутся эти споры.

Кто подписывает устав? Тот, кто даёт деньги и имеет власть. Не заказчик, который просто «хочет», а спонсор проекта — по-английски sponsor. Спонсор — это человек наверху, который выделяет бюджет, снимает блокеры и отвечает за бизнес-результат. Без спонсора менеджер проекта — это человек без власти: он не может достать деньги, не может уволить того, кто мешает, не может поднять вопрос наверх. Классическая ошибка молодых менеджеров — согласиться вести проект без спонсора, «потому что и так всё понятно». А потом, когда наступает кризис, выясняется, что поднять решение некому: все заняты, всем плевать, ваш проект — не приоритет. Не ведите проект без спонсора. Это правило номер один инициации.

Следующее, что нужно сделать, — определить заинтересованные стороны. Понятие, опять же, звучит по-бюрократически, а по сути это простой вопрос: на кого вообще влияет этот проект и кто влияет на него? Заказчики, пользователи, команда, подрядчики, руководство, акционеры, контролирующие органы, даже соседи по зданию, если вы делаете ремонт с шумом. И главное — для каждой стороны надо понять две вещи: насколько она влияет на проект и насколько проект важен для неё. Из этого строится простенькая матрица: высокое влияние и высокая заинтересованность — это ваши главные союзники и одновременно главная опасность, с ними надо работать плотно. Низкое влияние и низкая заинтересованность — просто держать в курсе, не тратя времени. Пропустить кого-то на этом этапе — значит, получить сюрприз в середине проекта: «а почему нас не спросили?».

Отдельно надо сказать про слова «допущения» и «ограничения». Допущение — это то, что мы принимаем как факт, но не проверяли. Например: «мы допускаем, что поставщик привезёт материал в срок». Ограничение — это рамка, в которой мы действуем: фиксированный бюджет, жёсткий срок, законодательные требования, специфические технологии. Зачем их записывать? Затем, что допущения имеют привычку не сбываться, а ограничения — давить. Если допущение записано, его можно проверить заранее и подготовить план Б. Если не записано — вы узнаете о его провале в самый неподходящий момент. В уставе допущениям и ограничениям уделяется скромное место, но именно там высекаются будущие проблемы.

Теперь про то, чего в инициации делать не надо. Не надо сразу бросаться планировать в деталях. Не надо строить диаграмму Ганта — ещё рано. Не надо считать трудозатраты по каждой задаче — вы ещё не знаете содержания. На этапе инициации вы делаете оценку «на пальцах», порядка величин: примерно столько-то денег, примерно столько-то месяцев, примерно такие-то специалисты. Точная оценка появится после планирования. Многие руководители требуют точной сметы на инициации — и это ошибка. Точность без плана — иллюзия. Вы можете быть точным «в вилке от трёх до шести месяцев», но назвать «ровно четыре» — значит, наврать. Честный менеджер говорит: сейчас, до детального планирования, вилка такая. Точность растёт по мере проработки плана — и это нормальный процесс.

Кстати, о том, почему оценка «пока грязная». Есть известный парадокс планирования. На старте проекта вы знаете меньше всего — и при этом должны дать оценку, которая повлияет на решение, давать ли проекту жизнь. Получается замкнутый круг: чтобы оценить, нужно спланировать; чтобы спланировать, нужно понять содержание; чтобы понять содержание, нужно поговорить с заказчиком; а заказчик сам не знает, что хочет. Решение этого парадокса — итеративность: вы уточняете требования на каждом шаге, и оценки становятся всё точнее. Это как фотография проявляется: сначала контуры, потом детали. На инициации — контуры, на планировании — детали, на исполнении — резкость.

Ещё один важный документ начала проекта — реестр заинтересованных сторон и коммуникационный план. Не буду вдаваться в детали — об этом будет отдельный материал — но запомните принцип: чем раньше вы начнёте информировать людей, тем меньше потом будет сюрпризов. Люди не любят, когда их ставят перед фактом. «А, кстати, ваш отдел с понедельника переезжает на третий этаж» — это провал коммуникации. «Мы переезжаем через месяц, вот план, вот как это повлияет на ваш отдел, вот к кому обращаться с вопросами» — это нормально. Инициация — идеальное время, чтобы настроить коммуникации, пока никто никуда не торопится и у всех есть время слушать.

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

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

Напоследок — про критерии успеха. Это не то же самое, что цель! Цель — «повысить конверсию до 2%». Критерии успеха — «конверсия не ниже 2%, бюджет не превышен более чем на 5%, заказчик подписал акт без замечаний, команда не разбежалась». Критерии успеха — это измеримые условия, по которым в конце все скажут: «да, проект удался». Их надо зафиксировать в уставе, а не «и так же всем понятно». Потому что всем понятно по-разному: один считает успехом выпуск продукта, другой — прибыль, третий — довольного руководителя. Когда критерии записаны, споров в конце меньше. А в конце проекта спорить — самое неблагодарное занятие.

Домашнее задание после этого блока: возьмите свой текущий или ближайший проект (можно тот же, что и в первом блоке) и напишите устав. Четыре страницы, по списку: обоснование, цель по SMART, границы содержания, менеджер и его полномочия, спонсор, заинтересованные стороны, допущения, ограничения, сроки, бюджет, критерии успеха. И покажите этот устав кому-нибудь, кто не в курсе проекта. Если он поймёт, о чём речь, — устав хороший. Если начнёт задавать вопросы «а что вообще происходит?» — вы что-то упустили.

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