· Во-вторых, постоянно контролируем нет ли изменений и делаем при необходимости перепланировку проекта
При инкрементном подходе Вы разбиваете проект на набор результатов (инкрементов), которые необходимо получить в ходе проекта (возможно, потом еще и увязать друг с другом, так как порознь они могут являть «запчастями», а не собранным «автомобилем»).
Каждый инкремент Вы запускаете «по кругу» (анализ-проектирование-разработка-тестирование-…) и «допиливаете» так, пока не будет достигнут необходимый результат. Это как «кушать слона по кусочку».
Именно при инкрементном подходе зачастую сначала создается минимально жизнеспособный продукт (MVP), который по мере прохождения итераций доделывается до целевого.
Глобально можно сказать, что если итеративный подход фокусируется на разработке целевого продукта путем выполнения ряда повторяющихся циклов, то инкрементный подход фокусируется на последовательном наращивании функциональности итогового продукта (вплоть до сборки из запчастей).
Сразу скажу, что деление на итеративный и инкрементный подходы теоретически-условное – на практике они оба используются одномоментно, потому в среде практиков можно просто говорить об адаптивном жизненном цикле как таковом.
Проектная документация
Проектная документация – это вещь, которая более всего заботит умы проектных менеджеров, работающих внутри компании. Многие пытаются найти «правильные шаблоны» документов – но их в природе не существует.
Даже тот же РМВoК описывает требования и содержание документов, но не дает шаблонов.
Каждая организация имеет свои стандарты и требования. Если их нет – то менеджер проекта волен руководствоваться здоровой логикой и целесообразностью документации. Вообще задайте в поисковике «шаблоны проектных документов» – и выбирайте в свободном доступе любой формат и варианты. Но Вы все равно будете адаптировать их под себя, организацию или проект.
Много книг по проектному менеджменту предлагают наборы шаблонов проектной документации (некоторые только из этих шаблонов и состоят). Я по ходу в книге также продемонстрирую внешний вид ряда документов для конкретного проекта. Но не буду выдавать списочный набор готовых шаблонов. Предпочтительнее, когда Вы уловите суть документа и сможете создать его под конкретный проект, а не «потирая руки» заполнить типовые бумаги как бухгалтер или кадровик.
Из моего опыта в трансформационных проектах есть три главные документа – устав, содержание и план. И еще один с моей колокольни важный, но оспариваемый многими коллегами по консалтинговому цеху, документ как бизнес-кейс – ведь он вроде как нужен только для запуска проекта, а потому и не является проблемой менеджера проектов, которому проектом остается лишь управлять…
От этих документов уже «отбиваются» остальные документы – сметы, бюджеты, отчеты и т. д. Да и зачастую имея вышеуказанный набор, все остальные документы в проектах преобразований иногда стают неважными.
Далее в нескольких последующих пунктах прицельно пройдемся по каждому из этих документов.
Устав проекта
Устав проекта – это документ, который обычно готовит руководитель проекта после получения вводных о проекте. Это будет Вашей Альфа и Омегой весь проект. Это то, о чем Вы договариваетесь «на берегу».
Многие заказчики тут же называют подготовку устава «бюрократической возней» и, извините, «жопорикрывательством» – но плюньте на мнения всех этих «птиц-говорунов». Мой совет – не начинайте никогда проект без устава.
В уставе обычно включаются (рис.1.6)
Рис.1.6. Составные части Устава Проекта
· Предпосылки (бэкграунд, исходная ситуация, проблематика, которая привела к инициации проекта)
· Цели проекта
· Описание результата проекта – то, что должно получиться в итоге на выходе.
· Скоуп (масштаб и границы) проекта – не только то, на что он распространяется, а и что в проект не входит. Например, Вы разворачиваете CRM систему – покрывающую все подразделения продаж, кроме розничной сети компании. И вот это (что в проект не входит) надо обязательно указать! Надо указывать вообще все что не входит в проект (особенно то, что кому-то из числа власть имущих в организации вдруг может показаться частью проекта). Но об этом мы еще отдельно будем говорить.
· Ключевые требования и метрики (если такие есть), по которым будут приниматься результаты проекта
· Любые предположения, ограничения и риски. Тут остановлюсь поподробнее, потому что из моего опыта даже опытные менеджеры проектов опускают эти моменты (рис. 1.7).
Рис.1.7. Предположения, ограничения и риски
С ограничениями обычно всем понятно – это данность в организации или ее внешней среде, с которой нужно смириться, так как за время существования проекта она не изменится (например, есть законодательный акт, который требует согласование поставки такого оборудования с 3 госслужбами каждая из которых рассматривает их не менее чем 1 месяц; или на рынке нет локальных поставщиков необходимых услуг). Ограничения напрямую закладываются в план управления проектом.
Если взять предположения – то это те вещи, которые должны быть правдой, чтобы проект был успешно реализован. Но нет уверенности в их истинности. Поэтому, если Вам дали одни вводные об окружении проекта в виде предположений, и Вы на них построили предположения, на которых базируется реализация трансформационного проекта – оговорите эти предположения. Ведь если потом окажется что-то не так, то будете долго и нудно (часто безуспешно) объяснять заказчику что он «сам дурак и ввел Вас в заблуждение».
Особенно это важно для внешних менеджеров проектов и консультантов – Ваши представления о том, в каком окружении и условиях будет осуществляться проект, строятся на тех предположениях и мнениях, которые Вам говорит заказчик. Даже если он сам в них верит – он все равно может сильно ошибаться, смотря на ситуацию сквозь свои «очки мировоззрения».
Например, заказчик говорит, что проект для нас по срокам критически важен и «все отделы будут на 100% помогать в реализации и день, и ночь, и выделять нужных людей» – обязательно указать сее изречение в качестве предположения.
Или заказчик гарантирует, что «у этого проекта вообще не будет никаких бюрократических преград внутри компании: сказали или е-мейл написали – и тут же получили», а потом оказывается, что «любой чих» – это действительно отсутствие преград кроме 100500 служебок.
В одном проекте я вообще основные предположения (ибо очень сладко мне «продавали» тот проект – вплоть до того, как госструктура все будет даже закупаться без тендеров) после первого общения (даже не готовя еще устава) выписал в табличку. Две колонки: в первой предположение, в соседней колонке – что будет если предположение ложное (тут затянутся сроки проекта, тут не будет вообще сделан функционал и т. д.). Так «прыти» у заказчиков сразу быстро поубавилось, посговорчивей стали и попрактичнее в части сроков, цены проекта, оплаты для команды и т.д..
Риски – о них все знают, и большинство из них следует из предположений, которые могут быть потом по факту ложными или истинными. Мы конечно не будем детально рассматривать управление рисками от идентификации, оценки и анализа, мониторинга и контроля, разработки мероприятий по снижению или устранению и т. д. Это опытные проектные менеджеры и так знают, а те кто новичок – смогут легко найти и прочесть.
Возвращаясь к уставу комплексно: главное не переборщите с его детализацией – он должен высокоуровнево описывать проект и его допущения, которые потом помогут в планировании. И описание всех моментов должно быть уровня заказчика проекта, а не «что попало». Например, писать мелочь в допущения (например, канцелярию выдадут сразу) – это полная глупость, если устав согласовывается с генеральным директором или руководителем функции.