Scope в управлении проектами — как определить и контролировать объём работы

Что такое скоуп в проекте и почему он так важен

Скоуп формируется на этапе планирования. Вот, где это находится в жизненном цикле проекта:

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

❗Не менее важная работа — контролировать то, что в проект не входит. По статистике Института управления проектами PMI, 52% проектов бесконтрольно расширяются по ходу реализации. Проектная команда обрастает новыми хотелками и задачами от заказчика, неуклонно теряя фокус, перерастая бюджет и адекватную рабочую нагрузку.

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

Расскажем, как сформировать скоуп из того, что должно войти в проект, — и как защитить его от разрастания.

Элементы Scope. Что входит в объём проекта

Скоуп проекта умещается во внушительный набор документации. Вместе эти документы складываются в инструмент для управления ходом проекта и общения команды.

Таков состав скоупа по PMBOK. Согласно своду, объём проекта детально прописывается в документе «Содержание проекта» (Scope Statement).

В некоторых методологиях свои стандарты скоупа. К примеру, в P3.express его уместили в четыре документа: резюме, реестр последующих действий, карту результатов и реестр здоровья проекта.

Сколько бы документов ни содержал скоуп, он описывает всего три вещи:

Об этом «не входит» — давай отдельно и на примере.

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

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

И отдельной строкой будет прописано: исполнитель не отвечает за наполнение сайта контентом.

☝️ Если не позаботиться об описании того, что в скоуп не входит, то придёт монстр «ползучий скоуп».

«Ползучий скоуп»: почему растёт объём работы и как управлять изменениями

Разрастание объёма проекта из незапланированных целей, задач и требований называют «ползучий скоуп», или Scope creep (от англ. «ползать», «подкрадываться»). 

Это как стул с одеждой: сначала на нём висела только рубашка, но постепенно появились и пиджак, и плед, и носочки. И вот стул стал вешалкой, на нём нет свободного места и невозможно сидеть. 

В руководстве PMBOK Scope creep описывается так: «Добавление функций и возможностей (сферы действия проекта) без учёта влияния на время, затраты и ресурсы или без одобрения заказчика».

Страшный сон проектной команды!

Рассказываем, почему так происходит и что с этим делать.

Причина 1. Требования не были чётко определены на старте

Это когда объём вовсе не определён — несуществующий скоуп разрастётся в первую очередь. 

Это следствие халатности или недальновидности. Команда либо поторопилась со стартом проекта, либо вовсе решила не заниматься «крючкотворством» планирования.

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

Как не допустить

Не создавать скоуп Шрёдингера — когда он будто бы есть, а по факту неизвестно. И не полагаться на устные договорённости, когда, мол, и так понятно.

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

Причина 2. Заинтересованные стороны не вовлечены или не оказывают поддержки

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

Как не допустить

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

Второе — определить ответственных лиц за принятие решений и распределить роли. Здесь пригодится матрица RACI — таблица, в которой расписаны роли людей, задействованных в проекте.

👉 Всё о матрице RACI и её сестре DACI

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

Причина 3. Задачи оказались сложнее, чем задумывалось

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

Как не допустить

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

Не помешает поискать также референсы на рынке и спросить более опытных коллег.

Причина 4. Скоуп растёт вместе с желаниями заказчика

Это когда капитанский совет — оговорить содержание проекта до старта работы и зафиксировать его в договоре — не сработал.

Просто высечь скоуп в камне почти никогда не получается: в реальности сложно наперёд продумать все тонкости. Нормально принимать и реализовывать новые идеи от заказчика, пока это не переходит границы разумного.

С этим надо научиться работать — выстроить процесс контроля изменений.

Как управлять изменениями 

Какой формат управления изменениями подойдёт, зависит от конкретного проекта.

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

❗Сдерживать «ползучий скоуп» должен набор правил и ограничений. В нём описывают порядок приёма новых желаний от заказчиков и как команда принимает решение. Новые договорённости тоже фиксируют в описании скоупа.

Как определяют scope проекта

Шаг 1. Собрать информацию

Составление scope начинается с обсуждений и созвонов.

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

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

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

Шаг 2. Определить цели и содержание

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

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

По итогам должна получиться чёткая цель, лаконично описанная в одном предложении. Можно воспользоваться фреймворком SMART.

👆 И помним — отдельно прописываем, что в проект не входит.

Шаг 3. Приоритизировать, составить иерархию и декомпозицию работ

Структура работ составляется с помощью WBS — модели планирования проекта через декомпозицию. Задачи группируются по этапам, стадиям проекта, содержанию или исполнителям с помощью визуальных инструментов по типу Mind Map.

Цель проекта будет отправной точкой для составления модели. Все этапы и задачи должны отвечать на вопрос: «Что нужно сделать для достижения цели?». 

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

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

📎 Подробнее о модели WBS

📎 Подробнее о календарном плане проекта 

Шаг 4. Составить критерии приёма результатов

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

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

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

Покажем на примере.

User Story: одно горячее блюдо из мяса с гарниром.

Критерии приёмки: это свиной шашлык или стейк на выбор, размер порции 300 г. Прилагается гарнир на выбор: овощной салат или картошка фри, размер порции 150 г.

Шаг 5. Прописать ограничения и правила управления изменениями 

Ограничения могут быть по закону — когда вы не можете изменить порядок начисления НДС и это накладывает ограничения на проект. Или по бюджету, когда нельзя выходить за рамки определённой суммы. Всё это нужно прописать в скоупе.

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

Изменения бывают как со стороны заказчика, так и со стороны команды.

В первом случае цепочка будет выглядеть так: получаем запрос от клиента ➡️ вносим его в реестр ➡️ оцениваем ➡️ утверждаем с клиентом.

Во втором: подаём официальный запрос на изменения заказчику ➡️ вносим их в реестр ➡️ оцениваем ➡️ утверждаем. 

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

Шаг 6. Утвердить скоуп 

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

Теперь со скоупом нужно сделать последнюю вещь — показать его всем, кто связан с проектом, и получить подтверждение, что всё окей.

Щелкай задачи на раз-два

Задачи™ — созданы для классного таск-менеджмента

Документы на стероидах

База знаний™ — создана для документов и совместного чего-то там

Воронки продаж без ворон

CRM™ — создана для продаж и ведения бизнеса

Зарегистрироваться