Управление проектами - это философия управления, а не инструмент или техника
Управление проектамиГлоссарийФорум

Элементы хорошего технико-экономического обоснования проекта

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

В общем, существуют шесть частей эффективного технико-экономического обоснования проекта:

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

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

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

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

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

4. Подход представляет рекомендуемое решение или план действий для удовлетворения требований. На данном этапе учитываются различные альтернативы вместе с объяснением того, почему выбранное решение оказалось предпочтенным. Что касается дизайна в проектах, то это именно то место, где разрабатываются эскизные проекты для того, чтобы определить реализуемость. Также, в этом случае используются существующие структуры и учитываются коммерческие альтернативы (а именно, "создать или купить"). Важнейшими соображениями являются:

  • Удовлетворяет ли рекомендуемый подход требования?
  • Является ли это практичным и реализуемым решением?

Тщательный анализ необходим для того, чтобы выполнить данный шаг.

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

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

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

Вывод

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

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


Newer news items:
Older news items:

 

Предложения

Copyright ©2014, PMToday.ru. При копировании материалов наличие прямой индексируемой ссылки на сайт обязательно.