Читать книгу Трансформация: особенности управления проектами преобразований. МВА-библиотека - Никита Сергеев - Страница 10

Устав проекта – это документ, который обычно готовит руководитель проекта после получения вводных о проекте. Это будет Вашей Альфа и Омегой весь проект. Это то, о чем Вы договариваетесь «на берегу».

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

В уставе обычно включаются (рис.1.6)

Рис.1.6. Составные части Устава Проекта

· Предпосылки (бэкграунд, исходная ситуация, проблематика, которая привела к инициации проекта)

· Цели проекта

· Описание результата проекта – то, что должно получиться в итоге на выходе.

· Скоуп (масштаб и границы) проекта – не только то, на что он распространяется, а и что в проект не входит. Например, Вы разворачиваете CRM систему – покрывающую все подразделения продаж, кроме розничной сети компании. И вот это (что в проект не входит) надо обязательно указать! Надо указывать вообще все что не входит в проект (особенно то, что кому-то из числа власть имущих в организации вдруг может показаться частью проекта). Но об этом мы еще отдельно будем говорить.

· Ключевые требования и метрики (если такие есть), по которым будут приниматься результаты проекта

· Любые предположения, ограничения и риски. Тут остановлюсь поподробнее, потому что из моего опыта даже опытные менеджеры проектов опускают эти моменты (рис. 1.7).

Рис.1.7. Предположения, ограничения и риски

С ограничениями обычно всем понятно – это данность в организации или ее внешней среде, с которой нужно смириться, так как за время существования проекта она не изменится (например, есть законодательный акт, который требует согласование поставки такого оборудования с 3 госслужбами каждая из которых рассматривает их не менее чем 1 месяц; или на рынке нет локальных поставщиков необходимых услуг). Ограничения напрямую закладываются в план управления проектом.

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

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

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

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

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

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

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

И вообще вопрос детализации устава очень часто возникает ку слушателей: нет стандартов к объему устава, зависит от проекта и компании, от длительности и прошлого опыта сотрудничества с организацией…

Устав вообще может выглядеть брифом на 1 страничку (рис.1.8).

Рис.1.8. Устав в виде 1-страничного брифа в Excel

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