Коллеги, help!
Пытаюсь составить шаблон Устава проекта.
Открываю PMBoK, который рекомендует включить в Устав следующие разделы:
1.Требования...
2.Производственная необходимость...
3.Цель или обоснование проекта
4.Информацию о назначенном менеджере проекта ...
5.Отношения между участниками проекта....
6.Функциональные организации и их участие
7.Внешние допущения..
8.Ограничения ..
9.Реальная бизнес-ситуация, служащая обоснованием ..
10.Бюджет проекта.
У меня есть свое представление о том, что подразумевают эти разделы, но нет уверенности, что мое представление верно.
А не могли бы Вы написать для каждого пункта такой вопрос, ответ на который, раскрыл бы суть самого раздела.
Например, Требование - Чего мы хотим достичь?
Заранее благодарен.

по п2. - напишите, что случиться если проект не будет реализован.

По PMBOK устав готовит спонсор проекта
Правда в жизни с такой практикой я не сталкивался.
Главное в уставе - кратко описать проект и его возможное развите, затем подробне это всё раскрывать в scope и т.д.
Впрочем, в любой проектной организации куча уставов от старых проектов (база знаний)

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

Особое внимание следует уделить пункту 5.
И описать процедуры управления проектом.

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

Специфика же внедрения системы SAP отражена в методологии ASAP. Если внимательно ее изучать, то можно заметить что в ASAP интегрированы 2 методологии:
1) Методология внедрения ERP-системы
2) Методология управления проектом внедрения (пусть и обобщенно).

Если отнести сказанное к Уставу проекта внедрения, то в представленом списке разделов PMI, ИМХО, не достаточно раскрыта именно тема внедрения ERP-системы.

Исходя из вышесказанного и своего опыта предлагаю составить Устав проекта из следующих разделов:

1) Цели проекта
Здесь необходимо указать бизнес-цели внедрения ERP-системы, которые ставит функциональный Заказчик. Очень желательно также определить показатели (метрики) целей, чтобы можно было формально определить достигнута она или нет с точки зрения Заказчика (он должен быть удовлетворен ее достижением).
Например, цель "снижение затрат" можно достигнуть снизив затраты всего на 1 копейку, но Заказчик будет не удовлетворен, т.к. не был указан показатель на сколько необходимо сократить затраты. В данном случае необходимо определить цель, как "Снизить затраты на 20%".
Впрочем, когда внедрение системы производится "для галочки" (а таких в России пока много), описывать цели надо как раз туманно и без методов их измерений. Например, в этом случае подойдет такая цель: "автоматизировать бизнес-процессы бухгалтерии" и т.п.

2) Функциональные границы проекта
Здесь должны быть перечислены укрупненные бизнес-процессы, которые будут автоматизированы, а также модули системы SAP, которые их автоматизируют.
Примеры:
- Расчеты с кредиторами и учет кредиторской задолженности (модуль FI-AP)
- Учет основных средств и расчет амортизации (модуль FI-AA)
- Учет кассовых операций (модуль FI-BL)
и т.д.
Чем детальнее - тем лучше, т.к. потом будет легче формально отбиваться от дополнительных требований Заказчика. Но без фанатизма, т.к. для детального описания бизнес-процессов и требований в ASAP есть другой документ - концептуальный проект.

3) Подход к внедрению
В данном разделе необходимо указать:
- этапы проекта внедрения - по ASAP это: Подготовка к проекту, Концептуальный проект, Реализация, Заключительная подготовка, Ввод в эксплуатацию и поддержка
- результаты каждого этапа проекта: список и описание итоговых документов и актов закрытия работ
- как будут собираться требования к системе и проверяться их реализация (тестирование)
- из каких этапов будет состоять тестирование системы (подтверждение прототипа, заключительное подтверждение прототипа, интеграционное тестирование) и как будут исправляться дефекты
- на каких этапах будет вестись разработка ABAP-расширений и как они будут тестироваться (компонентное тестирование, интеграционное тестирование)
- как будет организовано обучение специалистов Заказчика и кто чему будет обучаться на различных этапах проекта
- как будет проводиться работа по организации и подготовке системного ландшафта системы

4) План проекта
В этом разделе нужно указать план проекта до каждого итогового документа и работ. Также нужно указать ответственных за выполнение работ по плану.
План проекта в Уставе не должен быть детальный, "шаг" планирования - минимум 2 недели.
Можно оформить в виде приложения к Уставу, чтобы потом было легче его изменять.

5) Оргструктура проекта
Здесь необходимо указать структуру проекта и подчиненность от Спонсора проекта до проектных групп.
Лучше оформить в виде схемы.

6) Функции участников и проектных групп
Здесь ввиде таблицы необходимо представить список участников проекта и групп, а также описать их функции. Что-то типа должностной инструкции.
Это нужно, чтобы решать конфликты, связанные с ответственностью различных участников проекта.

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

8) Процедуры управления проектом
Здесь надо прописать процедуры управления проектом:
- График и процедуры проведения совещаний
- Процедура разработки и согласования проектных документов
- Процедура управления изменениями
- Процедура управления рисками
- Процедура управления проблемами и открытыми вопросами
- Процедура документирования (работа с проектной библиотекой)
- Процедура информационного обмена в проекте (управление коммуникациями)
и т.д. в зависимости от того, какие процессы управления проекта необходимо формализовать.
Данные процедуры нужны чтобы все участники проекта понимали как решается тот или иной вопрос или задача в проекте, а также для решения связанных с ними конфликтов.
Процедуры можно оформить схематически или в виде текста (регламент).

О бюджете проекта
Бюджет проекта в Устав включать не стоит, т.к. доступ к такой информации, как правило, имеет ограниченное количество участников проекта. Луше оформить его отдельным документом.

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

Алексей Марейко

Это из классики или из жизни?:)

Из классики было то, что методология PMI нужна, но не достаточна для ведения проекта внедрения ERP-системы.
А вот содержание Устава проекта - это уже больше из жизни, т.е. личного практического опыта

С точностью до наоборот.
Методология PMM, разработаная PMI избыточна.
Ну а ASAP - это и не совсем методология.
И ASAP-а уже несколько лет нет.

murenets, Читайте внимательно!
PMI - не достаточна для ведения проекта внедрения ERP-системы. Ну ничего там не сказано про концептуальный проект, про подтверждение прототипа, про разработку расширений, про интеграционное тестирование, про сопровождение.
А если говорить про управление проектом внедрения, то безусловно она избыточна. Не нужно на проекте внедрения управлять закупкой и поставкой материалов, не всему нужно уделять такое пристальное внимание, как этого требует PMI.

Почему Вы говорите, что ASAP уже нет? ASAP не стоит на месте и нашел свою вторую жизнь в SAP Solution Manager. Куда ж без методологии внедрения то?
И если уж вообще глубоко копать, то ASAP до сих пор жив в первоначальной формулировке ASAP Roadmap (см. http://www.service.sap.com/roadmaps)

И почему вы считаете, что ASAP - это не методология? Я не хочу здесь вдаваться в понятие "методология", готов поговорить об этом при личной встрече. Просто поступлю формально и приглашу пойти по указанной выше ссылке. Вот текст с SAP-сайта:
The ASAP Implementation Roadmap for SAP Solutions provides proven implementation methodology for implementation of mySAP Business Suite

А если вы посмотрите презентацию
https://websmp101.sap-ag.de/~sapidb/011000358700004873022004E
то думаю окончательно убедитесь, что ASAP это:
1) Методология внедрения mySAP Business Suite
2) Методология управления проектом внедрения

Еще раз повторюсь - читайте все внимательно, также как Устав проекта

2 Алексей Марейко.
Ща письма заказчикам понаписыіваю, а к вечеру постараюсь ответить. Ок?

Лучше в личку, а то мы и так уже отклонились от темы. ОК?

Или давайте откроем новые темы, например:
- Достаточно ли методологии PMI для внерения SAP?
- ASAP мертв?
- Является ли ASAP методологией?

Ну, я же написал "не совсем методология" а не "совсем не методология".

А тему предлагаю открыть с таким названием.
-ASAP - экскурс в историю.

Да. Можно читать личку.

Озвучьте ответ! А то как-то недочеловеками себя чувствуим! Чо читать-то млин на сон грядущий??? ASAP типа "Война и мир" или што-то ищо - типа "Анна Каренина"?

Я раньше Кафкой баловался. Один абзац - и ты уже храпишь! Самое верное средство!