Как часто стоит пересматривать портфель проектов

У вас множество проектов. Вы не можете выполнить все одновременно , потому что у вас нет столько ресурсов. Вы же знаете, что если вы попросите кого-нибудь работать над более чем одним проектом, никто ничего не сможет сделать. Одной из стратегий выполнения нескольких проектов является создание портфеля проектов и их ранжирование согласно приоритету.

Когда множество людей собирают свои проекты в портфель, у них всегда есть 12-18 месяцев на их выполнение. На каком-то этапе, задолго до завершения 12-и месяцев, может так случиться, что вам необходимо будет пересмотреть свой портфель.

Вам стоит планировать будущие изменения после рассмотрения портфеля, но как часто его стоит пересматривать? Если выбудете делать это слишком часто, то вы можете раздражать всех вовлеченных в проект потому, что мало чего будет изменяться. Редких пересмотров не хватит. Так где же золотая середина? Ответ зависит от нескольких вещей.

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

Идеальным временем пересмотра портфеля являются следующие этапы :

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

Данные циклы независимы. Вот пример, когда данные зависимости могут быть выражены.

Начальник производства Том в большой компании разговаривая с другим начальником производства Алексом спрашивал

Том: Алекс, мне необходимы разработчики для работы над усовершенствованием моего продукта. Когда они завершат работу над твоим?

Алекс: Не ранее чем через 3 месяца.

Том: Погоди. Они работают на тебя уже шесть месяцев. Мой продукт должен быть выпущен раньше, чем через 3 месяца. Мои заказчики требуют его, и корпоративный регламент также требует от меня выпуска нового продукта в течение трех месяцев. Если разработчики не смогут работать над моим продуктом, как же он будет выпущен? Из-за чего такие задержки?

Алекс: Ну, у нас были проблемы с определением требований, и это нас немного задержало. Затем проблемы появились с функциональными спецификациями. Требования все еще были не совсем четкими, поэтому нам пришлось их пересмотреть. Я настоял на том, чтобы все функции были разработаны одновременно, поэтому тестеры не могут начать работу, потому что ничего еще не выполнено для них.

Ситуация не из приятных.

Алекс допустил несколько классических ошибок:

1. Он думал, что его проект единственный, не учитывая остальной портфель в своих планах.
2. Настаивал на серийном цикле разработки, хотя он знал о временных ограничениях своего проекта.
3. Не позволил команде реализовывать и тестировать отдельные функции, чтобы они могли остановиться на каком-то этапе, даже когда не все требования будут исполнены.

Если бы Алекс и Том пересматривали портфель чаще, то Алекс мог бы избежать первой ошибки и мог бы заметить следующие ошибки далее в проекте.

Зависимость циклов проекта от времени него завершения

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

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

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

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

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

Зависимость циклов планирования от плана разработки продукта

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

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

Планирование расходов в цикле спонсирования

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

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

Поскольку уже к третьему месяцу бюджет оказывается неверным, то вам стоит составить цикл спонсирования длительностью в три месяца, при этом спонсировать один раз в этом периоде. Если вы используете гибкую методологию разработки с более короткими, чем 3 месяца, сроками на реализацию функций, то вы можете установить длительность цикла спонсирования, равную срокам реализации.

Одним из преимуществ частого спонсирования является то, что вам не приходится спонсировать все, - вам необходимо спонсировать только ближайшее будущее. Вы будете тратить меньше времени на спонсирование и больше времени на понимание того, что вам нужно.

Дополнительным преимуществом будет то, что для негибкого метода разработки проектная команда должна будет пересматривать время, которое понадобится на завершение проекта. Зачастую команды не имеют понятия о том, сколько времени им необходимо. Если их прогнозы неверны, то в случае с частым спонсированием они будут больше понимать о текущем состоянии дел и будут делать лучшие прогнозы.

Трехмесячные циклы пересмотра портфеля

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

Обратно к исходному вопросу

Том и Алекс изучили различные типы жизненных циклов проекта и перепланировали свой подход к управлению продуктом. Во-первых, они создали трехмесячный план разработки продукта, составив список функций, реализуемых за каждый период. Они сделали наброски требований для каждого элемента из списка, обновляя требования по мере поступления информации и знаний о требованиях.

Они работали с высшим руководством для определения, когда стоит выпускать продукты, а затем разработали "желаемый" портфель продуктов. Но также был составлен текущий портфель ("как есть"), отображающий реальность.

Затем они работали с руководителями проектов для того, чтобы донести до них информацию о наличии или отсутствии ограничивающих сроков. Вот как это выглядело на ежемесячном собрании с руководителями проектов. Том разослал всем участникам текущий портфель и план разработки как своих продуктов, так и продуктов Алекса. Высшее руководство требовало от них выпуска обоих продуктов в текущей четверти, но с текущим портфелем они этого выполнить не могли. Руководство также указало, что проект Алекса имеет высший приоритет.

Как же это можно решить?

Алекс предложил перейти к более коротким срокам, не более чем четыре недели, или даже две. Разработчики могут работать над его проектом первое время, выпустить его продукт в первой половине четверти и затем перейти к проекту Тома. Если они встретят проблемы, то они будут знать заранее об этом, потому что всем будет известно , что уже завершено, а что еще нет. Тогда они могут обновить портфель и увидеть то, что еще стоит выполнить.

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

Вывод

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

Задумываясь обо всех этих методах и циклах разработки, нам стоит вернуться к исходному вопросу - как часто вам стоит пересматривать портфель проектов?

Пересматривайте по возможности, но не чаще необходимого . Вам стоит работать с другими руководителями проектов и высшим руководством, организовывая ваши проекты таким образом, чтобы продукты были выпущены хотя бы раз в год. Нет необходимости в официальном выпуске продукта, но если ваш проект находится в финальном состоянии, то вы можете переместить команду к другому проекту, удовлетворяя нужды портфеля проектов. Затем вы сможете пересмотреть портфель и осуществить новые решения по поводу работы, выполняемой организацией.

Johanna Rothman