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

· Во-вторых, постоянно контролируем нет ли изменений и делаем при необходимости перепланировку проекта

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

Каждый инкремент Вы запускаете «по кругу» (анализ-проектирование-разработка-тестирование-…) и «допиливаете» так, пока не будет достигнут необходимый результат. Это как «кушать слона по кусочку».

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

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

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

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

Даже тот же РМВoК описывает требования и содержание документов, но не дает шаблонов.

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

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

Из моего опыта в трансформационных проектах есть три главные документа – устав, содержание и план. И еще один с моей колокольни важный, но оспариваемый многими коллегами по консалтинговому цеху, документ как бизнес-кейс – ведь он вроде как нужен только для запуска проекта, а потому и не является проблемой менеджера проектов, которому проектом остается лишь управлять…

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

Далее в нескольких последующих пунктах прицельно пройдемся по каждому из этих документов.

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

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

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

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

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

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

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

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