[ «УПРАВЛЕНИЕ ПРОЕКТАМИ УЧЕБНОЕ ПОСОБИЕ ИЗДАТЕЛЬСТВО САНКТ-ПЕТЕРБУРГСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА ЭКОНОМИКИ И ФИНАНСОВ 2012 ББК 65.050.2 У 66 Управление проектами : учебное пособие / М.В. Тихонова У 66 [и др.]. – ...»
Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее потребностям, стандарт CMMI имеет две формы представления – классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов. В таблице 2.3 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.
Стандарт SPICE Аббревиатура SPICE раскрывается как Software Process Improvement and Capability dEtermination. Основные цели SPICE:
• удовлетворение растущих потребностей в оценке возможностей процессов производства программного обеспечения в подразделениях;
• гармонизация методов и моделей, используемых для оценки процессов.
Проект SPICE был начат ISO в июле 1991 года и к настоящему времени объединил лучшие из существующих в мире практик. В основу SPICE легли такие стандарты, как:
• STD (Compita);
• TRILLIUM (Bell);
• BootStrap (Esprit);
• HealthCheck (BT);
В отличие от одномерной модели CMM архитектура SPICE двумерна и состоит из так называемых «уровней возможностей», их насчитывается 6 (плюс 9 атрибутов процессов и 32 правила менеджмента); категорий процессов (5) и типовых процессов (29), а также наилучших известных практик (best known practices, их более 200). Центральной идеей SPICE является оценивание возможностей не одним числом, как в CMM, а путем построения так называемого профиля организации. Сама организация может проанализировать свою деятельность, выявить, какие из наилучших практик в ней применяются, а какие нет, и построить профиль – кривую, наглядно показывающую, в каких областях деятельности организация сильна и где в ней узкие места. Наличие масштабируемого механизма самооценки является важнейшим достоинством SPICE. В таблице 2. проведено сравнение механизма самооценки SPICE и процедуры аудита в ISO 9000.
Детальные критерии Абстрактные критерии Внутреннее участие Внешний, независимый Позитивное суждение Негативное суждение SPICE предлагает достаточно подробную модель, предоставляющую пользователям свободу в выборе путей к улучшению работы. Модель улучшения процессов в SPICE трехмерна, где по одной оси откладывается Эффективность работы (удовлетворенность заказчиков, качество продукции и продуктивность), по другой – Возможности персонала, и по третьей – Адекватность процесса. Таким образом, можно выбирать траекторию улучшения процесса в трехмерном пространстве, где улучшения по каждой из осей идут параллельно с улучшениями по другой. Собственно, параллельность не является требованием, это, скорее, рекомендация, позволяющая избежать серьезных перекосов в процессе производства.
Как уже говорилось, SPICE вобрал в себя все самое лучшее из целого ряда популярных стандартов, но он не стал простым их объединением.
Для того чтобы показать, чем же SPICE отличается от своих предшественников, целесообразно провести сопоставление SPICE и других наиболее известных стандартов.
Развитая документация Малая документация Разработан для производства ПО Разработан для производства в целом Улучшение процессов и оценка Сертификация возможностей Требования к самооценке Не содержит руководство по применению
SPICE CMM
Двумерная структура Последовательная, одномерная структура Допускает гибкость в выработке Содержит предопределенный путь стратегии улучшения развития Уровни возможностей для каждо- Единый уровень зрелости для всех прого процесса цессов Результаты требуют упрощения Результаты легко понимаемы Результаты очень подробные Упрощенные результатыТЕМА 3. СТРУКТУРА СТАНДАРТОВ
3.1. Специализация и детализация стандартов Стандарты управления проектами уровня предприятия в части методологии обычно имеют основу, определяемую документами достаточно общего характера (иногда эти документы называют «рамочными»). К таким документам относится Project Management Body of Knowledge (PMBoK) Американского института управления проектами (PMI), признаваемый многими международным стандартом де-факто, и стандарт ISO 10006:1997, придавший ряду наиболее важных положений PMBoK статус стандарта де-юре. Смысл и содержание перехода от рамочных стандартов (какими являются и PMBoK, и в еще большей степени ISO 10006) к стандарту предприятия состоят в их специализации и детализации.Специализация означает включение в стандарт предприятия только тех положений, которые имеют отношение к проектной деятельности именно на этом предприятии и связаны с его реалиями. Прежде всего из этого следует, что такие реалии должны иметь четко определенные понятия, измеримые показатели и т.п. В связи с этим стандарт предприятия неизбежно должен содержать описание и классификацию проектов компании.
Проекты компании могут относиться к различным профессиональным областям деятельности (юридическая, финансовая, ИТ, строительная, маркетинговая и т.д.), иметь различную сложность с точки зрения решаемых задач, различный масштаб с точки зрения привлекаемых ресурсов и предполагаемого результата. Могут выделяться некоторые категории проектов, специфические с точки зрения конкретных отраслей. Например, в стандарте компании Enron, специализировавшейся в своё время в области электроэнергетики, отдельно рассматривались международные (overseas) проекты, как предъявляющие особые требования к законодательной базе, к персоналу, оборудованию, экономической инфраструктуре, логистике и т.д.
Организационные структуры и персонал проекта также являются предметом специализации. В стандарте предприятия могут не только фиксироваться стандартные проектные роли (руководитель проекта, администратор, менеджер по качеству и т.д.), но и определяться структура и принципы формирования органов управления проектами. Примером такой специализации может служить двухуровневая управленческая структура в проектах внедрения ERP систем.
Для всех постоянных (определенных штатной структурой) подразделений, тем или иным образом связанных с исполнением проектов, должны быть определены принципы их участия в проектах – виды выполняемых работ, порядок выделения и отзыва персонала, формы и размеры получаемого вознаграждения.
Для руководства этих подразделений должны быть определены их права и обязанности по отношению к организационным структурам проекта. Для сотрудников, привлекаемых в проект, должны быть определены правила, регламентирующие их работу в проекте, в том числе, регулирующие вопросы двойного подчинения и материального стимулирования.
Предметом специализации, безусловно, являются и процессы управления проектами. Общее множество возможных процессов представим в виде трехмерного пространства, изображенного на рис. 3.1. По осям координат отложены те измерения, которые упоминаются в рамочных стандартах, могут быть предложены и другие, например уровни управления, календарные периоды. Каждая точка этого пространства представляет собой элементарный процесс управления. Например, «планирование рисков на стадии внедрения системы».
Рис. 3.1. Процессы управления проектами Выбранные элементарные процессы образуют процедуры управления проектами, которые могут быть построены по «осевому» принципу (здесь имеются в виду абсцисса, ордината и аппликата, обозначенные на рис. 3.1).
Собственно, описание этих процедур и составляет основной объем стандарта. Если быть более точным, под стандартом предприятия мы понимаем совокупность документов, объясняющих или предписывающих как, в какой последовательности, в какие сроки, с использованием каких шаблонов нужно выполнять те или иные действия в процессе управления проектами. Количество этих документов зависит от степени детализации стандарта и может быть достаточно велико (от десятков до сотен документов). На рис. 3.2 они представлены в виде ступенчатой пирамиды (цилиндрического зиккурата), которая обычно выстраивается сверху вниз по мере пробуждения аппетита у тех, кто организует и регламентирует работы на предприятии, и соответствующего ему развития стандарта.
Предметом описания в стандарте могут быть также типовые ситуации, характерные для проектов предприятия, и рекомендации менеджерам по реагированию на эти ситуации, то есть своеобразные таблицы решений, что-то вроде списка возможных неисправностей и рекомендаций по их устранению (checklist). Конечно, решение все равно будет принимать менеджер, но у него перед глазами будет обобщенный опыт («сын ошибок трудных») предыдущих поколений.
Рис. 3.2. Структура стандарта управления (Товб А., Ципес Г. От рамочных стандартов управления http://www.zulanas.lt/images/ adm_source/docs/3%20Tovb-full%20paper-RUS_old_.pdf ) Классификация проектов как первый этап создания стандарта Ключевым моментом в создании стандарта управления проектами является осмысление того, какие проекты выполняются на предприятии, каковы их отличия, что между ними общего. Эти вопросы связаны с практикой управления проектами и отражаются в стандарте предприятия.
В западной науке существует мнение, что профессиональный руководитель может управлять проектом независимо от области, к которой он относится – от прокладки железных дорог до разработки программного обеспечения. Это особенно важно для предприятий, реализующих комплексные проекты, захватывающие различные предметные области. Характерным примером, в котором в равной степени очевидны и необходимость привлечения «универсального» руководителя проекта, и пути снижения стоимости его «содержания», является проект создания филиала банка. Такой проект включает целый ряд взаимосвязанных и, вместе с тем, относительно независимых подпроектов: юридический, строительный, технологический, ИТ, рекрутинговый, маркетинговый и т.д. В крупных банках филиалы создаются десятками. После одного-двух таких проектов опыт их реализации может оказаться достаточным для того, чтобы сформировать для каждого вида проектов (подпроектов) типовые цели и результаты, типовые календарный и ресурсный планы и бюджет, определить известные риски и эффективные стратегии работы с ними и т.д.
Но как раз эта информация и составляет сущность основного документа, с которого должен начинаться любой проект – Плана управления проектом (в различных источниках можно найти и другие названия подобного документа – Устав проекта, Определение проекта). Таким образом, могут быть подготовлены специализированные шаблоны Плана управления проектами, фиксирующие совершенно конкретные методы управления проектами, рекомендованные на данном предприятии для данного типа проектов, а вслед за ними и другие типовые шаблоны.
Что должно быть отражено в Плане управления проектом Содержание и границы проекта – цели и задачи проекта, основные результаты, критерии оценки того, что работа или ее часть выполнена.
Ключевые вехи проекта – основные события проекта (milestones) и план их достижения, возможно, с использованием структуры декомпозиции работ (WBS).
Предположения и ограничения – предпосылки, на основе которых делались оценки сроков выполнения, трудоемкости работ проекта и стоимости, включая описание начальных рисков.
Требования и стандарты – перечень нормативных и регламентирующих документов или их отдельных положений, которые следует соблюдать в ходе выполнения работ проекта.
Подходы к выполнению проекта – концепция предполагаемого решения (возможно несколько альтернативных вариантов), методы разработки и базовые информационные технологии.
Организационная структура – ответственность и порядок взаимодействия участников, имена и обязанности ключевых фигур проекта.
Управление проектной документацией – структура, среда хранения и процедура создания и сопровождения репозитария документов проекта, перечень шаблонов документов.
Управление отклонениями – процедуры работы с рисками, с возникающими проблемами и изменениями форм соответствующих проектных документов.
Обеспечение качества – перечень и регламенты проведения мероприятий, направленных на обеспечение качества как результатов проекта (продукта), так и процессов управления проекта и выполнения работ.
Контроль и отчетность – регламент проведения мероприятий по анализу состояния проекта, соответствующие формы отчетности.
Преимущества типовых шаблонов очевидны – экономия на консультантах, унификация подходов, сокращение времени на подготовку документации проекта. Недостатки тоже есть, мы отметим здесь только два.
Создание таких шаблонов – дело достаточно трудоемкое, а будут их использовать или нет, заранее неизвестно. Это зависит от воли и настойчивости руководства предприятия. Второе – есть опасение, что наличие таких шаблонов будет сковывать инициативу и самостоятельность руководителя проекта и он не сможет адекватно реагировать на нештатные ситуации. Нам кажется, что эти сложности окажутся не столь критичными, если шаблоны будут удобны, а их специализация и детализация будут оптимальными для данного предприятия и его проектов. А это уже вопрос качества работы консультантов и аналитиков, создающих стандарт.
Сколько разных шаблонов Плана управления проектом целесообразно иметь в стандарте? Для того чтобы ответить на этот вопрос необходимо построить классификацию проектов, выполняемых на предприятии. Причем, очевидно, что для каждого предприятия это будет уникальная классификация. Собственно, с построения такой классификации и должно начинаться создание стандарта.
Прежде всего, отметим, что вряд ли возможно построить единую древовидную классификацию проектов предприятия. Скорее всего, это будут несколько классификаций по различным основаниям, связанным с определенными разделами Плана. Рассмотрим некоторые из них.
Классификация по предметным областям и по продуктам в рамках этих областей позволяет специализировать разделы «Содержание и границы», «Ключевые вехи», «Требования и стандарты». Эту классификацию как раз можно выстроить по иерархическому принципу. Например, «информационные технологии» – «проекты системной интеграции» – «создание интегрированных систем управления проектами».
Классификация по масштабности проекта позволяет специализировать разделы «Организационная структура», «Управление отклонениями», «Обеспечение качества». Для построения этой классификации могут использоваться различные основания – территориальная разбросанность, как это принято в Enron Corp., или стоимость проекта (IBM), может быть, какие-то другие основания и их комбинации.
Классификация по форме оплаты и, следовательно, учета работ позволяет специализировать Контроль и отчетность, Управление проектной документацией на основании таких форм контрактов, как «Время и материалы» и «Фиксированная цена».
Таким образом, можно вести речь, например, о шаблоне «План управления проектом создания концепции (продукт) информационной системы (предметная область) стоимостью свыше $ 100 тыс. (масштабность) с контрактом в форме “время и материалы” (форма оплаты и учета работ)», как о макрошаблоне, получаемом простой сборкой из нескольких более мелких (микро-) шаблонов отдельных разделов Плана. Кроме того, в макрошаблон должны быть включены и некоторые дополнительные разделы, которые не могут быть определены на микроуровне (такие, например, как «Сроки работ по этапам»). Микрошаблоны могут быть глубоко специализированными – насколько это позволяет соответствующая классификация и накопленный на предприятии опыт.
Рассмотренные выше примеры классификаций проектов специально подобраны нами для иллюстрации возможности сборки шаблона из относительно независимых стандартных фрагментов. Однако в реальной жизни встречаются и другие ситуации. Например, в IBM принята классификация проектов по сложности (комплексности). В соответствии с этой классификацией проекты делятся на обычный бизнес (Business as Usual – BaU), стандартные проекты системной интеграции и сложные проекты системной интеграции. Причем именно эта классификация является определяющей для структуры и содержания Плана управления проектом. При этом другие классификации сохраняют свое значение для формирования отдельных разделов Плана.
План управления проектом, содержащий согласованное всеми участниками документально зафиксированное представление о проекте, – это основополагающий документ – «точка опоры» для всего последующего развития проекта.
Покажем, как могут выглядеть некоторые разделы специализированного шаблона Плана управления проектом. Используем для этого пример проекта создания филиала банка, приведенный в предыдущем разделе. Рассмотрим подпроект создания ИТ-инфраструктуры филиала банка.
При построении специализированного микрошаблона «Содержание и границы проекта» использованы рекомендации PMBoK PMI (табл. 3.1).
В этом шаблоне остается менять только названия программного обеспечения и сроки выполнения этапов работ.
Специализированный микрошаблон: «Содержание и границы проекта создания ИТ-инфраструктуры филиала банка»
Пункт микрошаблона рамочного стандарта Обоснование проекта Описываются основ- Во всех филиалах должна быть Продукт проекта Основные характе- Доставить, установить и наристики продукта и строить во вновь создаваемый (Project product) Результаты проекта Приводится пере- Спецификации системного (Project deliverables) Пункт микрошаблона рамочного стандарта Критерии оценки Описание количест- Срок доставки оборудования и результатов венных критериев, программного обеспечения в (Project objectives) http://www.std1.ru/catalog/catalog293/catalog293294/catalog293294436/156/ Сопоставив приведенное в примере содержание разделов «Продукт проекта» и «Результаты проекта», можно заметить, что результатами проекта являются элементы декомпозиции продукта проекта. Именно поэтому при формировании Плана (а, следовательно, и при формировании шаблона Плана) часто используют структуру декомпозиции работ (WBS – Work Breakdown Structure), а многие ведущие компании включают в свои методологии и стандарты типовые WBS как в явном виде (Andersen Consulting), так и неявно (IBM).
По мнению некоторых авторов, совершенно несложно выполнить декомпозицию и составить структуру декомпозиции работ (WBS – Work Breakdown Structure): «Прежде всего, следует разбить проект на несколько подпроектов. Каждый из подпроектов, в свою очередь, может быть разбит на некоторое число подподпроектов. Так следует последовательно делить проект на составные части до тех пор, пока не будет достигнут нужный уровень детализации» (статья М. Ньюэлла «Структура декомпозиции работ» в журнале «Директор информационной службы» за март 2001 г.).
В действительности все оказывается не так просто, так как возникают некоторые сложности при создании WBS и открываются новые возможности. В следующем примере мы можем рассмотреть эту проблему более подробно.
На стадии инициализации проекта создания информационной системы (ИС) руководитель должен (обязан) решить несколько задач:
что нужно создать (определить продукты проекта);
как это выполнить (определить технологические этапы проекта);
кто это будет делать (определить исполнителей, соисполнителей, субподрядчиков);
кто и в какой форме будет оплачивать работы (определить, какие и с кем будут заключены контракты).
На какие подпроекты следует разбить исходный проект? Что будет удобнее видеть на первом уровне декомпозиции – компоненты ИС (программные, технические, информационные) или технологические этапы (концепция, техническое задание, проектирование и т.д.)? А, может быть, удобнее сгруппировать работы по исполнителям или по заказчикам?
Например, если работы проекта выполняются в интересах различных Заказчиков и, в то же время, финансируются различными Инвесторами (см. рис. 3.2) декомпозиция может выполняться либо по содержательному признаку отнесения работ к проектам, либо по формальному признаку отнесения работ к договорам финансирования. Другой случай – фиксация в структуре работ участия субподрядчиков. Тогда для этапа календарного плана проекта формально выделяются группы работ, выполняемые основным исполнителем (Подрядчиком) и другими исполнителями (Субподрядчиками). Такую декомпозицию целесообразно применять, если за субподрядчиками закреплены крупные логически взаимосвязанные блоки работ, относительно независимые от других работ проекта.
Итак, рецептов на все случаи жизни здесь не существует. Более того – каждый из упомянутых альтернативных взглядов интересен и имеет право на существование, благо программные средства календарного планирования позволяют поддерживать множество различных группировок работ.
Первое, что должно быть отражено в специализированном шаблоне WBS, – это какие альтернативные взгляды на структуру декомпозиции работ должны поддерживаться в проекте (взгляд руководителя проекта, взгляд куратора, взгляд инвестора и т.д.).
Если требуется декомпозиция по нескольким различным основаниям, должно быть указано главное (обычно – это взгляд руководителя проекта). Для поддержки остальных взглядов должны быть определены соответствующие классификационные признаки, описываемые как характеристики детальных работ. В качестве таких признаков могут использоваться, например, код проекта, код договора, код субподрядчика и т.д.
План управления проектом и рамочные стандарты Кому-то может показаться, что создать шаблон плана управления проектом достаточно просто, надо только иметь под рукой «рамочные»
стандарты, например PMBoK и ISO 10006, и разбираться в предметной области. На самом деле это совсем не так. В большинстве случаев рамочный стандарт дает лишь понятийный аппарат и общие методологические принципы. Более того, дело осложняется еще и тем, что необходимая информация в самих рамочных стандартах «рассыпана» по разным разделам и ее не так-то просто «собрать, выстроить, и привести к общему знаменателю».
Таким образом, на основе «рамочной» методологии должна быть создана методология «корпоративная», в которой основные положения, требования, принципы и практики управления проектами конкретизированы и систематизированы применительно к управлению проектами на данном предприятии на основе анализа конкретной специфики выполняемых предприятием проектов.
Эта корпоративная методология и специализированные шаблоны документов и составляют существо стандарта управления проектами уровня предприятия. А процесс создания стандарта напоминает спираль, на каждом новом витке которой методики становятся все более специализированными, а шаблоны – все более детализированными.
Проектные отклонения. Риски, проблемы, изменения Прежде всего, поясним термин «отклонения», это необходимо, поскольку в литературе по управлению проектами он трактуется неоднозначно.
Срочность Уже планируя проект, предполагают, что не все получится именно так, как запланировано. И реальное исполнение проекта, как правило, подтверждает эти опасения. Возникающие несовпадения первоначального согласованного и зафиксированного представления о проекте (project baseline) и того, что получается в действительности, и называются обычно отклонениями. Понимаемый в этом смысле термин «отклонения» эквивалентен термину «deviations», используемому в англоязычной литературе.
Вместе с тем в англоязычной литературе принят и другой термин – «exceptions», который в русских изданиях также переводится как «отклонения». Этим термином обозначают не только несовпадение фактических и плановых результатов, но и причины этих несовпадений, а также методы и технологии (exceptions management), позволяющие справляться с такими ситуациями в проекте с минимальными потерями. Именно эту более широкую трактовку мы и будем иметь в виду в дальнейшем, говоря об отклонениях.
К традиционным областям управления проектами, так или иначе связанным с отклонениями, относятся риски, проблемы и изменения. И хотя не во всех стандартах эти понятия объединяются общим понятием отклонения, наличие взаимосвязей между ними очевидно. Понимание этих связей и адекватное отражение их в стандарте управления проектом поможет не только правильно выстроить процедурную и документарную части стандарта, но и, что еще более важно, обеспечит возможность систематического контроля и анализа отклонений как в отдельном проекте, так и в масштабах предприятия в целом.
Управление отклонениями в основном сводится к борьбе с неприятностями, которая в общем случае может включать три стадии:
Управление рисками. Неприятности еще не наступили, но существует возможность возникновения нежелательных и незапланированных событий, которые могут привести к тому, что цели проекта (одна или несколько) не будут достигнуты. Цель этой стадии – предотвратить неприятности до их возникновения или, по крайней мере, встретить их во всеоружии.
Управление проблемами. Неприятности наступили и необходимо выяснить их происхождение, степень влияния на проект, способы преодоления. Цель этой стадии – обеспечить проекту возможность идти так, как запланировано.
Управление изменениями. Неприятности оказались достаточно серьезными, и справиться с ними без ущерба для проекта не удалось. Цель этого этапа – то, что у финансистов называется «зафиксировать убытки» – модификация ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, управленческих и технологических процессов и т.п.
По мнению некоторых ученых, изменения носят не всегда отрицательный характер и связаны с неприятными событиями, так как к рискам относятся также и желательные, но незапланированные события (возможности). Например, уменьшение учетной ставки процента создает дополнительные возможности для финансирования проекта. Однако в данном пособии мы будем рассматривать только отрицательные отклонения.
Полному циклу управления отклонениями соответствует первый сценарий, при котором:
в ходе планирования проекта был идентифицирован риск, но работа с ним не привела к желаемому результату;
возникшая в результате наступления рискового события проблема также не была успешно решена;
и все это в результате привело к необходимости внесения изменений в план проекта.
Для сравнения рассмотрим второй сценарий, при котором изменения в проекте реализуют, не дожидаясь возникновения проблем. Это достаточно ответственное решение. Ситуации, когда такие решения оправданны, могут быть описаны в стандарте с указанием конкретных категорий рисков и количественных оценок рисков, при которых должен быть реализован данный сценарий.
Особый интерес с точки зрения анализа отклонений представляют четвертый и пятый сценарии, соответствующие случаю возникновения проблем, неучтенных в качестве рисков. Причиной этого может быть, например, нетипичность ситуации или просто «потеря» риска в результате недостатка квалификации. Результатом анализа причин и тяжести последствий может явиться решение о том, что для определенных категорий проектов предприятия вообще нецелесообразно глубоко заниматься управлением рисками, а достаточно просто решать проблемы по мере их возникновения, в то время как для других категорий проекта наоборот необходимо резко усилить работу с рисками.
По нашему мнению, риски, проблемы, отклонения должны рассматриваться в одном разделе по управлению отклонениями, так как это явления одного порядка. В связи с этим необходимо, чтобы они были должным образом прописаны в частных процессах управления рисками, проблемами и изменениями, к рассмотрению которых мы и переходим.
Рис. 3.4. Структура и функции служб, обеспечивающих Самое простое и вместе с тем необходимое, что должно быть отражено в стандарте, – формальная сторона управления рисками, а именно:
1. Процедуры, регламентирующие основные этапы работы с рисками – идентификация рисков, мониторинг и анализ рисков, разработка, планирование и реализация мероприятий по противодействию рискам.
2. Шаблоны документов, отражающих процесс работы с рисками, – карточка риска, журнал рисков проекта и т.д.
Из всего многообразия методов управления рисками для стандарта должны быть отобраны те из них, которые адекватны проектам, в которых они будут применяться. Здесь мы имеем в виду, прежде всего, стоимость реализации управленческих процедур.
Так, при анализе рисков может допускаться сознательное огрубление оценок для каких-то конкретных категорий проектов, например, для проектов малой стоимости или сложности. Пример такого подхода приведен в табл. 3.3, где в качестве обобщенной оценки риска используется степень угрозы риска, «вычисляемая» через вероятность наступления рискового события и его влияния на ход проекта.
на проект Слабое Возможно появление вопросов или проблем в проекте, но вряд ли приведет к нарушению календарного графика, бюджета или ухудшению качества продукта Среднее Возможно нарушение графика, увеличение стоимости или ухудшение качества продукта Сильное Возможно значительное нарушение графика, увеличение стоимости или ухудшение качества продукта «Цена деления» на вспомогательной (вероятность и влияние) и на основной (степень угрозы) шкалах должна определяться из сугубо практических соображений – достижима ли та или иная точность и может ли она быть использована.
То, каким образом будет происходить управление отклонениями в проекте, определяется принятыми стратегиями работы с рисками. Например, можно делать все для избежания риска, и тогда наиболее вероятным является второй сценарий, а можно наоборот, принять риск и не противодействовать ему, допуская развитие событий по первому или по третьему сценарию. Возможно также снижать риск, и тогда при благоприятном развитии событий реализуется самый желанный сценарий, когда рисковое событие не наступает.
Сначала необходимо определить, что называют проблемами и почему проблемами можно (и нужно) управлять.
Рис. 3.5. Программная архитектура системы управления проектами Под проблемой в проекте понимается любой функциональный, технический или связанный с бизнесом вопрос, который возник в процессе осуществления проекта и требует ответа – изучения и решения, для того, чтобы проект мог идти так, как запланировано. Другими словами – проблема, это исключительные обстоятельства, которые должны быть под контролем (то есть управляемы) с момента их возникновения.
Проблемы можно разделить на две категории: проблемы, которые могут быть решены в месте возникновения, то есть на уровне управления проектом – problems, и эскалируемые проблемы – issues, которые для их решения требуется поднять на верхние уровни управления, в том числе внешние по отношению к проекту.
В стандарте должна быть отражена формальная сторона управления проблемами:
Процедуры, регламентирующие основные этапы работы с проблемами, – выявление проблемы, мониторинг и анализ проблемы, принятие решения и его исполнение, закрытие проблемы.
Шаблоны документов, отражающих процесс работы с проблемами – карточка проблемы, журнал проблем проекта и т.д.
Для анализа проблем могут разрабатываться специальные таблицы решений. Например, для определения такой важнейшей характеристики проблемы, как приоритетность ее решения, может использоваться матрица приоритетов.
Документы в проектах телекоммуникационной компании (пример) Специализация процедур управления ИТ-проектом Процедуры управления по временным и стоимостным параметрам Современная организация способна существовать и успешно конкурировать на рынке лишь при условии постоянного развития и адаптации под изменяющиеся условия ведения бизнеса. А это означает, что руководство компании, планируя и достигая определенные цели, постоянно сталкивается с соответствующими управленческими проблемами.
Анализируя работу любой организации, практически всегда можно выделить два вида деятельности, которые существуют параллельно: текущие, повторяющиеся без изменения операции и проекты, направленные на достижение определенных целей в рамках временных и бюджетных ограничений [3], характеризуемые уникальностью и привлечением большого количества специалистов в различных сферах деятельности.
Данные характеристики проектов накладывают огромную ответственность на деятельность проектно-ориентированных компаний и подчеркивают целесообразность применения ими методологии управления проектами, получившей широкое распространение на Западе.
Применение формализованных методов управления проектами позволяет более обоснованно определять цели инвестиций и оптимально планировать инвестиционную деятельность, более полно учитывать проектные риски, оптимизировать использование имеющихся ресурсов и избегать конфликтных ситуаций, контролировать исполнение составленного плана, анализировать фактические показатели и вносить своевременную коррекцию в ход работ, накапливать, анализировать и использовать в дальнейшем опыт реализованных проектов. Таким образом, система управления проектами (СУП) является одним из важнейших компонентов всей системы управления организацией [3, с. 81].
Внедрение СУП предприятия обеспечивает принятие обоснованных и проверенных решений, позволяет исполнять проекты быстрее, качественнее и с меньшими затратами, а также всегда иметь самую полную и разнообразную информацию о реализуемых проектах.
СУПП состоит из трех основных блоков – субъекты управления, объекты управления, процессы управления.
В качестве субъектов управления нами рассматриваются все активные участники проекта, взаимодействующие при выработке и принятии управленческих решений (управленческий и технический персонал предприятия, выделенный для выполнения проекта).
Источник: http://www.ellips.ru/publication?show_id= План внедрения системы управления проектами 1. Диагностика предприятия.
1.1. Определение участников проекта.
1.2. Анализ проектной деятельности Компании:
Структура проектов Компании.
Классификация проектов.
Специфические области.
1.3. Анализ процессов проектной деятельности:
Процессы инициации проектов.
Процессы планирования проектов.
Процессы контроля проектов.
Процессы завершения проектов.
1.4. Анализ организационной структуры.
1.5. Анализ информационной системы.
1.6. Анализ специфики предметной области.
2. Разработка модели СУП.
2.1. Разработка концепции управления проектами:
Основные параметры и результаты.
Стратегия реализации и развития.
Объем и средства автоматизации.
Структура стандарта.
2.2. Разработка корпоративной методики управления проектами:
Укрупненные процедуры управления проектами.
Технологии и методологии.
Перечень управленческих документов.
2.3. Разработка операционного стандарта управления проектами:
Детальные процедуры управления.
Должностные и технологические инструкции.
Шаблоны управленческих документов.
3. Пилотный проект.
3.1. Разработка архитектуры решения информационной СУП согласно определенным требованиям.
Настройка модулей системы в соответствии с требованиями и выбранной архитектурой по функциям:
календарное планирование проектов;
контроль сроков и объемов выполнения работ;
планирование и контроль использования ресурсов по проектам;
прогнозирование сроков и объемов работ по проектам;
информационный обмен между участниками проектов.
Настройка модулей информационной системы для обеспечения корпоративной работы.
Настройка модулей дополнительной системы в соответствии с требованиями и выбранной архитектурой по функциям:
формирование бюджетов проектов;
анализ отклонения бюджетов проектов по методу фактической прогнозирование затрат;
создание аналитических и агрегированных отчетов для различных уровней управления.
Настройка связки основной системы и дополнительных:
интеграция календарного плана работ и затрат на протяжении всего жизненного цикла проекта;
обеспечение целостности данных.
Настройка связки систем с существующими информационными системами в Компании:
интеграция на уровне ввода фактических данных;
разработка консолидированной отчетности.
Разработка шаблонов входных форм информации в систему и отчетов для контроля проектов.
Настройка рабочих мест пользователей и разработка инструкций.
Опытная эксплуатация ИСУП на пилотных проектах.
Внедрение.
Проведение обучения групп работе с ИСУП в соответствии с основными ролями участников проектов.
Разработка концепции развития СУП.
Объектами управления являются:
папка проектов – совокупность проектов предприятия, организованная в иерархическую структуру;
темпапка – совокупность проектов предприятия, организованная в иерархическую структуру по тематическому признаку;
проект – комплекс взаимосвязанных мероприятий, предназначенных для достижения поставленных целей с установленными требованиями по бюджету, ресурсам в течение заданного времени;
стадии жизненного цикла проекта (этапы) – логически взаимосвязанные работы проекта, в процессе завершения которых достигается один из основных результатов проекта.
Процессы управления проектами разбиты на пять групп:
1) процессы инициирования – обеспечение принятия решения, распознавание (понимание) того, что определенный проект должен начаться и необходимо вовлечение ресурсов в его выполнение;
2) процессы планирования – создание и поддержание работоспособной схемы достижения цели, ради которой был предпринят проект;
3) процессы исполнения – координация различного рода ресурсов для выполнения плана проекта;
4) процессы контроля – проверка достижения поставленных целей путем отслеживания и измерения прогресса и осуществление корректирующих действий при необходимости;
5) процессы завершения – формализация приемки результатов проекта и приведение проекта к соответствующему концу [2].
Внедрение системы управления проектами должно проводиться поэтапно и быть тщательно спланировано [3, с. 101]. Пример плана внедрения системы управления проектами на предприятии представлен в форме Устава (см. приложение).
Переход на современные средства управления проектами на предприятии не может быть осуществлен без создания или модернизации имеющегося стандарта управления проектами.
Стандарт управления проектами предприятия – совокупность документов, объясняющих или предписывающих, как, в какой последовательности, в какие сроки, с использованием каких шаблонов нужно выполнять те или иные действия в процессе управления проектами [1, с. 45].
Стандарты управления проектами уровня предприятия в части методологии обычно имеют основу, определяемую документами достаточно общего характера (иногда эти документы называют «рамочными»). К таким документам относится Project Management Body of Knowledge (PMBoK) Американского института управления проектами (PMI), признаваемый международным стандартом де-факто, и стандарт ISO 10006:1997, придавший ряду наиболее важных положений PMBoK статус стандарта деюре. Смысл и содержание перехода от рамочных стандартов (это и PMBoK, и в еще большей степени ISO 10006) к стандарту предприятия состоит в их специализации и детализации.
Специализация означает включение в стандарт предприятия тех и только тех положений, которые имеют отношение к проектной деятельности именно на этом предприятии и в привязке к его реалиям. Прежде всего, из этого следует, что такие реалии должны быть четко определены, а определять реалии надо в четко сформулированных понятиях, измеримых показателях и т.п. В связи с этим стандарт предприятия неизбежно должен содержать описание и классификацию проектов компании.
Организационные структуры и персонал проекта также являются предметом специализации. В стандарте предприятия могут не только фиксироваться проектные роли (руководитель проекта, администратор, менеджер по качеству и т.д.), но и определяться структура и принципы формирования органов управления проектами [1, с. 43-44].
Рис. 3.7. Структура управления интеграцией Предметом описания в стандарте могут быть также типовые ситуации, характерные для проектов предприятия, и рекомендации менеджерам по реагированию на эти ситуации, то есть своеобразные таблицы решений, что-то вроде списка возможных неисправностей и рекомендаций по их устранению. Конечно, решение все равно будет принимать менеджер, но у него перед глазами будет обобщенный опыт предыдущих поколений.
Предметом специализации, безусловно, являются и процессы управления проектами. Собственно, описание этих процедур и составляет основной объем стандарта. Количество этих документов зависит от степени детализации стандарта и может быть достаточно велико (от десятков до сотен документов). На рисунке они представлены в виде пирамиды, которая обычно выстраивается сверху вниз по мере развития стандарта [1, с. 45].
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Баранов С. Н. Управление программным проектом: Лекции по спецкурсу «Технология программирования» [рукопись]. – СПб.: СанктПетербургский государственный электротехнический университет, 2. Брукс Ф. Мифический человеко-месяц, или как создаются программные системы. – СПб.: Символ-Плюс, 1999.3. Димитриев Д.В., Димитриева З.М. Управление проектами – практическое руководство. – М.: Юркнига, 2003.
4. Клиффорд Грей Ф., Ларсон Эрик У. Управление проектами. – М., 5. Британский стандарт BS 6079-2:2000 Project management Part Vocabulary.
6. Мазур И.И., Шапиро В.Д., Ольдерогге Н.Г. Управление проектами. – М., 2004.
7. Михеев В.Н., Товб А.С. Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов // Сб. трудов 2-й Всероссийской практической конференции «Стандарты в проектах современных информационных систем». – М., 2002. – С. 33-37.
8. Основы профессиональных знаний и национальные требования к компетентности специалистов по управлению проектами / Под ред.
В.И. Воропаева. – М., 2001.
9. Либерзон В.И. Основы управления проектами. – М.: Олимп-Бизнес, 10. Полковников А.В. Корпоративная система управления проектами.
Электронный офис, 1997, октябрь.
11. Товб А.С., Ципес Г.Л. Метод и опыт создания предприятия по управлению ИТ-проектами // Сб. трудов 2-й Всероссийской практической конференции «Стандарты в проектах современных информационных систем». – М., 2002. – С. 42-47.
12. Товб А.С., Ципес Г.Л. Заметки по управлению проектами. Стандарт управления проектами уровня предприятия // Директор информационной службы. – 2001. – №№ 1-6; 2002. – №№ 1-6.
13. Товб А.С., Ципес Г.Л. Управление проектами: стандарты, методы, опыт. – М.: Олимп-Бизнес, 2003.
14. Управление проектами: Справочник для профессионалов / Под ред.
И.И. Мазура и В.Д. Шапиро. – СПб., 2001.
15. Управление программами и проектами. 17-модульная программа для менеджеров «Управление развитием организации». Модуль 8.
М.Л. Разу, В.И. Воропаев и др. – М., 1999.
16. Йордон Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. – М.: ЛОРИ, 2001.
17. Conger, Sue A. The New Software Engenering. Wadsworth Publishing Company, 1994.
18. Pierre N. Robillard, Martin P. Robillard. Types of collaborative work in software engineering. // The Journal of Systems and Software 53, 2000, p. 219-224.
19. Rob Thomsett. Effective Project Teams: A Dilemma, a Model, a Solution.
American Programmer, July-August 1990.
20. Vliet H.V. Software Engineering: Principles and Practice. Join Wiley and Sons, 2000.
21. C. William Ibbs, Young-Hoon Kwak. The benefits of Project Management:
financial and organizational rewards to corporations. – Project Management Institute Education Foundation, 1997.
22. Wideman Comparative Glossary of Project Management Terms.
PMForum, 2000 (www.maxwideman.com).
23. A Guide to the Project Management Body of Knowledge. PMI Standards Committee.1996 Edition (используется перевод М. Грашиной).
24. Quality Management for Projects and Programs, Lew Ireland, Project Management Institute, Newtown Square, PA, 1991. (Цитируется по [MW], перевод авт.) 25. http://www.iteam.ru/publications/project/section_41/article_679/ 26. http://www.pmpractice.ru/knowledgebase/normative/ 27. ISO/TR 10006: 1997 (E). Quality Management – Guidelines to quality in project management (используется перевод Г.Е. Герасимовой).
28. http://www.iteam.ru/module/images/1608275842.gif ПРИЛОЖЕНИЕ
КОРПОРАТИВНЫЙ СТАНДАРТ
ПО УПРАВЛЕНИЮ ПРОЕКТАМИ
Положение о КСУП, или корпоративный стандарт по управлению проектами (далее – корпоративный стандарт), будет рассматриваться в качестве документа верхнего уровня в структуре внутренней нормативной документации, регламентирующей управление проектами в компании.Следует заметить, что в практике встречаются и другие трактовки корпоративного стандарта по управлению проектами.
В некоторых компаниях под корпоративным стандартом понимают совокупность документов, регламентирующих и обеспечивающих управление проектами.
В других – для управления проектами разрабатывают несколько корпоративных стандартов одного уровня, регламентирующих различные аспекты управления проектами. Такой подход, к примеру, был принят в отношении инвестиционных проектов в управляющей компании одной из известных финансово-промышленных групп.
Подходы, описанные во втором и третьем случае, по нашему мнению, имеют определенные недостатки.
Под корпоративным стандартом обычно понимается один документ.
Поэтому подобное название для совокупности документов представляется не вполне корректным и может дезориентировать тех, кто занимается разработкой корпоративной методологии управления проектами.
Разработка нескольких корпоративных стандартов одного уровня для управления теми же инвестиционными проектами может привести к созданию фрагментарной методологии. В этом случае определенные процессы и процедуры управления проектами могут быть пропущены или описаны и регламентированы в разных форматах, разными средствами в соответствии с опытом и субъективными представлениями об управлении проектами, имеющимися у разработчиков документов. Интегрировать несколько разных стандартов в единую методологию будет весьма затруднительно.
Разработке корпоративного стандарта может предшествовать создание концепции управления проектами в компании.
Создавать концепцию целесообразно по той причине, что для успешной разработки и внедрения корпоративной методологии управления проектами необходимо, чтобы собственники и руководители высшего уровня договорились между собой и согласовали свое видение и свои требования и ожидания относительно КСУП. Концепция как раз и создает хорошую основу для согласования позиций и достижения принципиальных договоренностей между лицами, принимающими ключевые решения по управлению проектами в компании.
Предназначение корпоративного стандарта по управлению проекта, по нашему мнению, заключается в том, чтобы описать саму КСУП, принципы ее построения, основные элементы, а также подход к управлению проектами, принятый в компании.
В корпоративный стандарт целесообразно включать следующие разделы:
назначение и область применения стандарта;
нормативные ссылки;
определения терминов, обозначения и сокращения;
принципы организации системы управления проектами в компании;
классификация проектов компании;
процессы управления проектами в компании;
организационная структура управления проектами;
распределение функций, полномочий и ответственности в рамках системы управления проектами компании (уровни портфеля, программ, проектов);
нормативная база управления портфелем, программами и проектами;
ведение реестра проектов;
назначение приоритетов проектов;
документирование и архивирование проектов;
информационная система управления проектами;
порядок внесения изменений в стандарт;
приложения (шаблоны основных рабочих документов).
УСТАВ ПРОЕКТА (PROJECT CHARTER)
1. Предназначение документа. Устав проекта предназначен для определения проекта. На фазе инициализации он включает в себя:документирование бизнес-потребностей (проблем, возможностей) и общее описание продуктов или услуг, удовлетворяющих данные потребности;
связи проекта с текущей (операционной) деятельностью организации.
2. Когда разрабатывается документ: после заключения контракта (если заключается контракт с внешним контрагентом).
3. Кто разрабатывает документ. Устав проекта могут разрабатывать:
менеджер проекта или команда проекта;
представитель внешней стороны, связанной с проектом.
4. Кто утверждает документ. Устав проекта может утверждать:
представитель внешней стороны, связанной с проектом.
Лицо, утверждающее Устав проекта, должно иметь полномочия по принятию основных решений по проекту, включая его финансирование.
5. Входы (исходные данные) для разработки документа:
документ определения работ (Statement of work);
факторы внешнего окружения и организационной среды;
организационные активы (Organizational process assets).
6. Содержание документа: Устав проекта непосредственно включает в себя следующие данные или ссылки на соответствующие документы:
Бизнес-потребности или требования к продукту, который будет Цель проекта или основание для разработки проекта (justification).
Потребности и ожидания заинтересованных лиц (stakeholders).
Укрупненное расписание контрольных событий.
Влияние заинтересованных лиц на проект.
Распределение функций (functional organizations).
Предположения, связанные с внешним окружением и внутренней организационной средой.
Ограничения, связанные с внешним окружением и внутренней организационной средой.
Бизнес-обоснование проекта, включающее возврат на инвестиции (ROI).
7. Порядок изменений документа: Команда проекта поддерживает Устав проекта в актуальном состоянии, получает обратную связь от участников проекта о необходимых улучшениях документа, контролирует изменения и выпускает релизы утвержденного документа.
ПРИМЕРЫ УСТАВОВ ПРОЕКТОВ КОМПАНИЙ
Пример 1. УСТАВ ПРОЕКТА (международная компания, занимающаяся производством компьютерной техники, разработкой программного обеспечения и проектами в сфере системной интеграции).Примечание: В материалах данной компании специально подчеркивается, что данный документ не является Планом проекта, хотя включает в себя даты, к которым нужно стремиться в рамках проекта.
Данный документ – Устав проекта – уточняется/изменяется и утверждается заново на каждой из стадий: на стадии предложения, на стадии исполнения (после подписания контракта).
СОДЕРЖАНИЕ:
1. ОБЗОР УСТАВА ПРОЕКТА
2. ОРГАНИЗАЦИЯ ПРОЕКТА
2.1. Менеджер Проекта по интегрированию систем 2.2. Привлеченная команда по системному интегрированию 2.3. Роли и обязанности 2.4. Полномочный орган по финансированию Проекта 2.5. Комитет спонсоров Проекта 2.6. Комитет директоров Проекта3. КРАТКОЕ ИЗЛОЖЕНИЕ ТРЕБОВАНИЙ ПО СИСТЕМНОМУ
ИНТЕГРИРОВАНИЮ
3.1. Обзор системного интегрирования 3.2. Определение потребности в системном интегрировании 3.3. Содержание и цели системного интегрирования 3.4. Факторы и риски, влияющие на системное интегрирование4. КРАТКИЕ СВЕДЕНИЯ ПО ПРОЕКТУ
4.1. Описание 4.2. Процессы Проекта5. ДЕЯТЕЛЬНОСТЬ ПО ИНТЕГРИРОВАНИЮ СИСТЕМЫ И
ПОСТАВЛЯЕМЫЕ ПОЗИЦИИ
5.1.1. Работы Этапа I 5.1.2. Поставляемые позиции Этапа I 5.1.3. Работы Этапа II 5.1.4. Поставляемые позиции Этапа II 5.1.5. Работы этапа III 5.1.6. Поставляемые позиции Этапа III 5.1.7. Работы Этапа IV 5.1.8. Поставляемые позиции Этапа IV 5.1.9. Работы Этапа V 5.1.10. Поставляемые позиции Этапа V6. ГРАФИКИ ХОДА ПРОЦЕССОВ
7. ДОКУМЕНТАЦИЯ Пример 2. УСТАВ ПРОЕКТА (международная компания, занимающаяся разработкой и внедрением информационных систем).СОДЕРЖАНИЕ:
1. ВВЕДЕНИЕ 1.1. Назначение данного документа 1.2. Изменения данного документа 2. ОПРЕДЕЛЕНИЕ
ПРОЕКТА
4. ОРГАНИЗАЦИЯ И УПРАВЛЕНИЕ ПРОЕКТОМ
4.1. Организационная структура Проекта 4.2. Распределение ролей участников Проекта 4.2.1. Спонсор Проекта 4.2.2. Управляющий Совет 4.2.3. Председатель Управляющего совета 4.2.4. Руководители Проекта 4.2.5. Группа внедрения 4.2.6. Состав группы внедрения 4.3. Документооборот Проекта 4.3.1. Общие документы 4.3.2. Отчетные документы 4.3.3. Рабочие документы 4.3.4. Периодичность подготовки отчетной документации 4.4. Процедура решения проблем 4.5. Подход к управлению изменениями рамок Проекта5. ЗАВЕРШЕНИЕ ПРОЕКТА
ПРИЛОЖЕНИЕ 1 – ДЕКЛАРАЦИЯ ЦЕЛЕЙ ВНЕДРЕНИЯ ИИСУ НА
ОАО «ХХХ»
ПРИЛОЖЕНИЕ 2 – СПИСОК ФУНКЦИЙ АВТОМАТИЗИРУЕМЫХ
ПОДРАЗДЕЛЕНИЙ.
ПРИЛОЖЕНИЕ 3 – ФОРМА РЕГИСТРАЦИИ ПРОБЛЕМЫ
ПРИЛОЖЕНИЕ 4 – ЖУРНАЛ РЕГИСТРАЦИИ ПРОБЛЕМ
ПРИЛОЖЕНИЕ 5 – ИНДИВИДУАЛЬНЫЙ ОТЧЕТ О
ПРОРАБОТАННОМ ВРЕМЕНИ
ПРИЛОЖЕНИЕ 6 – ОТЧЕТ РУКОВОДИТЕЛЯ ПРОЕКТА
ПРИЛОЖЕНИЕ 7 – РЕГУЛЯРНЫЙ ОТЧЕТ О СОСТОЯНИИ
ПРОЕКТА
ПРИЛОЖЕНИЕ 8 – ОТЧЕТ О РЕЗУЛЬТАТАХ ЭТАПА.
Пример 3. УСТАВ ПРОЕКТА (Российская компания – системный интегратор).
СОДЕРЖАНИЕ
1. ПРОФИЛЬ КОМПАНИИ 1.1. Сфера деятельности 1.2. Адрес компании 1.3. Контактные лица 1.4. Сотрудники2. ЦЕЛИ И ОПРЕДЕЛЕНИЕ ПРОЕКТА
3. ПЛАН ПРОЕКТА4. СТРУКТУРА ПРОЕКТА
4.1. Организационная структура Проекта 4.2. Ключевые роли и ответственность 4.3. Процедуры встреч и подготовки отчетов о состоянии Проекта 5. РИСКИ ПРОЕКТА6. ПЛАН ОБУЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
7. КОНТРОЛЬ ИЗМЕНЕНИЙ И ПРОЦЕДУРЫ ПРИЁМКИ РАБОТ
7.1. Управление изменениями 7.2. Процедуры тестирования и приемки работ 7.3. Статус и состав приемочной комиссии 7.4. Передача в опытную эксплуатацию8. ЛИСТ СОГЛАСОВАНИЙ
УПРАВЛЕНИЕ ПРОЕКТАМИ
Подписано в печать 12.09.12. Формат 60х84 1/16.Усл. печ. л. 5,25. Тираж 70 экз. Заказ 424. РТП изд-ва СПбГУЭФ.
Издательство СПбГУЭФ. 191023, Санкт-Петербург, Cадовая ул., д. 21.
«