Posts tagged Документ

Устав проекта

0

К вашему вниманию предлагается шаблон документа Устав проекта.

В документ включены следующие разделы

1 Обоснование проекта
1.1 Краткое описание проекта
1.2 Решаемые проблемы/возможность
1.3 Бизнес цели
1.4 Критерии успеха
1.5 Связи и зависимости
2 Определение проекта
2.1 Результаты проекта
2.2 Критерии приемки результатов проекта
2.3 Исключено из проекта
2.4 Время
2.5 Стоимость
2.6 Другие требования
2.7 Допущения и ограничения
3 Организационная структура проекта
3.1 Управляющий комитет проекта
3.2 Руководство проектом
3.3 Команда проекта
3.4 Ключевые лица со стороны заказчика
4 Права и обязанности
4.1 Права и обязанности руководителя проекта
4.2 Права и обязанности управляющего комитета
4.3 Права и обязанности члена команды
5 Порядок управления проектом
5.1 Методика управления проектом
5.2 Политика управления командой проекта
5.3 Политика коммуникаций
5.4 Порядок приемки результатов проекта

 

Скачать шаблон документа Устав проекта в PDF формате

Скачать шаблон документа Устав проекта в Word формате

В шкуре менеджера продукта – готовим бизнес кейс

0

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

Надо понимать что это работа больше предназначена для менеджера продукта (product manager). Но в наших краях (кроме телекомов и ряда банков) это еще редкая профессия. Посему нашему брату, менеджеру проекта, надо осваивать и смежные навыки с менеджером продукта. В частности подготовку бизнес кейса и составление документа маркетинговых требований. Речь, конечно же, не идет о том чтобы менеджер проекта стал оракулом маркетинга – но вот знать что спросить с маркетологов и продавцов надо. Надо знать что мы хотим получить бизнес кейс (business case / MRD – Marketing Requirements Document).

Для кого это документ:

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

Давайте разберемся что должно быть в документе:

  • Резюме для руководства – менее чем на страницу вывод из всего документа – предлагающего один или несколько вариантов решения, ключевые цифры и основания. Несколько вариантов решения полезно тогда когда руководство любит сделать свой вклад в решение – даже если правильный вариант очевиден.
  • Кто клиент продукта. Возможно будет несколько обособленных сегментов клиентов которые будут пользоваться вашим продуктом (услугой). Определить клиента не указав потребности – это значит говорить без каких либо оснований. Какие цели у клиентов? Какие проблемы они испытывали при использовании продуктов-заменителей или продуктов конкурентов? Где они в реальной жизни и когда нуждаются в продукте? Где они его приобретают?
  • Описание продукта – описание посредством пользовательских характеристик верхнего уровня.
  • Отличие продукта от конкурентов. В чем он уникален, кто ближайший конкурент, кто заменитель, в чем разница (конкурентное преимущество). Очень желательно проверить себя на то что мы не создаем еще один похожий на 100 уже существующих продуктов да еще не с самым лучшим соотношением цена-качество.
  • Риски, связанные с разработкой, производством и продажей продукта. Очень хорошо трезво взглянуть на рынок, оценить вероятность возможностей, ответные действия конкурентов и т.п.
  • Жизненный цикл продукта – когда выпускаем продукт, какие масштабы производства в какое время запланировано, в каких регионах. Сюда также полезно включить развитие характеристик продукта – создание новых версий и редакций продукта.
  • Анализ затрат и доходов
  • Соответствие стратегии, миссии и видения развития компании. Анализ соответствия по отдельным стратегиям – финансовой (можем ли мы обеспечить денежный поток необходимый для реализации проекта, достаточно ли у нас финансового запаса прочности), технологический (есть ли у нас необходимые инструменты и технологии, достаточно ли у нас опытных людей)

NASA Guidance for writing Work Statement

0

http://www.hq.nasa.gov/office/procurement/newreq1.htm

DoD Handbook for Preparation of Statement of Work

0

DOD Handbook For Preparations of  SOW.pdf

Документ определения работы

0

В данной статье к вашему вниманию предлагается один из первых документов проекта – Документ определения работы (Statement of Work, SOW). По результатам описания документа будет предложен к обсуждению шаблон данного документа.

Следует отметить что в нашей практике документ с названием Документ определения работы встречается редко. Чаще всего он принимает вид Технического задания или просто договора или приложений к договору. Далее будем придерживаться его классического названия – Документ определения работ (Statement of Work). По тексту будем применять как полное так и сокращенное название документа (SOW)

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

Типы SOW. SOW может составляться на разных этапах проекта. На этапе инициации подачи предложений от поставщиков (Proposal SOW, PSOW) и на этапе подписания договора с конкретным поставщиком (Contract SOW, CSOW).

Состав документа. Давайте рассмотрим более подробно каждую из составляющих документа определения работы ориентируясь на CSOW тип документа:

  • Определение проекта
    • Проблема/Возможность – что является основанием для выполнения проекта (почему).
    • Стратегия решения – какая стратегия решения проблемы реализации возможности (каким образом)
    • Видение решения – краткое описание решения (что).
    • Цель проекта – определение целей проекта со стороны заказчика
    • Границы проекта – что входит и что не входит в проект.
  • Результаты проекта – состав продуктов и услуг которые получит заказчик от исполнителя проекта, ключевые документы и результаты работ проекта. Желательно не перегружать основной документ большим объемом описания бизнес требований к продуктам и услугам – а вынести это в отдельное приложение.
  • Роли и ответственность – указание ролей и ответственность за результаты проекта, процессы или отдельные работы. Перечень конкретных людей с указанием их ролей.
  • Условия - перечень условий и правил выполнения работ. Следует рассмотреть условия выполнения работ с обеих сторон – заказчика и исполнителя.
    • Условия оплаты
    • Условия по объему работ
    • Условия по срокам
    • Условия конфиденциальности
    • Условия по определению прав собственности
    • Условия по квалификации участников проекта
    • Санкции и штрафы
    • Условия по соответствию стандартам и законодательству
    • Форсмажор
  • Подход к выполнению работ – описание ключевых требований к порядку выполнения работ. Если есть задокументированная методика проектного управления – достаточно указать требования по следованию методикой и включить ее как приложение к документу. Следует рассмотреть порядок выполнения работ с обеих сторон – заказчика и исполнителя.
    • Порядок контроля выполнения работ
    • Порядок управления изменениями
    • Порядок приема работ
    • Порядок передачи результатов работ
    • Порядок оплаты работ
    • Подход к решению проблем
    • Порядок коммуникаций
    • Порядок замены состава участников проекта

Рекомендуемые приложения к документу:

  • Ключевые бизнес требования к продуктам и услугам (business requirements)
  • Первичная структура работ (WBS)
  • Соглашение по качеству предоставляемых услуг (QoS)

Опциональные приложения к документу:

  • Методика проектного управления применимая к проекту
  • Шаблоны документов, форм
  • Детальные политики на которые ссылаются из документа
  • Первичная оценка графика работ
  • Перечень ключевых показателей проекта (KPI)

Коммуникации по документу

0

По ключевым документам следует ответить на следующие вопросы:

  • Кто готовит документ?
  • Кто согласовывает документ?
  • Кто визирует документ?
  • Кто будет читать документ?
  • Когда? (по всем вопросам выше)
  • Когда будет обсуждаться документ? В каком составе?
  • Кому он должен быть представлен для подписания?
  • Какой шаблон документа принят в организации?
  • Знакомы ли в организации с данным типом документа?
  • Кому он должен быть отправлен на ознакомление?
  • Какой размер документа является приемлемым для чтения?
  • Должна ли быть сопроводительная записка к документу?

 

Перечень заинтересованных лиц

0

Крайне важно на этапе инициации проекта зафиксировать основных заинтересованных лиц (stakeholders list), их роли в проекте и кратко описать суть их интереса в проекте. Это все можно легко сформировать в виде Excel таблицы или списка на Sharepoint сайте вашего проекта.

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

  • ФИО
  • Компания, должность
  • Дата включения в проект
  • Контакты
  • Через кого можно коммуницировать с заинтересованным лицом – далеко не со всеми заинтересованными лицами можно обращаться напрямую (топ менеджмент, наблюдательный совет, внешние топ менеджеры)
  • Роль – можно построить визуальную матрицу где в нескольких колонках будут отображены ключевые типы ролей, на их пересечении – отметка по соответствию с заинтересованным лицом
  • Ожидания

Кутузов, Шаблоны документов для управления проектами

0

А. С. Кутузов, А. Н. Павлов, А. В. Шаврин, А. Н. Бондаренко
Шаблоны документов для управления проектами
Дата поступления в продажу: 04.02.2011

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

Подробнее смотри тут.

Внимание! Если вам интересны шаблоны проектных документов – они есть на данном сайте. Смотри тут. Также смотри по ключевому слову Документ

Видение проекта (Vision)

0

Видение проекта – раннее определение проекта создаваемое в самом начале инициации проект. Данный документ критично важен  для получения согласия запуска проекта и служит первым документом интегрирующим команду и создающим общее понимание сути проекта. (more…)

Go to Top