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

Введение

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

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

Глава1. Общие соображения по созданию стандарта. Специализация и детализация

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

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

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

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

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

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

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

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

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

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

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

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

Глава 2. Классификация проектов как первый этап создания стандарта

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

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

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

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

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

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

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

Планируемый бюджет проекта

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

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

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

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

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

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

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

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

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

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

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

- по предметным областям позволит специализировать разделы Содержание и границы, Ключевые вехи, Требования и стандарты

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

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

Рассмотренные выше примеры классификаций проектов подобраны для иллюстрации возможности сборки шаблона из относительно независимых стандартных фрагментов. Однако в реальной жизни встречаются и другие ситуации. Например, классификация комплексности проектов по сложности. В связи с этим проекты делятся на обычный бизнес (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. Для создания специализированного шаблона этой информации недостаточно.

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