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

Содержание:

ВВЕДЕНИЕ

Поскольку в нашей стране произошел переход с плановой экономики на рыночную, методология управления проектами стала очень актуальна. В условиях российской экономики данная методика является эффективным средством управления. Это проверенный инструмент для достижения целей в поставленные сроки и при установленном бюджете. Управление проектом – это особая методология планирования, организации, а также руководства, координации материальных, человеческих и других ресурсов на протяжении всего жизненного цикла проекта, которая направлена на эффективное достижение его целей с помощью применения современных методов и технологий менеджмента для достижения определенных проектом целей и задач. Если это так, что же можно стандартизовать в управлении проектами? И имеет ли это смысл? Как это скажется на проекте, не погубит ли инициативу и креативность? В западных компаниях, у менеджеров приоритет это психология управления и выстраивание межличностных отношений в проекте. Самой распространенной структурой в России на сегодняшний день является функциональная структура, представляющая собой иерархию, в которой для каждого служащего четко определен один вышестоящий руководитель. На определенном этапе в организации возникают проекты и назначается их координатор. Он отвечает за выполнение проекта, достижение целей, сроки и бюджет. На практике этот сотрудник не имеет достаточно полномочий для решения поставленных задач. Отвечать «за все» и не иметь полномочий – главная проблема для эффективного управления проектами. Это действительно так и означает, что работа в рамках определенных ограничений и стандартов, является для наших менеджеров не просто привычной, но и вполне комфортной. Для руководителей компании придерживание стандартов также является гарантом качества при исполнении работ. Однако мы все-таки двигаемся вперед. Различные методы проектного менеджмента, распространенные на западе, сегодня все чаще используются и у нас. Главной задачей российских менеджеров является выработка умения использовать весь накопленный опыт зарубежных стран с наибольшей пользой. В современной отечественной практике проектного менеджмента, в целом, ведется активная разработка стандартов, которая направлена на формирование отечественной современной системы управления проектами, непосредственно обеспечивающей выпуск качественной продукции. Таким образом, изучение сущности и специфики стандартов управления проектами представляет на сегодняшний день большой интерес. Этим обусловлена актуальность темы данной курсовой работы.

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

Во время работы над этой курсовой пользовался как учебными пособиями: П.С. Зеленский, Т.С. Зимнякова / Управление проектами., Вылегжанина А.О. / Организационный инструментарий управления проектом.

Так и интернет ресурсами, статьями, конференциями: Оберемок И.И. / Классификация проектов, Софонов М.Ю. / Управление проектами, Товб А.С. / Теория и практика управления предприятием

1. Стандартизация проектной деятельности

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

Стандарты управления проектами уровня предприятия в части методологии обычно имеют основу, определяемую документами достаточно общего характера (иногда эти документы называют "рамочными"). К таким документам относится Project Management Body of Knowledge (PMBoK) Американского института управления проектами (PMI) и стандарт ISO 10006:1997. Смысл и содержание перехода от рамочных стандартов (какими, являются и PMBoK, и в еще большей степени ISO 10006) к стандарту предприятия, состоит в их специализации и детализации.

1.1 Виды стандартов

Рассмотрим подробнее основные существующие стандарты. Их условно можно разделить на две категории.

Первая категория представляет собой компетентностные стандарты управления проектами. Они отвечают на вопрос, каким должен быть руководитель проекта. Например ICB – Project Management international Competence Baseline. Рассказывает о том, что должен уметь руководитель. В нее входит 50 стран участниц, включая Россию. Российский аналог ICB это НТК – Национальные требования к компетентности.

Вторая категория отвечает на вопрос как именно управлять проектом. Американский национальный стандарт PMBok – Project Management Body of Knowledge, наиболее распространен. ISO 21500 является своеобразным конспектом стандарта PMBok. P2M – Project and Program Management for Innovation. Является японским, ценностно-ориентированным стандартом. Его определение проекта звучит так: Проект – ответственность менеджера по созданию ценности для организации. Британский стандарт PRINCE2 – Project in Controlled Environments2. Структурированный метод управления проектами, включает в себя подходы к менеджменту, контролю и организации проектов. Российский ГОСТ Р54869 2011^[2]

На рис. 1 можно рассмотреть мировые стандарты и страны, которые их разработали.

Рис. 1. Мировые стандарты управления проектами

Большинство мировых и национальных стандартов не противоречат друг другу, что дает возможность профессионалам со всего мира общаться и понимать друг друга. В этом им помогает общая терминология. Национальные стандарты включают в себя ГОСТ Р ИСО 9000-2015, ГОСТ Р ИСО 21500-2014, ГОСТ Р 56715.5-2015

1.2 Специализация и детализация

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

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

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

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

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

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

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

Выбранные процессы образуют собой части управления проектами, которые могут быть построены по "осевому" принципу.

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

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

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

Общий вывод по главе

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

2. Проект. Классификация и организационные структуры

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

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

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

PMBok предлагает нам классифицировать проекты следующим образом:

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

На рис. 4 можно рассмотреть классификацию и связь между собой

Рис. 4. Классификация проектов

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

2.1 План управления проектом

Разберем план управления проектом. Рассмотрим, для чего он нужен, и каким образом его можно разработать.

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

1. Старт
2. Планирование
3. Выполнение
4. Мониторинг (контроль выполнения)
5. Завершение

В создании УП принимают участие проектный менеджер, команда проекта, а также стрейкхолдеры (инвесторы, заказчики, акционеры)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 Рамочные стандарты

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

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

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

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

2.3 Организационные структуры

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

Организационные структуры бывают следующих типов:

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

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

Матричная - характеризуется тем, что руководитель проекта имеет большие права и полномочия по управлению проектом; в проекты привлекается от 50 до 95% всех организационных ресурсов предприятия. Руководитель проекта функционирует на постоянной основе и чаще всего имеет свой собственный штат. Для данной структуры характерным является конфликт подчиненности. Матричная структура делится на слабую, среднюю и сильную. В слабой матрице руководитель проекта имеет мало полномочий, которые в основном заключаются в предоставлении данных. Средняя матрица наиболее сбалансирована. В ней полномочия руководителя проекта и линейного руководителя примерно равнозначны. Сильная матрица является наиболее жесткой. В ней у руководителя проекта максимально возможные полномочия.

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

Общий вывод по главе

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

3. Проектные отклонения

Рассмотрим, что же такое отклонение? И какой интерес он представляет для нас, в рамках изучения нашей темы.

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

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

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

Управление отклонениями сводится к борьбе с неприятностями, которая может включать в себя три стадии:

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

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

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

На рис. 5 можно рассмотреть классификацию рисков.

Рис. 5. Виды рисков

В стандарте необходимо указать формальную сторону управления рисками:

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

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

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

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

В стандартах управления проектам выделяются:

1. Стратегии реагирования на негативные риски (угрозы);

2. Стратегии реагирования на позитивные риски (благоприятные возможности);

3. Общие стратегии реагирования на риски;

4. Стратегии реагирования на непредвиденные обстоятельства.

Любая стратегия работы с риском направлена на управление либо вероятностью риска, либо последствиями риска, либо одновременно двумя данными параметрами.

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

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

Обычно проблемы делят на две категории - на проблемы, которые могут быть решены в месте возникновения, то есть на уровне управления проектом - problems, и эскалируемые проблемы - issues, которые для их разрешения требуется поднять на верхние уровни управления, в том числе, внешние по отношению к проекту.

В стандарте должна быть отражена формальная сторона управления проблемами:

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

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

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

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

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

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

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

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

Плановые потери (учтены в плане управления проектом).

Допустимые потери (незначительные незапланированные затраты).

Нежелательные потери (значительные незапланированные затраты).

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

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

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

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

Часто стратегия изменений определяется тем, что, по крайней мере, по одной из осей изменения не должны приводить к выходу из области плановых потерь. А это означает необходимость смещения в одном или сразу в двух других измерениях. Так, если приоритетом для заказчика является качество, то рассматривать надо варианты изменений, связанных с манипулированием ресурсами и/или сроками (стратегия "Упрямый заказчик").

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

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

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

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

Общий вывод по главе

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

4. Преимущества внедрения стандарта

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

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

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

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

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

Сам факт использования стандарта управления проектами свидетельствует о том, что на предприятии достигнут определенный уровень зрелости процессов управления. Для того чтобы измерить этот уровень и определить направления дальнейшего развития могут применяться различные способы. Одним из популярных подходов является использование моделей зрелости, широко известна модель Capability Maturity Model (CMM), применяемая для оценки зрелости организаций, разрабатывающих программное обеспечение.

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

В качестве другого примера приведем пятиуровневую модель (PM) – Project Management Process Maturity Model.

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

Каким путем пойти в реализации проекта? Выбрать ли за основу тот вариант, в котором соответствие руководилеля проекта будет основным? Или выбрать стандарт PMBoK, который подсказывает как должен выполняться проект?

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Софонов М.Ю. / Управление проектами – М.: интернет-ресурс

2. Товб А.С. / Теория и практика управления предприятием - М.: конференция 2003.

3. Товб А.С. Ципес Г.Л. «Стандарты в проектах современных информационных систем», М., 2002. - с.42-47.

4. Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. «Директор информационной службы» № 1-6, 2001 и №№ 1-6, 2002.

5. Оберемок И.И. / Классификация проектов – М.: интернет-ресурс, - 2019

6. Вылегжанина А.О. / Организационный инструментарий управления проектом – М.: учеб. пособ., - 2015

7. П.С. Зеленский, Т.С. Зимнякова / Управление проектами – М.: учеб. пособ., - 2017

1. Управление проектами / П.С. Зеленский, Т.С. Зимнякова – М.: учеб. пособ., - 2017 с.80 ↑

2. При написании этого абзаца были использованы материалы из видео лекции Софонова М.И. Управление проектами-виды стандартов ↑

3. Товб А.С. / Теория и практика управления предприятием - М.: конференция 2003. ↑

4. При написании этого абзаца использовал материал из видео лекции Оберемок И.И. / Классификация проектов ↑

5. Вылегжанина А.О. / Организационный инструментарий управления проектом – М.: учеб. пособ., - 2015 ↑