Суть проекта в терминах повышения потребительской ценности продуктов, бизнес функций, бизнес процессов и задач … Толковый словарь по информационному обществу и новой экономике

Scope Statement - Scope statements may take many forms depending on the type of project being implemented and the nature of the organization. The scope statement details the project deliverables and describes the major objectives. The objectives should include… … Wikipedia

Project planning - is part of project management, which relates to the use of schedules such as Gantt charts to plan and subsequently report progress within the project environment. .

Бюджет проекта (Project budget) - утвержденное запланированное распределение финансовых средств проекта по различным основаниям: статьям затрат, временным периодам, участникам проекта, решаемым задачам, компонентам ожидаемых результатов, элементам организационной структуры проекта и т. п.

Бюджет проекта- сметная стоимость, распределенная по периодам выполнения проекта [НТК].

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

Участники проекта- физические лица и организации, которые непосредственно вовлечены в проект или чьи интересы могут быть затронуты при осуществлении проекта [РМВОЩ.

Изменения проекта (Project Changes) - модификация ранее согласованных продуктов и услуг сроков исполнения и стоимости работ, используемых ресурсов, управленческих и технологических процессов и т. п.

Изменения - увеличение или уменьшение характеристик элементов проекта. Пересмотр базового плана проекта. Подразумевает документально оформленные и утвержденные изменения [УП].

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

Расписание проекта - плановые даты для выполнения работ и плановые даты для наступления контрольных (ключевых) событий («вех») проекта [НТК].

Ключевые вехи проекта (Project Milestones) - ключевые события проекта, свершение которых является необходимым и достаточным условием, определяющим достижение результатов проекта. Обычно представляются в виде схемы или таблицы с взаимосвязями и сроками свершения, образуя план по вехам (Milestone Plan, Milestone Schedule, Master Schedule).

Контрольное событие- важное событие проекта, обычно связанное с достижением важнейших результатов [ОУП]. Другие варианты - ключевое событие [УП], контрольная точка [УП].

Куратор проекта (Sponsor) - лицо, отвечающее перед руководством предприятия за успех проекта в целом и имеющее полномочия для решения ресурсных и других проблем, эскалированных руководителем проекта.

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

Устав проекта (Project Charter)- документ, разработанный вышестоящей администрацией, который предоставляет менеджеру проекта право использовать ресурсы организации для выполнения работ проекта \PMBOK].

Определение проекта (Project Definition Report) - документ, определяющий проект, в том числе: каковы цели и результаты проекта; в чем его необходимость; что должно быть сделано; как, когда и где это должно быть сделано; что для этого нужно; сколько это будет стоить; какие необходимо привлечь внешние ресурсы и организации; какие стандарты и процедуры подлежат соблюдению при осуществлении проекта [НТК].

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

Проблемные ситуации (Problem situations ) - возникающие при осуществлении проекта ситуации, для выхода из которых необходимо находить оптимальные решения [НТК].

Решение проблем (Problem Solving) - определение последовательных систематических процедур, с помощью которых анализируются и решаются проблемные ситуации [НТК].

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

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

Проект - целенаправленная деятельность временного характера, предназначенная для создания уникального продукта или услуги [НТК].

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

Отклонение (Deviation) - выход за пределы установленных требований. К отклонениям относятся случаи, когда результат работы не удовлетворяет требованиям или необоснованно их превышает .

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

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

Менеджер проекта - лицо, ответственное за управление проектом [РМВОЦ.

Предметная область (Scope) - совокупность продуктов и услуг, производство которых должно быть обеспечено в рамках осуществляемого проекта [РМВОЦ.

Цели (Scope) - совокупность продуктов и услуг, намеченных к производству в проекте [ОУП].

Структура декомпозиции работ, СДР (Work Breakdown Structure, WBS) -

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

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

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

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

Управление проектами (Project Management) ----- профессиональная творческая деятельность по руководству людскими и материальными ресурсами путем применения современных методов, средств и искусства управления для успешного достижения заранее поставленных целей при

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

социальных системах.

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

Управление проектом- процесс применения знаний, навыков, методов и средств и технологий к проектной деятельности с целью достижения или превышения ожиданий участников проекта [РМВОЩ.

Источники, по которым цитируются определения 1.

Британский стандарт BS 6079-2:2000 Project management Part 2 Vocabulary (перевод авт.). 2.

ISO/TR 10006: 1997 (E). Quality Management - Guidelines to quality in project management. (ИСО/ТО 10006: 1997 (E). Менеджмент качества. Руководство качеством при управлении проектами (12/97), 3.

…и как бороться, если избежать не удалось?

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

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

Но это для Заказчика, а для нас – минимум 2 новые платформы (айфоны-то не у всех, у кого-то андроид), заботы о том, чтобы человек с этим айфоном не взлетел на воздух (взрывоопасность на производстве никто не отменял), работа с юристами (т.к. большой вопрос, одобрят ли они классную идею публикации корпоративных приложений в Google Play или AppStore), отдельные навыки специалистов службы поддержки, отсутствие покрытия 3G на производственных объектах и прочее, прочее, прочее. И вот “тот же функционал” взял и превратился в утроенный объем того же проекта.

Хорошая картинка в тему:

Еще есть схожее понятие feature creep или фичеризм – бесконечное добавление «бантиков» к продукту, которые не влияют на его основной функционал, но при этом отбирают ресурсы и усложняют дальнейшее развитие. Ну, например, возможность изменения цветовой схемы системы или подтягивание последних новостей из мира управления компетенциями на главную страничку решения – это приятно, но ни разу не необходимо, и задачи, поставленные перед системой (управлять компетенциями персонала) не решает.

Почему происходит scope creep

Причин появления scope creep множество, вот самые частые:

• Вы не обозначили или сделали это очень размыто. И либо Заказчик сейчас вами манипулирует, либо он действительно не понимал, что мобильного приложения не будет.
• У Заказчика поменялись приоритеты или бизнес-процессы, и ему теперь нужно не совсем то, что было заявлено в начале проекта.
• Вы не в начале проекта, а они вдруг взяли и материализовались со своими вполне законными требованиями.
• Вы не дружите со словом «нет» либо у вас не хватает полномочий его сказать.
• Первоначальный анализ был проведен плохо, и вы (или ваши аналитики) не поняли, что именно и зачем надо Заказчику (), и теперь удивляетесь. С вашей точки зрения – требования «из ниоткуда», с точки зрения Заказчика – «это же очевидно!».
• Вы изначально не построили процесс управления изменениями и не сделали его прозрачным для Заказчика. Один раз согласились, второй раз включили в объем, потому что «там же немного, и для них это важно», третий раз не просчитали влияние изменения и пришлось переписывать большой кусок – и вот сроки проекта поехали на два месяца.

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

Как понять, что происходит scope creep

Самый простой способ понять, что происходит scope creep – это попытаться ответить на вопрос “как вот этот вот функционал помогает достижению цели, обозначенной в ?” (вы ведь его написали и заверили у спонсора и Заказчика, правда?). Если ответ неочевиден и приходит не сразу, через много «если-то» – то стоит задуматься.

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

Что делать, если scope creep уже произошел

Если вы вдруг осознали, что, кажется, объем «поплыл», то самое время предпринять корректирующие действия. Что именно делать – зависит от ситуации, но более-менее стандартный набор шагов выглядит так:

1. Внимательнее изучить имеющиеся факты, подготовить статистику. А то иногда кажется, что «ой, поплыло!», а при ближайшем рассмотрении новые требования оказываются вполне в рамках разумного.
2. Определить корневую причину (см.список выше).
3. Если это в рамках ваших полномочий или добрые отношения с Заказчиком или Спонсором позволяют – попытаться решить вопрос на своем уровне. Очень часто достаточно просто поговорить с другими участниками проекта, чтобы эту причину устранить и в мире и согласии делать проект дальше. В таких ситуациях очень помогает, если у другого человека есть опыт управления проектами, но такое счастье редко случается.
4. Если договориться не удалось – проанализировать влияние scope creep на проект, построить прогноз («если мы будем делать мобильное приложение – это х4 к срокам и х6 к бюджету»), сформулировать конкретные предложения по выходу из сложившейся ситуации с плюсами и минусами. Чаще всего это предложение «давайте не будем распыляться, сделаем один кусок и сразу за ним другой. И деньгами и сроками будет управлять проще, результат вы получите раньше» либо «ок, это важный объем, давайте сделаем его вместо вот этого куска, его тогда из проекта выкидываем». Хотя возможны и ситуации типа «взять какую-то часть в объем проекта», особенно если, например, бюджет уже поплыл, и это способ вернуться к запланированным показателям.
5. Согласовать предложения со своим руководителем и со спонсором, вынести на Управляющий комитет и решить, что делать дальше. Даже если предложения услышаны не будут – вы хотя бы попытались.

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

Если это так, то scope creep празднует победу. И, несмотря на сдвинутые ограничения проекта, вы теперь:

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

б) оправдываетесь перед другими стейкхолдерами за сдвинутые сроки (несмотря на то, что это решение Управляющего комитета – вы останетесь «тем РМом, из-за которого мы в марте не запустились»);

в) размываете результат проекта.

Банально, но чем больше и разноплановей объем – тем меньше управляемость, поэтому по возможности такой ситуации лучше избежать.

Как предотвратить scope creep

Лучше, конечно, предотвратить, чем ликвидировать. В целом для этого нужно ликвидировать причины, описанные раньше, а именно:

• Четко , и не только то, что мы делаем, но и то, что мы не делаем (это даже важнее).
• Идентифицировать и их «хотелки», разработать прозрачную и понятную систему приоритезации требований и управления ими.
• При анализе требований учитывать не только сказанное вслух, но и стараться смотреть «сверху» – зачем это заказчику? Как это может поменяться в ходе проекта? Как это требование связано с поставленной целью?
• Построить процесс управления изменениями и не допускать нарушений этого процесса, даже если это «совсем маленькое изменение».
• Заложить разумный запас бюджета и времени на изменения, т.к. они все равно будут.

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

А вы как со scope creep боретесь?

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

Краткий глоссарий

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

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

Проект – целенаправленная деятельность временного характера, предназначенная для создания уникального продукта или услуги [НТК].

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

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

План управления проектом (Project Management Plan) - основополагающий документ (baseline document), с которого должен начинаться любой проект. Содержит согласованное всеми участниками документально зафиксированное представление о проекте. В инвестиционных проектах – Мастер-план проекта (Project Master Plan) (УП).

Устав Проекта (Project Charter) - документ, разработанный вышестоящей администрацией, который предоставляет менеджеру проекта право использовать ресурсы организации для выполнения работ проекта .

Определение Проекта (Project Definition Report) - документ, определяющий проект, в том числе: каковы цели и результаты проекта; в чём его необходимость; что должно быть сделано; как, когда, и где это должно быть сделано; что для этого нужно; сколько это будет стоить; какие необходимо привлечь внешние ресурсы и организации; какие стандарты и процедуры подлежат соблюдению при осуществлении проекта [НТК].

Базис (Project Baseline) - Основополагающие параметры и фиксирующие их согласованное понимание всеми участниками документы проекта – «точка опоры» для всего последующего развития проекта.

Базовый план (Baseline) - Первоначальный план проекта с утвержденными изменениями. Базовый план бывает также и по составляющим проекта - стоимости, расписанию и т.д. [ОУП].

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

Цели (Scope) - совокупность продуктов и услуг, намеченных к производству в проекте [ОУП].

Ключевые вехи проекта (Project Milestones) - ключевые события проекта, свершение которых является необходимым и достаточным условием, определяющим достижение результатов проекта. Обычно представляются в виде схемы или таблицы с взаимосвязями и сроками свершения, образуя План по Вехам (Milestone Plan, Milestone Schedule, Master Schedule).

Контрольное событие - важное событие проекта, обычно связанное с достижением важнейших результатов [ОУП].

Другие варианты – ключевое событие [УП], контрольная точка [УП].

Структура декомпозиции работ (Work Breakdown Structure), СДР (WBS) - представление проекта, в виде иерархической структуры работ, полученной путем последовательной декомпозиции. СДР предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей.

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

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

Структура разбиения работ – иерархическая структура последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня пакеты детальных работ [УП],

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

Отклонение (Deviation) – выход за пределы установленных требований. К отклонениям относятся случаи, когда результат работы не удовлетворяет требованиям или необоснованно их превышает.

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

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

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

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

Проблемные ситуации (Problem situations) – возникающие при осуществлении проекта ситуации, для выхода из которых необходимо находить оптимальные решения [НТК].

Решение проблем (Problem Solving) – определение последовательных систематических процедур, с помощью которых анализируются и решаются проблемные ситуации [НТК].

Изменения проекта (Project Changes) - модификация ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, используемых ресурсов, управленческих и технологических процессов и т.п.

Изменения – Увеличение или уменьшение характеристик элементов проекта. Пересмотр базового плана проекта. Подразумевает документально оформленные и утвержденные изменения [УП].

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

Расписание проекта - плановые даты для выполнения работ и плановые даты для наступления контрольных (ключевых) событий («вех») проекта [НТК].

Куратор проекта (Sponsor) - лицо, отвечающее перед руководством предприятия за успех проекта в целом и имеющее полномочия для решения ресурсных и других проблем, эскалированых руководителем проекта.

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

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

Начнем эту заметку с рассказа об одном забавном эпизоде. Однажды в нашей компании проходили практику студенты-дипломники, специализирующиеся на управлении проектами. Выдавая им задание, руководитель практики (один из авторов этой заметки) попросил описать scope проекта (он так и сказал - скоуп). «А что такое scope?» - осторожно поинтересовалась одна девушка. «О, scope - это...» - ответил руководитель и нарисовал руками в воздухе нечто, напоминающее средних размеров глобус. «Понятно, - грустно сказала девушка. - Нам в институте так же объясняли».

Ситуация очень характерная и довольно опасная. Есть некий термин, употребляемый в англоязычных источниках и не имеющий очевидного и однозначного перевода на русский язык в контексте управления проектами. На профессиональном жаргоне мы привыкли пользоваться этим термином на языке оригинала. Действительно, гораздо удобнее сказать scope, чем какое-нибудь достаточно громоздкое «содержание и границы». Если кому-то непонятно, то всегда можно объяснить, хотя бы с помощью жестов. А приводит все это к тому, что некоторое время спустя точного значения термина никто уже не помнит, каждый трактует его по-своему, и при этом все думают, что понимают друг друга !

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

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

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

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

КРАТКИЙ СРАВНИТЕЛЬНЫЙ ГЛОССАРИЙ

Проект (project) - уникальный комплекс взаимосвязанных мероприятий для достижения заранее поставленных целей при определенных требованиях к срокам, бюджету и характеристикам ожидаемых результатов. Проект - уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам . Проект - целенаправленная деятельность временного характера, предназначенная для создания уникального продукта или услуги [НТК]. Управление проектами (Project Management) - профессиональная творческая деятельность по руководству людскими и материальными ресурсами путем применения современных методов, средств и искусства управления для успешного достижения заранее поставленных целей при определенных требованиях к срокам, бюджету и характеристикам ожидаемых результатов проектов, осуществляемых в рыночных условиях в социальных системах. Управление проектом включает планирование, организацию, мониторинг и контроль всех аспектов проекта в ходе непрерывного процесса достижения его целей . Управление проектом - процесс применения знаний, навыков, методов, средств и технологий к проектной деятельности с целью достижения или превышения ожиданий участников проекта . План управления проектом (Project Management Plan) - основополагающий документ (baseline document), с которого должен начинаться любой проект. Содержит согласованное всеми участниками документально зафиксированное представление о проекте. В инвестиционных проектах - мастер-план проекта (Project Master Plan) (УП). Устав проекта (Project Charter) - документ, разработанный вышестоящей администрацией, который предоставляет менеджеру проекта право использовать ресурсы организации для выполнения работ проекта . Определение проекта (Project Definition Report) - документ, определяющий проект, в том числе: каковы цели и результаты проекта; в чем его необходимость; что должно быть сделано; как, когда и где это должно быть сделано; что для этого нужно; сколько это будет стоить; какие необходимо привлечь внешние ресурсы и организации; какие стандарты и процедуры подлежат соблюдению при осуществлении проекта [НТК]. Базис (Project Baseline) - основополагающие параметры и, фиксирующие их согласованное понимание всеми участниками, документы проекта - "точка опоры" для всего последующего развития проекта. Базовый план (Baseline) - первоначальный план проекта с утвержденными изменениями. Базовый план бывает также и по составляющим проекта - стоимости, расписанию и т. д. [ОУП] Содержание и границы проекта (Project Scope) - цели и задачи проекта, основные результаты, критерии оценки того, что работа или ее часть выполнена. Содержание проекта, объем работ (Scope) - (букв. пределы, рамки, сфера). Содержание работ и результаты проекта (или его части). Проект описывается путем перечисления всех выполняемых работ, необходимых ресурсов и конечных результатов, включая требования к качеству [УП]. Предметная область (Scope) - совокупность продуктов и услуг, производство которых должно быть обеспечено в рамках осуществляемого проекта . Цели (Scope) - совокупность продуктов и услуг, намеченных к производству в проекте [ОУП]. Ключевые вехи проекта (Project Milestones) - ключевые события проекта, свершение которых является необходимым и достаточным условием, определяющим достижение результатов проекта. Обычно представляются в виде схемы или таблицы с взаимосвязями и сроками свершения, образуя План по Вехам (Milestone Plan, Milestone Schedule, Master Schedule) . Контрольное событие - важное событие проекта, обычно связанное с достижением важнейших результатов [ОУП]. Другие варианты - ключевое событие [УП], контрольная точка [УП]. Структура декомпозиции работ (Work Breakdown Structure), СДР (WBS) - представление проекта в виде иерархической структуры работ, полученной путем последовательной декомпозиции. СДР предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей. Структурная декомпозиция работ - иерархическая структуризация работ проекта, ориентированная на основные результаты проекта, определяющие его предметную область. Каждый нижестоящий уровень структуры представляет собой детализацию элемента высшего уровня проекта. Элементом проекта может быть как продукт, услуга, так и пакет работ или работа [НТК]. Иерархическая структура работ - структуризация работ проекта, отражающая его основные результаты. Каждый следующий уровень иерархии отражает более детальное определение компонентов проекта [ОУП]. Структура разбиения работ - иерархическая структура последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня, пакеты детальных работ [УП]. Проектные отклонения (Project Exceptions) - несовпадения фактических и плановых результатов проекта, причины таких несовпадений, методы и технологии, позволяющие справляться с такими ситуациями в проекте. Включают в себя риски, проблемы и изменения. Отклонение (Deviation) - выход за пределы установленных требований. К отклонениям относятся случаи, когда результат работы не удовлетворяет требованиям или необоснованно их превышает. Проектные риски (Project Risks) - возможность возникновения непредвиденных ситуаций или рисковых событий в проекте, которые могут негативно или позитивно воздействовать на достижение целей проекта. Риск проекта характеризуется следующими факторами: источниками и характеристиками событий, которые могут оказать влияние на его выполнение; вероятностями появления таких событий; возможным ущербом проекту и оценкой его влияния на проект. Риск - потенциальная, численно измеримая возможность неблагоприятных ситуаций и связанных с ними последствий в виде потерь, ущерба, убытков [УП]. Проектный риск в самом общем понимании - это опасность нежелательных отклонений от ожидаемых состояний в будущем, из расчета которых принимаются решения в настоящем [УПП]. Проблемы проекта (Project Problems) - любой функциональный, технический или связанный с бизнесом вопрос, который возник в процессе осуществления проекта и требует изучения и решения для того, чтобы проект мог идти так, как запланировано. Проблемные ситуации (Problem situations) - возникающие при осуществлении проекта ситуации, для выхода из которых необходимо находить оптимальные решения [НТК]. Решение проблем (Problem Solving) - определение последовательных систематических процедур, с помощью которых анализируются и решаются проблемные ситуации [НТК]. Изменения проекта (Project Changes) - модификация ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, используемых ресурсов, управленческих и технологических процессов и т. п. Изменения - увеличение или уменьшение характеристик элементов проекта. Пересмотр базового плана проекта. Подразумевает документально оформленные и утвержденные изменения [УП]. Календарный план проекта (Project Schedule) - перечень планируемых работ проекта со сроками исполнения и ответственными лицами, подготовленный в соответствующей форме, определенной планом управления проектом. Расписание проекта - плановые даты для выполнения работ и плановые даты для наступления контрольных (ключевых) событий ("вех") проекта [НТК]. Куратор проекта (Sponsor) - лицо, отвечающее перед руководством предприятия за успех проекта в целом и имеющее полномочия для решения ресурсных и других проблем, эскалированных руководителем проекта. Спонсор проекта - лицо или организация, для которых проект предпринят и которые в наибольшей степени принимают на себя проектный риск . Руководитель проекта (Project manager) - менеджер, отвечающий за успешную реализацию проекта, взаимодействие с заказчиком, субподрядчиками и подразделениями компании, а также за организацию подготовки и предоставление отчетности по проекту. Менеджер проекта - лицо, ответственное за управление проектом . Бюджет проекта (Project budget) - утвержденное запланированное распределение финансовых средств проекта по различным основаниям: по статьям затрат, по временным периодам, по участникам проекта, по решаемым задачам, по компонентам ожидаемых результатов, по элементам организационной структуры проекта и т. п. Бюджет проекта - сметная стоимость, распределенная по периодам выполнения проекта [НТК]. Заинтересованные лица (Stakeholders) - физические и юридические лица, как непосредственно участвующие в проекте, так и те, чьи интересы могут быть затронуты процессами осуществления проекта и его результатами. Участники проекта - физические лица и организации, которые непосредственно вовлечены в проект или чьи интересы могут быть затронуты при осуществлении проекта .

Источники, по которым цитируются определения:

1. Британский стандарт BS 6079-2:2000. Project management. Part 2 Vocabulary. (Перевод авторов статьи.)
2. ISO/TR 10006: 1997 (E). Quality Management - Guidelines to quality in project management. (Перевод Г. Е. Герасимовой.)
3. Wideman Comparative Glossary of Project Management Terms. PMForum, 2000 (www.maxwideman.com ).
4. A Guide to the Project Management Body of Knowledge. PMI Standards Committee.1996 Edition. (Перевод М. Грашиной.)
5. Quality Management for Projects and Programs. Lew Ireland. Project Management Institute. 1991. (Цитируется по , перевод авторов статьи.)
6. [НТК] Основы профессиональных знаний и национальные требования к компетентности специалистов по управлению проектами. Под ред. В. И. Воропаева, 2001.
7. [ОУП] Основы управления проектами. В. И. Либерзон.
8. [УП] Управление проектами. Справочник для профессионалов. Под ред. И. И. Мазура и В. Д. Шапиро, 2001.
9. [УПП] Управление программами и проектами. 17-модульная программа для менеджеров - "Управление развитием организации". Модуль 8. М. Л. Разу, В. И. Воропаев и др., 1999.