Предпроектный анализ: Серия 4

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

[snedpulse-form id=”278″]

В предыдущих сериях

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

Во второй серии я рассказывал про частые проблемы предпроекта.

В прошлой (третьей) серии речь шла о части базовых принципов таких как:

• Устройство IT-системы и классификация IT-продуктов.
• Уровни V-модели и жизненный цикл системы.
• Взгляд на систему как на финансовый актив.

В этой серии мы закончим с описанием «как правильно», чтобы дальше посмотреть, что делать, если правильно не выходит.

В этой серии вы узнаете:

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

Жизненный цикл системы и конус неопределенности

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

Каждая фаза построения системы снимает часть неопределенности. При прохождении по типовым фазам проекта неопределенность падает экспоненциально:

• Когда у нас есть идея, выраженная в полустраничном брифе, разброс в стоимости и отдаче может достигать нескольких порядков.
• Когда появились бизнес-требования, при этом бизнес-план или бизнес-модель проработаны, мы уменьшаем разброс в стоимости/отдаче до порядка.
• Для дальнейшего уменьшения разброса нужно проработать ключевые решения по облику и устройству системы. Такая проработка снижает разброс до полупорядка. Несмотря на то что разброс все еще велик, анализ соотношения отдачи и стоимости дает основное решение — будем ли мы строить систему или поищем что-то более выгодное.
• Уточнив условия, в которых будет строиться система (кто это будет делать и в какие сроки), мы можем снизить разброс стоимости до величин, с которыми можно работать методами проектного управления, закладывая запасы и обрабатывая риски. Уточненные условия записываются в техническое задание.
• Только техническое проектирование дает практически точную смету с погрешностью, приемлемой для бизнеса.

Что из этого следует:

• С точки зрения распределения ресурсов мы должны успеть свернуть проект до того, как потратили существенную долю стоимости, если он перестал быть выгодным. Фазы от брифа до технического проекта должны занимать малую долю общей стоимости системы.
• Также надо понимать, что нельзя прийти с идеей и сразу заложить стоимость. Когда вам говорят, что здесь 20 млн и это точно, имея только бриф, — не верьте, так не бывает.
• Бизнес-требования и концептуальную проработку делать нужно, так как они снимают неопределенность, но это может не отбиться, если проект не стартует. Как результат — фазы должны быть максимально дешевыми, но качественно снимать неопределенность.

Как работает оценка

Есть распространенное заблуждение, препятствующее нормальному запуску предпроектных работ: если мы не можем быстро обеспечить точную оценку, то не стоит вообще возиться с требованиями. Это неверно. Сумма неточных оценок точнее — факт из теории вероятности.

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

Фазы проекта с точки зрения режима оценки выглядят так:

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

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

Еще одна распространенная идея звучит так: «Бизнес-требования не должны быть измеримыми». Запомните — это ложь!

Чего нужно добиться в предпроекте

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

1. Понять сроки и стоимость, чтобы запланировать затраты и принять решение «go/not go». Желательно спрогнозировать эффект и отдачу для ускорения этого решения.
2. Допродать систему: показать заказчику понимание его целей; показать пользователям решение их проблем; успешно завершить торг за бюджет (он есть всегда).
3. Создать основание для приемки (контракт на объем и качество результата — техническое задание), не забыть заложить в план валидацию получившейся системы с точки зрения практического оправдания ожиданий всех сторон.
4. Определиться с ресурсами: видами, этапами, сроками, объемами работ и источниками ресурсов, чтобы подтвердить оценки у исполнителей и зафиксировать стоимость системы.

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

Почему это может не (или даже не может) работать

В итоге всех предыдущих рассуждений у нас есть 3 конфликтующих условия:

1. Предпроектный анализ надо делать быстро.
2. Предпроектный анализ надо делать дешево.
3. Предпроектный анализ надо делать качественно.

Те, кто знаком с правилом проектного треугольника, понимают, что так не бывает.

Есть еще несколько дополнительных трудностей:

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

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

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

Это достаточно распространенная точка зрения среди менеджеров проектов, ведь, если тебе что-то поручено, ты должен убиться сам, выдавить до капли команду, вывернуть до переломов руки поставщикам, изнасиловать заказчика, но достичь цели.

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

Правильный подход заключается в том, что от невыгодного актива необходимо избавиться как можно раньше. Задача аналитика и менеджера в предпроекте — сделать это.

Как получить бюджет на предпроект

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

Пока неопределенность велика, мы должны мало вкладывать и снижать ее.

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

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

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

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

Мои (очень усредненные) рекомендации по соотношению стоимости частей предпроекта:

• Все, что происходит до старта выполнения работ, не должно стоить более 10-30% проекта.
• Предпроект должен стоить 1—5% от прогнозной стоимости системы.
• На ранних стадиях, пока нет бизнес-требований, прогнозной стоимости может не быть и нужно отталкивать от подсчитанной отдачи — можно принять 0,1—0,5% за срок эксплуатации системы на бюджет создания бизнес-требований (с учетом того, что стартует не каждый предложенный проект).

Например, если мы продаем систему, которая стоит ~100 млн (по аналогии). Это имеет смысл, если отдача от ее эксплуатации составит хотя бы ~300-500 млн с учетом низкой точности всех оценок.

В таком случае можно считать нормальными такие затраты:

• Бизнес-требования — 0,5—1 млн.
• Концепция — 1—3 млн.
• Технический проект — 10—30 млн

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

Краткий итог

На этом мы завершаемм обзор правильного предпроекта и повторим самое главное:

1. Проект необходимо рассматривать как рискованный финансовый актив.
2. Уровень неопределенности должен быть известен всем и обсуждаем между всеми заинтересованными лицами.
3. Затраты на анализ должны соотноситься с прогнозной выгодой и вероятностью ее получения.
4. В ходе проработки необходимо добиваться качества требований, достаточного для оценки стоимости и сроков с точностью, присущей текущей фазе.
5. В частности, уже бизнес-требования должны быть измеримыми.
6. Необходимо помнить о полном списке задач предпроектной фазы, пропуск каждой из которых повышает вероятность провала проекта на порядки.

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

Продолжение следует…