Устав проекта — это "скорлупа яйца". Курс по управлению проектами, часть 5

Продолжение моего учебного курса по проектному управлению. Предыдущие материалы: 

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

2. Три фундаментальных принципа проектного управления

3. Роли в проектном управлении

4. Управление заинтересованными сторонами 

Устав появляется в конце этапа инициации.
Инициация – это стадия, на которой вы думаете, запускать ли проект или нет, и определяетесь, что именно в проект войдет. Будем ли мы строить дом или нет? Будем строить сами или с помощью подрядчика? Может быть, мы позовем подрядчика только на какие-то отдельные работы, например проектирование, а остальное сделаем сами? То есть инициация — стадия, когда какие-то обсуждения по проекту уже идут, но еще не принято решение — запускать проект или не запускать. А когда у вас готов устав, проект запущен, переходим к планированию. Обратите внимание, что инициация может ничем не кончиться. Вы могли думать-думать, но в итоге решить, что проект сложный, сроки нереальные, и запускать его не стоит. Так что инициация может закончиться ничем, и это нормально. Но если вы решили взяться за проект, то у вас должен появиться устав. Нет устава – нет проекта, вам не за что отвечать.
 
В интернете есть шаблоны, которые можно заполнить по своему проекту. Моя практика показывает — какой бы шаблон вы не использовали, очень трудно написать устав хорошо с первого раза. У устава есть особенность: его качество нельзя оценить сразу. То, что у вас плохой устав, вы понимаете, когда на проекте начинаются проблемы. В самом худшем случае вы узнаете об этом при закрытии. Устав – это такой забавный документ — и пока вы не понимаете, зачем он придуман, его почти невозможно нормально заполнить, какой бы вы шаблон не взяли. Чтобы объяснить, зачем нужен устав проекта, используем метафору.
 
Представьте, что вы с мальчишками после школы решили поиграть в футбол. Сидите и ждете, когда прозвенит звонок с последнего урока, чтобы выйти на школьный двор и погонять мяч. Допустим, мяч у вас есть, звонок прозвучал, вы собираете поиграть. Вы разбились на команды, у вас есть мячик, поле. Чего не хватает? Ворот, конечно. Но поскольку это школьный футбол, то ворота обычно делают из двух портфелей. Все, можно играть. И обычно игра начинается сразу, как только принесли мячик и сделали ворота. Чего ждать-то? Уроки закончились, давно хочется начать игру. А дальше, как это часто бывает, каждые полторы минуты мяч улетает в соседний двор. И двое ребят – по одному из каждой команды – убегают за мячом и долго гоняют по соседнему двору, продолжая бороться за мяч. Потом через несколько минут усталые и довольные возвращаются, а все остальные в это время стоят и ждут. Мячик отсутствует всего несколько минут, но эти минуты очень сильно портят игру всем остальным. Потому что, когда несколько минут ты играешь в футбол, время быстро пролетает, а когда ты ждешь, то кажется, что время идет очень долго. И такая борьба двух мальчишек за пределами импровизированного поля всех раздражает.
 
Или другой вариант развития игры – кто-то из команды противника становится возле ваших ворот и ждет, когда мяч проскочит, чтобы забить гол. И у него получается, поскольку промахнуться невозможно. Такое поведение тоже всех раздражает, потому что все бегают, играют в футбол, а один умный просто стоит и забивает голы.
 
Вот на этом-то этапе игроки понимают, что забыли один очень важный момент — забыли договориться о правилах. Потому что без правил играть оказывается неудобно. К примеру, договариваются, что если мяч улетает в соседний двор, его берут в руки, кладут на край поля и вводят в игру. Или договариваются о наличии специальной штрафной площади, чтобы «умные» не могли стоять у ворот соперника.
 
Другими словами – вы придумываете правила футбола. И правила – это прямая аналогия устава. Думайте об уставе, как о правилах игры, например, в футболе.
 
Что пишут в правилах? Это очень лаконичный документ, в котором половину занимают наглядные картинки, а вторая половина посвящена описанию игры.
 
Что такое хорошие правила? Представьте, что человек, который не знает правил и никогда не бывал на футболе, впервые попадает на матч (он — зритель). Сможете вы объяснить ему в чем суть игры так, чтобы он через 2-3 минуты уже с интересом следил за игрой? И даже начал болеть за какую-то команду по своему выбору?
Технически — да. Футбол простая игра и за пару минут вы сумеете объяснить все нужное (скажем, в бейсболе это было бы невозможно).
Что вы будете рассказывать в эти две минуты? Ключевые правила. Те, которые нужны для понимания игры, без которых футбола не получится.
Это прямая аналогия с уставом. То есть в уставе нужно указать только те аспекты, которые точно не изменятся, например, никогда нельзя будет игрокам брать мяч руками или забегать на трибуны за улетевшим мячом.
 
Что не пишут в правилах и уставе, соответственно? Подробные установки на игру. Например, не описывают, что ты пойдешь на третьей минуте на середину поля, на 3,5 минуте дашь пас к воротам, потом вернешься, а на 4-ой минуте снова отправишься на середину поля. Таких деталей в уставе быть не должно.
 
Еще раз: устав – это документ, в котором фиксируют только неизменные аспекты. Установки для команды в нем не описаны, только правила игры.
 

Кто формирует устав проекта? Чаще всего это менеджер проекта и спонсор, потому что у них договор о реализации проекта. Причем, формирует, пишет устав менеджер, а спонсор, скорее, его утверждает. А как участвует заказчик? В PMBoK предлагается, чтобы заказчик тоже участвовал в этом процессе, но есть оговорки.
 
Фактически устав дает всем сторонам четкое понимание, что это за проект, что на нем делают и что нужно каждой из сторон, чтобы работа была доведена до ума. Обычно спонсор не бегает за менеджером проекта. Потому что спонсор — ему и так хорошо, безо всяких уставов. Он начальник, он сам назначает правила. Сначала поручил, а потом передумал. А менеджера проекта устав спасает от того, чтобы он с командой не попал в ситуацию, когда спонсор поменял правила игры посреди матча и требует от него невозможного.
 
Поговорим про состав устава проекта. Какие разделы всегда необходимо включать в устав?
 
1. Сроки. Их менять нельзя. Их обычно устанавливает спонсор, но менеджер должен проверить, насколько они реалистичны. Как правило, фиксируют сроки окончания всего проекта. Но есть и промежуточные сроки. Например, идет строительство дома. Сам дом должен быть готов, допустим, через год, но через полгода у спонсора заканчивается аренда земли, и с этого момента по площадке не сможет двигаться строительная техника. Значит, в уставе нужно упомянуть 2 срока: первый – срок, когда надо сдать дом, – через год, второй – срок, когда дом должен быть накрыт крышей, чтобы всю технику можно было отпустить с площадки. Иначе придут контролирующие органы и могут возникнуть проблемы.
 
Если спонсор указал конкретные сроки, менеджеру ничего придумывать не надо. Задача менеджера проекта — услышать, чего хочет спонсор.
 
2. Деньги. Как  и сроки, этот раздел не подлежит изменению после начала проекта. По правилам классического проектного управления, если возникла необходимость внести изменения в любой раздел Устава, то надо перезапускать проект. Если вы разрешите футболистам играть с мячом руками, это уже не совсем футбол. Надо остановить игру, и начать новый матч, по новым правилам. Устав меняться не может, поэтому и сроки, и деньги описывают очень коротко и в терминах «не позже чем», «не больше чем». Например, строим 9-этажный дом в течение года. Тогда срок записывается так: «не больше чем  12 месяцев». А бюджет – «не больше 1 млн долларов». То есть это какие-то рамки, за которые ни в коем случае нельзя выйти, иначе проект теряет смысл.
 
3. Цель. Очень часто в уставах пишут плохие цели. Например, проект по созданию и внедрению IT-системы. Цель – “создать и внедрить IT-систему”. Жуть. Самосбывающаяся цель. Нельзя копать яму, с целью копать яму. КОпать яму для чего-то. Чтобы что-то произошло. Цель создания и внедрения ИТ-системы не “создать и внедрить”, а в чем-то еще. Проверяйте свои цели внимательно (среди них часто попадаются очень слабые).
 
4. Содержание. Записывает очень коротко, буквально в пяти абзацах. Больше – вряд ли найдется. Содержание описывается в терминах «что делаем» (продукт проекта), «что не делаем» (исключено из проекта). Допустим, 9-этажный дом строим, но придомовую территорию не облагораживаем.
 
К слову, какого объема должен быть весь устав? На самом деле, это не очень важно. Но норма – 3-5 страниц. Больше бывает редко, но чаще всего это и не нужно. Потому что на проектах не бывает столько неизменных параметров, чтобы устав занимал много страниц. На практике, люди иногда называют уставами и более объемные документы. Часто такое случается в государственных компаниях. Там берут какой-то план-график на календарный год, называют его «устав проекта», создают распоряжение о создании рабочей группы и начинают проект. Вот такое получается проектное управление.
 
И еще: объем устава не зависит от размера проекта. Не важно, строите вы  газопровод или делаете IT-систему. Все равно ключевых неизменных аспектов мало.
 
5. Риски. Менеджер проекта управляет рисками, закладывает на них определенные резервы. Нюанс в том, что схема, используемая в большинстве компаний, на практике не работает. Определение резерва на риски сверху нельзя считать осуществлением управления рисками.
В устав имеет смысл включать только ключевые риски, самые страшные, которые могут угрожать успеху всего проекта. Например, бюджет проекта в рублях, а половина закупок – в долларах. И можно договориться: если рубль упадет, и курс окажется больше 100 рублей за доллар, то денег на проект не хватит, и проект придется досрочно завершить как нецелесообразный. В устав можно записать ключевые терминирующие риски: курсовая разница и какая именно, поломка ключевого станка или сервера (если менеджер едва ли может на нее повлиять) и т.п. Если это случится, то ни менеджер, ни команда не виновата. Придется менять какие-то из ограничений проекта – например, бюджет, или содержание.
 
6. Команда, ресурсы. У вас ресурсы могут быть выражены в деньгах, которые позволят нанять людей и закупить нужные вещи. А могут быть выражены в конкретных людях. То есть вам могут выделить на проект конкретное количество людей. 
 
Если у вас ресурсы в людях, то в уставе, как в неизменном документе, необходимо указать только тех людей, без которых проект невозможен. Если уход специалиста не критичен, его фамилию можно не записывать в уставе. Но общее количество людей все равно надо указать, например, для проекта необходимо 5 электриков I разряда или 6 программистов определенного уровня. И когда есть договоренность со спонсором о количестве специалистов конкретного уровня, не обязательно перечислять какие-то фамилии.
  
Это основные разделы устава. Догмы нет, устав можно менять под себя, но методология рекомендует добавлять все перечисленные разделы.
 
Теперь разберемся, как устав фиксировать: в электронном виде или на бумаге с подписью и печатями, в нескольких экземплярах?
 
Иногда спонсоры противятся уставам, и не поддерживают их составление. Но менеджеру необходимо, чтобы такой документ был — как мы уже обсуждали выше, это элемент его безопасности. Устав обязательно должен быть в печатном виде, но его не надо где-то регистрировать или ставить на нем печать. Потому что это не юридический документ. Устав – это договор о том, что спонсор предоставляет ресурсы на проект, а менеджер выполняет поставленную задачу, имея определенные временные рамки и бюджет.
 
Почему не надо ставить печать на уставе? Представьте, что начальник обещал выделить ресурсы на проект, но не предоставил их. Вы пойдете жаловаться в Гаагский трибунал? Нет, конечно. Потому что устав – это внутренний документ, который за пределы компании никогда не выйдет. Он помогает не забыть, о чем договорились стороны.
 
Что касается подписи спонсора, то она нужна обязательно. Когда работаешь в компаниях с низким уровнем зрелости проектного управления, часто сталкиваешься с ситуацией, что спонсор не хочет подписывать устав. Мол, менеджер – бюрократ, и подпись — это условность. Но когда спонсор собирается подписать конкретную бумажку, конкретно в тот момент, когда он заносит над ней ручку — у него иначе включается мозг, и он уже внимательно вычитывает каждый раздел. Именно такого эффекта нам и надо достичь: чтобы спонсор ознакомился с основными разделами, если у него есть претензии, сразу их высказал. Зато потом, в ходе реализации проекта, проблем уже будет меньше. Спонсору придется выделять ресурсы или еще что-то делать, потому что он уже подписал устав.
 
Обратите внимание. Если менеджер борется за реализацию проекта в рамках треугольника (время, деньги, содержание работ), то спонсор ходит по периметру треугольника, снаружи.  И в приличном обществе он должен отгонять всех от проекта, в том числе самого себя. Что это значит? Это значит, что если он обещал команду в 15 человек, то пусть 15 и даст. 15, а не 12 или 14. Если в уставе были прописаны какие-то особые люди со сверхъестественной квалификацией — пусть спонсор даст именно их. Или пусть перезапускает проект, меняя сроки и содержание (да, нужен будет новый устав). Потому что если обещали 1 миллион долларов, а дали только полмиллиона, то построить такой же дом уже не получится. Так и с людьми. Ключевой аргумент российского менеджмента – «очень надо». Например, у вас команда из 10 человек, приходит спонсор и говорит, что ему очень нужны 3 из них. Резонно спросить: мы вообще делаем проект или нет. Если делаем – оставь команду в покое. Если тебе нужны люди, давай этот проект свернем и сделаем другой – поменьше.
 
А теперь попробуем разобраться, в каких ситуациях нельзя показывать устав проекта заказчику. Ответ – в содержании устава, его разделах. Что может смутить заказчика?
 
Конечно, деньги. Представьте себе ситуацию проекта для внешнего заказчика с высокой маржинальностью. Допустим, клиент заплатил за проект 1 миллион долларов. Вам спонсор согласовал 10 000 долларов бюджет проекта. И если клиент (заказчик) увидит это, у него случится инфаркт. Он поймет, что его просто ограбили. Или заказчик увидит какие-то другие подробности проекта, из которых поймет, что его хотят обмануть. Поэтому когда заказчик платит вам деньги, а у вас в уставе указан бюджет, и этот бюджет существенно расходится с тем, что он вам платит, лучше проявить благоразумность и не показывать ему устав. Но ему можно показывать отдельные разделы документа.
 
Подводя итог, напомним. Инициация проекта заканчивается принятием решения о том, будем мы делать проект или не будем, если будем, то в каком виде. Все правила записываются в устав. Это короткий лаконичный документ, неизменный план, где указано только то, что точно не будет меняться в ходе проекта.
 
С уставом менеджер сверяется в конце, когда проект завершен. По тому, насколько удалось уместиться в неизменные рамки с тройственным ограничением, можно определить, был ли проект успешным. Если устава нет, то сложно определить, получилось ли достичь поставленных целей. В таком случае непонятно, за что платятся бонусы менеджеру, ведь неясно, сумел ли он работать в рамках треугольника. Поскольку проект – это вещь сопряженная с конфликтами, менеджеру всегда сложно. И если он получает бонусы за проект, выполненный по планам, которые сам же переписывает по ходу, или по субъективному мнению высшего руководства, то это уже совсем другая история, а не проектное управление. В этом случае руководство прокачивает в людях неумение управлять проектами, а умение нравиться. А это не сложно – понравиться одному человеку, начальнику. Даже если все время проект проваливаешь. Но в итоге в таких компаниях часто выращивают целую плеяду людей, которые умеют строить отношения внутри компании, но не умеют управлять проектами.
 
После того, как подписали устав, вышли из условного кабинета спонсора проекта и закрыли за собой дверь — вы теперь “главный”. Спонсор теперь ждет, когда появится результат проекта. Он свое дело сделал: задачу поставил, и ему не очень интересно, что дальше, он не будет бегать за вами. А дальше ваше дело, какие планы вы будете строить, как вы будете их строить. Вам решать как лучше планировать. Как мотивировать команду. Как проверять контрольные точки и так далее. Главное — попадите в устав, в треугольник, достигните цели и удовлетворенности ключевых заинтересованных сторон.
 
Методологи придумали некий алгоритм. Они считают — если использовать его, то вероятность попасть в треугольник и удовлетворить ключевые ожидания повышается. Но никто, и даже PMI не считает это алгоритм “догматичным” и обязательным. Если нужно — переделывайте. “Допиливайте” под себя, дорабатывайте напильником. Нет идей как “допиливать” — попробуйте использовать в чистом виде. 🙂

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

Данная статья написана на основании видео учебного курса по управлению проектами.

Предыдущая часть курса: Управление заинтересованными сторонами. Курс по управлению проектами, часть 4

Следующая часть курса: Алгоритм управления содержанием проекта. Курс по управлению проектами, часть 6

Начало курса: Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера. Курс по управлению проектами, часть 1