Файл: Стандарты управления проектами (.Общие вопросы создания стандарта).pdf
Добавлен: 04.04.2023
Просмотров: 89
Скачиваний: 1
Кроме международных нормативных документов и стандартов в ряде государств разработаны и применяются национальные системы стандартов и требований. Они носят частных характер и регламентируют отдельные аспекты Прожект менеджмент.
Одной из более презентабельных, исторически сформировавшихся и комплексных национальных систем стандартов считается британская национальная система по прожект менеджмент.[17]
Первые национальные стандарты по Прожект Менеджмент появлялись в Великобритании в 1981 году как комплекс стандартов по использованию сетевых технологий для управления проектами. Первые три стандарта введены в 1981 году и посвящены непосредственно вопросам применения сетевых методов, методов проектных оценок, использованию вычислительной техники, а также анализу ресурсов и контролю расходов в проектах.
В 1984 году в состав комплекса стандартов вводится Руководство по использованию процедур управления, планирования, контроля и отчетности. Первые три стандарта, являются частями второго, третьего и четвертого, а последний – частью первого, то есть стандарты, определяющие использование сетевого планирования и управления в управлении проектов, появились существенно раньше, чем изначально предусмотренный в качестве основного стандарт, определяющий процедуры Прожект Менеджмент. Глоссарий терминов, применяемых в сетевом планирование проектов, был введен лишь только в 1987 году. «Вторая очередь» английских стандартов по Прожект Менеджмент была введена в 1992 году и считалась обновлением первых трех стандартов 1981 года. В 2000 году были введены первые три стандарта принципиально нового комплекса стандартов по Прожект Менеджмент.[18]
Первый или же начальный уровень зрелости соответствует ситуации, когда в организации нет де-юре принятых процедур управления проектами, выполнение проектов не намечается, работы проекта слабо определены по содержанию, объёму и цене. Процессы управления проектами полностью непредсказуемы и слабо контролируемы. Высшее руководство нередко не осознает главных вопросов управления проектами, поэтому и успех проектов зависит в большей степени от индивидуальных усилий, чем от организации процессов управления проектами. Фирмы, находящиеся на этом уровне можно охарактеризовать, как пытающиеся стихийно освоить базовые процессы управления проектами.
Второй уровень зрелости так называемый уровень индивидуального планирования проектов соответствует использованию в организации отдельных неформализованных и некомплектных процедур управления проектами. Руководителями проектов процессы управления проектами отчасти признаются и контролируются. Впрочем, в любом определенном проекте планирование и управление находится в зависимости от персонального подхода его руководителя.
Третий уровень зрелости или же уровень управления подразумевает частичную формализацию процессов управления проектами и использование базовой системы планирования и управления проектами в организации. Организации, достигшие этого уровня, осуществляют систематический и структурированный подход к проектному планированию и контролю. Проектный персонал подготовлен для понимания и использования методологии и инструментальных средств управления проектами.
Четвертый уровень зрелости, он же уровень интеграции, характеризуется абсолютной формализацией с официальным утверждением всех процессов управления проектами и документированием всей соответствующей информации. Организации, достигшие этого уровня, в состоянии эффективно планировать, управлять и держать под контролем всё множество выполняемых ими проектов. Процессы управления проектами хорошо определены, количественно оценены, поняты персоналом и внедрены в практику. Данные, относящиеся к процессам управления проектами, стандартизованы, собраны и хранятся в базе данных для обеспечения действенного и объективного анализа и количественной оценки процессов. Собранные данные еще используются для прогнозирования нежелательных тенденций и предотвращения вероятных неблагоприятных ситуаций, которые грозят ухудшить производительность и качество. Это позволяет фирме создать фундамент для объективного принятия решений.
И наконец, на самом высоком, пятом уровне зрелости , он же уровень совершенствования, процессы управления проектами в организации постоянно улучшаются. Обеспечивается автоматический сбор данных по управлению проектами для выявления слабых мест в процессах. Эти данные тщательно анализируются и количественно оцениваются для определения возможностей последующих улучшений процессов управления проектами. Данный уровень предполагает наличие и использование инструментов постоянного совершенствования процессов управления проектами. В качестве этих инструментов могут выступать, к примеру, организационные структуры, процедуры и информационные технологии, обеспечивающие способности аудита, мониторинга и экспертизы проектов.
На мой взгляд, какая бы ни была принята модель зрелости процессов управления проектами, стандарт управления проектами обязан играть в ней главную роль. Так же достижение третьего и более высоких уровней зрелости по модели (PM) элементарно невообразимо без стандарта управления проектами. И как раз таки стандарт является формальным отражением достигнутого уровня зрелости процессов управления проектами.
2. Классификация проектов как первый этап создания стандарта
2.1. План управления проектом и рамочные стандарты
Главным фактором в создании стандарта управления проектами является осмысление того, какие проекты выполняются в организации, каковы их отличия, что между ними общего. Эти вопросы связаны с практикой управления проектами и отражаются в стандарте компании.
Среди западных коллег распространено мнение, что профессиональный руководитель проектов может успешно реализовывать любой проект, независимо от того, к какой области он относится – от строительства атомной электростанции до разработки программного обеспечения. В принципе данный тезис справедлив, но дьявол, как известно, кроется в деталях. Какое количество времени нужно и есть ли такой запас? Какое необходимо количество консультантов и какой квалификации? Сколько нам будет стоить такой руководитель проектов сам по себе и сколь велики будут дополнительные расходы?
Это особенно важно для компаний, реализующих комплексные проекты, захватывающие различные предметные области. Характерным примером, в котором в равной степени очевидны и необходимость привлечения универсального руководителя проекта, и пути снижения стоимости его содержания, является проект создания филиала банка. Такой проект включает целый ряд взаимосвязанных и, вместе с тем, относительно независимых под проектов: юридический, строительный, технологический, ИТ, рекрутинговый, маркетинговый и так далее. В крупных банках филиалы формируются десятками. После одного-двух таких проектов опыт их реализации может оказаться достаточным для того, чтобы сформировать для каждого вида проектов (под проектов) типовые цели и результаты, типовые календарный и ресурсный планы и бюджет, определить известные риски и эффективные стратегии работы с ними и так далее.[19]
Но как раз эта информация и составляет суть основного документа, с которого должен начинаться любой проект – плана управления проектом (в разных источниках можно найти и другие названия подобного документа – устав проекта, определение проекта). Таким образом, могут быть подготовлены специальные шаблоны плана управления проектами, фиксирующие совершенно конкретные методы управления проектами, рекомендованные в данной компании для данного типа проектов. А вслед за ними и иные типовые шаблоны.
Содержание и границы проекта – цели и задачи проекта, основные результаты, критерии оценки того, что работа или же ее часть выполнена.
Главные вехи проекта – основные события проекта (milestones) и план их достижения, вполне вероятно, с использованием структуры декомпозиции работ (WBS).
Предположения и ограничения – предпосылки, на основе которых делались оценки сроков выполнения, трудоемкости работ проекта и стоимости, включая описание исходных рисков.
Требования и стандарты – перечень нормативных и регламентирующих документов или же их отдельных положений, которые следует соблюдать в ходе выполнения работ проекта.
Подходы к выполнению проекта – концепция предполагаемого решения (возможно несколько альтернативных вариантов), методы разработки и базовые информационные технологии.
Организационная структура – ответственность и порядок взаимодействия участников, имена и обязанности главных фигур проекта.
Управление проектной документацией – структура, среда хранения и процедура создания и сопровождения репозитария документов проекта, перечень шаблонов документов.
Управление отклонениями – процедуры работы с рисками, с возникающими проблемами и изменениями, форм надлежащих проектных документов.
Обеспечение качества – перечень и регламенты проведения мероприятий, нацеленных на обеспечение качества, как результатов проекта (продукта), так же и процессов управления проекта и выполнения работ.
Контроль и отчетность – регламент проведения мероприятий по анализу состояния проекта, надлежащие формы отчетности.
Выдающиеся качества типовых шаблонов очевидны – экономия на консультантах, унификация подходов, сокращение времени на подготовку документации проекта. Недостатки тоже есть, но отметим здесь только лишь два. Создание таких шаблонов – дело достаточно трудоемкое, а будут их использовать или нет, заранее неизвестно. Это зависит от воли и настойчивости руководства организации. Второе – есть опасение, собственно, что наличие таких шаблонов будет сковывать инициативу и самостоятельность руководителя проекта, и он не сможет адекватно реагировать на нештатные ситуации. Но кажется, что эти сложности окажутся не столь критичными, если шаблоны будут удобны, а их специализация и детализации будут оптимальными для данной организации и ее проектов. А это уже вопрос качества работы консультантов и аналитиков, создающих стандарт.[20]
Сколько же различных шаблонов плана управления проектом целесообразно иметь в стандарте? Для того чтобы ответить на данный вопрос необходимо выстроить классификацию проектов, выполняемых в организации. Причем, очевидно ведь, что для каждой компании это будет уникальная классификация. Именно с построения такой классификации и должно начинаться создание стандарта управления.
Прежде всего, отметим, что вряд ли вероятно построить единую древовидную классификацию проектов организации. Скорее всего, это будут несколько классификаций по различным причинам, связанным с определенными разделами Плана. Можно рассмотреть некоторые из них.[21]
Классификация по предметным областям и по продуктам в рамках данных областей позволяет специализировать разделы Содержание и границы, Ключевые вехи, Требования и стандарты. Данную классификацию как раз можно выстроить по иерархическому принципу. К примеру, «информационные технологии» – «проекты системной интеграции» – «создание интегрированных систем управления проектами».
Классификация по масштабности проекта позволяет специализировать разделы Организационная структура, Управление отклонениями, Обеспечение качества. Для построения данной классификации могут использоваться различные основания – территориальная разбросанность, как это принято в Энрон Корпорэйшн, или же стоимость проекта (IBM), возможно, какие-то другие основания и их комбинации.
Классификация по форме оплаты и, значит, учета работ позволяет специализировать Контроль и отчетность, Управление проектной документацией на основании таких форм контрактов как «Время и материалы» и «Фиксированная цена».
Таким образом, можно вести речь, к примеру, о шаблоне «План управления проектом создания концепции (продукт) информационной системы (предметная область) стоимостью свыше ста тысяч долларов (масштабность) с договором в форме время и материалы (форма оплаты и учета работ)», как о макро шаблоне, получаемом простой сборкой из нескольких более мелких (микро) шаблонов отдельных разделов Плана.[22] Кроме того, в макро шаблон обязаны включать и некоторые дополнительные разделы, которые не могут быть определены на микроуровне (такие, к примеру, как сроки работ по этапам). Микро шаблоны могут быть глубоко специализированными – насколько это позволяет соответствующая классификация и накопленный в организации опыт.
Рассмотренные выше примеры классификаций проектов специально подобраны нами для иллюстрации возможности сборки шаблона из относительно независимых стандартных фрагментов. Впрочем, в реальной жизни встречаются и иные ситуации. К примеру, в IBM принята классификация проектов по сложности (комплексности). В соответствии с данной классификацией проекты делятся на обычный бизнес (Business as Usual – BaU), стандартные проекты системной интеграции и сложные проекты системной интеграции. Причем именно данная классификация является определяющей для структуры и содержания Плана управления проектом. При этом другие классификации сохраняют свое значение для формирования отдельных разделов Плана.