Краткая характеристика содержания проекта это

Обновлено: 07.07.2024

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

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

Ограничения и предположения

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

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

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

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

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

Возможный выход из положения – привлечь команду из семи – десяти человек, занятых в проекте, и воспользоваться одной из методик социометрии, известной как (The Crawford Slip).

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

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

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

Здравствуйте, Майк!

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

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

На сегодня мнения наших клиентов разделились. Одни полагают, что описанием проекта должен заниматься менеджер проекта, другие придерживаются точки зрения, что это обязанность представителя спонсора. Исходя из наших наблюдений, в тех случаях, когда авторство описания проекта принадлежит спонсору, проекты получаются лучше. Почему? Если менеджер проекта играет роль своего рода , ему легче обнаружить ошибки, способные привести к неудаче. Также исключается ситуация, при которой менеджеру проекта будет передана к исполнению сырая или заведомо порочная идея спонсора. Вы считаете, что менеджер проекта должен играть основную роль при подготовке его описания; при этом подразумевается, что менеджер проекта способен заставить лицо, принимающее решения, внести изменения в свой вариант этого документа до начала работ. Наш опыт свидетельствует о том, что этого не происходит. Как раз наоборот – руководитель занимается подготовкой описания собственного проекта, а об объективности зачастую забывают.

Ваша точка зрения позволяет поставить вопрос достаточно неожиданно: предположим, вы – менеджер проекта и числитесь в штате компании; имеете ли вы право наложить вето на реализацию проекта? В современном мире крупного бизнеса, где репутация менеджера определяется его последним проектом, следует ли вам браться за проект, если он, по вашему глубокому убеждению, обречен на провал? Некоторые исследования показывают, что менее 60% от общего числа проектов в сфере ИТ укладываются в смету, график и перечень требований, предъявляемых заказчиком. С составлением программы проекта дело обстоит получше – здесь успех сопутствует в 80% случаев. Впрочем, это тоже не ахти какое достижение.

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

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

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

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

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

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

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

Аннотация: План управления проектом. Формирование иерархической структуры проекта. Построение ИСР. Определение содержания проекта. Критические факторы успеха. Формирование списка работ (операций) проекта. Определение логической последовательности выполнения работ. Оценка трудоемкости и потребности в ресурсах Определение длительности операций. Исходная информация процесса определения длительности операций. Результаты процесса оценки длительности операций. Концептуальная оценка стоимости проекта. Формирование сметы. Шаблон сметы проекта. Проверка качества составления сметы проекта. Разработка базового плана по стоимости проекта.

План управления проектом

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

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

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

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

базового расписания проекта ;
базового плана по стоимости;
базового плана по качеству;
базового плана по конфигурации;
реестра рисков .

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

Формирование иерархической структуры проекта

Иерархическая структура работ ( ИСР ) - это ориентированный на результаты способ группировки элементов проекта, который упорядочивает и определяет общее содержание проекта . Работы, не включенные в ИСР , находятся за пределами содержания проекта [18].

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

Построение ИСР

Существуют два основных способа разработки ИСР : "сверху вниз" и "снизу вверх". Далее приводится описание подхода "сверху вниз".

Разработка ИСР станет более легким и осмысленным делом, если будет доступна следующая информация:

требования заказчика;
пул доступных ресурсов;
конкретная проектная ситуация.

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

В соответствие с принципом, лежащим в основе построения ИСР по фазам жизненного цикла, на 1-ом уровне происходит разбитие проекта на фазы. Этот принцип следования естественному жизненному циклу проекта весьма популярен в некоторых отраслях и, в принципе, значительно упрощает разработку расписания проекта . Хороший пример использования такого типа структурирования ИСР - проект разработки программного обеспечения, состоящий из таких фаз, как определение требований, высокоуровневое проектирование, низкоуровневое проектирование, написание кода и тестирование. Принцип разбития по системам подразумевает разбитие на составляющие физические системы и отображение их на уровне 1 ИСР . Этот подход широко распространен в ряде традиционных производственных отраслей, в которых ИСР больше напоминает спецификацию производственного образца. Разбиение ИСР по географическим зонам практикуется, в частности, в сфере строительства, где уровень 1 ИСР проекта может состоять из здания A, здания B и т. д. Что касается следующих уровней ИСР , многие специалисты практикуют гибридные ИСР , сочетающие два или три метода.

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

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

Для определения степени детализации ИСР нужна следующая информация:

количество уровней в ИСР ;
количество и средний размер пакета работ, принятые в отрасли. Так, для большинства средних и малых ИТ-проектов характерны

ИСР со следующей детализацией:

от трех до четырех уровней;
от 15 до 40 пакетов работ;
от 40 до 80 часов на средний пакет работ;
от 3% до 7% общего бюджета рабочих часов на средний пакет работ [18].

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

Определение содержания проекта

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

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

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

К информации, имеющей ключевое значение для составления описания содержания проекта, относятся:

устав проекта ;
формулировка требований организации-заказчика;
ТЭО ;
внутрикорпоративная методология управления проектами и соответствующие политики.

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

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

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

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

Также стоит различать содержание проекта и содержание продукта: в первом случае, это работы, которые необходимо выполнить для получения желаемого результата (продукта, услуги), во втором случае – это функции и характеристики результата.

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

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

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

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

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

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

Содержание проекта включает в себя:

Описание содержания проекта;
Критерии приемки результата;
Границы проекта (что входит в проект и что нет); ; .

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

Описание содержания проекта

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

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

Критерии приемки результата проекта

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

Настоящее искусство – это сформулировать критерии так, чтобы они были действительно удобны в использовании и не вызывали разночтения.

Например, для элемента “Обученные пользователи” (подкатегория “Обученные бухгалтера по работе с дебиторами”) критерием приемки может быть “Бухгалтер может выполнить следующие операции: ввод акта сверки, согласование счета и т.д. самостоятельно не более чем за 1 минуту”.

Границы проекта

Помимо того, что команда проекта будет делать в ходе его реализации, очень важно определить, чего она делать не будет.

На рисунке ниже схематично изображено определение границ проекта.

Определение границ проекта

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

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

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

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

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

Доверь свою работу кандидату наук!

Узнать стоимость бесплатно

Для чего нужна аннотация в курсовой работе

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

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

Итак, аннотация к курсовой должна:

подчеркивать новизну исследования;
отражать ключевые моменты работы, но при этом не дублировать отдельные части текста;
включать только факты и опираться на тезисы, которые содержатся в материале.

Правила оформления аннотации к курсовой работе

Аннотация к курсовой работе имеет свои правила оформления, которые необходимо соблюдать: чёткое месторасположение, объём и блоки информации.

Расположение аннотации

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

Объём аннотации

Объём зависит от темы и сложности курсовой работы. Оптимальным считается размер от 500 до 1500 знаков.

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

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

Работа включает 38 страниц, использованы 48 источников, содержит 15 графиков, 8 таблиц, 17 фотографий и 31 приложение.

Смысловые блоки

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

тема курсовой работы;
ФИО студента-автора;
ФИО научного руководителя;
группа и факультет, на котором учится студент;
ключевые тезисы работы;
ценность исследования.

Кстати! Для наших читателей сейчас действует скидка 10% на любой вид работы.

Как написать аннотацию к курсовой работе

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

Пошаговая инструкция по написанию аннотации

Чтобы грамотно написать аннотацию к курсовой работе, необходимо найти ответы на следующие вопросы:

Тема работы	Рассматриваются вопросы …, анализируется метод…, изложена теория…, приводятся данные…, ставятся задачи …, даётся обзор …, внимание сконцентрировано на…
Каким образом?	Предлагается алгоритм…, приведены малоизвестные сведения…, подробно обозреваются …, делается попытка…
Как структурирована?	Состоит из пяти глав, 9 подразделов и так далее.
Какова целевая аудитория?	Разработки ориентированы на…

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

Правильные языковые средства

Языковые средства, которые принято использовать в аннотации к курсовой работе:

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

Не стоит думать, что аннотация — это необязательная часть курсовой. Её наличие непосредственно влияет на итоговую оценку работы. Ведь аннотация — это визитная карточка вашего проекта.

Аннотация к курсовому проекту: примеры

Чтобы у вас не осталось вопросов, как писать аннотацию к курсовой, давайте рассмотрим конкретные примеры:

Пример №1: Аннотация к курсовой работе

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

Во введении обоснована актуальность темы исследования, цель и задачи.

В заключении приведены основные выводы, полученные в результате проведённого исследования.

Ключевые слова: безналичный расчёт, электронная платежная система.

Общий объём работы 68 страниц.

Пример №2: Аннотация к курсовой работе

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

Представленная курсовая работа состоит из введения, трёх глав, заключения, списка литературных источников и приложений.

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

Ключевые слова: источники права, правовые семьи.

Работа состоит из 31 страницы, содержит 43 литературных источника, 3 таблицы и 8 приложений.

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

Анастасия Бабина. В моей фамилии часто ставят ударение на "И", но я привыкла. Копирайтер и редактор компании Zaochnik. Любительница мистических триллеров, отчаянный киноман и гурман в хорошей форме.

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

Правила определения состава работ

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

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

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

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

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

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

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

определение содержания проекта;
определение состава работ.

Мы рассматривали данные процессы в упомянутой выше статье. Краткое содержание проекта формируется в составе документа, именуемого планом по вехам. Развернутый состав работ находит отражение в ИСР, сетевой модели и, наконец, в расписании (календарном плане проекта). Управление данной категории глубоко описано в руководстве PMBOK, в котором рассматривается шесть процессов данного раздела управления проектами.

Планирование управлением содержанием.
Сбор требований.
Определение содержания.
Создание ИСР.
Подтверждение.
Контроль.

Три последних процесса мы рассмотрим в отдельных материалах сайта.

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

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

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

Читайте также: