Свобода менеджера как осознанная необходимость, или Стандарт управления проектами уровня предприятия

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

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

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

И наконец, упомянем тот факт, что практика создания собственных методик и руководств по управлению проектами («фирменных стандартов») широко распространена в крупнейших западных компаниях, таких как Oracle, IBM, PricewaterhouseCoopers, Andersen Consulting, SAP, Enron Power и др.

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

Каково же конкретное наполнение такого стандарта? Как сделать стандарт предприятия работающим инструментом управления проектами? Какие информационные технологии могут использоваться для поддержки стандарта?

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

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

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

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

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

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

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

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

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

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

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

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

Вот и все — для начала. А далее предстоит охарактеризовать отдельные шаги на пути создания и использования такого стандарта.

Статья опубликована в журнале "Директор ИС", № 7, 2001 год