Преподаватель который помогает студентам и школьникам в учёбе.

Стандарты управления проектами(Общие соображения по созданию стандарта. Специализация и детализация)

Содержание:

ВВЕДЕНИЕ

Часто даже определение проекта включает слова об уникальности, не повторении целей, условиях реализации и результатах проекта. Поскольку это действительно так, что может быть стандартизировано в управлении проектами? И если это возможно, нужно ли это? Будет ли это не только мешать, сковывать инициативу, навязывать неправильные решения? Если западные менеджеры отдают приоритет психологическим аспектам управления и искусству построения межличностных отношений в проекте, то их отечественные коллеги предпочитают процедурный подход. Это действительно так (по крайней мере, в отношении российских менеджеров) и означает, что работа в рамках определенных ограничений и стандартов не только знакома нашим менеджерам (напомним хотя бы советские ГОСТы), но и вполне комфортна. А что тогда с менеджментом компании, для которого наличие и внедрение таких стандартов означает гарантированный уровень качества реализации проекта?

И, наконец, тот факт, что практика создания собственных методологий и руководств по управлению проектами широко распространена в крупных западных компаниях, таких как Oracle, IBM, PricewaterhouseCoopers, Andersen Consulting, SAP AG, Siemens и т. д. Все эти соображения представляют интерес, которые побудил меня рассмотреть эту тему.

ГЛАВА 1. ОБЩИЕ СООБРАЖЕНИЯ ПО СОЗДАНИЮ СТАНДАРТА ДЛЯ ПРОЕКТА. СПЕЦИАЛИЗАЦИЯ И ДЕТАЛИЗАЦИЯ

1.1 Стандарт управления проектом организационный

Стандарты управления проектами предприятия с точки зрения методологии обычно имеют основу, определяемую документами довольно общего характера (иногда эти документы называют «рамочными»). К ним относятся Свод знаний по управлению проектами (PMBoK) Американского института управления проектами (PMI) и ISO 10006: 1997. Значение и содержание перехода от рамочных стандартов (которые являются как PMBoK, так и в еще большей степени ISO 10006) Стандарт предприятия заключается в их специализации и уточнении^[1].

Специализация означает включение в стандарт предприятия тех и только тех положений, которые имеют отношение к проектной деятельности на данном конкретном предприятии и в отношении реалий этого предприятия. Прежде всего следует, что такие реалии должны быть четко определены. Что ж, реалии должны быть определены в четко определенных терминах, измеримых показателях и т. д. В этом отношении стандарт предприятия должен неизбежно содержать описание и классификацию проектов компании.

Проекты компании могут относиться к различным профессиональным сферам деятельности (юридическая, финансовая, ИТ, строительство, маркетинг и т. д.), иметь разную сложность с точки зрения решаемых задач, разный масштаб с точки зрения привлеченных ресурсов и ожидаемых результатов. Можно выделить несколько категорий проектов, которые являются специфическими с точки зрения конкретных отраслей. Например, стандарт компании Enron, которая в то время специализировалась на электроэнергетике, отдельно рассматривал международные проекты как налагающие особые требования на правовую базу, персонал, оборудование, экономическую инфраструктуру, логистику и т. д.

Организационные структуры и персонал проекта также подлежат специализации. Стандарт предприятия может не только фиксировать стандартные роли проекта (руководитель проекта, администратор, менеджер по качеству и т. Д.), но и определять структуру и принципы формирования органов управления проектами. Примером такой специализации является двухуровневая структура управления в проектах по внедрению ERP-систем^[2].

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

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

Предметом специализации, безусловно, являются процессы управления проектами. Общий набор возможных процессов может быть представлен в виде трехмерного пространства, показанного на рис. 1. Вдоль координатных осей упоминаются те измерения, которые упомянуты в стандартах каркаса, и другие могут быть предложены, например, контроль уровни, календарные периоды. Каждая точка этого пространства представляет элементарный процесс управления. Например, «планирование рисков на этапе внедрения системы».

Рис. 1. Пространство процессов управления

Выбранные элементарные процессы формируют процедуры управления проектом, которые могут быть построены по «осевому» принципу (здесь мы имеем в виду абсциссу, ординату и аппликацию, обозначенные на рис. 1)^[4].

Фактическое описание этих процедур составляет основную часть стандарта. А если быть более точным, под стандартом предприятия мы подразумеваем набор документов, объясняющих или предписывающих, как, в какой последовательности, в какое время, с использованием каких шаблонов вам необходимо выполнять определенные действия в процессе управления проектами. Количество этих документов зависит от степени детализации стандарта и может быть довольно большим (от десятков до сотен документов). На рис. 2 они представлены в виде ступенчатой пирамиды, которая обычно строится сверху вниз, когда пробуждается аппетит для тех, кто организует и регулирует работу на предприятии, и соответствующую стандартную разработку.

Типичные ситуации, специфичные для корпоративных проектов, и рекомендации руководителям о том, как реагировать на эти ситуации, также могут быть описаны в стандарте. Это своего рода таблица решений, что-то вроде списка возможных неисправностей и рекомендации по их устранению (контрольный список). Конечно, менеджер все равно примет решение, но на его глазах у него будет обобщенный опыт («сын трудных ошибок») предыдущих поколений^[5].

Рис. 2. Структура стандарта управления проектами

1.2 Классификация проектов как первый шаг в создании стандарта

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

Среди западных коллег широко распространено мнение, что профессиональный менеджер проекта может успешно реализовать любой проект, независимо от того, к какой области он относится - от строительства атомной электростанции до разработки программного обеспечения. Возникают вопросы: сколько времени нужно и есть ли такой запас? Сколько консультантов нужно и какой квалификации? Сколько нам будет стоить один такой руководитель проекта и сколько будут стоить дополнительные расходы?

Это особенно важно для предприятий, реализующих комплексные проекты, охватывающие различные предметные области. Типичным примером, в котором необходимость привлечения «универсального» менеджера проекта и способы снижения стоимости его «сопровождения» в равной степени очевидны, является проект создания отделения банка. Такой проект включает в себя ряд взаимосвязанных и в то же время относительно независимых подпроектов: юридический, строительный, технологический, ИТ, рекрутинг, маркетинг и т. д. В крупных банках создаются десятки филиалов. После одного или двух таких проектов опыта их реализации может быть достаточно для формулирования типичных целей и результатов для каждого типа проекта (подпроекта), типовых календарных и ресурсных планов и бюджета, выявления известных рисков и эффективных стратегий работы с ними и т. д^[6].

Но именно эта информация является сутью основного документа, с которого должен начинаться любой проект - плана управления проектом (в различных источниках можно найти другие названия для такого документа - устав проекта, определение проекта). Таким образом, могут быть подготовлены специализированные шаблоны для Плана управления проектом, в котором установлены очень специфические методы управления проектом, рекомендованные на данном предприятии для данного типа проекта. А после них и другие стандартные шаблоны.

Что должно быть отражено в плане управления проектом^[7]

Содержание и границы проекта - цели и задачи проекта, основные результаты, критерии оценки того, что работа или ее часть были выполнены.

Ключевыми этапами проекта являются основные события проекта (этапы) и план их достижения, возможно, с использованием структуры декомпозиции работ (СПП).

Бюджет проекта

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

Требования и стандарты - перечень нормативных и нормативных документов или их отдельных положений, которые необходимо соблюдать при реализации проекта.

Подходы к реализации проекта - концепция предлагаемого решения (возможны несколько альтернативных вариантов), методы разработки и базовые информационные технологии.

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

Управление проектной документацией - структура, среда хранения и порядок создания и ведения проектных документов, список шаблонов документов.

Управление отклонениями - процедуры по устранению рисков, возникающих проблем и изменений, формы соответствующих проектных документов.

Обеспечение качества - это перечень и регламенты для реализации мероприятий, направленных на обеспечение качества, как результатов проекта (продукта), так и процессов управления проектом и работы.

Мониторинг и отчетность - регламент реализации мероприятий по анализу состояния проекта, соответствующие формы отчетности.

Преимущества стандартных шаблонов очевидны - экономия на консультантах, унификация подходов, сокращение времени на подготовку проектной документации. Есть и недостатки, отметим здесь только два. Создание таких шаблонов является довольно трудоемкой задачей, и заранее неизвестно, будут ли они использоваться или нет. Это зависит от воли и настойчивости руководства предприятия. Во-вторых, есть опасение, что наличие таких шаблонов помешает инициативе и независимости руководителя проекта, и он не сможет адекватно реагировать на чрезвычайные ситуации. Нам кажется, что эти трудности не будут столь критичными, если шаблоны удобны, а их специализация и детали будут оптимальными для этого предприятия и его проектов. И это уже вопрос качества работы консультантов и аналитиков, которые создают стандарт^[8].

Сколько различных шаблонов планов управления проектами соответствуют стандарту? Чтобы ответить на этот вопрос, необходимо построить классификацию проектов, осуществляемых на предприятии. Более того, очевидно, что для каждого предприятия — это будет уникальная классификация. Собственно, создание такой классификации должно начинать создание стандарта.

Следует отметить, что вряд ли возможно построить единую древовидную классификацию корпоративных проектов. Скорее всего, это будет несколько классификаций по различным признакам, связанным с определенными разделами Плана. Давайте рассмотрим некоторые из них^[9]:

Классификация по предметным областям и по продуктам в этих областях позволяет специализировать разделы Содержание и границы, Ключевые этапы, Требования и стандарты. Эта классификация может быть построена на иерархической основе. Например, «информационные технологии» - «системная интеграция проектов» - «создание интегрированных систем управления проектами».

Классификация по масштабу проекта позволяет специализироваться по разделам Организационная структура, Управление отклонениями, Обеспечение качества. Для построения этой классификации могут использоваться различные основания - территориальная дисперсия, как это принято в Enron Corp., или стоимость проекта (IBM), возможно, некоторые другие основания и их комбинации.

Классификация по форме оплаты и, следовательно, учет работ позволяет специализировать Контроль и отчетность, Управление проектной документацией на основе таких форм договоров, как «Время и материалы» и «Фиксированная цена».

Приведенные выше примеры классификаций проектов специально отобраны, чтобы проиллюстрировать возможность сборки шаблона из относительно независимых стандартных фрагментов. Однако в реальной жизни бывают и другие ситуации. Например, IBM приняла классификацию проектов по сложности (сложности). В соответствии с этой классификацией проекты подразделяются на обычные бизнес-проекты (Business as Usual - BaU), стандартные проекты системной интеграции и сложные проекты системной интеграции. Более того, именно эта классификация является решающей для структуры и содержания Плана управления проектом. В то же время другие классификации сохраняют свое значение для формирования отдельных разделов Плана.

План управления проектом и рамочные стандарты^[10]

Кому-то может показаться, что создать шаблон для плана управления проектом довольно просто, вам просто нужно иметь под рукой «базовые» стандарты, например, PMBoK и ISO 10006, и понимать предметную область. На самом деле это совсем не так. В большинстве случаев базовый стандарт предоставляет только концептуальную основу и общие принципы. Более того, дело осложняется тем фактом, что необходимая информация в самих базовых стандартах «разбросана» по разным разделам, и не так просто «собрать, построить и привести к общему знаменателю».

Проиллюстрируем это на примере несложного раздела плана «Организационная структура проекта». В PMBoK необходимая информация разбросана по нескольким разделам (2.2; 2.3; 2; 4; 4.1.3; 9), а в ISO 10006: 1997 (E) - раздел 5.8. Но в обоих случаях этой информации недостаточно для создания специализированного шаблона!

Таким образом, на основе «рамочной» методологии должна быть создана «корпоративная» методология, в которой основные положения, требования, принципы и практики управления проектами определены и систематизированы в отношении управления проектами на данном предприятии на основе анализа. о специфике проектов, осуществляемых предприятием.

Эта корпоративная методология и специализированные шаблоны документов составляют сущность стандарта управления проектами на уровне предприятия. И процесс создания стандарта напоминает спираль, в каждом новом раунде которой методы становятся все более специализированными, а шаблоны становятся более подробными.

ГЛАВА 2. РАСЧЕТНЫЕ ОТКЛОНЕНИЯ. РИСКИ, ПРОБЛЕМЫ, ИЗМЕНЕНИЯ

Прежде всего, мы объясняем термин «отклонения», это необходимо, поскольку в литературе по управлению проектами это трактуется по-разному.

План управления проектом является «точкой опоры» или отправной точкой для всего последующего развития проекта. Однако, уже планируя проект, мы предполагаем, что не все получится именно так, как планировалось. И фактическое выполнение проекта, как правило, подтверждает эти опасения. Несоответствия первоначальной согласованной и фиксированной идеи проекта (базовой линии проекта) и того, что получается в действительности, обычно называют отклонениями^[11].

В то же время в английской литературе принят другой термин для отказа - «исключения», которые в русских изданиях также переводятся как отклонения. Этот термин означает не только несоответствие между фактическими и запланированными результатами, но также причины этих расхождений, а также методы и технологии (управление исключениями), которые могут справиться с такими ситуациями в проекте с минимальными потерями. Именно это более широкое толкование мы будем иметь в виду в будущем, говоря об отклонениях^[12].

Традиционные области управления проектами, так или иначе связанные с отклонениями, включают риски, проблемы и изменения. И хотя не все стандарты объединяют эти понятия с общей концепцией отклонения, наличие связей между ними очевидно. Понимание этих отношений и их адекватное отражение в стандарте управления проектами поможет не только правильно построить процедурную и документальную части стандарта, но, что более важно, даст возможность систематического контроля и анализа отклонений, как в отдельном проекте, и по всему предприятию в целом^[13].

Управление отклонениями в основном сводится к борьбе с неприятностями, которые в общем случае могут включать три этапа:

Управление рисками. Неприятностей еще не возникало, но есть вероятность нежелательных и незапланированных событий, которые могут привести к тому, что цели проекта (одна или несколько) не достигнуты. Цель этого этапа - предотвратить неприятности до их возникновения или, по крайней мере, встретить их полностью вооруженными.

Управление проблемами. Проблемы пришли, и необходимо выяснить их происхождение, степень влияния на проект и способы их преодоления. Цель этого этапа - предоставить проекту возможность идти в соответствии с планом. стандартная специализация проекта

Управление изменениями. Проблемы были довольно серьезными, и не смогли справиться с ними без ущерба для проекта. Целью этого этапа является то, что финансисты называют «фиксировать потери» - модификация ранее согласованных продуктов и услуг, сроки и стоимость работ, управленческие и технологические процессы и т. д.

2.1 Управление рисками

Самым простым и в то же время необходимым, который должен быть отражен в стандарте, является формальная сторона управления рисками, а именно:

Процедурами, регулирующими основные этапы работы с рисками, являются идентификация рисков, мониторинг и анализ рисков, разработка планирования и реализация мер по противодействию рискам.

Шаблоны документов, отражающие процесс управления рисками - карта риска, журнал рисков проекта и т. д.

Из всего множества методов управления рисками для стандарта следует выбирать те, которые соответствуют проектам, в которых они будут применяться. Здесь мы имеем в виду, прежде всего, стоимость внедрения процедур управления^[14].

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

2.2 Управление проблемами

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

Как правило, проблемы делятся на две категории - проблемы, которые могут быть решены на месте возникновения, то есть на уровне управления проектом - проблемы и обостренные проблемы - проблемы, которые необходимо поднять на более высокие уровни управления, включая внешние. отношение к проекту^[15].

Стандарт должен отражать формальную сторону управления проблемами^[16]:

Процедуры, регламентирующие основные этапы работы с проблемами - выявление проблемы, мониторинг и анализ проблемы, принятие решения и его реализация, закрытие проблемы.

Шаблоны документов, отражающие процесс работы с проблемами - проблемная карта, журнал проблем проекта и т. д.

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

2.3 Управление изменениями

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

Изменение в проекте - это изменение ранее согласованных продуктов и услуг, сроков и стоимости работ, управленческих и технологических процессов и т. д^[17].

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

С точки зрения серьезности последствий изменения можно классифицировать, например, следующим образом^[18]:

Запланированные потери (включены в план управления проектом)
Допустимые потери (незначительные незапланированные расходы)
Нежелательные потери (значительные незапланированные расходы)
Неприемлемые потери (незапланированные расходы, которые неприемлемы для одного или нескольких участников проекта).

Для каждого проекта первоначально (хотя и приблизительно) можно определить степень влияния определенных изменений на сумму вероятных потерь, возникающих в результате реализации этих изменений. На рис. 3 эта информация представлена в виде диаграммы, в которой изменения связаны с областями потерь. Конечно, типы возможных изменений и их расположение по регионам является свойством конкретных проектов, а точнее, типов проектов. Поэтому такие диаграммы могут быть включены в стандарт предприятия в качестве характеристики типов проектов, определенных в классификации проектов.

Рис. 3. Области потерь

Ограничения на изменения в ресурсах, времени, продуктах могут быть жесткими в различной степени, и в зависимости от этого в проектах возникают довольно типичные ситуации, которые также могут быть описаны заранее. Рассмотрим некоторые из этих ситуаций^[19].

Часто стратегия изменений определяется тем, что, по крайней мере, на одной из осей изменения не должны приводить к выходу из области запланированных потерь. А это означает необходимость смещения в одном или двух других измерениях одновременно. Поэтому, если известно, что клиент ориентирован в первую очередь на достижение запланированного уровня качества продукции, то должны быть предусмотрены варианты изменений, связанных с манипулированием ресурсами и / или сроками (стратегия «Упрямый клиент»)^[20].

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

На диаграмме могут быть показаны как желаемые, так и возможные альтернативные стратегии измерения (см. Рис. 4). Теперь, чтобы иметь возможность сравнивать альтернативные варианты не только качественно, но и количественно, остается только разработать метрики для каждой из осей. И тогда стратегию можно оценить, например, по площади соответствующего треугольника^[21].

Также отметим, что работа с изменениями на стратегическом уровне должна подкрепляться формальными процедурами, описывающими основные процессы управления изменениями - регистрация и регистрация заявок на изменения, рассмотрение и утверждение заявок, внедрение изменений. Кроме того, необходимо отслеживать процессы управления изменениями, что обеспечивает контроль за их реализацией^[22].

Рис. 4. Стратегии изменений в проекте

ГЛАВА 3. ОРГАНИЗАЦИОННЫЕ СТРУКТУРЫ В ПРОЕКТАХ

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

Для создания и функционирования команды проекта используются определенные рецепты, которые обеспечивают эффективность этих процессов. Эти рецепты не являются универсальными и должны учитывать специфику предприятия - от его организационной структуры до выпускаемой продукции^[23].

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

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

Функциональная структура, предполагающая использование существующей функциональной иерархической структуры организации. Руководитель проекта обеспечивает только общую координацию работы;

дивизионная форма управления организацией (некая функциональная структура, сформированная по региональным, товарным или технологическим признакам;

проектная структура. Этот подход предполагает, что рабочий пакет проекта разрабатывается независимо от иерархической структуры организации;

матричная структура. Промежуточная форма, которая сочетает в себе преимущества дизайна и функциональных структур управления. Можно выделить три разновидности матричной структуры организации: слабая матрица, когда координатор проекта отвечает за координацию задач проекта, но имеет ограниченную власть над ресурсами; сбалансированная матрица, когда руководитель проекта координирует всю работу и разделяет ответственность за достижение цели с руководителями функциональных подразделений; жесткая матрица, когда руководитель проекта обладает максимальными полномочиями, но также несет полную ответственность за выполнение задач проекта^[24].

Другие организационные формы управления проектом, обусловленные условиями проекта.

3.1 Тактика и стратегия внедрения стандарта управления проектами

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

Рассмотрим некоторые важные обстоятельства, рассмотрение которых позволит в определенной степени оптимизировать тактику и стратегию разработки и внедрения стандарта. Основные этапы создания стандарта управления проектами. Процесс создания и внедрения стандарта довольно длительный, трудоемкий и, зачастую, очень болезненный как для отдельных сотрудников, так и для целых отделов. Поэтому целесообразно предусмотреть определенную фазировку, позволяющую постепенно вносить изменения, постоянно оценивая достигнутые результаты и внося необходимые корректировки^[25].

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

Концепция управления проектами является основополагающим документом системы управления проектами предприятия (EMS), обосновывающим необходимость бизнеса для создания EMS (включая экономическую эффективность внедрения), определяя его основные параметры и результаты, стратегию внедрения и развития, объем автоматизации и используемые информационные технологии^[26].

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

В корпоративной методологии процессы управления проектами описываются в формате процедур, определяющих порядок реализации основных этапов проекта, применяемых технологий и методологий, а также рекомендуемых документов управления.

Стандарт управления проектами затрагивает широкий спектр аспектов деятельности предприятия. Поэтому его разработка и внедрение должны осуществляться с учетом общего контекста управления предприятием, который состоит из таких компонентов, как система качества, организационная структура, финансовая система и другие (см. Рис. 5)^[27].

Рис. 5. Стандарт управления проектами в системе управления предприятием

Стандарт управления проектами неразрывно связан с системой качества и должен быть согласован со стандартами качества, применяемыми на предприятии. В лучшем случае стандарт управления проектами должен быть создан как неотъемлемая часть системы качества предприятия и может стать основой для подготовки предприятия, его подразделений и сотрудников к сертификации в соответствии с ISO 9000 и управления проектами.

Внедрение методов управления проектами существенно влияет на организацию бизнеса компании и, как правило, приводит к определенным изменениям в организационной структуре предприятия, в управлении документооборотом и в некоторых бизнес-процессах. Стандарт управления проектами является наиболее подходящим способом для регистрации этих изменений де-юре, что, конечно, невозможно без заинтересованного участия высшего руководства предприятия.

Отдельным и очень важным вопросом является финансовое управление предприятием, которое осуществляет свою деятельность в форме проекта. Здесь должны быть определены отношения между тремя типами бюджетов - бюджетом проекта, бюджетом на единицу и бюджетом предприятия в целом.

За эти и другие подобные вопросы отвечают не специалисты по управлению проектами, а консультанты в соответствующих областях (качество, финансы, организационные структуры, бизнес-процессы и т. д.), Которые должны быть привлечены для выполнения этих работ^[28].

3.2 Дополнительные преимущества от внедрения стандарта

Стандарт управления проектами и человеческие ресурсы.

Независимо от того, насколько детализирован стандарт, невозможно вложить в него весь объем знаний, необходимый руководителю проекта. Да, стандарт не предназначен для этого. Стандарт определяет, что и когда делать, в какой форме и кому представлять результат. Но как это сделать - дело не в стандартах, а в профессиональной компетенции менеджера. Ответ на вопрос, как искать в учебниках и справочниках (их на русском языке немного, но они есть)^[29].

Стандарт не заменяет эту литературу, но его роль в целевом обучении персонала компании может быть очень значительной. Здесь, по нашему мнению, будет уместна следующая параллель. С точки зрения процессов управления проектами, стандарт предприятия специализируется и детализирует требования базовых стандартов (таких как ISO 10006 или PMBOK PMI). Таким же образом, с точки зрения квалификации управленческого персонала, стандарт предприятия специализирует и детализирует требования нормативных документов рамочного характера в этой области (таких как ICB или NTK).

Стандарт предприятия включает в себя разделы, связанные, прежде всего, с областями управления проектами, которые наиболее важны для предприятия. Именно эти темы должны стать предметом программы обучения персонала. Более того, комплексная программа обучения в виде списка квалификационных требований может быть включена непосредственно в текст соответствующих разделов стандарта. Те же требования могут быть включены в должностные инструкции руководящего персонала проекта.

И, конечно же, разработка стандарта управления проектами предприятия является наиболее важным шагом для специалиста, который рассчитывает получить международно-признанный сертификат в области управления проектами.

Стандарт управления проектами и уровень зрелости процессов управления.

Факт использования стандарта управления проектами свидетельствует о том, что в компании достигнут определенный уровень зрелости процессов управления. Для измерения этого уровня и определения направлений дальнейшего развития могут применяться различные методы. Одним из популярных подходов является использование моделей зрелости, широко известной моделью является модель зрелости возможностей (CMM), которая используется для оценки зрелости организаций, разрабатывающих программное обеспечение^[30].

Подобные модели существуют в области управления проектами. На самом деле, такая модель, хотя и довольно упрощенная, была предложена нами в одном из предыдущих заметок при обсуждении стратегии и тактики создания стандарта. Эта модель предполагает использование трех уровней зрелости, которые соответствуют концепции, методологии и оперативному стандарту управления проектами.

Другим примером является пятиуровневая модель (PM) - модель зрелости процесса управления проектами^[31].

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

Второй уровень зрелости (уровень индивидуального планирования проекта) соответствует заявке индивидуального неформального и неполного процедурного управления проектами. Менеджеры проектов частично признаются и контролируются процессами управления проектами. Однако в каждом конкретном проекте планирование и управление зависят от индивидуального подхода его руководителя.

Третий уровень зрелости (уровень управления) включает в себя частичную формализацию процессов управления проектами и использование базовой системы планирования и управления проектами в организации. Компании, достигшие этого уровня, используют системный и структурированный подход к планированию и контролю проекта. Сотрудники проекта обучены понимать и применять методологию и инструменты управления проектом^[32].

Четвертый уровень зрелости (уровень интеграции) характеризуется полной формализацией с официальным одобрением всех процессов управления проектами и документированием всей соответствующей информации. Компании, достигшие этого уровня, могут эффективно планировать, управлять и контролировать все множество проектов, которые они выполняют. Процессы управления проектами четко определены, определены количественно, понятны персоналу и применяются на практике. Данные, относящиеся к процессам управления проектами, стандартизируются, собираются и хранятся в базе данных для обеспечения эффективного и объективного анализа и количественной оценки процессов. Собранные данные также используются для прогнозирования нежелательных тенденций и предотвращения потенциальных неблагоприятных ситуаций, которые угрожают ухудшить производительность и качество. Это позволяет компании создать основу для объективного принятия решений.

И, наконец, на самом высоком, пятом уровне зрелости (уровень улучшения) процессы управления проектами в компании постоянно совершенствуются. Данные управления проектом автоматически собираются для выявления слабых мест в процессах. Эти данные тщательно анализируются и количественно определяются для определения возможностей дальнейшего улучшения процессов управления проектами. Этот уровень предполагает наличие и использование инструментов для постоянного улучшения процессов управления проектами. Такие инструменты могут включать, например, организационные структуры, процедуры и информационные технологии, которые обеспечивают аудит, мониторинг и экспертизу проектов^[33].

По нашему мнению, какой бы ни была модель зрелости процессов управления проектами, стандарт управления проектами должен играть в этом ключевую роль. Таким образом, достижение третьего и более высокого уровня зрелости по модели (PM) просто немыслимо без стандарта управления проектами. И именно этот стандарт является формальным отражением достигнутого уровня зрелости процессов управления проектами.

ЗАКЛЮЧЕНИЕ

Стандарт управления корпоративными проектами - это, прежде всего, набор документов, объясняющих или предписывающих, как, в какой последовательности, в какое время, с использованием каких шаблонов, вам необходимо выполнять определенные действия в процессе управления проектом. Эти документы не являются собственностью какого-либо одного проекта и образуют нормативно-методическое обеспечение системы управления проектами в целом, и их количество может быть довольно большим.

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

Стандарт управления проектами является внутренним документом компании. Однако, как и любое достижение в области качества, наличие этого стандарта имеет значительный маркетинговый эффект и укрепляет позиции компании на рынке.

Очень часто, чтобы получить выгодный контракт, компания должна показать, что она знает, как управлять проектами и знает, как это сделать. Фактически, практически любой крупный тендер на разработку информационных систем обязательно содержит требования, касающиеся управления проектами. Иногда эти требования специфичны, например: «Как будет организована команда проекта с учетом участия многочисленных сторон в проекте? Как будут поддерживаться отношения с различными партнерами? Чаще всего они формулируются в самой общей форме:

«Предоставлять информацию о процессах управления вашей компанией, которая позволяет отслеживать и контролировать все аспекты, связанные с проектом, в том числе ...».

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

Михеев В.Н., Товб А.С. «Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов.» М., 2002. - с.33-37.
Товб А.С. Ципес Г.Л. «Стандарты в проектах современных информационных систем», М., 2002. - с.42-47.
Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. «Директор информационной службы» № 1-6, 2001 и №№ 1-6, 2002.
Баженов Р.А. «Стандарты и правила проектного мышления» .
«Директор информационной службы» №5, 2001.://www.cfin.ru/management/practice/supremum2002/24.shtml
Управление проектами. Справочник для профессионалов. Под ред. И.И. Мазура и В.Д. Шапиро, 2001.

Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. «Директор информационной службы» № 1-6, 2001 и №№ 1-6, 2002. ↑
Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. «Директор информационной службы» № 1-6, 2001 и №№ 1-6, 2002. ↑
Тамже. ↑
Товб А.С. Ципес Г.Л. «Стандарты в проектах современных информационных систем», М., 2002. - с.42-47. ↑
Товб А.С. Ципес Г.Л. «Стандарты в проектах современных информационных систем», М., 2002. - с.42-47. ↑
Михеев В.Н., Товб А.С. «Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов.» М., 2002. - с.33-37. ↑
Товб А.С. Ципес Г.Л. «Стандарты в проектах современных информационных систем», М., 2002. - с.42-47 ↑
Товб А.С. Ципес Г.Л. «Стандарты в проектах современных информационных систем», М., 2002. - с.42-47 ↑
Михеев В.Н., Товб А.С. «Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов.» М., 2002. - с.33-37. ↑
Управление проектами. Справочник для профессионалов. Под ред. И.И. Мазура и В.Д. Шапиро, 2001 ↑
Управление проектами. Справочник для профессионалов. Под ред. И.И. Мазура и В.Д. Шапиро, 2001 ↑
Баженов Р.А. «Стандарты и правила проектного мышления» (интернет-ресурс) ↑
Управление проектами. Справочник для профессионалов. Под ред. И.И. Мазура и В.Д. Шапиро, 2001. ↑
Михеев В.Н., Товб А.С. «Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов.» М., 2002. - с.33-37. ↑
«Директор информационной службы» №5, 2001.://www.cfin.ru/management/practice/supremum2002/24.shtml ↑
Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. «Директор информационной службы» № 1-6, 2001 и №№ 1-6, 2002. ↑
Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. «Директор информационной службы» № 1-6, 2001 и №№ 1-6, 2002. ↑
Баженов Р.А. «Стандарты и правила проектного мышления» (интернет-ресурс) ↑
Баженов Р.А. «Стандарты и правила проектного мышления» (интернет-ресурс) ↑
Управление проектами. Справочник для профессионалов. Под ред. И.И. Мазура и В.Д. Шапиро, 2001. ↑
Управление проектами. Справочник для профессионалов. Под ред. И.И. Мазура и В.Д. Шапиро, 2001. ↑
Баженов Р.А. «Стандарты и правила проектного мышления» (интернет-ресурс) ↑
Михеев В.Н., Товб А.С. «Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов.» М., 2002. - с.33-37 ↑
«Директор информационной службы» №5, 2001.://www.cfin.ru/management/practice/supremum2002/24.shtml ↑
Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. «Директор информационной службы» № 1-6, 2001 и №№ 1-6, 2002. ↑
Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. «Директор информационной службы» № 1-6, 2001 и №№ 1-6, 2002. ↑
Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. «Директор информационной службы» № 1-6, 2001 и №№ 1-6, 2002. ↑
Михеев В.Н., Товб А.С. «Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов.» М., 2002. - с.33-37. ↑
Михеев В.Н., Товб А.С. «Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов.» М., 2002. - с.33-37. ↑
Баженов Р.А. «Стандарты и правила проектного мышления» (интернет-ресурс) ↑
Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. «Директор информационной службы» № 1-6, 2001 и №№ 1-6, 2002. ↑
Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. «Директор информационной службы» № 1-6, 2001 и №№ 1-6, 2002. ↑
Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. «Директор информационной службы» № 1-6, 2001 и №№ 1-6, 2002. ↑