Процессы инициации

WBS Dictionary или Словарь ИБС

WBS Dictionary (он же Словарь ИБС) – это описание на страничку А4 (или подробнее) для каждого пакета работ, включающее код пакета работ, его наименование, детальное описание результата, критерии приемки, ответственного (это, наверное, самое ценное в словаре), ограничения и допущения и вообще все, что кажется вам полезным.

Это, наверное, все, что нужно знать о создании и использовании WBS для старта. Удачи!

P.S. И да, неполная, недостаточная и не совсем правильная WBS все равно гораздо лучше, чем ее отсутствие

Cкачать пакет примеров реальных WBS с различных проектов вы можете всего за 199 руб. После оплаты  на почту вы получите архив с WBS по трем реальным проектам и – бонусом! – WBS приведенного в посте примера с ремонтом, в котором уже настроено удобное форматирование для построения своего варианта. В пакет входят WBS для проектов разного типа – создания новой ИТ-системы с нуля, доработки существующей системы и миграции с одной системы на другую. Также в них разный фокус и разный уровень детализации, чтобы, ознакомившись с примерами WBS, вы смогли сделать свою WBS  такой, какая нужна именно вам. Все файлы WBS представлены как в исходном формате mmap (открываются в Mindjet MindManager), так и в jpg с высоким разрешением на тот случай, если у вас не установлен MindJet. Воспользуйтесь чужим опытом и сэкономьте свое время, оно стоит намного дороже! Скачайте примеры, изучите их и начните строить WBS для вашего проекта на основе лучших практик прямо сейчас!

Как использовать допущения в ходе проекта:

1. Сначала – надо еще суметь подписать устав, в который вы все эти допущения внесли. А без устава, как вы помните, работу мы не начинаем. С вероятностью 146% заинтересованные лица очень удивятся, увидев все это на бумаге. Тут же начнется что-то типа «нет, 100% времени сотрудников мы не можем выделить!», «ну кому мы врем, в Процедуре по закупке 2 месяца, но еще никому меньше чем за 4 месяца купить не удалось», «я тут подумал, не факт, что мы сможем без тендера обойтись» и прочие радости. В общем, после пары циклов согласований у вас таки будет подписанный устав с реальными допущениями и мнооого материала для управления рисками.
2. После того, как список определен – это отличная вводная для управления рисками, т.к. любое допущение – это нечто, в чем вы не уверены, т.е. потенциальный риск. Просто берем список допущений на первую сессию управления рисками и вуаля! Ну и во время согласования списка допущений отмечаем для себя наиболее болезненные области, чтобы потом посмотреть туда внимательнее.
3. В ходе проекта устав с допущениями используем как аргумент во всем, что касается этих допущений. Мол, на проект надо 2х юристов на 2 недели, что значит «нет»? Устав проекта предполагает, что я могу привлечь их на 100% времени! Нет? Ок, пошли вместе к Заказчику. Скорее всего, Заказчик, подписавшийся под этими допущениями, юристов вам все-таки найдет, или какие-то разумные обходные пути предложит или, на крайний случай, запрос на изменение согласует (но это надо аккуратно делать все, опасное развлечение).

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

Этап планирования

Этап планирования особенно важен, поскольку именно на нем:

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

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

Выход процессов планирования:

• План, отражающий описание проектного содержимого. До определения разбиения работ на части требуется собрать полные и подробные данные.
• Иерархическая структура работ должна отражать максимально подробное содержание проекта.
• Описание внешней среды. Проект не является замкнутой системой, в его рамках происходит интенсивная коммуникация с внешним миром; поэтому требуется понимать, какие события и ситуации возникают вне проекта, чтобы принимать в учет факторы окружающей среды.
• Требования. Потребуется собрать и задокументировать потребности всех заинтересованных сторон, определить и согласовать процедуру по изменению проектных требований.
• Финансы. Определяется сводный бюджет, который включает в себя данные о финансовых потребностях каждого этапа (скажем, одной из задач является бюджетирование расходов и доходов). В бюджете необходимо предусмотреть возможность отражения как технических изменений, так и методологических (формируется соответствующий порядок внесения бюджетных изменений).

Результатами процесса временного планирования могут быть:

График Ганта; диаграмма управления сотрудниками. Такой документ детально описывает потребность в работниках, дает понимание их знаний, опыта, численности персонала. С помощью данной диаграммы можно определить, в какое время и какое количество сотрудников (и какого уровня подготовки) нужно задействовать на каждом из этапов для выполнения конкретной операции; как замотивировать людей, как организовать их деятельность, выявить потребности для качественной работы; как сформировать план действий в случае окончании функционала для одного или группы работников и т. д.
План управления взаимодействием. Это также немаловажная часть планирования, способная улучшить согласование и осведомленность участников в рамках степени их допуска. Такой документ описывает формы, периодичность, содержание встреч заинтересованных лиц, порядок таких встреч, регламент занесения данных, архивирование данных по проекту, форматы и порядок как отчетов, так и информационных данных. Основная цель такого плана – упрощение командного взаимодействия внутренних членов проектного коллектива с внешними участниками таким образом, чтобы все заинтересованные лица обладали беспрепятственным доступом к данным в рамках своего статуса и свободно общались между собой.
План закупок. Является документом, где согласовывается покупка нужных для реализации проекта материалов, сырья, нематериального обеспечения. При этом документ должен содержать т. н. «ритм реализации», т. е. покупки должны выполняться своевременно.
План рисков. Без риска не обходится практически ни один проект

Риски либо берут во внимание, либо стараются избегать, либо принимают, либо стараются страховаться. Для любой из описанных ситуаций нужно выработать регламент шагов при возникновении рисков

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

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

Заинтересованные лица

Заинтересованные лица – те люди, на которых отразится результат твоего проекта. На первый взгляд ты можешь думать, что тут все понятно, но на практике ты их всех не знаешь. На этапе инициации проекта стоит поговорить и рассказать о своем проекте разным людям, а если ты работаешь в корпорации, запланировать уведомление или опрос. Все зависит от политики компании. На этом этапе хорошо, когда задают вопросы: Зачем? Почему? Кому это надо? А если вот так? А если не так? Лучше всего собрать все возможные вопросы и всех заинтересованных лиц. Если так произойдет, на этой стадии ты добился успеха. Да, обычно таких людей называют заграничным словом стейкхолдеры. Можешь его использовать в корпорациях на собеседовании.

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

1 Обзор процессов

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

Процесс руководства проектом

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

Обратите внимание, что процесс начала проекта происходит до его фактического начала. Во время процесса руководства проектом совет проекта утверждает стадии проекта и управляет проектом в целом, применяя способ “управление по исключению”

Процесс начала проекта

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

Процесс инициации проекта

Процесс инициации проекта — это процесс, который определяет продукт проекта, качество продукта, сроки и затраты проекта, анализ рисков и выделение ресурсов, а также формирует ДИП (документацию по инициации проекта). Это также процесс, в котором создается план проекта и завершается написание экономического обоснования проекта. Вся эта информация собирается в документации по инициации проекта.

Процесс контроля стадии

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

Процесс управления поставкой продуктов

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

Процесс управления границей стадии

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

Процесс закрытия проекта

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

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

Цели и задачи проектной инициации

Проектная инициация – это не один процесс, а целая их группа согласно стандарту PMI. Они формируют начальную группу мероприятий для обеспечения состоятельности самой проектной идеи и запуска ее проектной реализации. При этом уже на данной фазе выявляются и даже устраняются многочисленные риски, отработать которые на стадии инициации гораздо выгоднее, чем после старта проекта. Инициация метафорична фразе из поговорки «Семь раз отмерь!», поскольку планирование и исполнение, начавшись практически одновременно, после приказа о начале проекта становятся значительно более затратными.

Выше вашему вниманию предложена модель процессов инициации, заимствованная из курса МВА по управлению проектами А.В. ПолковниковаПолковников А.В. Управление проектами. Полный курс МВА/ А.В.Полковников, М.Ф.Дубовик – М.:Издательство «Олимп-Бизнес», 2016 – 552 с. . Каждому процессу функциональных зон проектной интеграции и содержания на нашем сайте посвящен отдельный материал. Нас же здесь интересует в большей степени само начало инициации в вопросе, как принимается решение о проекте и о его месте в портфельном рейтинге? И прежде чем мы перейдем к его рассмотрению, предлагаю определиться с целями и задачами, которые решаются процедурами инициации. Ключевая задача этой работы состоит в определении, согласовании и утверждении показателей и результата проекта, если он принимается к исполнению в обозримой перспективе (в ближайший год). Основными целями инициации предлагаю считать:

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

Среди задач-результатов процессов инициации выделяются следующие.

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

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

Что такое видение проекта

Также как и в случае с видением продукта – канонического определения или истины в последней инстанции о том, что же такое видение проекта, нет. Разные подходы есть в SCRUMе, ГОСТе, RUPе, веб-разработке и проч. Поэтому будем включать здравый смысл и логику.

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

Видение проекта или Project Vision – это краткое описание представления о том, каким будет результат нашего проекта или программы проектов, и как он будет достигнут. Это еще не Project Scope Statement  и тем более не WBS, но уже не просто сформулированная в уставе цель и список ключевых требований. Для не сильно больших проектов Project Vision и Project Scope Statement – это одно и то же.

Видение проекта решает 2 основные задачи:

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

По-хорошему, Project Vision создается одновременно с формированием устава проекта, т.е. на этапе инициации проекта, но может зависеть от используемой методологии.

Понятие видения проекта тесно связано с границами проекта (про это есть отдельный пост)

То есть важно четко обозначить, что в итоге будет, а чего – не будет

Инструменты для разработки WBS

Единственное правило тут – разрабатывать в том, в чем удобно. Если у вас есть какой-то инструмент для построения диаграмм – отлично, если нет – подойдет любой другой, например, Mind Manager, Excel, MS Project, Visio или любой онлайн-аналог.

Типовая ошибка тех, кто делает WBS в MS Project – одновременно пытаться описать результаты и указать зависимости (в самых тяжелых случаях – еще и трудоемкость и ресурсы).  Цель WBS – получить именно полное содержание проекта, а не закрыть задачу планирования одним махом. А еще так легко что-то упустить, так как представление в MS Project не наглядное.

Реализация

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

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

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

Процессы планирования

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

Напомним, что следует различать цели проекта и цели продукта проекта, под которым понимается продукция (или услуги), созданная или произведенная в результате исполнения проекта.

1. Цели продукта — это свойства и функции, которыми должна обладать продукция проекта.
2. Цели проекта — это работа, которую нужно выполнить для производства продукта с заданными свойствами.

В ходе исполнения проекта эти процессы многократно повторяются. Изменениям могут подвергнуться цели проекта, его бюджет, ресурсы и т.д. Кроме того, планирование проекта – это не точная наука. Различные команды проекта могут разработать различные планы для одного и того же проекта. А пакеты управления проектами могут составить различные расписания выполнения работ при одних и тех же исходных данных.

Основные процессы планирования

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

К основным процессам планирования относятся:

1. Планирование целей — разработка постановки задачи (проектное обоснование, основные этапы и цели проекта),
2. Декомпозиция целей — декомпозиция этапов проекта на более мелкие и более управляемые компоненты для обеспечения более действенного контроля,
3. Определение состава операций (работ) проекта — составление перечня операций, из которых состоит выполнение различных этапов проекта,
4. Определение взаимосвязей операций — составление и документирование технологических взаимосвязей между операциями,
5. Оценка длительностей или объемов работ — оценка количества рабочих временных интервалов, либо объемов работ, необходимых для завершения отдельных операций,
6. Определение ресурсов (людей, оборудования, материалов) проекта — определение общего количества ресурсов всех видов, которые могут быть использованы на работах проекта (ресурсов организации) и их характеристик;
7. Назначение ресурсов — определение ресурсов, необходимых для выполнения отдельных операций проекта;
8. Оценка стоимостей — определение составляющих стоимостей операций проекта и оценка этих составляющих для каждой операции, ресурса и назначения;
9. Составление расписания выполнения работ — определение последовательности выполнения работ проекта, длительностей операций и распределения во времени потребностей в ресурсах и затрат, исходя и с учетом наложенных ограничений и взаимосвязей;
10. Оценка бюджета — приложение оценок стоимости к отдельным компонентам проекта (этапам, фазам, срокам);
11. Разработка плана исполнения проекта — интеграция результатов остальных подпроцессов для составления полного документа.
12. Определение критериев успеха — разработка критериев оценки исполнения проекта.

Вспомогательные процессы планирования

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

Такие процессы включают в себя:

1. Планирование качества — определение того, какие стандарты качества использовать в проекте, и того, как эти стандарты достичь;
2. Планирование организации — определение, документирование и назначение ролей, ответственности и взаимоотношений отчетности в организации;
3. Назначение персонала — назначение человеческих ресурсов на выполнение работ проекта;
4. Планирование взаимодействия — определение потоков информации и способов взаимодействия, необходимых для участников проекта,
5. Идентификация риска — определение и документирование событий риска, которые могут повлиять на проект;
6. Оценка риска — оценка вероятностей наступления событий риска, их характеристик и влияния на проект;
7. Разработка реагирования — определение необходимых действий для предупреждения рисков и реакции на угрожающие события;
8. Планирование поставок — определение того, что, как и когда должно быть поставлено;
9. Подготовка условий — выработка требований к поставкам и определение потенциальных поставщиков.

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

Операции

PRINCE2 рекомендует восемь операций в составе Инициации проекта, а именно:

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

Как написать видения проекта

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

В Project Vision для ИТ-системы можно, например, ответить на следующие вопросы:

• Предпосылки или текущая ситуация, и почему необходимы изменения (может не быть, если уже отражено в уставе);
• Бизнес-цели, которые должны быть достигнуты;
• Ключевые ожидания стейкхолдеров;
• Высокоуровневое описание затрагиваемых бизнес-процессов;
• Перечень внедряемых или разработываемых модулей с краткой детализацией, последовательностью внедрения, расширением функционала и проч.;
• Количество и типы пользователей, порядок подключения разных групп пользователей к работе в системе;
• Подходы к обучению, коммуникации, мотивации пользователей (вообще это нестандартный пункт, но я так много раз наступала на грабли “ой, а мы и не думали, что нужно их всех как-то обучить” в конце проекта, что стала это в видение включать в обязательном порядке);
• Фотографии прототипов, скетчей, досок с результатами стратегических сессий и т д. (если культура компании такое позволяет делать в документах);
• Выбранная платформа для разработки или принципы ее выбора (если платформа еще не определена);
• Интеграция, если предусмотрена;
• Инфраструктура;
• Какие-то нефункциональные вещи типа скорости работы, информационной безопасности или принципиальных подходов к процессу разработки, если для проекта они критичны;
• Рамки проекта;
• И т.д.

Вариации на тему ЖЦ инвестиционного проекта

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

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

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

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

1. Выявление проблемы и выработка замысла.
2. Формулирование цели и задач проекта через анализ проблемы и вытекающих требований.
3. Разработка концепции проекта.
4. Детальная планово-спецификационная проработка.
5. Стадия реализации.
6. Управление и использование (внедрение, документационное и техническое обслуживание, эксплуатация).
7. Процесс ликвидации.

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

1. Предынвестиционный.
2. Инвестиционный.
3. Эксплуатационный.
4. Ликвидационно-аналитический.

Жизненный цикл инвестиционного проекта