(926)274-88-54
Бесплатная доставка.
Бесплатная сборка.
График работы:
Ежедневно. С 8-00 до 20-00.
Почта: soft_hous@mail.ru
|
|
Звоните! (926)274-88-54 Бесплатная доставка. Бесплатная сборка. |
Ассортимент тканей График работы: Ежедневно. С 8-00 до 20-00. Почта: soft_hous@mail.ru |
  
|
Читальный зал --> Международные стандарты управление проектами Шаблон Плана (макрошаблон) получается как простая сборка микрошаблонов Классификация проектов >s Ь 1 = с g о (5 с о Ф О I e-i Содержание и границы проекта Ключевые вехи проекта Плановый бюджет проекта Требования и стандарты Организационная структура Управление документацией Управление отклонениями Обеспечение качества Контроль и отчетность Рис. 2.3. От классификации проектов к Плану управления проектом (Business as Usual - Ball), стандартные проекты системной интеграции и сложные проекты системной ингеграции. Причем именно эта классификация является определяющей для структуры и содержания Плана управления проектом. При этом другие классификации сохраняют свое значение для формирования отдельных разделов плана. План управления проектом, содержащий согласованное всеми участниками документально зафиксированное представление о проекте, - это основополагающий документ - точка опоры для всего последующего развития проекта. Покажем, как могут выглядеть некоторые разделы специализированного шаблона Плана управления проектом. Используем для этого пример проекта создания филиала банка, приведенный в предыдущем разделе. Рассмотрим подпроект создания ИТ-инфраструктуры филиала банка. При построении специализированного микрошаблона Содержание и границы проекта мы использовали рекомендации РМВОК РМ/ (см. табл. 2.2). В этом шаблоне остается менять только названия программного обеспечения и сроки выполнения этапов работ. Для случаев, когда в организации исполняется много однотипных небольших проектов, должны создаваться специализированные шаблоны Плана управления проектом, ориентированные на максимальную экономию усилий менеджеров по их заполнению. Хорошим примером такого подхода могут быть проекты подключения (цифровых и/или аналоговых) клиентов телекоммуникационных компаний (см. табл. 2.3). Таблица 2.2. Специализированный микрошаблон Содержание и границы проекта создания ИТ-инфраструктуры филиала банка Пункт Рекомендация микро- рамочного стандарта шаблона (для любого проекта) Содержание специализированного шаблона для проектов создания ИТ-инфраструктуры филиала банка Обоснование Описываются основные Во всех филиалах должна быть установлена проекта (Project justification) характеристики продукта и их взаимосвязь с деловой необходимостью или иными стимулами унифицированная, надежная, гибкая и легко наращиваемая ИТ-инфраструктура на основе платформы ХХХХХХХХХ, позволяющая использовать в качестве основного средства обработки бизнес транзакций прикладного программного обеспечения YYYYYYYYYY Продукт проекта {Project product) Результаты проекта (Project deliverables) Основные характеристики Доставить, установить и настроить оборудование продукта и их взаимо- и системное программное обеспечение во вновь связь с деловой необхо- создаваемый филиал банка, формирующее димостью или иными основу для последующего внедрения банковской стимулами информационной системы Приводится перечень результатов (подпро-дуктов), достижение (полное и успешное создание) которых означает завершение проекта Спецификации системного программного обеспечения и его конфигурация Требования к помещению для установки оборудования Перечень оборудования и программного обеспечения План технического решения Эталонные копии установки и конфигурации системного программного обеспечения Оборудование и системное программное обеспечение, доставленное в филиал банка, установленное и подготовленное для установки банковской информационной системы Критерии оценки результатов (Project objectives) Описание количественных Срок доставки оборудования и программного критериев, которые должны быть удовлетворены, чтобы проект считался успешным обеспечения в Москву не должен превышать XX дней Срок наладки оборудования и программного обеспечения в Москве не должен превышать УУдней Срок транспортировки оборудования и программного обеспечения в филиал банка не должен превышать ZZ дней Срок установки и наладки оборудования и программного обеспечения в филиале не должен превышать WW дней В отличие от РМВОК PMI в методологии MITP(PMM) IBM термин Project objectives означает задачи проекта, решение которых, то есть достижение соответствующих подцелей, может быть оценено по количественным критериям. Таблица 2.3. План управления проектом цифрового подключения клиента телекоммуникационной компании
Сведения о клиенте Наименование клиента
Параметры заказа Параметры заказа Услуги Подключение по прямому проводу Подключение через радиодоступ Подключение через PCM/PGS Подключение до точки местной сети Номера {Компании} по данному адресу № т/ф линий, предоставленных для уплотнения За счет переключения номера Организация новой серийной группы Заведение в серийную группу Возможные технические решения Содержание коммерческого предложения Предполагаемый состав работ Предполагаемые закупки материалов и оборудования Наименование Количество Поставщик Требования к персоналу проекта Персональный состав
Риски проекта
Структура декомпозиции работ как часть Плана управления проектом Сопоставив приведенное в примере содержание разделов Продукт проекта и Результаты проекта , можно заметить, что результатами проекта являются элементы декомпозиции продукта проекта. Именно поэтому при формировании Плана (а следовательно, и при формировании шаблона Плана) часто используют структуру декомпозиции работ (WBS - Work Breakdown Structure), а многие ведущие компании включают в свои методологии и стандарты типовые WBS как в явном виде (Andersen Consulting), так и неявно (IBM). Провести декомпозицию и составить структуру декомпозиции работ (JVBS- Work Breakdown Structure), по утверждению некоторых авторов, очень легко: Прежде всего, следует разбить проект на несколько подпроектов. Каждый из подпроектов, в свою очередь, может быть разбит на некоторое число подподпроектов. Так следует последовательно делить проект на составные части до тех пор, пока не будет достигнут нужный уровень детализации (цит. по: Ньюэлл М. Стрз?ктура декомпозиции работ Директор информационной службы. 2001. №3). На самом деле все не так однозначно, причем речь пойдет не только о сложностях со;злания WBS, но и об открывающихся возможностях. Рассмотрим проблему на примере проекта создания информационной системы (И С). На фазе инициализации проекта руководитель проекта должен ответить на целый ряд вопросов (на самом деле их, конечно, гораздо больше, но мы ограничимся этими): что нужно сделать (определить продукты проекта); как это нужно делать (определить технологические этапы проекта); кто это будет делать (определить исполнителей, соисполнителей, субподрядчиков); в кто и в какой форме будет оплачивать работы (определить, какие и с кем будут заключены контракты). На какие же подпроекты следует разбить исходный проект? Что будет удобнее видеть на первом уровне декомпозиции - компоненты ИС (программные, технические, информационные) или технологические этапы (концепция, техническое задание, проектирование и т.д.)? А может быть, удобнее сгруппировать работы по исполнителям или по заказчикам? Например, если работы проекта выполняются в интересах различных заказчиков и в то же время финансируются различными инвесторами, декомпозиция может выполняться либо по содержательному признаку отнесения работ к проектам, либо по формальному признаку отнесения работ к договорам финансирования (см. рис. 2.4). Другой случай - фиксация в структуре работ участия субподрядчиков (см. рис. 2.5). Тогда для Функциональный заказчик 
Договор Д1 Договор Д2  -Декомпозиция по содержательному признаку -Декомпозиция по формальному признаку (финансовые потоки) Рис. 2.4. Декомпозиция работ по различным основаниям этапа календарного плана проекта формально выделяются группы работ, выполняемые основным исполнителем (подрядчиком) и другими исполнителями (субподрядчиками). Такую декомпозицию целесообразно применять, если за субподрядчиками закреплены крупные логически взаимосвязанные блоки работ, относительно независимые от других работ проекта. Итак, рецептов па все с.чучаи жязии ileci, по существует. Более того, каждый из упо.мянутых альтернативных впмилои интересен и имеет право на существование, благо, [ipo! pa\i\nii>c срс [c; :jli календарного планирования позволяют под:1ержи1зать Мюжссгво рахтчных группировок работ. А следовательно, первое, что .чо.чжк) бьгп отражено в специализированном шаблоне WBS, это какие альтернативные взгляды на структуру деко.мпозиции работ должны полл1ер>киват!>ся п проекте (взглял руко1?о-дителя проекта, взгляд куратора, взгляд инвестора w г. .i.). Если требуется декомпозиция по псско.изкпм раз.пипиим основа!1ия\1, должно быть указано главное (обычно jro взыял р\ коволн юля проекта). Для поддержки остальных вз1лило15 .юлжны бьпь опрсло.!снь1 соогвег-ствующие классификацио1шыс признаки. omicbn5ac.\n>ie как характеристики детальных работ. В качестве таких признаков \ioiyr использоваться, например, код проекта, кол логовора. кол субполрялИка li 1.л.
ООО «Мягкий Дом» - это Отечественный производитель мебели. Наша профильная продукция - это диваны еврокнижка. Каждый диван можем изготовить в соответствии с Вашими пожеланияи (размер, ткань и материал). Осуществляем бесплатную доставку и сборку. Звоните! Ежедневно! (926)274-88-54 Продажа и изготовление мебели. Копирование контента сайта запрещено. Авторские права защищаются адвокатской коллегией г. Москвы. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||