Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Государственное бюджетное образовательное учреждение высшего профессионального образования

"Челябинский государственный университет"

К урсовая работа

" Стандарты управления проектами "

• Введение
• 1. Общие соображения по созданию стандарта. Специализация и детализация
• 2. Классификация проектов как первый этап создания стандарта
• 2.1 Что должно быть отражено в плане управления проектом
• 2.2 План управления проектом и рамочные стандарты
• 3. Проектные отклонения. Риски, проблемы, изменения
• 3.1 Управление рисками
• 3.2 Управление проблемами
• 3.3 Управление изменениями
• 4. Организационные структуры в проектах
• 5. Тактика и стратегия внедрения стандарта управления проектами
• 6. Дополнительные преимущества от внедрения стандарта
• Заключение
• Список используемой литературы

Введение

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

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

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

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

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

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

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

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

Заключение

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

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

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

Очень часто для того, чтобы получить выгодный контракт, компания должна показать, что знает, как управлять проектами и умеет это делать. Собственно, практически в любом крупном тендере на разработку информационных систем обязательно содержатся требования в части управления проектами. Иногда эти требования носят конкретный характер, например, "Как будет организована проектная группа с учетом участия в проекте многочисленных сторон? Каким образом будут поддерживаться отношения с различными партнерами?". Чаще они формулируются в самом общем виде: "Предоставьте информацию по процессам управления Вашей компании, позволяющим отслеживать и контролировать все аспекты, относящиеся к проекту, включая …".

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

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

Список используемой литературы

1. Михеев В.Н., Товб А.С. "Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов." М., 2002. - с.33-37.

2. Товб А.С. Ципес Г.Л. "Стандарты в проектах современных информационных систем", М., 2002. - с.42-47.

3. Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. "Директор информационной службы" № 1-6, 2001 и №№ 1-6, 2002.

4. Баженов Р.А. "Стандарты и правила проектного мышления" (интернет-ресурс)

5. Управление проектами. Справочник для профессионалов. Под ред. И.И. Мазура и В.Д. Шапиро, 2001.

6. "Директор информационной службы" №5, 2001.

Размещено на Allbest.ru

...

Подобные документы

Специализация и детализация при создании проектов. План управления проектом и рамочные стандарты. Проектные отклонения: управление рисками, проблемами и изменениями. Организационные структуры в проектах. Тактика и стратегия внедрения стандарта управления.

курсовая работа , добавлен 12.01.2015


Международные стандарты ISO серии 9000 как обобщение мирового опыта в сфере управления качеством. Принципы, положенные в основу для разработки и внедрения результативной и эффективной системы менеджмента качества. Рекомендации по принятию решений.

реферат , добавлен 19.05.2014


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

практическая работа , добавлен 07.04.2015


Сущность и функции корпоративной системы управления проектами (КСУП), ее элементы и предъявляемые к ней требования. Базовые методологии и процессы управления проектами. Характеристика основных ролей в контексте КСУП, этапы ее разработки и внедрения.

контрольная работа , добавлен 13.06.2013


Понятие и функции управления качеством. Международные стандарты семейства ISO 9000:2000. Разработка и процессы системы менеджмента качества, проверка ее работоспособности. Экономика и правовое обеспечение качества. Некоторые методы обеспечения качества.

учебное пособие , добавлен 28.11.2009


Понятие и структура корпоративной системы управления проектами. Основные методы диагностики уровня зрелости управления проектами. Инициация и планирование, финансирование проектов. Управление программами, рисками, коммуникациями и портфелем предприятия.

дипломная работа , добавлен 20.08.2017


Система управления рисками как неотъемлемый компонент корпоративного управления предприятием. Международные стандарты управления рисками предприятия и концепция стандарта COSO ERM. Анализ состояния систем управления рисками в казахстанских компаниях.

реферат , добавлен 21.12.2011


Понятие качества продукции в Российской Федерации. Стандарты серии ISO 9000. Методика разработки и построения системы управления качеством. Требования к терминологии, символике, упаковке, маркировке или этикеткам. Российские версии стандартов ISO.

презентация , добавлен 08.12.2013


Виды и структура инвестиционных проектов компании. Теоретические основы управления проектами. Анализ и исследование компании ООО «ВИСТрейд». Определение инвестиционных возможностей данной компании. Этапы управления проектом на прединвестиционной фазе.

дипломная работа , добавлен 26.06.2009


Понятие, состав и виды проектов. Этапы управления проектами на предприятии. Организационно-экономическая характеристика ТОО "Казцинктех". Анализ экономических показателей работы предприятия. Основные проблемы в управления проектами и пути их решения.

В армии существует поговорка: «хоть и безобразно, зато однообразно».

Зачем нужно однообразие или стандартность?

Упрощение понимания в взаимодействия.

Людям, мыслящим стандартно проще найти общее понимание друг с другом. Стандарты объединяют нации и народы. Например, европейцу в языковом и культурном плане будет сложно понять индуса, но какие-то математические термины и формулы оба будут понимать прекрасно. Точно также и английский язык, который сейчас является стандартом взаимодействия, помогает людям из разных стран общаться друг с другом.

Точно также стандарты в управлении проектами, помогают руководителям проектов со всего мира понимать друг друга

Лучшие практики.

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

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

Систематизация знаний.

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

Сейчас мы познакомимся с основными существующими на сегодняшний день стандартами в управлении проектами.

ISO 21500 – разработанное международным проектным сообществом в 2012 году руководство по управлению проектами.

ГОСТ Р 54869-2011 – российский стандарт по управлению проектами. Был введен в эксплуатацию 1 сентября 2012. В стандарте отражены основные этапы работы с проектами.

PMBOK – разработанный PMI(самая крупная в мире некоммерческая ассоциация профессиональных руководителей проектов) свод правил и законов по управлению проектами. Применяется в большинстве стран мира.

C-PMBOK – китайская версия PMBOK.

P2M – японский стандарт, который в первую очередь фокусируется на управлении программами (про то, что такое программа, вы можете прочитать в статье «Термины управления проектами. Проект, программа, портфель.». Цель данного стандарта – это реализация сложных инновационных идей и интеграция этих идей с предприятием.

М-Modell – разработанный Германий и США в 1979 году стандарт, который в первую очередь используется для создания программного обеспечения.

ICB (International Competence Baseline) IPMA – стандарт, сочетающий в себе несколько европейских стандартов. Этот стандарт включает в себя 28 основных областей знаний в управлении проектами и 14 дополнительных. Хорошо описывает компетенции менеджеров проектов. Используется в Евросоюзе, Индии, Украине, Казахстане, Азербайджане.

Hermes – швейцарский стандарт управления проектами в основном применяемый в ИТ.

PRINCE2 – первоначально был разработанных как метод ведения ИТ-проектов, но вскоре стал универсальным.

APMBOK – национальный стандарт Великобритании, охватывающий 52 нужных для ведения проекта.

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

Международный Стандарт по Управлению Проектами ISO 21500:2012

Утвержден Россией, США и Евросоюзом

I SO (Международная организация по стандартизации) является всемирной федерацией национальных организаций по стандартизации (комитетов-членов ISO). Работа по подготовке международных стандартов осуществляется через технические комитеты ISO. Каждый член организации, заинтересованный в деятельности, для которой создавался технический комитет имеет право быть представленным в этом комитете. Международные правительственные и неправительственные организации также принимают участие в этой работе совместно с ISO. ISO тесно сотрудничает с Международной электротехнической комиссией (IEC) по всем вопросам стандартизации в области электротехники.

Международные стандарты разрабатываются в соответствии с правилами, приведенными в Директивах ISO/IEC (Часть 2).

Основной задачей технических комитетов является подготовка Международных стандартов. Проекты международных стандартов, принятые техническими комитетами, рассылаются организациям-членам на голосование. Для их опубликования в качестве международных стандартов требуется одобрение по меньшей мере, 75% организаций-членов, участвующих в голосовании [данный стандарт утвержден единогласно Россией, США и Евросоюзом].

Некоторые элементы этого документа могут быть объектом патентных прав. ISO не несет ответственность за идентификацию какого-либо или всех таких патентных прав.

ISO 21500 был подготовлен Проектным комитетом ISO/PC 236, управление проектами .

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

Цели стандарта ISO 21500:

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

Обеспечить руководителей проектов и членов команды проекта эталоном для сравнения с актуальными стандартами и практиками.

Обеспечить разработчиков национальных и корпоративных стандартов базовым документом

[см. также комментарии об приоритете использования ISO 21500 над ГОСТ и PMBOK в Российской Федерации согласно Статье 7 ГК РФ ]

Введение (Introduction)

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

Целевой аудиторией для этого стандарта являются:

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

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

Разработчики национальных или внутриорганизационных стандартов для единого последовательного подхода при разработке собственных стандартов управления проектами.

Общие положения

Этот международный стандарт (ISO 21500) описывает лучшие практики по управлению проектами.

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

Этот международный стандарт (ISO 21500) рассматривает проекты в контексте программ и портфелей проектов. Не представляет собой детальное руководство по управлению программами и портфелями. Разделы имеющие отношение к общему менеджменту представлены только в из связи с управлением проектами

Термины и определения

[см. также комментарии к терминам и определениям в стандарте ]

Для целей этого документа (ISO 21500) будут использоваться следующие термины и определения.

2.1 операция (activity)

определенная часть работы в расписании которая требует реализации для завершения проекта

2.2 область применения (application area)

2.3 исходные данные (baseline)

относительная основа по сравнению с которой проект осуществляется мониторинг проекта и контроль

документация, которая устанавливает предлагаемые изменения в проекте

2.5 конфигурационный менеджмент (configuration management)

использование процедур для контроля технических требований и атрибутов

2.6 контроль (control)

Сравнение актуальной реализации с запланированной, оценка расхождения и принятие соответствующих корректирующих и превентивных действий.

2.7 корректирующие воздействие (corrective action)

Направление по изменению направления реализации работ для возврата к запланированному

2.8 критический путь (critical path)

Последовательность операций, которые определяют самую возможную раннюю дату завершения проекта.

2.9 групповая динамика (group dynamics)

Описывает как группа индивидуумов взаимодействует при принятии решений или организуется для реализации задач

2.10 Лаг (lag)

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

2.11 Лид (lead)

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

2.12 Кривая обучения (learning curve)

форма представления развития навыков в зависимости количества повторений командой или одним участником

2.13 Жизненный цикл проекта (project life cycle)

установленная последовательность фаз от начала до завершения проекта.

2.14 Руководитель проекта (project manager)

лицо ответственное за достижение требований предъявляемых к проекту.

2.15 Реестр рисков (risk register)

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

2.16 Заинтересованный участник (stakeholder)

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

2.17 Тендер (tender)

документ в форме сбора предложений для обеспечения закупок продуктов или услуг.

2.18 Словарь иерархической структуры работ (work breakdown structure dictionary)

документ, которые описывает каждый из компонентов структурной декомпозиции работ.

3 Концепция управления проектами (Project management concepts)

3.1 Обзор (Overview)

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

Рисунок 1 - Обзор концепции управления проектами в связи с другими сущностями

Легенда: Блоки представляют понятия управления проектами, введенные в следующих разделах

Стрелки представляют собой логическую последовательность, в которой понятия связаны

Пунктирные линии представляют собой организационные границы

3.2 Проект (Project)

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

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

У любого проекта есть установленное начало и завершение. Обычно проект реализуется через ряд фаз. Проект начинается и завершается в соответствии с разделом 4.3.1.

3.3 Управление проектом (Project management)

Управление проектами – это применение методов, инструментов, техник и компетенцией к проекту. Управление проектами включает интеграцию различных фаз жизненного цикла проекта, как описано в разделе 3.10.

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

3.4 Стратегия организации и проекты (Organizational strategy and projects)

3.4.1 Стратегия организации (Organizational strategy)

Организации утверждают стратегию основанную на миссии, видении и политике. Проекты, обычно подчинены являются стратегическим целям. На Рисунке 2 представлен типовой цикл управления портфелем проектов для от стратегии к получению выгод (преимуществ).

Рисунок 2 - Управление портфелем проектом от стратегии до получения преимуществ (см. также комментарии )

3.4.2 Определение возможностей и инициация проектов (Opportunity identification and project initiation)

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

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

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

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

[Данные положения ISO 21500 связаны с типовых сценарием управления портфелем проектов, описывая стыковку с будущим стандартом ISO по Портфелям проектов. Более подробно см. в комментариях ]

3.4.3 Реализация преимуществ (Benefits realisation)

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

3.5 Среда проекта (Project environment)

3.5.1 Общие положения (General)

Окружение проекта может влиять на эффективность реализации и успех проекта. Команда проекта должна учитывать следующее:

Внешние факторы вне границ материнской организации - социально-экономическая, георграфическиая, политическая, правовая, технологическая и экологическая ситуация.

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

3.5.2 Проекты в материнской организации (Projects within the organizational boundary)

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

Рисунок 3 - Проекты, программы и портфели проектов

3.5.2.1 Управление портфелем проектов (Project portfolio management)

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

Может оказаться целесообразным проведение выявления и выбора возможностей, утверждения и управления проектами с помощью автоматизированной системы управления портфелями проектов [подробнее см. в комментариях ].

3.5.2.2 Управление программой (Programme management)

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

3.6 Внешнее Руководство проектом (Project governance)

Внешнее Руководство (Governance) - это организационная система, с помощью которой организацией управляют и контролируют. Руководство проектом касается тех сфер организации, которые непосредственно относятся к работам в проекте.

Внешнее Руководство проектом включает такие аспекты, как определение структуры управления; политика, процессы и методологии, которые будут применяться; ограничения в полномочиях при принятии решений; ответственность и подотчетность заинтересованных участников; взаимодействия такие, как отчетность и эскалация проблем или рисков. Ответственность за обеспечение соответствующего руководства проектом возлагается как на Куратора проекта, так и на руководящий комитет проекта.

3.7 Проекты и операционная деятельность (Projects and operations)

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

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

3.8 Заинтересованные стороны и оргструктура проекта (Stakeholders and Project Organization)

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

Рисунок 4 – Заинтересованные стороны проекта (Project Stakeholders )

Взаимодействия заинтересованными сторонами осуществляется с помощью процессов управления проектами, описанными в пункте 4.

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

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

команда управления проектом (при необходимости) - оказывает помощь менеджеру проекта в руководстве и управлении работами проекта и достижении результатов проекта.

команда проекта - исполняет работы проекта для успешного завершения проекта

Внешнее управление проектом Заказчиком (Project governance) может включать в себя следующих лиц:

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

Руководящий комитет или совет (при необходимости) - вносит свой вклад в проект обеспечивая высший уровень руководства проекта.

Рисунок 4 включает в себя следующих дополнительных заинтересованных лиц:

Заказчик или представитель Заказчика - вносят вклад в проект, посредством формирования требований к проекту и принятия результатов проекта;

поставщики - вносят вклад в проект путем предоставления ресурсов для реализации проекта.

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

3.9 Компетенции участников проекта (Competencies of project personnel)

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

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

Компетенции управления проектами могут быть классифицированы, но не ограничиваются, следующим:

Техническими компетенциями, для реализации проектов структурированно, включая терминологию, понятия и процессы управления проектами определенные в настоящем Международном стандарте;

Поведенческими компетенциями, связанными с личными отношениями внутри определенных границ проекта;

Контекстные компетенции, связанные с управлением проектом внутри организационной и внешней среды.

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

3.10 Жизненный цикл проекта (Project life cycle)

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

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

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

3.11 Ограничения проекта (Project constraints)

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

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

Некоторые ограничения могут быть такими:

Продолжительность или целевая дата для осуществления проекта;

Наличие бюджета проекта;

Наличие ресурсов для проекта, таких как люди, сооружения, оборудование, материалы, инфраструктура, инструменты и другие ресурсы, необходимых для выполнения проектных мероприятий, связанных с требованиями проекта;

Факторы, связанные со здоровьем и безопасностью персонала;

Уровень приемлемого риска;

Потенциальные социальные или экологические последствия проекта;

Законы, нормы и другие законодательные требования.

3.12 Взаимосвязь между концепцией и процессами (Relationship between concepts and processes)

Управление проектом осуществляется через процессы с применением понятий и компетенций, изложенных в пп с 3.1 по 3.11. Процесс представляет собой совокупность взаимосвязанных действий. Процессы, используемые в проектах, как правило, делятся на три основных категории:

процессы управления проектами, которые являются специфическими для управления проектами и определяют, как управляются действия, отобранные для проекта;

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

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

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

4. Процессы управления проектами (Project management processes)

[См. также контрольную матрицу по процессам управления проектами по ISO 21500 для проверки соответствия ваших регламентов Стандарту]

4.1 Применение процессов управления проектом (Project management process application)

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

Руководителям проекта совместно с другими заинтересованными сторонами проекта рекомендуется внимательно изучить процессы, приведенные в п. 4.3, в качестве руководства высокого уровня, чтобы применять те процессы, которые соответствуют проекту и потребностям организации.

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

Для того чтобы проект был успешным, менеджер проекта и проектная команда должны:

выбрать соответствующие процессы, описанные в п. 4.3, которые необходимы для достижения целей проекта;

использовать соответствующий подход к разработке или адаптации спецификации продукта и планов по достижению целей и требований проекта;

соблюдать требования, для удовлетворения спонсора, клиентов и других заинтересованных сторон проекта;

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

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

Процессы управления проектами в данном стандарте определены в терминах целей, которым они служат, отношениям между процессами, взаимодействия в рамках процессов, а также первичных входов и выходов, связанных с каждым процессом.

4.2 Группы процессов и предметные группы (Process groups and subject groups)

Процессы управления проектами можно рассматривать в двух различных ракурсах: с точки зрения управления проектом как групп процессов описанных в пункте 4.2.1, и с точки зрения группировки процессов по предметным областям описанных в пункте 4.2.2 как предметные группы. Эти две различные группы представлены в таблице 1. Отдельные процессы описаны более подробно в п.4.3. Каждый процесс показан в группе процессов и предметной группе, в которой осуществляется большая часть его активности. Например, если процесс, который обычно происходит во время планирования, пересматривается или дорабатывается во время исполнения, то сам процесс тот же, который был выполнен при планировании, а не дополнительный новый процесс.

Таблица 1 - Соответствие процессов управления проектами группам процессов и предметным группам

Предметные группы	Группы процессов
Инициирование	Планирование	Исполнение	Управление	Завершение
Интеграция	4.3.2 Разработка устава проекта	4.3.3 Разработка планов проектов	4.3.4 Непосредственная работа по проекту	4.3.5 Управление проектными работами	4.3.7 Закрытие отдельной фазы или проекта
			4.3.6 Управление изменениями	4.3.8 Извлеченные уроки
Заинтересованные стороны	4.3.9 Определение заинтересованных сторон		4.3.10 Управление заинтересованными сторонами
		4.3.11 Определение содержания проекта		4.3.14 Управление содержанием проекта
	4.3.12 Создание структуры декомпозиции работ
	4.3.13 Определение состава работ
	4.3.15 Создание команды проекта	4.3.16 Оценка ресурсов	4.3.18 Развитие команды проекта	4.3.19 Управление ресурсами
	4.3.17 Определение организационной структуры проекта		4.3.20 Управление командой проекта
		4.3.21 Последовательность работ		4.3.24 Управление расписанием
	4.3.22 Оценка длительности работ
	4.3.23 Разработать расписания
Стоимость		4.3.25 Оценка затрат		4.3.27 Управление затратами
	4.3.26 Разработка бюджета
		4.3.28 Определение рисков	4.3.30 Отношение к рискам	4.3.31 Управление рисками
	4.3.29 Оценка рисков
Качество		4.3.32 Плана по качеству	4.3.33 Обеспечение требований качества	4.3.34 Управление качеством
Поставки		4.3.35 Плана поставок	4.3.36 Выбор поставщиков	4.3.37 Администрирование контрактов
Коммуникации

Управление проектами — в соответствии с определением национальным стандартом ANSI PMBoK — область деятельности, в ходе которой определяются и достигаются четкие цели проекта при балансировании между объёмом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и др.), временем, качеством и рисками. Ключевым фактором успеха проектного управления является наличие чёткого заранее определённого плана, минимизации рисков и отклонений от плана, эффективного управления изменениями (в отличие от процессного, функционального управления, управления уровнем услуг).

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

Управление проектами является частью системы менеджмента предприятия.

Альтернативные стандарты и школы иногда вкладывают в понятие управления проектами более широкий или более специфический смысл.

История

В основе современных методов управления проектами лежат методики структуризации работ и сетевого планирования, разработанные в конце 50-х годов XX века в США.

Классическая форма тройственной ограниченности

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

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

Ограниченность времени определяется количеством доступного времени для завершения проекта. Ограниченность стоимости определяется бюджетом, выделенным для осуществления проекта. Ограниченность содержания определяется набором действий, необходимых для достижения конечного результата проекта. Эти три ограниченности часто соперничают между собой. Изменение содержания проекта обычно приводит к изменению сроков (времени) и стоимости. Сжатые сроки (время) могут вызвать увеличение стоимости и уменьшение содержания. Небольшой бюджет (стоимость) может вызвать увеличение сроков (времени) и уменьшение содержания.

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

Подходы

Существует множество подходов к управлению проектами в зависимости от типа проекта:

· предположение о неограниченности ресурсов, критичен только срок выполнения и качество — метод PERT, метод критического пути;

· предположение о критичности качества, при этом требования к сроку и ресурсам достаточно гибки (под качеством здесь понимается полнота удовлетворения потребностей, как известных, так и неизвестных заранее, часто создаваемых выходом нового продукта) — гибкая методология разработки;

· предположение о неизменности требований, низких рисках, жесткий срок, из этого исходят классические методы PMBOK, во многом опирающиеся на модель водопада;

· предположение о высоких рисках проекта — метод инновационных проектов.

Существуют также варианты нейтральных (сбалансированных) подходов, делающие либо акцент на взаимодействие исполнителей (метод PRINCE2), либо на взаимодействие процессов (процессно-ориентированное управление).

Роли в проекте

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

Заказчик определяет цель и ограничения проекта и его финансирование. Исполнитель выполняет проект согласно утвержденному плану.

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

В случае четкого разделения ролей заказчик-исполнитель целью управления проектом является стабилизация работ и минимизация отклонений от утвержденного заказчиком плана.

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

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

Цель управления проектом и успешность проекта

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

Группы оценок успешности:

Ориентированные на контракт , например традиционные методологии, в том числе PMBOK: «проект успешен, если выполнен согласно утвержденным критериям: объёму, сроку, качеству». То есть проект успешен, если исполнен и закрыт договор между Заказчиком и Исполнителем (вне зависимости от того, являлся ли он юридическим документом в случае внешних проектов или определялся как-то иначе в случае внутренних проектов). При этом оценка успешности единая как для заказчика так и для исполнителя.

Ориентированные на заказчика , например гибкие методологии SCRUM, частично управление программами, направленное на длительное взаимодействие, а не на один проект/контракт: «проект успешен, если заказчик удовлетворен». Здесь делается акцент на продолжение сотрудничества Исполнителя с Заказчиком в рамках последующих проектов и иного взаимодействия, либо проект можно рассматривать как программу из нескольких небольших проектов. Оценка успешности рассматривается в основном с точки зрения заказчика.

Сбалансированные , например PRINCE2: «проект успешен при сбалансированности по крайней мере по трем категориям — бизнеса, ориентации на пользователя и технологической зрелости». Здесь делается акцент на финансовой успешности проекта, удовлетворенности пользователей и развитии (косвенная польза для самого исполнителя). Оценка успешности может различаться с точки зрения бизнеса, пользователя и исполнителя. Такие методики оценки чаще используются для внутренних проектов, когда заказчик и исполнитель находятся в одной организации.

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

В целом можно определить цель управления проектами следующим образом:

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

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

Корпоративная система управления проектами

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

Процедуры управления проектом

Процедуры управления проектом по традиционной методологии

Последовательность процедур управления проектом:

· Определение среды проекта.

· Формулирование проекта.

· Планирование проекта.

· Техническое выполнение проекта (за исключением планирования и контроля).

· Контроль над выполнением проекта.

Процедуры управления проектом по методологии PMI

· Основные процедуры и процессы PMI описаны в стандарте PMBOK:

· Определение требований к проекту

· Постановка чётких и достижимых целей

· Балансирование конкурирующих требований по качеству, возможностям, времени и стоимости

· Адаптация спецификаций, планов и подходов для нужд и проблем различных заинтересованных лиц (стейкхолдеров)

Процедуры управления проектом по методологии IPMA

· Системное представление Управления проектами IPMA

Процедуры управления проектом по методологии PRINCE

· Начало проекта (SU).

· Запуск проекта (IP).

· Планирование проекта (PL).

· Управление проектом (DP).

· Контроль стадий (CS).

· Контроль границ стадий (SB).

· Управление производством продукта (MP).

· Завершение проекта (CP).

Прочие процедуры (управление командой, контрактами) вынесены «за рамки» методологии и называются инструментарием менеджера проекта. Кроме того, методология рассматривает «компоненты», которые состоят из Бизнес плана (Business Case), организации, планирования, управления рисками, управления качеством, управление конфигурацией, контроля и управления изменениями.

План управления проектом

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

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

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

Международные стандарты управления (менеджмента) проектами:

· ISO 10006:2003, Quality management systems — Guidelines for quality management in projects (вРоссииприняткакГОСТРИСО 10006-2005 Системыменеджментакачества. Руководство по менеджменту качества при проектировании )

· ISO 21500:2012 Guidance on project management (в России принят как ГОСТ Р ИСО 21500 - 2014 «Руководство по проектному менеджменту»)

Национальные стандарты с расширенной географией применения:

· ANSI PMI PMBOK 5th Edition - A Guide to the Project Management Body of Knowledge (PMBOK Guide)

· PRINCE2 (PRojects IN a Controlled Environment)

· ISEB Project Management Syllabus

· Oracle Application Implementation Method (AIM)

Национальные стандарты управления проектами:

· ГОСТ Р 54869—2011 «Проектный менеджмент. Требования к управлению проектом» (Россия)

· ГОСТ Р 54870—2011 «Проектный менеджмент. Требования к управлению портфелем проектов» (Россия)

· ГОСТ Р 54871—2011 «Проектный менеджмент. Требования к управлению программой» (Россия)

NASA Project Management (США )

· BSI BS 6079 (Великобритания)

· APM Body of Knowledge (Великобритания)

· OSCEng (Великобритания)

· DIN 69901 (Германия)

· V-Modell (Германия)

· VZPM (Швейцария)

· AFITEP (Франция)

· Hermes method (Швейцария)

· ANCSPM (Австралия)

· CAN /CSA -ISO 10006-98 (Канада)

· P 2M (Япония)

· C-PMBOK (Китай)

· South African NQF4 (ЮАР)

CEPM (Индия )

PROMAT (Южная Корея)

Стандарты оценки компетенции менеджера проекта:

· ICB IPMA Competence Baseline (IPMA)

· НТК (Национальные требования к компетентности специалистов) (Ассоциация управления проектами «СОВНЕТ», Россия)

PMCDF (США )

NCB UA (National Competence Baseline, Version 3.0) (Украина)

Методологии управления проектами

Методология PMI, сформулированная в виде стандарта PMBOK, базируется на концепции управления проектами через группу стандартных процессов. Однако последняя версия стандарта PMBOK отражает существенную коррекцию методологии в сторону интерактивных методик

Методология IW URM (Unique Reliable Method), разрабатывалась и оттачивалась с тем, чтобы в любом проекте был гарантирован успех — цели клиента достигнуты в оговоренный срок, в рамках определенного бюджета и с необходимым качеством. Для реализации разных типов проектов используется набор различных процедур, документов и технологий, наиболее подходящих для конкретного типа проекта.

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

Методология P2M базируется в ориентированности не на продукт или процессы, а на улучшение организации в результате выполнения проектов. Иными словами, методология описывает, как использовать полученный в результате выполнения проектов опыт для развития компании.

Программное обеспечение

Существует программное обеспечение как для управления проектами, так и управления портфелем проектов.

Регламент управления проектами (корпоративный стандарт управления проектами) - это внутренний нормативный документ в организации, который определяет подход к управлению проектами , программами и портфелем. Основная часть регламента посвящена описанию процесса, ролей, ответственностей и результатов (промежуточных и окончательных). Регламенты обычно пишутся на основании различных мировых или локальных стандартов (PMBoK , PRINCE2, ISO 21500, ГОСТ 54 и т.д.). Любой регламент содержит в основе процессы, описанные на основе стандартов, про которые писалось ранее и по большому счету мало отличаются друг от друга. Специфика по областям деятельности (ИТ, Строительство и т.д.) достигается выпуском дополнительных приложений, уточняющих детали той или иной области, специфики работы.

Пример регламента управления проектами

Далее описана структура регламента управления проектами и приведен пример для крупных ИТ-компаний. Легенда следующая - существует Группа Компаний (Группа "PME"), в состав которой входит головная компания (ОАО "ГОЛОВНАЯ КОМПАНИЯ") и множество дочерних. И головная и дочерние имеют сеть филиалов по стране. Одна из дочерних компаний (ООО «ДОЧЕРНЯЯ КОМПАНИЯ») является исполнителем (оператором) по проектам и отвечает за информационно-технологическое обеспечение всей Группы компаний (проекты по разработке и внедрению информационных систем управления).

Регламент написан достаточно подробно и даёт основное понимание (пример) того, что именно пишется в тех или иных разделах, как самого регламента управления проектами, так и всех неотъемлемых приложений (Устав проекта, План управления проектом, Описание содержания и т.д.). При использовании данного регламента управления проектами для нужд своей компании, достаточно просто избавиться от лишнего и скорректировать связанные процессы. Регламент служит подробным примером написания такого рода документов и доступен для бесплатного скачивания. Скачать регламент управления проектами можно в конце статьи по ссылке.

Описание

Цель регламента управления проектами по направлениям ИТО в ООО «ДОЧЕРНЯЯ КОМПАНИЯ» (далее - Регламент) - сформировать единый подход к управлению проектами по направлениям информационно-технологического обеспечения (далее - проектами), оператором по которым является ООО «ДОЧЕРНЯЯ КОМПАНИЯ».

Задачи Регламента:

• описание порядка проведения основных процедур управления проектами;
• разграничение функций между участниками процесса управления проектами;
• определение требований к составу документов, необходимых при проведении процедур управления проектами;
• определение сроков выполнения функций при проведении процедур управления проектами.

Структура и описание регламента управления проектами:

Регламент процесса управления проектами
по направлениям ИТО в
ООО «ДОЧЕРНЯЯ КОМПАНИЯ»

1. Общие положения

1.1. Введение

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

Например:

Цель Регламента процесса управления проектами - сформировать единый подход к управлению проектами по направлениям информационно-технологического обеспечения (далее - проектами), оператором по которым является ООО «ДОЧЕРНЯЯ КОМПАНИЯ».

Задачи Регламента:

• описание порядка проведения основных процедур управления проектами;
• разграничение функций между участниками процесса управления проектами;
• определение требований к составу документов, необходимых при проведении процедур управления проектами;
• определение сроков выполнения функций при проведении процедур управления проектами.

Цель процесса управления проектами – обеспечение достижения целей проектов при заданных ресурсных и временных ограничениях.

Задачи совершенствования процесса управления проектами:

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

1.2. Область применения

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

Например:

Действие настоящего Регламента распространяется на все структурные подразделения аппарата управления ООО «ДОЧЕРНЯЯ КОМПАНИЯ» и филиалы в части деятельности по управлению реализацией проектов ИТО.

В филиалах ООО «ДОЧЕРНЯЯ КОМПАНИЯ» управление проектами и портфелями проектов филиалов осуществляется в соответствии с настоящим Регламентом и нормативно-регламентными документами, разрабатываемыми в филиалах и отражающими особенности процессов управления в условиях конкретной организации.

1.3. Нормативные документы

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

Например:

Настоящий Регламент разработан на основании следующих документов:

• Инвестиционная политика Группы «PME», утвержденная решением Правления ОАО «ГОЛОВНАЯ КОМПАНИЯ» от --.--.--;
• Положение об управлении инвестиционной деятельностью в Группе «PME», утвержденное решением Правления ОАО «ГОЛОВНАЯ КОМПАНИЯ» от --.--.--;
• Методика оценки эффективности проектов в области информационно-технологического обеспечения, утвержденная решением Правления ОАО «ГОЛОВНАЯ КОМПАНИЯ» от --.--.--;
• Бюджетный регламент Группы «PME», утвержденный решением Правления ОАО «ГОЛОВНАЯ КОМПАНИЯ» от --.--.--.

При разработке Регламента использовались рекомендации, содержащиеся в следующих методологиях и стандартах:

• The Standard for Portfolio Management (PMI 2006);
• ANSI/PMI 99-001-2008. Project Management Body of Knowledge (PMBOK);
• Information Technology Infrastructure Library (ITIL);
• ISO/IEC 20000 Information Technology – Service Management;
• ГОСТ Р ИСО/МЭК 12207. «Информационная технология. Процессы жизненного цикла программных средств»;
• ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;
• ГОСТ Р ИСО 9000:2000;
• ГОСТ 54869-2011 «Проектный менеджмент. Требования к управлению проектом»;
• ГОСТ 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов»;
• ИСО/ТО 10006:1997 (Е). «Менеджмент качества. Руководство качеством при управлении проектами».

1.4 Термины, определения и принятые сокращения

Описание терминов и их определений используемых в настоящем Регламенте, а также принятые сокращения.

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

2. Требования к объектам управления

2.1 Определение объектов управления

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

Например:

Объектами управления являются:

• портфель проектов;
• проект/инвестиционное мероприятие;
• подпроект;
• работа.

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

2.3. Классификация проектов

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

Например:

Основными классификационными признаками для группировок проектов являются:

• принадлежность к Бизнес-сегменту организации – пользователю/общекорпоративному проекту;
• принадлежность к Бизнес-сегменту организации – балансодержателю результатов проекта ИТО;
• принадлежность к направлению деятельности ИТО;
• категория проектов;
• объемы инвестиций в проект;
• наличие оцениваемого экономического эффекта;
• организации-пользователи / Функциональные заказчики проектов ИТО;
• организации – балансодержатели результатов проекта ИТО;
• кураторы проектов;
• структурные подразделения ООО «ДОЧЕРНЯЯ КОМПАНИЯ», реализующие проект.

2.4. Жизненный цикл проекта

В данном разделе перечисляются стадии жизненного цикла проекта.

Например:

Для целей настоящего Регламента в рамках жизненного цикла проекта выделяются следующие стадии:

• стадия запуска;
• стадия планирования;
• стадия исполнения;
• стадия завершения.

3. Участники процессов управления проектами

3.1. Участники процессов управления проектами

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

Например:

Основными участниками процесса управления проектами в ООО «ДОЧЕРНЯЯ КОМПАНИЯ» являются:

• Совет по управлению проектами;
• Отдел организации управления проектами;
• Отдел управления портфелем программ и проектов;
• Куратор проекта;
• Куратор проекта от ЦАУ (по проекту 3-й категории, реализуемому филиалом);
• Руководитель Проектного офиса (Проектной группы);
• Администратор Проектного офиса (Проектной группы);
• Владелец ресурса;
• Менеджер проектных рисков;
• Владелец риска.

3.2. Функции по управлению проектами

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

Например:

Совет по управлению проектами:

• Формирование предложений по назначению Кураторов проектов, определению категорий проектов;
• Координация запуска связанных проектов, формирование предложений по корректировке дат запуска проектов;
• Рассмотрение отчетности, аналитических материалов по состоянию портфеля проектов;
• Рассмотрение Запросов на изменения по отдельным проектам, управление конфигурацией изменений в целом по портфелю проектов;
• Подготовка решений по перераспределению инвестиций между отдельными проектами и по корректировке лимита инвестиций по Обществу в целом;
• Подготовка решений в части ресурсного обеспечения портфеля проектов;
• Инициация досрочного завершения проектов.

Отдел организации управления проектами:

• Разработка проектов Приказов ООО «ДОЧЕРНЯЯ КОМПАНИЯ» о реализации Инвестиционной программы в планируемом году;
• Проверка корректности введенных в ИАС данных по проектам;
• Внесение данных в Реестр Руководителей Проектных офисов (Проектных групп);
• Анализ отчетных данных по проектам;
• Формирование сводных отчетов о состоянии и прогрессе проектов, аналитических отчетов по состоянию портфеля проектов и его ресурсообеспеченности;
• Формирование предложения по вариантам решений по запросам на изменения параметров проектов;
• Разработка прогнозов по реализации проектов;
• Рассылка аналитических материалов для рассмотрения членам Совета по управлению проектами;
• Контроль исполнения решений по изменениям портфеля проектов.

Владелец ресурса:

• Согласование Ресурсного плана;
• Принятие решений о привлечении к работе в Проектном офисе (Проектной группе) конкретных сотрудников;
• Рассмотрение представленной Руководителем Проектного офиса (Проектной группы) информации об эффективности работы сотрудников для проведения аттестации проектного персонала.

3.3. Требования к организационной структуре проектов

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

4. Описание процессов управления проектом

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

Процессами управления проектом являются:

• запуск (соответствует стадии запуска в жизненном цикле проекта);
  • назначение Кураторов проектов, категорирование и формирование графика запуска проектов;
  • подготовка и издание приказов о запуске и реализации проекта;
  • разработка и утверждение Устава проекта;
  • ввод данных о проекте в Реестр проектов ИАС.
• планирование (соответствует стадии планирования в жизненном цикле проекта);
  • Формирование Плана проекта (после запуска проекта) в первом годовом цикле;
  • Формирование Детализированного Календарного плана, Ресурсного плана, Бюджета проекта и Плана расходов по инвестиционному проекту ИТО на планируемые годовые периоды, следующие за годом запуска проекта;
  • Формирование Бюджета проекта и Плана расходов по инвестиционному проекту ИТО на планируемый квартал/ месяц;
  • Заключение договоров.
• мониторинг и управление (соответствует стадии исполнения в жизненном цикле проекта);
  • мониторинг параметров проекта;
  • управление изменениями параметров проекта;
  • мониторинг рисков по проекту;
  • мониторинг устранения недостатков по результатам опытно-промышленной эксплуатации;
  • управление трудовыми ресурсами.
• управление изменениями (соответствует любой стадии жизненного цикла проекта);
  • завершение договора;
  • завершение этапа;
  • завершение проекта.
• завершение (соответствует стадиям исполнения и завершения в жизненном цикле проекта).

Например:

5. Описание процессов управления портфелем проектов

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

В основном ограничиваются следующими процессами управления портфелем проектов:

• формирование отчетности о состоянии портфеля проектов;
  • формирование сводной отчетности по портфелю проектов;
  • формирование отчетности по динамике реализации проектов;
  • формирование прогнозов исполнения портфеля проектов;
  • формирование отчетов по показателям портфеля проектов;
  • формирование отчетов по структуре портфеля проектов.
• анализ отчетности по портфелю проектов;
• управление изменениями портфеля проектов;
  • завершение отдельных проектов;
  • временная остановка реализации отдельных проектов;
  • инициация открытия новых проектов.

6. Документирование и хранение Регламента

В данном разделе определяют структурное подразделение ответственное за сопровождение данного регламента и место хранения регламента по управлению проектами.

Например:

Контрольный экземпляр настоящего Регламента хранится в ООУП. Электронная версия настоящего Регламента находится на внутреннем корпоративном Портале и доступна для чтения всем пользователям.

7. Внесение изменений в Регламент

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

8. Распределение Регламента

Ответственными за порядок доведения требований настоящего Регламента до Руководителей структурных подразделений является ООУП (Проектный офис).

9. Организация изучения Регламента

Ответственными за доведение требований настоящего Регламента до работников структурных подразделений являются Руководители структурных подразделений компании.

Приложения к регламенту

• Приложение 1. Порядок выполнения процедур запуска проектов
• Приложение 2. Приказ ООО «ДОЧЕРНЯЯ КОМПАНИЯ»
• Приложение 3. Приказ ОАО «ГОЛОВНАЯ КОМПАНИЯ»
• Приложение 4. Приказ ООО «ДОЧЕРНЯЯ КОМПАНИЯ»
• Приложение 5. Приказ о реализации проекта
• Приложение 6. Приказ ООО «ДОЧЕРНЯЯ КОМПАНИЯ»
• Приложение 7. Реестр проектов ИТО ООО «ДОЧЕРНЯЯ КОМПАНИЯ»
• Приложение 8. Приказ ОАО «ГОЛОВНАЯ КОМПАНИЯ»
• Приложение 9. Типовой Устав проекта
• Приложение 10. Типовой Устав проекта (упрощенный)
• Приложение 11. Порядок выполнения процедур планирования проектов
• Приложение 12. Приказ о завершении проекта ООО «ДОЧЕРНЯЯ КОМПАНИЯ»
• Приложение 13. План по вехам
• Приложение 14. Укрупненный календарный план
• Приложение 15. Детализированный календарный план
• Приложение 16. Бюджет проекта
• Приложение 17. Ресурсный план (форма УП-13-1)
• Приложение 17. Ресурсный план (форма УП-13-2)
• Приложение 17. Ресурсный план (форма УП-13-3)
• Приложение 17. Требования к определению ставки работника
• Приложение 18. План коммуникаций
• Приложение 19. План управления рисками
• Приложение 20. Методические указания по календарному планированию и учету фактического исполнения календарных планов
• Приложение 21. Реестр рисков
• Приложение 22. Методические указания по управлению рисками
• Приложение 23. Матрица назначений на проектные роли
• Приложение 24. Ролевые профили
• Приложение 25. Порядок выполнения процессов мониторинга и управления
• Приложение 26. Запрос на изменения
• Приложение 27. Реестр запросов на изменения
• Приложение 28. Итоговый отчет
• Приложение 29. Приказ о завершении проекта
• Приложение 30. Реестр Руководителей Проектных офисов \ Проектных групп (Руководителей проектов)
• Приложение 31. Аналитическая записка
• Приложение 32. Порядок выполнения процедур завершения проекта
• Приложение 33. Содержание раздела «Техническая поддержка» руководства пользователей ИС