Тема 3. Инициация проекта

Цель: рассмотреть инициацию проекта

План:

        1.	Управление приоритетами проектов
        2.	Концепция проекта
        3.	Цели и результаты проекта
        4.	Допущения и ограничения
        5.	Ключевые участники и заинтересованные стороны
        6.	Ресурсы
        7.	Сроки
        8.	Риски
        9.	Критерии приемки
        10.	Обоснование полезности проекта

1 Управление приоритетами проектов

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

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

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

    •	Финансовая ценность.
    •	Стратегическая ценность.
    •	Уровень рисков.

Шкала оценки финансовой ценности проекта может выглядеть следующим образом:

• ВысокаяОжидаемая окупаемость до 1 года. Ожидаемые доходы от проекта не менее чем в 1.5 раз превышают расходы. Все допущения при проведении этих оценок четко обоснованны.

• Выше среднегоОжидаемая окупаемость проекта от 1 года до 3 лет. Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы. Большинство допущений при проведении этих оценок имеют под собой определенные основания.

• Средняя.Проект позволяет улучшить эффективность производства в Компании и потенциально может снизить расходы компании не менее чем на 30%. Проект может иметь информационную ценность или помочь лучше контролировать бизнес.

• Низкая. Проект немного снижает расходы компании не менее чем на 10% и дает некоторые улучшения производительности производства.

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

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

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

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

• Низкая.Стратегическое воздействие отсутствует или незначительно. Влияние на клиентов несущественно. Конкуренты могут легко повторить результаты проекта.

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

• Низкий.Цели проекта и требования хорошо поняты и документированы. Масштаб и рамки проекта заданы четко. Ресурсы требуемой квалификации доступны в полном объеме. Разрабатываемые системы не потребуют новой технологической платформы.

• Средний. Цели проекта определены более-менее четко. Хорошее понимание требований к системе. Масштаб и рамки проекта заданы достаточно хорошо. Ресурсы требуемой квалификации доступны в основном. Системы создаются на новой, но стабильной технологической платформе.

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

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

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

2 Концепция проекта

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

    •	Название проекта
    •	Цели проекта
    •	Результаты проекта
    •	Допущения и ограничения
    •	Ключевые участники и заинтересованные стороны
    •	Ресурсы проекта
    •	Сроки
    •	Риски
    •	Критерии приемки
    •	Обоснование полезности проекта

В качестве примера, который позволит иллюстрировать теоретическое изложение основ управления проектами, возьмем реальный проект разработки ПО для автоматизации одного из подразделений крупной производственной компании. Назовем его «Автоматизированная система продажи документации». Краткая легенда проекта. Заказчик ОАО «XYZ» является одним из ведущих производителей сложных технических изделий. Отдел «123», входящий в ОАО «XYZ», отвечает за продажу дополнительной сопроводительной документации для клиентов ОАО. Дополнительная документация не входит в стандартную поставку, поскольку владелец этого технического изделия не всегда сам его эксплуатирует, а передает в эксплуатацию другой компании, которая становится клиентом «XYZ», и закупает у нее эксплуатационную документацию. Ремонт и техобслуживание конкретного изделия может выполнять третья компания, которой уже потребуется детальная техническая документация по ремонту и обслуживанию. Она также становится клиентом «XYZ» и закупает у нее требуемую продукцию.

Основная функция отдела «123» — получение и обработка заказов на дополнительную документацию, согласно ежегодно рассылаемому каталогу. В связи с переездом отдела «123» в новое здание, была поставлена задача на разработку и поставку системы, автоматизирующей основную деятельность отдела «123». Текст документа Концепция проекта, который будет приводиться в качестве примера, будем выделять цветом фона.

3 Цели и результаты проекта

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

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

Цели должны быть значимыми (направленными на достижение стратегических целей Компании), конкретными (специфичными для данного проекта), измеримыми (т.е иметь проверяемые количественные оценки), реальными (достижимыми). Четкое определение бизнес-целей важно, поскольку существенно влияет на все процессы и решения в проекте. Проект должен быть закрыт, если признается, что достижение цели невозможно или стало нецелесообразным. Например, если реальные затраты на проект будут превосходить будущие доходы от его реализации. Результаты проекта отвечают на вопрос, что должно быть получено после его завершения. Результаты проекта должны определять:

- Какие именно бизнес-выгоды получит заказчик в результате проекта.
- Какой продукт или услуга. Что конкретно будет произведено по окончании проекта.
- Высокоуровневые требования. Краткое описание и при необходимости ключевые свойства и/или характеристики продукта/услуги.

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

    1.	Цели и результаты проекта
    1.1. Целью проекта является повышение эффективности основной производственной
         деятельности отдела «123».
    1.2. Дополнительными целями проекта являются:
    1.2.1. Установление долгосрочных отношений с важным заказчиком ОАО «XYZ».
    1.2.2. Выход на новый перспективный рынок современных B2C систем.
    2.	Результаты проекта должны обеспечить:
    2.1. Снижение затрат на обработку заявок.
    2.2. Снижение сроков обработки заявок.
    2.3. Повышение оперативности доступа к информации о наличии продукции.
    2.4. Повышение оперативности доступа к информации о прохождении заявок.
    2.5. Повышение надежности и полноты хранения информации о поступивших заявках и
         результатах их обработки.
    3.	Продуктами проекта являются:
    3.1. Прикладное ПО и документация пользователей.
    3.2. Базовое ПО.
    3.3. Оборудование ЛВС, рабочие станции, сервера и операционно-системное ПО.
    3.4. Проведение пуско-наладочных работ и ввод в опытную эксплуатацию.
    3.5. Обучение пользователей и администраторов системы.
    3.6. Сопровождение системы на этапе опытной эксплуатации.
    3.7. Передача системы в промышленную эксплуатацию.
    4.	Система должна автоматизировать следующие функции:
    4.1. Авторизация и аутентификация пользователей.
    4.2. Просмотр каталога продуктов.
    4.3. Поиск продуктов по каталогу.
    4.4. Заказ выбранных продуктов.
    4.5. Просмотр информации о статусе заказа.
    4.6. Информирование клиента об изменении статуса заказа.
    4.7. Просмотр и обработка заказов исполнителями из службы продаж.
    4.8. Просмотр статистики поступления и обработки заказов за период.
    4.9. Подготовка и сопровождение каталога продукции.

4 Допущения и ограничения

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

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

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

    5.	Допущения и ограничения
    5.1. Проектирование прикладного ПО выполняется с использованием UML.
    5.2. Средством разработки ПО является Symantec Visual Cafe for Java.
    5.3. В качестве промежуточного ПО сопровождения и поддержки каталога используется ОО БД «Poet».
    5.4. Нагрузка на систему не должна быть более 100 одновременно работающих пользователей.
    5.5. В рамки проекта не входят:
    5.5.1. Защита системы от преднамеренного взлома.
    5.5.2. Разработка B2B API и интеграция с другими системами.

5 Ключевые участники и заинтересованные стороны

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

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

    Содержание этого раздела в концепции-примере будет иметь вид.
    6.	Ключевые участники и заинтересованные стороны
    6.1. Спонсор проекта — директор Департамента информатизации ОАО «XYZ» В.Васильев.
    6.2. Заказчик — начальник Отдела «123» Ф.Федотов
    6.3. Пользователи автоматизированной системы:
    6.4. Клиенты ОАО «XYZ» (поиск и заказ документации).
    6.5. Руководство ОАО «XYZ» (анализ деятельности Отдела «123»).
    6.6. Сотрудники производственных департаментов ОАО «XYZ» (сопровождение каталога).
    6.7. Сотрудники Отдела «123» (обработка заявок и поставка документации).
    6.8. Сотрудники департамента информатизации ОАО «XYZ» (администрирование системы).
    6.9. Куратор проекта — начальник отдела заказных разработок И.Иванов.
    6.10. Руководитель проекта — ведущий специалист отдела заказных разработок МП П.Петров.
    7.	Соисполнители:
    7.1. Поставщик оборудования и операционно-системного ПО — ООО «Альфа».
    7.2. Поставщик базового ПО — ООО «Бета».

6 Ресурсы

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

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

Специфика программного проекта заключается в том, что людские ресурсы вносят основной вклад в его стоимость. Все остальные затраты, как правило, незначительны, по сравнению с этим расходами. О том, как следует подходить к оценкам трудозатрат на реализацию проекта разработки ПО, мы будем подробно говорить в следующих лекциях. На фазе инициации хорошей считается оценка трудозатрат с точностью от -50% до +100%. Необходимо помнить, что помимо непосредственно программирования в проекте разработки ПО есть много других процессов, которые требуют ресурсы соответствующей квалификации, а само программирование составляет лишь четверть всех затрат. Распределение трудозатрат по основным производственным процессам при современном процессе разработки ПО выглядит в среднем следующим образом:

Рисунок 14.Распределение трудозатрат по основным производственным процессам при разработке ПО

Поэтому, если по вашей оценки для реализации требуемой функциональности в проекте необходимо написать 10 KSLOC (тысяч строк исходного программного кода), а ваши программисты пишут в среднем по 100 SLOC в день, то общие трудозатраты на проект будут не 100 чел.*дней, а не менее чем 400 чел.*дней. Остальные ресурсы потребуются на анализ и уточнение требований, проектирование, документирование, тестирование и другие проектные работы. Прежде, чем определять численность и состав проектной команды для нашего примера, нам необходимо сделать оценку трудоемкости разработки ПО. В нашем случае такая экспертная оценка составила с учетом затрат на гарантийное сопровождение на этапе опытной эксплуатации 9000 чел.*час. Исходя из эмпирической кривой Б. Боэма (рисунок 14), численность команды, близкая к оптимальной, составила 10 человек, из них

    8.	Ресурсы проекта
    8.1. Требования к персоналу
    8.1.1. 1 — руководитель проекта,
    8.1.2. 1 — технический лидер (архитектура, проектирование),
    8.1.3. 1 — системный аналитик (требования, тест-дизайн, документирование),
    8.1.4. 4 — программисты (с учетом работ по конфигурационному управлению),
    8.1.5. 3 — тестировщика.
    8.2. Материальные и другие ресурсы
    8.2.1. Сервер управления конфигурациями и поддержки системы контроля версий
    8.2.2. 2 серверных комплекса (для разработки и тестирования):
    8.2.3. Сервер приложений с установленным BEA Weblogic AS
    8.2.4. Сервер оперативной БД с установленной Oracle RDBMS
    8.2.5. Сервер каталога с установленной OODB "Poet"
    8.3. Лицензии на средства разработки и тестирования:
    8.3.1. Oracle Designer — 1 лицензия
    8.3.2. Symantec Visual Cafe for Java — 5 лицензий.
    8.3.3. IBM Rational Test Robot (1 лицензия разработчика + неограниченная лицензия на клиент).
    8.4. Расходная часть бюджета проекта
    8.4.1. Разработка и сопровождение прикладного ПО:
    8.4.1.1. 9000 чел.*час. * $40 = $360 000
    8.4.2. Поставка оборудования и операционно-системного ПО:
    8.4.2.1. 3 сервера * $10 000 = $30 000
    8.4.3. Поставка базового ПО:
    8.4.3.1. BEA Weblogic AS $20 000
    8.4.3.2. Oracle RDBMS $20 000
    Итого: $430 000

7 Сроки

Ф. Брукс писал: «Чтобы родить ребенка требуется девять месяцев независимо от того, сколько женщин привлечено к решению данной задачи. Многие задачи программирования относятся к этому типу, поскольку отладка по своей сути носит последовательный характер». Там же Брукс приводит исключительно полезную, но почему-то редко применяемую, эмпирическую формулу оценки срока проекта по его трудоемкости. Формула была выведена Барии Боэмом (Barry Boehm) на основе анализа результатов 63 проектов разработки ПО, в основном в аэрокосмической области. Согласно этой формуле, для проекта, общая трудоемкость которого составляет N ч.*м. (человеко-месяцев), пожно утверждать что:

- • Существует оптимальное, с точки зрения затрат, время выполнения графика для первой поставки: T = 2,5 (N ч.*м.)1/3. То есть оптимальное время в месяцах пропорционально кубическому корню предполагаемого объема работ в человеко-месяцах. Следствием является кривая, дающая оптимальную численность проектной команды (рисунок 15).
- • Кривая стоимости медленно растет, если запланированный график длиннее оптимального. Работа занимает все отведенное для нее время.
- • Кривая стоимости резко растет, если запланированный график короче оптимального. Практически ни один проект невозможно завершить быстрее, чем за 3/4 расчетного оптимального графика вне зависимости от количества занятых в нем! (рисунок 16)

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

Рисунок 15. Закон Б.Боэма

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

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

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

Рисунок 16. Следствия закона Б.Боэма

Соответствующий раздел концепции нашего проекта-примера будет иметь следующий вид.

    9.	Сроки проекта
    9.1. 03.03 старт
    9.2. 28.11 завершение
    9.3. Контрольные точки:
    9.3.1. 15.04 ТЗ утверждено
    9.3.2. 30.04 1-я итерация завершена. Подсистема заказа документации
                 передана в тестовую эксплуатацию (на серверах разработчика).
    9.3.3. 15.05 Монтаж оборудования у заказчика завершен .
    9.3.4. 30.05 Базовое ПО установлено у заказчика.
    9.3.5. 15.06 2-я итерация завершена. Подсистема обработки заказов передана
                 в тестовую эксплуатацию на оборудовании Заказчика
    9.3.6. 02.09 3-я итерация завершена. Акт передачи системы в опытную эксплуатацию
                 утвержден
    9.3.7. 28.11 Система передана в промышленную эксплуатацию.

8 Риски

Риск — неопределенное событие или условие, наступление которого отрицательно или положительно сказывается на целях проекта.

Как правило, в случае возникновения негативного риска, почти всегда стоимость проекта увеличивается и происходит задержка в выполнении мероприятий, предусмотренных расписанием проекта. Управлению рисками проекта будет посвящена отдельная лекция. На этапе инициации, когда нет необходимых данных для проведения детального анализа, часто приходится ограничиваться качественной оценкой общего уровня рисков: низкий, средний, высокий. В случае нашего проекта-примера раздел «риски» будет выглядеть следующим образом. 10. Риски проекта 10.1. Задачи системы поняты недостаточно полно. Понимание масштаба и рамок проекта недостаточно. Системы создаются на новой технологической платформе, сомнения в рыночной стабильности платформы. Суммарный уровень рисков следует оценить выше среднего.

9 Критерии приемки

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

    11.	Критерии приемки. По итогам опытной эксплуатации система должна продемонстрировать
        следующие показатели:
    11.1. Средние затраты сотрудников Отдела «123» на регламентную обработку одного заказа
          не превышают 4 чел.*час.
    11.2. Срок регламентной обработки 1-го заказа не более 2 недель.
    11.3. Время поиска и предоставления информации о наличии дополнительной документации не
          более 1 мин.
    11.4. Время предоставления информации о сделанных заказах и истории их обработки не более 1 мин.
    11.5. Система хранит всю информацию о сделанных заказах и истории их обработки.
    11.6. Показатель доступности системы 98%.

10 Обоснование полезности проекта

Этот раздел концепции должен содержать краткое технико-экономическое обоснование проекта:

- Для кого предназначены результаты проекта.
- Описание текущей ситуации «As Is». Какие у потенциального заказчика существуют проблемы.
- Каким образом результаты проекта решают эти проблемы («To Be»).
- Насколько значимо для клиента решение данных проблем (оценка экономического эффекта).
- Какие преимущества в итоге из этого может извлечь компания-исполнитель проекта.

Соответствующий раздел в концепции проекта-примера будет иметь следующий вид.

    12.	Обоснование полезности проекта
    12.1. Для Заказчика:
    12.1.1. Повышение производительности обработки заказов в 2 раза.
    12.1.1.1. "As Is": 2500 заказов/год по 8 чел.*час.
    12.1.1.2. "To Be": 2500 заказов/год по 4 чел.*час.
    12.1.1.3. Экономия: 2500 * 4 * $50 = $500 000 в год.
    12.1.2. Повышение оперативности контроля
    12.1.2.1. "As Is": Ежемесячная отчетность.
    12.1.2.2. "To Be": Отчетность on-line.
    12.1.3. Повышение удовлетворенности клиентов:
    12.1.3.1. Сокращение срока обработки заказа в 2 раза.
    12.1.3.2. Сокращение времени на поиск необходимой документации в 10 раз
    12.1.3.3. Повышение оперативности обновления каталога 10 раз. 12.2. Для компании-исполнителя:
    12.2.1. Высокая стратегическая ценность. Дает устойчивое увеличение рынка и завоевание нового
            рынка.
    12.2.2. Финансовая ценность выше среднего. Ожидаемые доходы от проекта не менее чем в 1.3 раза
            превышают расходы.

Выводы

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

    Приоритет проекта определяется на основе оценки трех показателей:
    •	Финансовая ценность.
    •	Стратегическая ценность.
    •	Уровень рисков.