Управление замыслом проекта

из "Путеводитель в мир управления проектами "

Управление замыслом проекта включает процессы, необходимые для подтверждения того, что проект включает все виды деятельности и только виды деятельности, необходимые для успешного завершения проекта [5.1]. Основная его задача состоит в определении и проверке того, что включено или не включено в проект. Рис. 5.1 обеспечивает обзор основных процессов управления замыслом проекта. [c.53]
Данные процессы могут взаимодействовать друг с другом, а также с процессами из других областей знания. Каждый процесс может привлекать усилия индивидуумов или групп людей в зависимости от потребностей проекта. Каждый процесс проявляется, по крайней мере, один раз в каждой фазе проекта. [c.53]
Хотя процессы представлены здесь как дискретные элементы с четкими взаимодействиями, на практике они могут пересекаться и взаимодействовать не указанными здесь путями. Взаимодействие процессов детально обсуждено в главе 3. [c.53]
В фокусе данной главы находятся инструментарий и технологии, используемые для управления замыслом проекта. Инструментарии и технологии управления замыслом продукта разнятся в зависимости от области деятельности и обычно описываются как составляющие жизненного цикла проекта (жизненный цикл проекта обсуждается в разделе 2.1). [c.53]
Проект состоит из единичного продукта, но продукт может включать составные элементы, каждый со своим отдельным, но увязанным с проектом в целом замыслом продукта. Например, новая телефонная система в общем случае будет включать четыре основные части оборудование, программное обеспечение, подготовку персонала и использование. [c.53]
Достижение замысла продукта измеряется по отношению к требованиям, тогда как достижение замысла проекта - по отношению к плану. Оба типа управления замыслом должны быть хорошо интегрированы для подтверждения того, что деятельность по проекту обеспечит создание требуемого продукта. [c.53]
Инициирование - это процесс формального распознавания того, что существует новый проект или что существующий проект должен перейти в новую фазу (см. раздел 2.1 для детального обсуждения фаз проекта). Данное формальное инициирование соединяет проект с постоянной деятельностью исполняющей организации. В некоторых организациях проект обычно формально не утверждается до завершения исследования возможности осуществления, до создания предварительного плана или другой схожей формы анализа, которая была инициирована отдельно. Некоторые типы проектов, а особенно проекты по оказанию услуг внутри компании или проекты создания новых продуктов, обычно инициируются неформально, при этом проводится некоторый ограниченный объём работ для получения одобрений, необходимых для формального инициирования. Проекты обычно утверждаются в результате одного или нескольких нижеперечисленных факторов. [c.55]
Данные стимулы могут также именоваться проблемами, возможностями или потребностями бизнеса. Центральной темой во всех этих терминах является то, что управленческий персонал должен принять ответное решение. [c.55]
Данное описание должно также определять отношение между создаваемым продуктом или услугой и деловой необходимостью либо иными стимулами из вышеприведенного списка, породившими проект. Хотя форма и содержание описания продукта будут меняться, оно всегда должно иметь достаточно деталей для поддержания проектного планирования на последующих стадиях. [c.55]
Многие проекты включают одну организацию (Продавца), производящую работу по контракту с другой (Покупателем). В данных обстоятельствах начальное описание продукта обычно предоставляется Покупателем. Если деятельность Покупателя также является проектом, то описание продукта будет определением вида деятельности, описанным в разделе 12.1.3.2. [c.55]
На данные методы часто ссылаются, как на модели решений. Модели решений включают как основные технологии - деревья решений, вынужденный выбор и др., так и специальные технологии - процесс аналитической иерархии, анализ логической схемы и др. Применение комплексных критериев выбора проекта в сложной модели часто считается отдельной фазой проекта. [c.56]
Устав должен быть издан независимым менеджером, не включенным в проект, и на уровне, отвечающем нуждам проекта. Устав дает менеджеру проекта власть использовать ресурсы организации на нужды проекта. [c.56]
При осуществлении проекта в рамках контракта подписанный контракт в общем будет являться уставом для Продавца. [c.56]
При осуществлении проекта по контракту ограничениями обычно являются условия контракта. [c.56]
Планирование замысла является процессом создания формального описания замысла как базы для последующих решений проекта, включающих, в частности, критерии определения успешности окончания проекта или фазы проекта. Формальное описание замысла одинаково важно как для проектов, так и для подпроектов. Например, инженерная фирма, создающая проект нефтеперерабатывающего завода, должна иметь описание замысла для определения границ процесса проектирования. Описание замысла проекта формирует базу для соглашения между командой проекта и заказчиком проекта путем идентификации как основных целей проекта, так и его предметов. [c.57]
Если все элементы описания замысла уже доступны (например, запрос предложения может определять основные цели, а задачи определяются в уставе проекта), то данный процесс обычно сводится к простому написанию документа. [c.57]
В некоторых прикладных областях цели проекта носят название предметов проекта, предметы проекта именуются критическими факторами успеха. [c.58]
План управления замыслом может быть формальным или неформальным, высок детальным или широко описательным в зависимости от нужд проекта. Это один из элементе общего плана проекта, который описан в разделе 4.1.3.1. [c.58]
Многие прикладные области имеют стандартные или наполовину стандартные WBS, которые могут быть использованы как шаблоны. Примером может служить Министерство обороны США, определившее стандартные структуры WBS для проектов, связанных с вопросами обороны. Фрагмент одной из таких структур приведён на рис. 52. [c.59]

Вернуться к основной статье