Файл: Стандарты управления проектами (.Общие вопросы создания стандарта).pdf
Добавлен: 04.04.2023
Просмотров: 68
Скачиваний: 1
Может показаться, что создавать шаблон плана управления проектом достаточно просто, надо только иметь под рукой «рамочные» стандарты, например PMBoK и ISO 10006 и разбираться в предметной области. На самом деле, это абсолютно не так. В большинстве случаев рамочный стандарт выделяет только понятийный аппарат и общие методологические основы. Более того, дело осложняется еще и тем, что вся необходимая информация в самих рамочных стандартах рассыпана по различным разделам и ее не так-то просто собрать, выстроить, и привести к общему знаменателю.
Показать это можно на примере не самого сложного раздела плана «Организационная структура проекта». В PMBoK необходимая информация разбросана по нескольким разделам (2.2.; 2.3.; 2;4.; 4.1.3.; 9), а в ISO 10006:1997(Е) – разделе 5.8. Но и в том и в другом случае для создания специализированного шаблона этой информации не достаточно.[23]
Таким образом, на основе рамочной методологии должна быть создана методология корпоративная, в которой главные положения, требования, принципы и практики управления проектами конкретизированы и систематизированы применительно к управлению проектами на данном предприятии на основе анализа конкретной специфики выполняемых организацией проектов.[24]
Данная корпоративная методология и специализированные шаблоны документов и составляют существо стандарта управления проектами уровня предприятия. А процесс создания стандарта напоминает спираль, на каждом новом витке которой методики становятся все более специализированными, а шаблоны – все более детализированными.
2.2.Организационные структуры в проектах
Сейчас довольно большой редкостью являются случаи, когда организационная структура проекта совпадает с организационной структурой организации или же какой-нибудь ее частью. Значительно чаще работники, в соответствии со штатным расписанием, распределены по функциональным подразделениям предприятия, а для выполнения проекта формируются специальные временные организационные структуры, именуемые командами проекта, включающие представителей всевозможных подразделений.
Для создания и функционирования команды проекта используются конкретные рецепты, которые обеспечивают эффективность выполнения данных процессов. Рецепты эти не считаются универсальными и должны принимать во внимание специфику организации – от ее организационной структуры до производимого продукта.
Среди первых проблем, которые появляются при формировании организационных структур проекта и которые должны быть решены на уровне стандарта управления проектами, отметим проблемы, связанные с пересечениями функций административного управления и управления проектами.
Осуществление проекта происходит в рамках организации, структура которой в большей степени влияет на успех проекта. Выделяют следующие принципиальные организационные формы:[25]
- функциональная структура, предполагающая использование имеющейся функциональной иерархической структуры организации. Менеджер проекта осуществляет только лишь общую координацию работ;
- дивизиональная форма организации управления, разновидность функциональной структуры, сформированная по региональному, продуктовому или же технологическому признакам;
- проектная структура. Данный подход подразумевает, что комплекс работ проекта разрабатывается независимо от иерархической структуры организации;
- матричная структура. Промежуточная форма, объединяющая выдающиеся качества проектной и функциональной структур управления. Можно выделить три разновидности матричной структуры организации: слабая матрица, когда координатор проекта отвечает за координацию задач по проекту, но содержит ограниченную власть над ресурсами; сбалансированная матрица, когда менеджер проекта координирует все работы и разделяет ответственность за достижение цели с руководителями функциональных подразделений; жесткая матрица, когда менеджер проекта обладает максимальными полномочиями, но и несет полную ответственность за выполнение задач проекта.
3.Проектные отклонения. Риски, проблемы, изменения
3.1.Управление рисками и проблемами
Прежде всегο, важнο οбъяснить термин «οтклонения», это нужнο, потοму что в литературе пο управлению прοектами он трактуется разнοсторонне. В предыдущей главе курсовой работы гοворилось ο Плане управления проектом – οсновополагающем дοкументе, сοдержащем сοгласованнοе всеми участниками документальнο зафиксирοваннοе представление ο прοекте. Иными слοвами, План управления прοектом является тοчкой опοры или же начальным оснοванием для всегο дальнейшегο станοвления прοекта.
Впрочем, уже планируя проект, предполагается, что не все получится конкретно так же, как и было запланировано. И реальное исполнение проекта, как правило, подтверждает эти опасения. Образующиеся несовпадения первоначального согласованного и зафиксированного представления о проекте (исходные условия проекта) и того, что получается в действительности, и называются обычно отклонениями. Понимаемый в этом смысле термин «отклонения» эквивалентен термину deviations, применяемому в англоязычной литературе.
Вместе с тем, в английской литературе принят и иной термин – exceptions, который в российских изданиях также переводится как отклонения. Данным термином обозначают не только лишь несовпадение фактических и плановых результатов, но и предпосылки данных несовпадений, а также методы и технологии (exceptions management), позволяющие справляться с такими ситуациями в проекте с минимальными потерями. Как раз эту и более широкая трактовка и будет иметься в виду в последующем, говоря об отклонениях.
К классическим областям управления проектами, так или же иначе связанным с отклонениями, относятся риски, проблемы и изменения. Но хотя и не во всех стандартах эти мнения соединяются общим понятием отклонения, присутствие взаимосвязей между ними бесспорно. Осознание этих связей и адекватное отражение их в стандарте управления проектом, несомненно, поможет не только лишь правильно построить процедурную и документарную части стандарта, но и собственно, что еще наиболее важно, обеспечит вероятность периодического контроля и анализа отклонений, как, к примеру, в отдельном проекте, так и в масштабах предприятия в целом. Отметим так же то, что мнения, предоставленные в данном разделе, не являются какими-то отвлеченными рассуждениями и основаны на материалах действующего стандарта управления проектами компании IBS. [26]
Управление отклонениями в основном сводится к борьбе с проблемами, которая в общем случае может включать три стадии:[27]
Одна из стадий это управление рисками. Неприятности еще не наступили, но уже существует вероятность появления нежелательных и незапланированных событий, которые имеют возможность привести к тому, что цели проекта (одна или несколько) не будут достигнуты. Задача данной стадии – предупредить неприятности до их появления или же, по крайней мере, встретить их во всеоружии.
Следующая стадия это управление проблемами. Неприятности уже наступили и нужно узнать их происхождение, уровень воздействия на проект, методы преодоления. Цель этой стадии – обеспечить проекту возможность идти так, как и задумано.
Далее идет управление изменениями. Проблемы оказались довольно серьезными, и преодолеть их без ущерба непосредственно для самого проекта не получилось. Задача этого этапа заключается в том, что у финансистов именуется зафиксировать убытки – трансформация раньше согласованных продуктов и услуг, сроков выполнения и стоимости работ, управленческих и технологических процессов и тому подобное.
Самое несложное, и вместе с тем особо важное, что обязано быть отражено в стандарте – формальная сторона управления рисками, а конкретно:
Непосредственно сами процедуры, регламентирующие главные этапы работы с рисками это идентификация рисков, мониторинг и анализ рисков, осуществление планирования и реализация мероприятий по противодействию рискам.
Сами шаблоны документов, отображающих процесс работы с рисками это карточка риска, журнал рисков проекта и так далее.
Из всего обилия способов управления рисками для стандарта должны быть отобраны те из них, которые адекватны проектам, в которых они станут применяться. Здесь имеется в виду, прежде всего, стоимость реализации управленческих процедур.
Так, при анализе рисков может допускаться намеренное огрубление оценок для каких-либо конкретных категорий проектов, к примеру, для проектов малой стоимости или же сложности.
Прежде всего, необходимо выяснить, что же называется проблемами и почему проблемами можно (или нужно) управлять. В ходе реальной работы по созданию и внедрению стандарта управления проектами на предприятии авторам довелось столкнуться с тем, собственно что словосочетание «управление проблемами» вызывает недоумение у коллег, не имевших опыта знакомства с англоязычными стандартами управления проектами. Многим кажутся более привычными укоренившиеся в русской литературе термины «решение» или «разрешение проблем», которые отвечают требованиям к определениям problem solving или problem resolution, принятым в упоминавшихся выше так называемых рамочных стандартах.
Авторы в данном вопросе предпочитают следовать духу и букве этих стандартов управления проектами как MITP/PMM/WISDDM корпорации IBM, в которых данный процесс именуется problems/issues management, что в русском переводе больше всего, на наш взгляд, выглядит точно как управление проблемами.[28]
Под проблемой в проекте понимается любой функциональный, технический или же связанный с бизнесом вопрос, который появился в процессе воплощения проекта и просит ответа – изучения и решения для того, чтобы проект мог идти так, как задумано. Иными словами – проблема, это исключительные обстоятельства, которые могут находиться под контролем (то есть, управляемы) с момента их появления.
Как правило, проблемы делят на две категории – на проблемы, которые могут решаться в месте возникновения, то есть на уровне управления проектом – problems, и эскалируемые проблемы – issues, которые для их разрешения потребуется доводить на верхние уровни управления, в том числе, внешние по отношению к проекту.[29]
В стандарте должна быть отражена формальная сторона управления проблемами: процедуры, регламентирующие главные этапы работы с проблемами – выявление проблемы, мониторинг и анализ проблемы, принятие решения и его выполнение, закрытие проблемы.
Шаблоны документов, отражающих процесс работы с проблемами – карточка проблемы, журнал проблем проекта и так далее.
Для анализа проблем могут разрабатываться особые таблицы решений. К примеру, для определения такой важнейшей характеристики проблемы, как приоритетность ее решения, может использоваться матрица приоритетов.
3.2. Управление изменениями
Можно привести примеры, иллюстрирующие работу с рисками и проблемами, мы опирались на классические для управления проектами значения – ресурсы, сроки, качественные свойства продукта. Понятно, собственно, что и управляющие воздействия, связанные с противодействием рискам или же с решением проблем, ограничены этими же рамками.
Изменение в проекте – это трансформация раньше согласованных продуктов и предложений, сроков выполнения и стоимости работ, управленческих и технологических процессов и тому подобное.
В качестве традиционных действий по изменению ресурсов, применяемых в проекте, используются, к примеру, наращивание темпа работ, материальный стимул, замена или же привлечение дополнительных исполнителей и субподрядчиков. В случае если же есть возможность регулирования сроков, то речь может идти об изменении сроков окончания конкретных работ, смещении вех внутри проекта или же об увеличении всего срока окончания проекта. Наконец-таки, в каких-либо случаях приходится прибегать и к наименьше желательным мерам, связанным с понижением требований к качественным характеристикам, заменой и в том числе исключением продукта.
С точки зрения тяжести последствий изменения могут быть классифицированы, к примеру, следующим образом: плановые потери (учтены в плане управления проектом); допустимые потери (незначительные незапланированные затраты); нежелательные потери (значительные незапланированные затраты); недопустимые потери (незапланированные затраты, которые являются неприемлемыми для одного или же нескольких участников проекта).[30]
Для различных проектов изначально (пусть и приблизительно) имеет возможность определяться степень воздействия тех или же иных изменений на величину вероятных потерь, образующихся при реализации данных изменений. В приложении 4 данная информация представлена в виде диаграммы, в которой изменения связаны с областями потерь. Естественно, и виды возможных изменений и их расположения различным по областям является свойством определенных проектов, а конкретнее, видов проектов. Вследствие этого, эти диаграммы имеют возможность быть включены в стандарт предприятия как характеристика видов проектов, имеющихся в классификации проектов.