Этот раздел
обеспечивает контроль разработки и
рассылки версий Положения о проекте (далее
- Положение) вплоть до момента
утверждения. Положение не изменяется в
во время жизненного цикла проекта, а
разрабатывается и изменяется в начале
проекта, стимулируя утверждение проекта
и его начальные стадии планирования.
Положение содержит все необходимые
ссылки на заинтересованные стороны
проекта. Таблица внизу содержит номера
версий (определяются Вашей системой
учета документов), даты изменений и
выпуска, авторов, ответственных за
изменения, и краткое описание контекста
и\или рамок изменений в данной версии.
Короткое
описание проекта. Включается описание
в бизнес-терминах причин проекта,
времени исполнения и ожидаемого
результата. Также должна быть дана
некоторая историческая информация о
том, как и почему проект был иницирован.
Опишите, кто (в терминах индивидуальных
ролей и\или организационных областей)
будет использовать окончательный
результат проекта, и определите
заинтересованные стороны, которые
результат проекта окажет влияние.
Документ "Бизнес-"
может уже содержать информацию для
этого раздела и может быть использован
в качестве ссылки.
Определите
рамки проекта и рамки услуги\товара (продукта).
Рамки
продукта определяют спект свойств и
функциональностей, которые должны
поставляться, и ограничения, которые
должны быть выполнены, чтобы
контролировать выпуск или поставку
продукта (что проект будет выполнять).
Описание
рамок продукта в Положении не
определяет требования или
спецификации продукта. Напротив,
предполагается предложить лишь общее
описание продукта и начальное
понимание и соглашение о рамках
продукта.
Рамки проекта
определяют работу, которая требуется,
чтобы обеспечить соответствие
проектного продукта целям проекта (как
проект будет исполняться).
Хотя рамки
продукта и рамки проекта тесно связаны,
остальные разделы Положения описывают
лишь рамки проекта и процессы,
необходимые для получения продукта.
Фокус Положения дожен
концентрироваться на процессах
проекта.
Определите
общие цели проекта. Определите то, чего
проект должен достичь в бизнес- и
технических терминах. Сделайте ссылки
на "Инвестиционное решение", "Бизнес-кейс"
и "Логический структурный анализ".
Определите
все непогашенные эмиссии ценных бумаг,
которые необходимо погасить в рамках
проекта. Эти эмиссии должны быть
определены при разработке "Бизнес-кейса"
и в процессе согласования и\или
инициации проекта.
Этот раздел
определяет имена и роли
заинтересованных сторон проекта и их
согласие с Положением. В этот раздел
часто включаются подписи. В некоторых
организациях список из спонсоров
проекта и менеджера проекта - это
все, что требуется.
Определите
другие документы, включая, например,
"Инвестиционное решение", "Бизнес-кейс",
и "Логический структурный анализ",
(в электронной и бумажной форме),
которые связаны с проектом во время
разработки Положения. Включите текущий
номер версии, дату выпуска, автора,
место хранения и способ доступа к
каждому документу или ссылке. Также
должна быть предоставлена достаточная
информация, чтобы объяснить, как
документ связан с проектом , какой
именно его фрагмент относится к
проекту и как он может быть найден.
Определите все
уникальные и ключевые термины и\или
акронимы, часто используемые в проекте.
Термины, которые могут быть или новыми
или непонятными для заинтересованных
сторон, должны быть четко разъяснены.
Представьте
список результатов, кторые будут
получены как при исполнении, так и
завершени проекта. Определите ключевые
контрольные точки. Для каждого
результата дайте описание его
качественных целей в терминах
выходного качества и согласованных
требований. Например, "доклады о
текущем состоянии будут поставляться
еженедельно спонсору проекта и лидерам
проектной команды и должны
утверждаться каждой из персон до
передачи в архив проекта". Степень
поддержки, которая должна быть оказана
продукту, должна быть также
представлена как качественная цель.
Этот раздел
определяет требования к проектной
команде и, принимая во внимание
ресурсный план организации и требования
к навыкам проектирования, назначает
роли и ответственность поименованным
индивидам. Возможная структура
организации:
Исполнительный
комитет
Лидер
проекта
Менеджер
проекта (IT-менеджер проекта и\или
менеджер проекта в бизнес- области)
Лидеры
проекта в IT-области (Лидеры команд
разработки или лидеры проектных
команд в IT-области, которые помогают
менеджеру проекта в
администрировании и\или управлении
специфическими аспектами проекта)
Члены
проектных команд (включая членов IT-команд
и бизнес-клиентов)
Координатор
испытаний
Контролер
качества
Контролер
конфигурации
Контролер
изменений
Индивиды
могут совмещать исполнение ролей в
проекте. Например, в небольших проектах
менеджер проекта может быть
одновременно членом проектной команды,
контроллером конфигурации и изменений
и координатором испытаний. В небольших
проектах Исполнительный комитет может
не создаваться, и лидер проекта
исполняет согласующую и надзорную
функцию.
В больших
проектах лидеры проектных команд IT-области
могут назначаться помощниками
менеджера проекта в действиях по по
координации всех операций проекта и
управлению специфическими выходами по
плану работ.
В большинстве
проектов является предпочтительным
разделять роли менеджера проекта и
лидера команды. Совмещение ведет к
отклонению от исполнения основных
функций по управлению проектом.
Эти роли
обычно описываются в "Руководстве
менеджера IT-проекта", "Основные
роли и обязанности".
В рамках этого
раздела описываются отношения по
предоставлению докладов и проектные
интерфейсы. Необходимые согласования,
интрефейсы с внешними организациями (для
оказания посреднических услуг) и с
комитетами надзора, контроля и высшего
управления должны быть
задокументированы.
Все
зависимости за пределами прямого
контроля управляющих проектом или
внешние рамки проекта (которые могут
повлиять на успех проекта) должны быть
определены. Например, действия, которые
должны быть исполнены клиентом или
субконтрактором, или действия или
выходы внешних проектов, которые
необходимы внутри контекста
расматриваемого проекта.
Внутренние
зависимости также должны быть рассмотрены.
Зависимости проекта и\или выходов проекта
от других проектов\продуктов (существующие
или находящиеся в развитии) должны быть
ясны. Например, если необходимый ресурс
становится недоступным до завершения
другого проекта, эта зависимость должна
быть определена и соответствующий риск
должен быть задокументирован в подходящем
для этого разделе Положения. Должны быть
также определены необходимые связи с
другими существующими или планируемыми
системами.
Здесь
описываются планы поддержки операций.
Примерами такой поддержки могут быть обучение,
обеспечение качества, управление
конфигурацией и документарная
поддержка. Если эти планы существуют
как документы внешние в отношении к
Плану проекта (План управления
конфигурацией, План качества, План
обучения), то здесь необходимо привести
на них сслыку.
Потребности
проекта в таком обеспечении и ресурсах,
как офисное пространство, специальные
средства обслуживания, вычислительная
техника, офисное оборудование должны
быть определены. Ответственость за
поставку или обеспечение исполнения
этих условий дожна быть ясно
обозначена и описана.
Планирование
необходимых вычислительных мощностей (память,
процессор, дисковое пространство)
должно принимать во внимание размеры
приобретаемого или разрабатываемого
программного обеспечения, уровень
персонала проекта и историю подобных
проектов в прошлом.
Все риски,
связанные с проектом и действиями, которые
могут быть предприняты с целью
минимимизации рисков, должны быть описаны.
Меры предосторожности и планируемые
реакции также должны быть описаны.
Например, риск
может зависеть от одного из навыков (одного
ресурса) в рамках организации. Менеджмент
должен в этом случае по меньшей мере
определить альтерантивные источники этого
навыка или обеспечить обучение резервного
ресурса. Использование аппратного
обеспечения ного типа тоже рождает риск.
Управление риском должно предусмотреть
предварительное ознакомление с
прототипами оборудования и дополнительное
тестирование.
Должен быть
описаны как процессы идентификации,
документирования, слежения и мониторинга
рисков, так и процессы снижения и
исключения рисков и стратегии реакций.
В больших
проектах План управления рисками может
разрабатываться вне настоящего Положения.
В небольших проектах он начинается как
часть Положения, но дорабатывается в
течение реализации проекта в виде внешнего
документа или системы.
Известен подход,
называемый Непрерывным управлением
рисками (Continuous Risk
Management - CRM). Существуют соответствующие
Руководства (открытые
ресурсы в Интернет) , в содержание которых
входят систематический (таксономический)
вопросник и все алгоритмы, которые могут
быть использованы в связанных инструментах
и технологиях.
Если Ваш
департамент уже определился с Методологией
управления проектами или Методологией
системного проектирования жизненного
цикла, это должно быть отражено в настоящем
разделе. Если по каким-либо причинам
отклонения от этих стандартов видятся
необходимыми и\или желательными для
проекта, эти отклонения должны быть
определены, и их рациональное
обоснование должно быть здесь помещено.
Включает описание
жизненного цикла проекта (проекта) и
жизненного цикла поставки решения (разработки
проекта). Должны быть определены этапы
проекта, цели каждого этапа и признаки их
входов \ выходов.
Сделайте ссылки
на принятые для этапа проекта в Вашем
департаменте определений для входных
ресурсов \ результата и признаков входа \
выхода. Для каждого этапа жизненного цикла,
прикладных процедур, методов и стандартов
должны быть представлены ссылки или
определения.
В разделе
объясняются методы и процедуры, которые
применяются для оказания помощи мнеджеру
проекта в оценке исполнения проекта и
информировании об исполнении проектной
команды, спонсора проекта и
заинтересованных сторон проекта. Он также
включает определение подхода к устранению
отклонений от плана проекта и проведению
корректирующих операций. Управление
проектом характеризуется:
Типом
и частотой производства проектных
отчетов
Частотой
проведения совещаний проектной команды
Частотой
обсуждений контрольных точек этапов
проекта (проводимых, по-возможности,
Исполнительным комитетом).
Частотой
собраний Исполнительного комитета
Именем и
размещение проектного файла
Методами,
которые должны быть использованы, чтобы
получить допуск и контроллировать
проектные операции
Критерием
выпуска измененных версий проектного
плана
Метриками,
которые должны быть собраны при
реализации проекта, и анализом, который
должен быть выполнен с ними
Этот раздел также
определяет методы и политики, используемые
для контроля границ проекта, управления
эмиссиями и управления изменениями и
конфигурированием. Также в рамках
настоящего раздела должна быть представлен
план проектных коммуникаций - методы,
синхронизация, наблюдатели и т.д. в
проектных коммуникациях (инструменты
которые должны использоваться, методы
получения результата, адресаты, коллекция
проектной информации и реакций на нею и
архивация рабочих бумаг проекта).
Действия по
управлению качеством связаны как с
процессами управления проектом, так и с
результатами проекта. Требуется список все
обзоров по качеству и тестам качества,
используемым в проекте, включая
права собственности, приближенные план-графики
и усилия. Например, дожны присутствовать
обзор проектного плана, конструкционные
обзоры, испытания устройств, испытания
систем, приемные испытания. Для этого
должен быть составлен и спланирован список
всех объединенных потребительско-клиентских
обзоров.
Включите
совещания для подготовки обзоров по
результам тестов приемки и проверку
соответствия требованиям. В данной точке
проекта специфичные обзоры, связанные с
продуктами, и процессы (конструкционные
обзоры, системные тесты и т.п.) могут быть
еще не известны. Тем не менее, описание
ожидаемых типов обзоров и уровней
вовлечения различных заинтересованных
сторон и членов команды должно быть здесь
представлено.
Диаграмма Гантта
для работ, ресурсов и связанных с ними
ответственных исполнителей. Методология
управления проектами Вашего департамента и\или
Методология управления жизненным циклом
систем может оказать влияние на построение
диаграммы Гантта (включая соответствующую
декомпозицию работ). График проекта должне
учитывать критические зависимости между
проектными группами. Рекомендуется
использовать специальные программные
инструменты проектного менеджмента для
разработки графика проекта и мониторинга
его реализации в соответвии с графиком.
Этот раздел
описывает проектные усилия в человеко-днях
или человеко-месяцах, оцениваемые в
соответствии с процедурой оценки, принятой
в Вашем департаменте. Усилия должны быть
декомпозированы на этапы и фазы проекта.
Включается
информация, используемая для оценки усилий
(допущения, исторические данные,
используемые для получения оценок и т.п.).
Этот раздел
определяет стоимость проекта, оцениваемую
в соответствии с процедурой, принятой в
Вашем департаменте. Стоимость должна быть
классифицирована ( труда, оборудования,
офисного пространства и т.д.) и
декомпозирована на этапы и фазы проекта.
Дополнительно,
политика и методы снабжения\поставок ,
используемые в проекте, должны быть
детализированы (кто отвечает за решения о
закупках и разработку и управление счетами
заказов, платежными поручениями и т.п. и как
все это управляется).
Включается
информация, используемая для получения
оценок стоимости (допущения, источники
стоимостной информации, история стоимостей,
используемые для оценки).