Стандарты управления проектами (Управление изменениями)
Содержание:
Введение
На первый взгляд понятия проект и стандарт могут показаться трудно совместимыми. Ведь часто даже в определение проекта включают слова об уникальности, неповторяемости целей, условий реализации, результатов проектов. Поскольку это действительно так, что же в таком случае можно стандартизовать в управлении проектами? А если и можно, то нужно ли? Не будет ли это только мешать, сковывать инициативу, навязывать неоптимальные, а то и просто неверные решения? Если для западных менеджеров приоритетными являются психологические аспекты управления и искусство выстраивания межличностных отношений в проекте, то их отечественные коллеги предпочитают процедурный подход. Это действительно так (по крайней мере, в отношении российских менеджеров) и означает, что работа в рамках определенных ограничений и стандартов, является для наших менеджеров не просто привычной (вспомним хотя бы советские ГОСТы), но и вполне комфортной. А что тогда говорить о руководстве компании, для которого наличие и исполнение таких стандартов означает гарантированный уровень качества выполнения проектов?
Сошлемся также на результаты всероссийских конференций "Стандарты в проектах современных информационных систем", где тема стандартов управления проектами была представлена достаточно широко и вызвала живой интерес и дискуссии, как в зале заседаний, так и в кулуарах. В решениях конференций было "признание роли стандартов в организации выполнения отдельных проектов и в постановке проектного дела в целом на предприятиях". И, наконец, упомянем, тот факт, что практика создания собственных методик и руководств по управлению проектами широко распространена в крупнейших западных компаниях, таких как Oracle, IBM, PricewaterhouseCoopers, Andersen Consulting, SAP AG, Siemens и др. Все эти соображения и позволяют нам предположить, что тема стандарта управления проектами должна вызвать интерес.
1. Общие соображения по созданию стандарта. Специализация и детализация
Стандарты управления проектами уровня предприятия в части методологии обычно имеют основу, определяемую документами достаточно общего характера (иногда эти документы называют "рамочными"). К таким документам относится Project Management Body of Knowledge (PMBoK) Американского института управления проектами (PMI), признаваемый многими международным стандартом де-факто, и стандарт ISO 10006:1997, придавший ряду наиболее важных положений PMBoK статус стандарта де-юре. Смысл и содержание перехода от рамочных стандартов (какими, являются и PMBoK, и в еще большей степени ISO 10006) к стандарту предприятия состоит в их специализации и детализации.
Специализация означает включение в стандарт предприятия тех и только тех положений, которые имеют отношение к проектной деятельности именно на этом предприятии и в привязке к реалиям этого предприятия. Прежде всего, из этого следует, что такие реалии должны быть четко определены. Ну, а определять реалии надо в четко определенных понятиях, измеримых показателях и т.п. В связи с этим стандарт предприятия неизбежно должен содержать описание и классификацию проектов компании.
Проекты компании могут относиться к различным профессиональным областям деятельности (юридическая, финансовая, ИТ, строительная, маркетинговая и т.д.), иметь различную сложность с точки зрения решаемых задач, различный масштаб с точки зрения привлекаемых ресурсов и предполагаемого результата. Могут выделяться некоторые категории проектов, специфические с точки зрения конкретных отраслей. Например, в стандарте компании Enron, специализировавшейся в своё время в области электроэнергетики, отдельно рассматривались международные (overseas) проекты, как предъявляющие особые требования к законодательной базе, к персоналу, оборудованию, экономической инфраструктуре, логистике и т.д.
Организационные структуры и персонал проекта также являются предметом специализации. В стандарте предприятия могут не только фиксироваться стандартные проектные роли (руководитель проекта, администратор, менеджер по качеству, и т.д.), но и определяться структура и принципы формирования органов управления проектами. Примером такой специализации может служить двухуровневая управленческая структура в проектах внедрения ERP систем.
Для всех постоянных (определенных штатной структурой) подразделений, тем или иным образом связанных с исполнением проектов, должны быть определены принципы их участия в проектах – виды выполняемых работ, порядок выделения и отзыва персонала, формы и размеры получаемого вознаграждения.
Для руководства этих подразделений должны быть определены их права и обязанности по отношению к организационным структурам проекта. Для сотрудников, привлекаемых в проект, должны быть определены правила регламентирующие их работу в проекте, в том числе, регулирующие вопросы двойного подчинения и материального стимулирования.
Предметом специализации, безусловно, являются и процессы управления проектами. Общее множество возможных процессов представим в виде трехмерного пространства, изображенного на рис.1 . По осям координат отложены те измерения, которые упоминаются в рамочных стандартах, могут быть предложены и другие, например уровни управления, календарные периоды. Каждая точка этого пространства представляет собой элементарный процесс управления. Например, "планирование рисков на стадии внедрения системы".
Выбранные элементарные процессы образуют процедуры управления проектами, которые могут быть построены по "осевому" принципу (здесь имеются в виду абсцисса, ордината и аппликата, обозначенные на рис. 1).
Собственно описание этих процедур и составляет основной объем стандарта. А если быть более точным, под стандартом предприятия мы понимаем совокупность документов, объясняющих или предписывающих как, в какой последовательности, в какие сроки, с использованием каких шаблонов нужно выполнять те или иные действия в процессе управления проектами. Количество этих документов зависит от степени детализации стандарта и может быть достаточно велико (от десятков до сотен документов). На рис. 2 они представлены в виде ступенчатой пирамиды (цилиндрического зиккурата), которая обычно выстраивается сверху вниз по мере пробуждения аппетита у тех, кто организует и регламентирует работы на предприятии, и соответствующего ему развития стандарта.
Предметом опис ания в станд арте могут бы ть также типо вые ситуации, характ ерные для прое ктов предприятия, и рекомендации менед жерам по реагир ованию на эт и ситуации. Т о есть своеоб разные таблицы реше ний, что-т о вроде спи ска возможных неиспра вностей и рекоме ндаций по и х устранению (checklist). Коне чно, решение вс е равно буд ет принимать мене джер, но у него пер ед глазами буд ет обобщенный оп ыт ("сын оши бок трудных") преды дущих поколений.
Ри с. 1. Пространство проце ссов управления
Ри с. 2. Структура станд арта управления проек тами
2. Классификация проектов как первый этап создания стандарта
Ключ евым моментом в создании станд арта управления проек тами является осмыс ление того, как ие проекты выполн яются на предпр иятии, каковы и х отличия, чт о между ни ми общего. Эт и вопросы связ аны с практ икой управления проек тами и отраж аются в станд арте предприятия.
Сре ди западных кол лег распространено мне ние, что професси ональный руководитель прое ктов может успе шно реализовать люб ой проект, незав исимо от то го, к как ой области о н относится – о т строительства атом ной электростанции д о разработки програ ммного обеспечения. В принципе эт от тезис справ едлив, но дья вол, как изве стно, кроется в деталях! Как ое количество врем ени нужно и есть л и такой зап ас? Какое необх одимо количество консуль тантов и как ой квалификации? Скол ько нам буд ет стоить так ой руководитель прое ктов сам п о себе и сколь вел ики будут дополни тельные расходы?
Эт о особенно важ но для предпр иятий, реализующих компле ксные проекты, захваты вающие различные предм етные области. Характ ерным примером, в котором в равной степ ени очевидны и необходимость привле чения "универсального" руково дителя проекта, и пути сниж ения стоимости ег о "содержания", явля ется проект созд ания филиала бан ка. Такой про ект включает цел ый ряд взаимосв язанных и, вме сте с те м, относительно незави симых подпроектов: юридич еский, строительный, технолог ический, ИТ, рекрути нговый, маркетинговый и т. д. В круп ных банках фили алы создаются десят ками. После одн ого-двух так их проектов оп ыт их реали зации может оказа ться достаточным дл я того, что бы сформировать дл я каждого ви да проектов (подпро ектов) типовые це ли и резул ьтаты, типовые календ арный и ресур сный планы и бюджет, опред елить известные рис ки и эффект ивные стратегии раб оты с ни ми и т. д.
Н о как ра з эта инфор мация и соста вляет сущность основ ного документа, с которого дол жен начинаться люб ой проект – Пла на управления прое ктом (в разли чных источниках мож но найти и другие назв ания подобного докум ента – Устав прое кта, Определение прое кта). Таким обра зом, могут бы ть подготовлены специализ ированные шаблоны Пла на управления проек тами, фиксирующие совер шенно конкретные мет оды управления проек тами, рекомендованные н а данном предпр иятии для данн ого типа прое ктов. А всл ед за ни ми и дру гие типовые шабл оны.
2.1. Что должно быть отражено в плане управления проектом
Содержание и границы прое кта – цели и задачи прое кта, основные резул ьтаты, критерии оце нки того, чт о работа ил и ее час ть выполнена.
Ключ евые вехи прое кта – основные собы тия проекта (milestones) и план и х достижения, возм ожно, с использ ованием структуры декомп озиции работ (WBS).
План овый бюджет прое кта
Предположения и ограничения – предпо сылки, на осн ове которых дела лись оценки сро ков выполнения, трудое мкости работ прое кта и стоим ости, включая опис ание начальных рис ков.
Требования и стандарты – пере чень нормативных и регламентирующих докум ентов или и х отдельных полож ений, которые след ует соблюдать в ходе выпол нения работ прое кта.
Подходы к выполнению прое кта – концепция предпола гаемого решения (возм ожно несколько альтерн ативных вариантов), мет оды разработки и базовые информа ционные технологии.
Организа ционная структура – ответств енность и поря док взаимодействия участ ников, имена и обязанности ключ евых фигур прое кта
Управление проек тной документацией – струк тура, среда хран ения и проце дура создания и сопровождения репози тария документов прое кта, перечень шабл онов документов.
Управ ление отклонениями – проце дуры работы с рисками, с возникающими пробл емами и измене ниями, форм соответс твующих проектных докум ентов.
Обеспечение каче ства – перечень и регламенты прове дения мероприятий, направ ленных на обеспе чение качества, ка к результатов прое кта (продукта), та к и проце ссов управления прое кта и выпол нения работ.
Конт роль и отчет ность – регламент прове дения мероприятий п о анализу состо яния проекта, соответс твующие формы отчет ности.
Преимущества типо вых шаблонов очев идны – экономия н а консультантах, унифи кация подходов, сокра щение времени н а подготовку докуме нтации проекта. Недос татки тоже ес ть, мы отме тим здесь тол ько два. Созд ание таких шабл онов – дело доста точно трудоемкое, а будут и х использовать ил и нет, зара нее неизвестно. Эт о зависит о т воли и настойчивости руково дства предприятия. Вто рое – есть опас ение, что нали чие таких шабл онов будет сковы вать инициативу и самостоятельность руково дителя проекта, и он н е сможет адекв атно реагировать н а нештатные ситу ации. Нам каже тся, что эт и сложности окаж утся не сто ль критичными, ес ли шаблоны буд ут удобны, а их специал изация и детали зации будут оптима льными для данн ого предприятия и его прое ктов. А эт о уже воп рос качества раб оты консультантов и аналитиков, созда ющих стандарт.
Скол ько разных шабл онов Плана управ ления проектом целесоо бразно иметь в стандарте? Дл я того что бы ответить н а этот воп рос необходимо постр оить классификацию прое ктов, выполняемых н а предприятии. При чем, очевидно, чт о для кажд ого предприятия эт о будет уника льная классификация. Собст венно, с постр оения такой классиф икации и дол жно начинаться созд ание стандарта.
Пре жде всего, отме тим, что вр яд ли возм ожно построить еди ную древовидную классиф икацию проектов предпр иятия. Скорее все го, это буд ут несколько классиф икаций по разли чным основаниям, связа нным с определ енными разделами Пла на. Рассмотрим некот орые из ни х.
Классификация п о предметным обла стям и п о продуктам в рамках эт их областей позво ляет специализировать разд елы Содержание и границы, Ключ евые вехи, Требо вания и станд арты. Эту классиф икацию как ра з можно выстр оить по иерархи ческому принципу. Напр имер, "информационные техно логии" – "проекты систе мной интеграции" – "созд ание интегрированных сис тем управления проек тами".
Классификация п о масштабности прое кта позволяет специали зировать разделы Организа ционная структура, Управ ление отклонениями, Обеспе чение качества. Дл я построения эт ой классификации мог ут использоваться разли чные основания – территор иальная разбросанность, ка к это прин ято в Enron Corp., ил и стоимость прое кта (IBM), может бы ть, какие-т о другие основ ания и и х комбинации.
Классиф икация по фор ме оплаты и, следовательно, уче та работ позво ляет специализировать Конт роль и отчет ность, Управление проек тной документацией н а основании так их форм контр актов как "Вре мя и матер иалы" и "Фиксиро ванная цена".
Так им образом, мож но вести ре чь, например, о шаблоне "Пл ан управления прое ктом создания конце пции (продукт) информа ционной системы (предм етная область) стоим остью свыше $ 100 ты с. (масштабность) с контрактом в форме "вре мя и матер иалы" (форма опл аты и уче та работ)", ка к о макрош аблоне, получаемом прос той сборкой и з нескольких бол ее мелких (мик ро) шаблонов отдел ьных разделов Пла на. Кроме то го, в макрош аблон должны бы ть включены и некоторые дополни тельные разделы, кото рые не мог ут быть опред елены на микроу ровне (такие, напр имер, как "Сро ки работ п о этапам"). Микрош аблоны могут бы ть глубоко специализи рованными – насколько эт о позволяет соответс твующая классификация и накопленный н а предприятии оп ыт.
Рассмотренные вы ше примеры классиф икаций проектов специ ально подобраны на ми для иллюст рации возможности сбо рки шаблона и з относительно незави симых стандартных фрагм ентов. Однако в реальной жиз ни встречаются и другие ситу ации. Например, в 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. Но и в то м и в другом слу чае для созд ания специализированного шабл она этой инфор мации не доста точно!
Таким обра зом, на осн ове "рамочной" методо логии должна бы ть создана методо логия "корпоративная", в которой осно вные положения, требо вания, принципы и практики управ ления проектами конкрети зированы и системати зированы применительно к управлению проек тами на дан ном предприятии н а основе анал иза конкретной специ фики выполняемых предпр иятием проектов.
Эт а корпоративная методо логия и специализ ированные шаблоны докум ентов и соста вляют существо станд арта управления проек тами уровня предпр иятия. А проц есс создания станд арта напоминает спир аль, на каж дом новом вит ке которой мето дики становятся вс е более специализи рованными, а шабл оны – все бол ее детализированными.
3. Проектные отклонения. Риски, проблемы, изменения
Прежде все го, поясним тер мин "отклонения", эт о необходимо, поско льку в литер атуре по управ лению проектами о н трактуется неодно значно. В преды дущем разделе м ы рассказали о Плане управ ления проектом – основопо лагающем документе, содер жащем согласованное все ми участниками докумен тально зафиксированное предста вление о прое кте. Другими слов ами, План управ ления проектом явля ется "точкой опо ры" или исхо дной базой дл я всего послед ующего развития прое кта.
Однако, уж е планируя про ект, мы предпо лагаем, что н е все получ ится именно та к, как заплани ровано. И реал ьное исполнение прое кта, как прав ило, подтверждает эт и опасения. Возник ающие несовпадения первонач ального согласованного и зафиксированного предста вления о прое кте (project baseline) и то го, что получ ается в действит ельности, и назыв аются обычно отклон ениями. Понимаемый в этом смы сле термин "откло нения" эквивалентен терм ину "deviations", используемому в англоязычной литер атуре.
Вместе с тем, в англоязычной литер атуре принят и другой тер мин – "exceptions", который в русских изда ниях также перево дится как откло нения. Этим терм ином обозначают н е только несовп адение фактических и плановых резуль татов, но и причины эт их несовпадений, а также мет оды и техно логии (exceptions management), позволяющие справл яться с так ими ситуациями в проекте с минимальными поте рями. Именно эт у более широ кую трактовку м ы и буд ем иметь в виду в дальнейшем, гов оря об отклон ениях.
К традиц ионным областям управ ления проектами, та к или ина че связанным с отклонениями, относ ятся риски, проб лемы и измен ения. И хо тя не в о всех станд артах эти поня тия объединяются общ им понятием откло нения, наличие взаимо связей между ни ми очевидно. Поним ание этих свя зей и адекв атное отражение и х в станд арте управления прое ктом поможет н е только прави льно выстроить процед урную и докумен тарную части станд арта, но и что ещ е более важ но, обеспечит возмож ность систематического конт роля и анал иза отклонений, ка к в отдел ьном проекте, та к и в масштабах предпр иятия в цел ом.
Отметим, чт о соображения, предста вленные в эт ом разделе, н е являются как ими-то отвлеч енными рассуждениями и основаны н а материалах действ ующего стандарта управ ления проектами комп ании IBS. Мы благо дарны компании з а предоставленную возмож ность использования эт их материалов, и коллективу разрабо тчиков (Илья Виног радов, Мария Чук ова) за возмож ность использования эт их материалов.
Управ ление отклонениями в основном свод ится к бор ьбе с неприят ностями, которая в общем слу чае может вклю чать три ста дии:
Управление риск ами. Неприятности ещ е не насту пили, но сущес твует возможность возникн овения нежелательных и незапланированных собы тий, которые мог ут привести к тому, чт о цели прое кта (одна ил и несколько) н е будут дости гнуты. Цель эт ой стадии – предотв ратить неприятности д о их возникн овения или, п о крайней ме ре, встретить и х во всеор ужии.
Управление пробл емами. Неприятности насту пили и необх одимо выяснить и х происхождение, степ ень влияния н а проект, спос обы преодоления. Це ль этой ста дии – обеспечить прое кту возможность ид ти так, ка к запланировано. стан дарт проект специал изация детализация
Управ ление изменениями. Неприя тности оказались доста точно серьезными, и справиться с ними бе з ущерба дл я проекта н е удалось. Це ль этого эта па – то, чт о у финанс истов называется "зафикси ровать убытки" – модифи кация ранее согласо ванных продуктов и услуг, сро ков исполнения и стоимости раб от, управленческих и технологических проце ссов и т.п.
3.1. Управление рисками
Сам ое простое, и вместе с тем необхо димое, что дол жно быть отра жено в станд арте – формальная стор она управления риск ами, а име нно:
Процедуры, регламен тирующие основные эта пы работы с рисками – идентиф икация рисков, монит оринг и ана лиз рисков, разра ботка планирование и реализация меропр иятий по противод ействию рискам.
Шабл оны документов, отраж ающих процесс раб оты с риск ами – карточка рис ка, журнал рис ков проекта и т.д.
Из все го многообразия мето дов управления риск ами для станд арта должны бы ть отобраны т е из ни х, которые адекв атны проектам, в которых он и будут примен яться. Здесь м ы имеем в виду, пре жде всего, стоим ость реализации управле нческих процедур.
Та к, при анал изе рисков мож ет допускаться сознат ельное огрубление оце нок для как их-то конкр етных категорий прое ктов, например, дл я проектов мал ой стоимости ил и сложности.
3.2. Управление проблемами
Пре жде всего, пояс ним, что м ы называем пробл емами и поч ему проблемами мож но (и нуж но) управлять. В ходе реал ьной работы п о созданию и внедрению станд арта управления проек тами на предпр иятии авторам приш лось столкнуться с тем, чт о словосочетание "управ ление проблемами" вызы вает недоумение у коллег, н е имевших опы та знакомства с англоязычными станда ртами управления проек тами. Многим кажу тся более привы чными укоренившиеся в русскоязычной литер атуре термины "реше ние" или "разре шение проблем", кото рые соответствуют опреде лениям "problem solving" или "problem resolution", прин ятым в упомина вшихся выше та к называемых "рамо чных" стандартах.
Авт оры в эт ом вопросе предпо читают следовать ду ху и бук ве таких станд артов управления проек тами как MITP/PMM/WISDDM корпо рации IBM, в кото рых этот проц есс называется "problems/issues management", чт о в русс ком переводе луч ше всего, н а наш взг ляд, выглядит име нно как "управ ление проблемами".
По д проблемой в проекте поним ается любой функцио нальный, технический ил и связанный с бизнесом воп рос, который воз ник в проц ессе осуществления прое кта и треб ует ответа – изуч ения и реше ния для то го, чтобы про ект мог ид ти так, ка к запланировано. Друг ими словами – проб лема, это исключи тельные обстоятельства, кото рые должны бы ть под контр олем (то ес ть, управляемы) с момента и х возникновения.
Обы чно проблемы дел ят на дв е категории – н а проблемы, кото рые могут бы ть решены в месте возникн овения, то ес ть на уро вне управления прое ктом – problems, и эскали руемые проблемы – issues, кото рые для и х разрешения требу ется поднять н а верхние уро вни управления, в том чис ле, внешние п о отношению к проекту.
В стандарте дол жна быть отра жена формальная стор она управления пробл емами:
Процедуры, регламен тирующие основные эта пы работы с проблемами – выявл ение проблемы, монит оринг и ана лиз проблемы, прин ятие решения и его испол нение, закрытие проб лемы.
Шаблоны докум ентов, отражающих проц есс работы с проблемами – карт очка проблемы, жур нал проблем прое кта и т.д.
Дл я анализа проб лем могут разрабат ываться специальные табл ицы решений. Напр имер, для опреде ления такой важне йшей характеристики проб лемы, как приорит етность ее реше ния, может использ оваться матрица приори тетов.
3.3. Управление изменениями
Приводя прим еры, иллюстрирующие раб оту с риск ами и пробл емами, мы опира лись на традиц ионные для управ ления проектами ценн ости – ресурсы, сро ки, качественные характе ристики продукта. Поня тно, что и управляющие воздей ствия, связанные с противодействием рис кам или с решением проб лем, ограничены эти ми же рамк ами.
Изменение в проекте – эт о модификация ран ее согласованных проду ктов и усл уг, сроков испол нения и стоим ости работ, управле нческих и технолог ических процессов и т.п.
В каче стве традиционных меропр иятий по измен ениям ресурсов, исполь зуемых в прое кте, применяются, напр имер, увеличение интенси вности работ, матери альное стимулирование, зам ена или привле чение дополнительных исполн ителей и субподр ядчиков. Если имее тся возможность маневри рования сроками, т о речь мож ет идти о б изменении сро ков завершения отдел ьных работ, смещ ении вех вну три проекта ил и даже о б увеличении общ его срока завер шения проекта. Нако нец, в как их-то случ аях приходится прибе гать и к наименее желате льным мерам, связа нным со сниже нием требований к качественным характер истикам, заменой и даже исключ ением продукта.
С точки зре ния тяжести послед ствий изменения мог ут быть классифи цированы, например, следу ющим образом:
План овые потери (учт ены в пла не управления прое ктом).
Допустимые пот ери (незначительные незаплани рованные затраты).
Нежелат ельные потери (значит ельные незапланированные затр аты).
Недопустимые пот ери (незапланированные затр аты, которые явля ются неприемлемыми дл я одного ил и нескольких участ ников проекта).
Дл я каждого прое кта изначально (пус ть приблизительно) мож ет быть опред елена степень влия ния тех ил и иных измен ений на вели чину вероятных пот ерь, возникающих пр и реализации эт их изменений. Н а Рис. 5 эт а информация предст авлена в ви де диаграммы, в которой измен ения связаны с областями пот ерь. Разумеется, и типы возмо жных изменений и их распол ожения по обла стям является свойс твом конкретных прое ктов, а точ нее, видов прое ктов. Поэтому, так ие диаграммы мог ут быть вклю чены в стан дарт предприятия ка к характеристика вид ов проектов, опреде ленных в классиф икации проектов.
Ограни чения на измен ения по ресу рсам, времени, проду ктам могут бы ть жесткими в различной степ ени и в зависимости о т этого в проектах возни кают достаточно типи чные ситуации, кото рые также мог ут быть опис аны заранее. Рассм отрим некоторые так ие ситуации.
Час то стратегия измен ений определяется те м, что, п о крайней ме ре, по одн ой из ос ей изменения н е должны приво дить к вых оду из обла сти плановых пот ерь. А эт о означает необход имость смещения в одном ил и сразу в двух дру гих измерениях. Та к если изве стно, что зака зчик ориентирован, пре жде всего, н а соблюдение запланир ованного уровня каче ства продукта, т о должны бы ть предусмотрены вари анты изменений, связа нных с манипули рованием ресурсами и/или срок ами (стратегия "Упря мый заказчик"). мене джер проектный управ ление бизнес
В других случ аях могут потребо ваться иные страт егии, например, "Жест кие сроки" ил и "Ограниченный бюд жет, когда в области запланир ованных потерь дол жны быть зафикси рованы, соответственно, измен ения по сро кам и ресу рсам.
На диагр амме могут бы ть показаны и желаемая, и возможные альтерн ативные стратегия измер ений (см. Ри с. 6). Теперь дл я того, что бы получить возмож ность сравнивать альтерн ативные варианты н е только качест венно, но и количественно, оста лось только разраб отать метрики дл я каждой и з осей. И тогда страт егию можно буд ет оценивать, напр имер, площадью соответс твующего треугольника.
Заме тим также, чт о работа с изменениями н а стратегическом уро вне обязательно дол жна быть подкре плена формальными процед урами, описывающими осно вные процессы управ ления изменениями – оформ ление и регист рация заявок н а изменения, рассмо трение и утверж дение заявок, реали зация изменений. Кро ме этого дол жен осуществляться монит оринг процессов управ ления изменениями, кото рый обеспечивает конт роль их осущест вления.
Рис. 5. Обла сти потерь
Ри с. 6. Стратегии измен ений в прое кте
4. Организационные структуры в проектах
Сегодня доста точно большой редко стью являются слу чаи, когда организа ционная структура прое кта совпадает с организационной струк турой предприятия ил и какой-ли бо ее час тью. Гораздо ча ще сотрудники, в соответствии с о штатным распис анием, распределены п о функциональным подразд елениям предприятия, а для выпол нения проекта формир уются специальные време нные организационные струк туры, называемые коман дами проекта включ ающие представителей разли чных подразделений.
Дл я создания и функционирования кома нды проекта примен яются определенные реце пты, которые обеспе чивают эффективность выпол нения этих проце ссов. Рецепты эт и не явля ются универсальными и должны учиты вать специфику предпр иятия – от ег о организационной струк туры до произво димого продукта.
Сре ди первых проб лем, которые возни кают при формир овании организационных стру ктур проекта и которые дол жны быть реш ены на уро вне стандарта управ ления проектами, отме тим проблемы, связа нные с пересеч ениями функций администр ативного управления и управления проек тами.
Реализация прое кта происходит в рамках органи зации, структура кото рой в значит ельной степени вли яет на усп ех проекта. Выде ляют следующие принцип иальные организационные фор мы:
- функциональная струк тура, предполагающая использ ование существующей функцио нальной иерархической струк туры организации. Мене джер проекта осущес твляет лишь общ ую координацию раб от;
- дивизиональная фор ма организации управ ления (разновидность функцио нальной структуры, сформир ованная по региона льному, продуктовому ил и технологическому призн акам;
- проектная струк тура. Данный под ход предполагает, чт о комплекс раб от проекта разрабат ывается независимо о т иерархической струк туры организации;
- матри чная структура. Промежу точная форма, объеди няющая преимущества проек тной и функцио нальной структур управ ления. Могут бы ть выделены тр и разновидности матри чной структуры органи зации: слабая матр ица, когда коорди натор проекта отве чает за коорди нацию задач п о проекту, н о имеет ограни ченную власть на д ресурсами; сбаланси рованная матрица, ког да менеджер прое кта координирует вс е работы и разделяет ответств енность за дости жение цели с руководителями функцио нальных подразделений; жест кая матрица, ког да менеджер прое кта обладает максима льными полномочиями, н о и нес ет полную ответств енность за выпол нение задач прое кта.
Прочие организа ционные формы управ ления проектами, обуслов ленные условиями реали зации проекта.
5. Тактика и стратегия внедрения стандарта управления проектами
Затраты связ аны не тол ько с разраб откой содержания станд арта, но в значительно боль шей степени с теми преобраз ованиями в сист еме управления предпр иятием, которые дол жны сопутствовать внедр ению стандарта.
Рассм отрим некоторые важ ные обстоятельства, уч ет которых позв олит в как ой-то степ ени оптимизировать такт ику и страт егию разработки и внедрения станд арта. Основные эта пы создания станд арта управления проек тами. Процесс созд ания и внедр ения стандарта явля ется достаточно длите льным, трудоемким и, часто, вес ьма болезненным ка к для отдел ьных сотрудников, та к и дл я целых подразд елений. Поэтому целесоо бразно предусмотреть опреде ленную этапность, позвол яющую проводить измен ения постепенно, посто янно оценивая достиг нутые результаты и внося необхо димые коррективы.
Рабо тая в обла сти консалтинга, авт оры отлично предст авляют то раздра жение, которое мог ут вызвать у некоторой катег ории уважаемых кол лег слова "конце пция" и "мето дика". И, те м не мен ее, рискнем сказ ать, что предпочт ительным путем созд ания стандарта явля ется путь последов ательной детализации, включ ающий, в то м числе, эта пы разработки конце пции и мето дики управления проек тами предприятия
Конце пция управления проек тами является основопо лагающим документом сист емы управления проек тами (СУП) предпр иятия, обосновывающим дело вую необходимость созд ания СУП (вклю чая экономическую эффекти вность внедрения), опреде ляющим ее осно вные параметры и результаты, страт егию реализации и развития, объ ем автоматизации и используемые информа ционные технологии.
Конце пция должна содер жать аналитический раз дел, в кото ром составные час ти стандарта управ ления проектами описыв аются на обобщ енном уровне (прин ципы классификации прое ктов компании, опреде ление зон ответств енности и прин ципы формирования ком анд проектов, пере чень процедур управ ления проектами, степ ень их детали зации и формал изации).
В корпора тивной методике проц ессы управления проек тами описываются в формате проц едур, определяющих поря док выполнения осно вных этапов прое кта, применяемые техно логии и методо логии, а так же рекомендуемые управле нческие документы.
И, наконец, операц ионный стандарт разви вает и детали зирует процедуры управ ления проектами, допол няет их детал ьными инструкциями п о исполнению проц едур и шабло нами управленческих докум ентов.
Стандарт управ ления проектами затраг ивает самые разли чные стороны функцион ирования предприятия. Поэт ому его разра ботка и внедр ение должны осущест вляться с уче том общего конте кста управления предпр иятием, который соста вляют такие компо ненты, как сист ема качества, организа ционная структура, финан совая система и другие (с м. Рис. 11).
Ри с. 11. Стандарт управ ления проектами в системе управ ления предприятием
Стан дарт управления проек тами неразрывно свя зан с сист емой качества и должен бы ть гармонизирован с о стандартами каче ства, применяемыми н а предприятии. В оптимальном вари анте стандарт управ ления проектами дол жен создаваться, ка к составная час ть системы каче ства предприятия и может ста ть основой дл я подготовки предпр иятия, его подразд елений и сотруд ников к сертиф икации по станд арту ISO 9000 и п о управлению проек тами.
Внедрение проек тных методов управ ления существенным обра зом влияет н а организацию бизн еса компании и как прав ило приводит к определенным измен ениям в организа ционной структуре предпр иятия, в документ ообороте, в некот орых деловых проце ссах. Стандарт управ ления проектами явля ется самым подхо дящим способом зафикси ровать эти измен ения де-юр е, что, коне чно, не возм ожно без заинтерес ованного участия высш его руководства предпр иятия.
Отдельный и очень важ ный вопрос – финан совое управление предпр иятием, реализующим св ою деятельность в проектной фор ме. Здесь дол жны быть опред елены взаимоотношения меж ду тремя тип ами бюджетов – бюдж етом проекта, бюдж етом подразделения и бюджетом предпр иятия в цел ом.
Эти и другие подо бные вопросы наход ятся в компет енции не стол ько специалистов п о управлению проек тами, сколько консуль тантов по соответс твующим направлениям (каче ство, финансы, организа ционные структуры, биз нес-процессы и т.д.), которые и должны привле каться для выпол нения этих раб от.
6. Дополнительные преимущества от внедрения стандарта
Стан дарт управления проек тами и челове ческие ресурсы.
Ско ль бы детал ьным не бы л стандарт в него невоз можно вложить ве сь объем зна ний, необходимых руково дителю проекта. Д а стандарт и не предна значен для это го. Стандарт опред еляет, что и когда нуж но сделать, в какой фор ме и ко му представить резул ьтат. Но ка к сделать – эт о уже воп рос не станд арта, а професси ональной компетентности менед жера. Ответ н а вопрос ка к нужно иск ать в учебн иках и справо чниках (их н е так мно го на русс ком языке, н о они ес ть).
Стандарт н е заменит эт ой литературы, н о роль ег о в целенапр авленном обучении персо нала компании мож ет быть вес ьма значительной. Зде сь, на на ш взгляд, буд ет уместной следу ющая параллель. В части проце ссов управления проек тами стандарт предпр иятия специализирует и детализирует требо вания рамочных станд артов (таких ка к ISO 10006 или PMBOK PMI). Точ но также в части квалиф икации управленческого персо нала стандарт предпр иятия специализирует и детализирует требо вания нормативных докум ентов рамочного харак тера в эт ой области (так их как ICB ил и НТК).
В стандарт предпр иятия включаются разд елы, относящиеся, в первую очер едь, к наиб олее критичным дл я данного предпр иятия областям управ ления проектами. Име нно эти те мы и дол жны составить пред мет программы обуч ения персонала. Бол ее того, развер нутая программа обуч ения в ви де перечня требо ваний к квалиф икации может бы ть включена непосред ственно в тек ст соответствующих разд елов стандарта. Эт и же требо вания могут включ аться и в должностные инстр укции управленческого персо нала проектов.
И, конечно ж е, освоение станд арта управления проек тами предприятия явля ется важнейшей ступе нькой для специа листа, рассчитывающего полу чить международно призна ваемый сертификат в области управ ления проектами.
Стан дарт управления проек тами и уров ень зрелости проце ссов управления.
Са м факт использ ования стандарта управ ления проектами свидетел ьствует о то м, что н а предприятии дости гнут определенный уров ень зрелости проце ссов управления. Дл я того что бы измерить эт от уровень и определить направ ления дальнейшего разв ития могут примен яться различные спос обы. Одним и з популярных подх одов является использ ование моделей зрел ости, широко изве стна модель Capability Maturity Model (CMM), примен яемая для оце нки зрелости органи заций, разрабатывающих програ ммное обеспечение.
Подо бные модели сущес твуют и в области управ ления проектами. Собст венно, такая мод ель, хотя и достаточно упрощ енная, предложена на ми в одн ой из преды дущих заметок пр и обсуждении страт егии и такт ики создания станд арта. Эта мод ель предполагает использ ование трех уров ней зрелости, кото рым соответствуют конце пция, методика и операционный стан дарт управления проек тами.
В каче стве другого прим ера приведем пятиуро вневую модель (PM) – Project Management Process Maturity Model [5].
Пер вый (начальный) уров ень зрелости соответ ствует ситуации, ког да в органи зации нет форма льно принятых проц едур управления проек тами, выполнение прое ктов не планир уется, работы прое кта слабо опред елены по содер жанию, объёму и стоимости. Проц ессы управления проек тами полностью непредс казуемы и сла бо контролируемы. Выс шее руководство час то не пони мает ключевых вопр осов управления проек тами, поэтому усп ех проектов зави сит в боль шей степени о т индивидуальных уси лий, чем о т организации проце ссов управления проек тами. Компании, находя щиеся на эт ом уровне мож но охарактеризовать, ка к пытающиеся стих ийно освоить базо вые процессы управ ления проектами.
Вто рой уровень зрел ости (уровень индивиду ального планирования прое ктов) соответствует приме нению в органи зации отдельных неформали зованных и некомпл ектных процедур управ ления проектами. Руковод ителями проектов проц ессы управления проек тами частично призн аются и контрол ируются. Однако в каждом конкр етном проекте планир ование и управ ление зависит о т индивидуального подх ода его руково дителя.
Третий уров ень зрелости (уров ень управления) предпо лагает частичную формал изацию процессов управ ления проектами и использование базо вой системы планир ования и управ ления проектами в организации. Комп ании, достигшие это го уровня, осущес твляют систематический и структурированный под ход к проек тному планированию и контролю. Проек тный персонал подгот овлен для поним ания и приме нения методологии и инструментальных сред ств управления проек тами.
Четвертый уров ень зрелости (уров ень интеграции) характер изуется полной формали зацией с официа льным утверждением вс ех процессов управ ления проектами и документированием вс ей соответствующей инфор мации. Компании, дости гшие этого уро вня, в состо янии эффективно планир овать, управлять и контролировать вс ё множество выполн яемых ими прое ктов. Процессы управ ления проектами хор ошо определены, количес твенно оценены, пон яты персоналом и внедрены в практику. Дан ные, относящиеся к процессам управ ления проектами, стандарт изованы, собраны и хранятся в базе дан ных для обеспе чения эффективного и объективного анал иза и количес твенной оценки проце ссов. Собранные дан ные также примен яются для прогнози рования нежелательных тенде нций и предотв ращения возможных неблагоп риятных ситуаций, кото рые угрожают ухуд шить производительность и качество. Эт о позволяет комп ании создать фунда мент для объект ивного принятия реше ний.
И нако нец, на сам ом высоком, пят ом уровне зрел ости (уровне совершенс твования) процессы управ ления проектами в компании посто янно улучшаются. Обеспеч ивается автоматический сб ор данных п о управлению проек тами для выявл ения слабых ме ст в проце ссах. Эти дан ные тщательно анализи руются и количес твенно оцениваются дл я определения возмож ностей дальнейших улучш ений процессов управ ления проектами. Эт от уровень предпо лагает наличие и использование инстру ментов постоянного совершенс твования процессов управ ления проектами. В качестве так их инструментов мог ут выступать, напр имер, организационные струк туры, процедуры и информационные техно логии, обеспечивающие возмож ности аудита, монито ринга и экспе ртизы проектов.
Н а наш взг ляд, какая б ы ни бы ла принята мод ель зрелости проце ссов управления проек тами, стандарт управ ления проектами дол жен играть в ней ключ евую роль. Та к, достижение трет ьего и бол ее высоких уров ней зрелости п о модели (PM) про сто немыслимо бе з стандарта управ ления проектами. И именно стан дарт является форма льным отражением достиг нутого уровня зрел ости процессов управ ления проектами.
Заключение
Стандарт управ ления проектами предпр иятия представляет соб ой, прежде все го, совокупность докум ентов, объясняющих ил и предписывающих ка к, в как ой последовательности, в какие сро ки, с использ ованием каких шабл онов нужно выпол нять те ил и иные дейс твия в проц ессе управления проек тами. Эти докум енты не явля ются принадлежностью как ого-либо одн ого проекта и образуют норма тивно-методическое обеспе чение системы управ ления проектами в целом, а их колич ество может бы ть достаточно вел ико.
В си лу этого одн им из перспек тивных подходов явля ется организация станд арта как ба зы знаний, кото рая обеспечивает вс е необходимые серв исы по обнов лению и пои ску документов, п о организации взаимо связей между докуме нтами, перекрестных ссы лок и т.д. Хо тя известны прим еры и друг ого подхода, ког да для поддер жания стандарта созда ется специализированная информа ционная среда
Стан дарт управления проек тами является внутр енним документом комп ании. Однако ка к и люб ое достижение в области каче ства наличие это го стандарта оказы вает весомый маркети нговый эффект и укрепляет полож ение компании н а рынке.
Оче нь часто дл я того, что бы получить выго дный контракт, комп ания должна пока зать, что зна ет, как управ лять проектами и умеет эт о делать. Собст венно, практически в любом круп ном тендере н а разработку информа ционных систем обязат ельно содержатся требо вания в час ти управления проек тами. Иногда эт и требования нос ят конкретный хара ктер, например, "Ка к будет органи зована проектная гру ппа с уче том участия в проекте многочи сленных сторон? Как им образом буд ут поддерживаться отнош ения с разли чными партнерами?". Ча ще они формули руются в сам ом общем ви де: "Предоставьте инфор мацию по проце ссам управления Ваш ей компании, позвол яющим отслеживать и контролировать вс е аспекты, относя щиеся к прое кту, включая …".
Отме тим, прежде все го, что отв еты на подавл яющее большинство эт их вопросов в готовом ви де содержатся (дол жны содержаться) в стандарте управ ления проектами, чт о само п о себе значит ельно упрощает и удешевляет проц есс подготовки тенде рных предложений. И, кроме то го, ответы с о ссылками н а собственный стан дарт выглядят в глазах заказ чика намного бол ее привлекательными, че м вариации н а тему PMBOK, поско льку показывают, чт о в ваш ей компании оп ыт управления проек тами (а) имее тся, (б) системат изирован и (в) растиражирован, т о есть, исполь зуется массово.
Ес ли учесть, чт о вклад, дава емый в общ ую оценку тенде рных предложений требов аниями по управ лению проектами, пор ой достигает пятид есяти процентов, эффекти вность стандарта управ ления проектами стано вится достаточно очеви дной.
Список литературы
- Мих еев В.Н., Товб А.С. "Междуна родные и национ альные стандарты п о управлению проек тами, менеджменту прое ктов и професси ональной компетентности менед жеров проектов." М., 2002. – с.33-37.
- То вб А.С. Ципес Г.Л. "Станд арты в прое ктах современных информа ционных систем", М., 2002. – с.42-47.
- То вб А.С. Ципес Г.Л. Стан дарт управления проек тами уровня предпр иятия. "Директор информа ционной службы" № 1-6, 2001 и №№ 1-6, 2002.
- Баженов Р.А. "Станд арты и прав ила проектного мышл ения" (интернет-рес урс)
- Управление проек тами. Справочник дл я профессионалов. По д ред. И.И. Маз ура и В.Д. Шап иро, 2001.
- "Директор информа ционной службы" №5, 2001.
- Анализ денежных средств предприятия (на примере ООО «Климовская деревообрабатывающая компания») (Методика анализа денежных средств)
- Бухгалтерский баланс организации и порядок его составления (Роль и назначение бухгалтерского баланса)
- Теоретические основы формирования бухгалтерского баланса (Общая оценка структуры имущества предприятия и его источников по данным бухгалтерского баланса)
- Жизненный цикл предприятий
- Сравнительный анализ способов и устройств хранения данных
- Проектирование реализации операций бизнес-процесса ( Управление документооборотом )
- Право собственности граждан (Право собственности граждан на недвижимое имущество)
- Методы управления инновационными проектами (Методы управления)
- Проверка возможности использования в доказывании данных, полученных в результате ОРД
- Правовое регулирование рекламной деятельности (Правовое регулирование рекламной деятельности в РФ )
- Право на недвижимость и на земельный участок(Общие вопросы правого режима земельного участка как объекта права собственности)
- Менеджмент человеческих ресурсов (Характеристика методов диагностики и оценки мотивации)