Тема 7: управление стоимостью it-проектов: оценка стоимости и затрат проекта.

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

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

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

Оценка затрат IT-проекта предполагает выполнение следующих четырех шагов:

1. оценка размера разрабатываемого продукта;

2. оценка трудоемкости в человеко-месяцах или человеко-часах;

3. оценка продолжительности проекта в календарных месяцах;

4. оценка стоимости проекта.

Оценка трудоемкости проекта производится на основании его размера. Для такой оценки существуют 2 основных способа:

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

- в организации регулярно документируются результаты предыдущих проектов;

- по крайней мере один из предыдущих проектов (а лучше если несколько) имеет аналогичный характер и размер;

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

2. Если предыдущий подход по разным причинам оказывается неприменимым, следует использовать один из известных алгоритмических методов оценивания (например, модель СОСОМО или метод функциональных точек).

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

Структура затрат проекта состоит из 5 частей:

1.прямые и накладные затраты по каждой работе WBS;

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

3.затраты на резерв стимулирования персонала (часть допол­нительного финансирования, которая находится в ведении руководителя и членов команды во время проекта и не входит в фонд оплаты труда);

4.резерв на управление «известными рисками» (расходы на возможные штрафы, страхование контрактов, надбавки подрядчикам за фиксиро­ванные цены контрактов и т. п.);

5.резерв на управление «неизвестными рисками» (обычно от 1% до 10% от бюджета проекта).

В случае внешнего заказчика указанные затраты с учетом прибыли по про­екту составляют его цену.

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

Исходными данными для оценки стоимости проекта являются:

- WBS,

- календарно-сетевой график проекта,

- дерево ресурсов с их характеристиками,

- информация о стоимости накладных расходов,

- используемые принципы мотивации,

- поли­тика и резервы для управления рисками.

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

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

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

- допустимые трудозатраты (стоимость) на разработку ПО с требуемым качеством;

- время – длительность полного цикла создания программного продукта;

- необходимое и доступное число специалистов соответствующей квалификации.

Структура стоимости IT-проекта существенно зависит от его типа, жизненного цикла, применяемых методов его разработки и метода оценки. Так, многие авторы отмечают высокую долю стоимости этапа сопровождения. Для некоторых типов IT-проектов она может составлять 60% и более от общей стоимости. Между тем, этап сопровождения включает выполнение двух видов работ: исправление ошибок в программе (несоответствий первоначальным требованиям) и внесение изменений в программу (добавление новых требований). При другом подходе к оценке можно считать, что этап сопровождения не стоит оценивать отдельно, т.к. исправление ошибок можно отнести к продолжению тестирования, а внесение изменений – к новому проекту.

Типовое распределение стоимости между основными этапами (без сопровождения) жизненного цикла выглядит следующим образом:

- 15% - спецификация – формулировка требований и условий разработки

- 25% - проектирование – разработка и верификация проекта

- 20% - разработка – кодирование и тестирование компонент

- 40% - интеграция и тестирование – объединение и сборочное тестирование продукта

Отклонения от этой схемы в зависимости от типа IT-проекта выглядят следующим образом:

1. Для коробочного ПО характерна более высокая доля тестирования за счет сокращения, прежде всего, доли спецификации (до 5%)

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

3. Среди методов оценки стоимости проектов можно выделить:

1. по аналогиям(пассивный)— при таком подходе считается, что проекты и работы одно­типны, эффективность ресурсов не меняется, технологии не совершенствуют­ся.

2. параметрическая(1м - ***$, значит 9м - ***$)

3. оценка «снизу – вверх» –оценка необходимых для выполнения работ ресурсов начинается са­мими исполнителями. При этом используется ИСР, информация о вре­мени выполнения работ и затратах. Основана на параметрических оценках. Метод достаточно точный, т.к. исполнители имеют более точные сведения о требуемых ресурсах, чем высшее руководство. Здесь осуществляется прямое вовлечение менеджеров низшего звена в подготовку сметы, что повышает вероятность того, что они примут результи­рующую смету без проблем и негативной оценки. Иногда возникает ситуация, когда исполнители переоценивают необходи­мые ресурсы, поскольку считают, что высшее руководство все равно снизит итоговую смету на какой-то процент. Такое поведение высших менеджеров может быть связано с тем, что они считают метод бюджетирования «снизу вверх» рискованным, так как не слишком доверяют подчиненным. Смета яв­ляется наиболее важным инструментом контроля над участниками проекта. Высшее руководство не желает передавать этот контроль своим подчинен­ным, чьи опыт и мотивы неясны.

4. оценка «сверху - вниз» -оценка стоимости начина­ется с оценки высшим руководством ресурсов, необходимых для осуществления проекта, ограничений по финансированию и его итоговой стоимости. Основана на экспертных оценках стоимости. Смета, формируясь «наверху», разбивается на все более мелкие детали. Логика метода представлена в таблице 8.3.

5. вероятностная (метод PERT). Входом для данного метода оценки служит список элементарных пакетов работ. Для инженерного подхода нет необходимости точно знать закон распределения нашей оценки трудоемкости каждого такого элементарного пакета.

Диапазон неопределенности достаточно охарактеризовать тремя оценками:

1. Mi — наиболее вероятная оценка трудозатрат.
2. Oi — минимально возможные трудозатраты на реализацию пакета работ.
3. Pi — пессимистическая оценка трудозатрат. Все риски реализовались.

Оценку средней трудоемкости по каждому элементарному пакету можно определить по формуле:

Ei = (Pi + 4Mi + Oi)/6.