Документ о содержании проекта

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

Что включить в оценочный документ:

• Функциональный объем : ключевые функции, которые должен выполнять/доставлять продукт/услуга. Хотя на данном этапе могут быть известны не все требования, цель состоит в том, чтобы включить/исключить функциональные «блоки».

• Объем данных : это относится к ИТ-проектам и определяет объем переноса данных, архивирования данных, настройки данных и т. д.

• Технический объем : ключевые технологии, которые будут использоваться для реализации проекта и продукта/услуги. Включайте/исключайте инструменты, приложения и оборудование, включая версии, где это возможно.

• Географический охват : если ваш проект охватывает различные географические районы (например, несколько регионов или стран), вы должны указать в документе об охвате, что включено, а что нет.

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

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

Другие рекомендации:

• В области действия или вне области действия : вам не нужно указывать для каждого элемента, который находится в области действия, что не входит в область действия! Вы можете заранее сказать в своем документе, что то, что не упоминается как находящееся в области действия, неявно исключено. Однако на практике люди, как правило, делают много предположений, поэтому это помогает определить те элементы с большим влиянием, которые, по вашему мнению, могут быть ожиданиями или предположениями заинтересованных сторон, которые могут быть включены позже.
• Когда дело доходит до уровня детализации , чем больше у вас есть, тем лучше, но вам не обязательно иметь все требования. Вы должны иметь разумный уровень комфорта, что есть прочные и удобные рамки, в которых вы можете реализовать проект.
• Включите раздел « Предположения »: это важно, так как это даст обоснование того, что было включено/исключено из объема, а также защитит команду проекта от неконтролируемых серьезных изменений. Могут быть изменения, но тогда они будут признаны формальными базовыми изменениями и учтены в процессе управления изменениями.
• Включите раздел « Риски ». Если у вас есть известные риски в вашем проекте, это хорошее место, чтобы выделить их, поскольку это дает контекст для определения области.

Кто является аудиторией вашего аналитического документа?

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

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

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

Сначала закончите требования, а затем укажите в заявлении о содержании, какие из требований вы реализуете в этом проекте. (Например, если это 4-недельный спринт, вы можете реализовать только требования 1-5. Если это полный выпуск, вы можете реализовать все функциональные требования, но только на платформе A в среде B или что-то в этом роде.)

Недавно я написал статью об определении объема документов для цифровых проектов .

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

Очень рад ответить на любые вопросы / комментарии.