Файл: Стандарты управления проектами (Виды стандартов).pdf

На рис. 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. Управление изменениями. Неприятности оказались достаточно серьезными, и справиться с ними без ущерба для проекта не удалось. Цель этого этапа - то, что у финансистов называется "зафиксировать убытки" - модификация ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, управленческих и технологических процессов и т.п.