Преподаватель который помогает студентам и школьникам в учёбе.

Стандарты управления проектами (Жизненный цикл проекта)

Содержание:

Введение

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

В данной теме я опишу сущность проекта,его жизненный цикл и методы применяемы для его исполнения. А в качестве примера приведу ряд национальных и зарубежных стандартов позволяющих контролировать качество проекта,облегчающих работу как руководителей так и исполнителей проектов. Целью курсовой работы является рассмотрение видов стандартов и ГОСТов.При написании работы я опиралась на издание Новиков Д.А. Управление проектами: организационные механизмы, что бы описать методологию управления проектами. Рассматривая проект и его сущность, я отталкивалась от самоучителя «Основы управления проектами», а так же много информации было взято с надежных сайтов.

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

1.1 Сущность проекта

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

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

Существует ряд определений понятия «проект», каждое из которых имеет право на существование. Специалисты по управлению проектами пользуются тем из них, что наиболее подходит к решаемой ими задаче.[26]

Проект — это временное предприятие, предназначенное для создания уникальных продуктов или услуг.

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

Уникальность продуктов или услуг проекта обусловливает необходимость последовательного уточнения их характеристик по мере выполнения проекта.[18]

Проект как объект управления изучается в таком разделе современной теории управления как управление проектами (УП). Исторически сложились четыре обширных раздела теории управления проектами.

1. Календарно-сетевое планирование и управление (КСПУ), использующее методы теории графов для построения и оптимизации сетевого графика проекта и распределения ресурсов. Это направление появилось в начале 50-х годов XX века и долгое время под управлением проектами понималось именно КСПУ.

2. «Методология» управления проектами, отражающая сложившуюся на сегодняшний день терминологию и успешный опыт реализации проектов. Это направление, которое условно можно считать разделом менеджмента, выделилось в самостоятельное в начале 80-х годов XX века, и сегодня большинство, как теоретических исследований, так и практико-ориентированных работ по управлению проектами, относятся именно к этому направлению.

3. Механизмы управления проектами – организационные процедуры принятия управленческих решений, основывающиеся на разработке и анализе математических моделей организационного управления проектами. Это направление появилось в начале 70-х годов XX века и может рассматриваться как раздел 8 общей математической теории управления организационными и социально-экономическими системами.

4. Информационные системы управления проектами (ИСУП), позволяющие получать, хранить, перерабатывать и использовать для принятия решений информацию о проекте и его окружении. Информационное обеспечение УП стало самостоятельным направлением информационных систем с середины 80-х годов XX века, и на сегодняшний день существует множество программных средств управления проектами самого разного масштаба.[2]

В проекте должны быть четко определены:
Цели и запланированные результаты
Уровень качества
Этапы и сроки выполнения работ
Бюджет по срокам и видам работ

Перечисленные выше параметры – область охвата, качество, время, и стоимость - тесно связаны между собой. Область охвата, время, и стоимость образуют так называемый треугольник проекта (рис 1). Качество находится в центе этого треугольника. Изменение любой из сторон треугольника неизбежно ведет к изменению остальных сторон проекта и оказывает влияние на качество. Увеличение области охвата может привести к увеличению времени. Дополнительное время позволит повысить качество отдельных работ и всего проекта. С другой стороны, увеличение времени или области охвата предполагает дополнительные расходы.

В процессе своего развития проект проходит через несколько этапов, которые составляют жизненный цикл проекта.[3]

качество

время

стоимость

область охвата

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

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

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

Каждый проект состоит из этапов (фаз). Этапы проекта могут следовать один за другим, пересекаться и идти параллельно. Совокупность таких этапов и называют жизненным циклом проекта.

Жизненный цикл проекта определяют фазы, которые связывают начало проекта с его завершением.

Каждая фаза знаменуется получением одного или нескольких результатов.[19]

Характеристики фаз проекта (терминология)

1.Замысел (идея)

2.Прединвестиционная фаза:

Анализ проблем и препятствий

Разработка концепции

Разработка бизнес плана +Предварительный план

Анализ уровня риска

3.Разработка проекта:

Заключение контрактов
Формирование команды проекта
Структурное планирование
Разработка окончательного плана проекта

4.Реализация проекта:

Выполнение работ проекта
Мониторинг
Управление ходом

5.Ликвидация проекта:

Эксплуатационные испытания
Подготовка кадров для текущей эксплуатации
Сдача объекта заказчику
Подготовка итоговых документов
Возврат кредита [6]

Рис.2 Распределение трудозатрат по фазам жизненного цикла

Инвестиционный цикл принято делить на фазы, каждая из которых имеет свои цели и задачи:

прединвестиционную – от предварительного исследования до окончательного решения о принятии инвестиционного проекта;
инвестиционную – включающую проектирование, заключение договора или контракта, подряда на строительные работы и т.п.;
операционную (производственную) – стадию хозяйственной деятельности предприятия (объекта);
ликвидационную – когда происходит ликвидация последствий реализации ИП.

Прединвестиционная фаза включает несколько стадий:

а) определение инвестиционных возможностей;

б) анализ с помощью специальных методов альтернативных вариантов проектов и выбор проекта;

в) заключение по проекту;

г) принятие решения об инвестировании.

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

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

1.3 Двухфазная модель жизненного цикла

Основные этапы ЖЦП формируются в логико-временной структуре деятельности. Ранее отмечено, что состав фаз различается по отраслям и по позициям соответствующих авторов-методистов, разрабатывающих модели управления. Интерес представляет пример двухфазного состава структуры ЖЦ. Его содержание включает фазу разработки и фазу реализации. Характеристики фазы разработки отражают деятельность по:

формулированию целей;

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

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

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

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

Рис.3 Зависимость основных параметров проекта от фаз ЖЦП

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

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

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

Методология управления проектами – это подход к формированию набора методов, который структурирует систему управления проектами и отражается в руководствах.[4]

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

Как эталон (желаемое состояние) управления ИТ-проектом и ИТ-компанией «эффективная методология – серебряная пуля»;
Для обоснования существующей практики управления проектами. Как доказательство (обоснование) правильности принятых решений
Как руководство, содержащее конкретные рекомендации –«методология»
Как набор требований, предъявляемых клиентами, партнерами, собственниками, государственными организациями, профессиональными объединениями – «стандарт»
Для обеспечения «эффективного» диалога между менеджментом, участниками проектных команд, клиентами и субподрядчиками – «глоссарий»
Для понимания существующей практики – «концепция».[15]

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

- - - инициация;
    - планирование;
    - исполнение;
    - мониторинг и управление;
    - завершение.

В управление проектами, как правило, входит: определение требований, удовлетворение различных потребностей, решение проблем и удовлетворение ожиданий различных заинтересованных сторон проекта в ходе планирования и выполнения проекта. Уравновешивание конкурирующих ограничений проекта, среди прочих: o содержание; o качество; o расписание; o бюджет; o ресурсы; и o риски. Каждый конкретный проект окажет влияние на ограничения, которым должен уделять внимание менеджер проекта. Взаимоотношение между этими факторами таково, что если один из этих факторов изменится, то с большой долей вероятности будет затронут как минимум еще один фактор. Так, если сжимается расписание, то зачастую возникает необходимость увеличения бюджета и включения дополнительных ресурсов для выполнения одного и того же объема работ в более сжатые сроки. Если увеличение бюджета невозможно, может быть сокращено содержание или снижено качество для поставки продукта в более сжатые сроки в пределах установленного бюджета. Мнение заинтересованных сторон проекта по поводу того, какой из факторов более важный, могут разделяться, что приводит к повышению сложности проекта. Изменение требований, предъявляемых к проекту, может вызвать дополнительные риски. Команда проекта должна быть способна оценить ситуацию и уравновесить требования в целях достижения успеха проекта.[17]

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

- объем работ;

- качество работ;

- необходимые финансовые, материальные и др. ресурсы;

- состав участников (кадры);

- риск;

- сроки выполнения.

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

- структуру работ (WBS – Works Breakdown Structure). Под структурой декомпозиции работ понимают иерархическую структуру, позволяющую разделить проект на отдельно либо совместно управляемые части – пакеты работ. Каждый нижестоящий уровень структуры представляет собой детализацию элемента более высокого уровня. Каждый пакет работ характеризуется объективным и измеримым результатом, а также ответственным за достижение этого результата. Пакеты работ могут соответствовать подцелям проекта (структура декомпозиции целей называется деревом целей). С помощью структуры декомпозиции работ описывается содержание проекта.

- организационную структуру (OBS – Organization Breakdown Structure), которая отражает иерархическую взаимную подчиненность участников проекта (руководителя проекта в целом, руководителей подпроектов работ, исполнителей). Для проектной деятельности характерны матричные организационные структуры, в рамках которых каждый исполнитель одновременно подчинен нескольким руководителям – например, своему функциональному руководителю и руководителю проекта;

- структуру ресурсов (RBS – Resources Breakdown Structure), причем декомпозиция осуществляется как по видам ресурсов (условий осуществления деятельности: мотивационных, кадровых материально-технических, научно-методических, финансовых, организационных, нормативно-правовых, информационных), так и по «количествам» ресурсов того или иного вида.

- сетевой график, который отражает логику и технологию выполнения работ.[1]

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

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

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

ГОСТ («государственный стандарт») – это как раз пример участия государства в упорядочивании деятельности. В силу перипетий российского законодательства, некоторые из них называют «Национальным стандартом» (это ничего, по сути, не меняет – см. закон «О техническом регулировании»). В настоящий момент ГОСТы – не обязательны для соблюдения (в отличие от «технических регламентов», которые теоретически «невозможны» в проектном управлении). Однако ГОСТами очень охотно пользуются некоторые участники рынка, т.к. это помогает им договориться.

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

На сегодняшний день в семейство стандартов «Проектный менеджмент», утвержденных Приказом Федерального агентства по техническому регулированию и метрологии от 22 декабря 2011 г. №1582-ст, входят:

ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом».
ГОСТ Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов».
ГОСТ Р 54871-2011 «Проектный менеджмент. Требования к управлению программой».

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

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

ГОСТ Р 54869 – 2011 Проектный менеджмент. Требования к управлению проектом

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

Стандарт рассматривает процессы:
1. инициации проекта,
2. планирования проекта,
3. организации исполнения проекта,
4. контроля исполнения проекта,
5. завершения проекта.

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

Зачем мог быть создан ГОСТ «Проектное управление» Р 54869-2011?

Предположим, для:

облегчения коммуникаций (заказчику требующему «вести проект по ГОСТ» проще объяснить подрядчику, чего он хочет; подрядчик, придерживавшийся стандарта – также легче убедит потребителя что «работа выполнена наилучшим образом»)
повышения эффективности (что бы ни было целью проекта – она лучше достигается, если менеджер придерживается ГОСТ)[20]

ГОСТ Р 54871 – 2011 Проектный менеджмент. Требования к управлению программой

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

Стандарт рассматривает процессы:
1. инициации программы,
2. планирования программы,
3. обеспечения исполнения программы,
4. контроля выполнения программы и управления изменениями программы,
5. приемки результатов проектов и организации использования промежуточных выгод программы,
6. закрытия проекта программы,
7. завершения программы.

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

ГОСТ Р 54870 – 2011 Проектный менеджмент. Требования к управлению портфелем проектов

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

Стандарт рассматривает следующие процессы:

группа процессов обеспечения управления портфелем:
1. процесс сбора информации об условиях, ограничениях и требованиях к портфелю проектов;
2. процесс формализации процедур управления и параметров оценки портфеля проектов;
группа процессов формирования портфеля проектов:

процесс идентификации компонентов портфеля;
процесс оценки компонентов портфеля;
процесс расстановки приоритетов;
процесс оптимизации и балансировки портфеля проектов;
процесс авторизации портфеля проектов;
- группа процессов мониторинга и контроля портфеля проектов:
процесс контроля реализации портфеля проектов;
процесс управления изменениями.

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

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

2.2. Зарубежные стандарты

PMBoK (A Guide to the Project Management Body of Knowledge)

Свод знаний по управлению проектами (PMBOK 1996) стандарт, разработанный Project Management Institute (PMI) в 1996 г.[11]

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

Версия 2000 г. принята в качестве национального стандарта ANSI (ANSI/PMI 99-001-2000) 27 марта 2001 г.). По содержанию и структуре практически полностью соответствует PMBOK 1996.
Полностью переработана глава по Управлению рисками в проекте. Расширены и добавлены разделы, относящиеся к управлению проектами на основе Менеджмента освоенного объема (EVM Earned Value Management). Добавлены новые процедуры (tools and techniques) преобразования входных данных в выходные.

PMBoK 2004 года отличает следующие основные изменения по сравнению с изданием 2000. Была уточнена разница между жизненным циклом проекта и жизненным циклом продукта. Количество процессов возросло с 39 до 44. Добавлено семь и удалено два процесса, 13 процессов получили новые названия, в целом стало на пять новых процессов больше. Уточнено различие между группами процессов управления проектом и областями знаний. Особенно подчеркнута важность групп процессов. Процессы управления проектами изображены графически, чтобы показать интеграции процессов. Глоссарий был существенно расширен и исправлен. Во избежание путаницы некоторые термины были уточнены. Добавлены 7 процессов. Все входы, инструменты, методы и выходы процессов пересмотрены для соответствия улучшенной интеграции и графическому отображению процессов.

PMBoK является единственным стандартом в области Project Management, который соответствует ISO 9001[9]

PMBOK определяет 5 основных групп процессов и 9 областей знаний, типичных практически для всех проектов. Основные принципы применимы к проектам, программам и операциям. Пятью основными группами являются:

Инициация
Планирование
Выполнение
Мониторинг и управление
Завершение и закрытие

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

Входными данными (документы, планы, чертежи и т.д.)
Инструментами и техниками (механизмы, применяемые к входным данным)
Выходными данными (документы, товары и т.д.)

Далее мы приведем девять областей знаний:

Управление проектной интеграцией
Управление масштабом проекта
Управление сроками проекта
Управление затратами проекта
Управление качеством проекта
Управление кадрами проекта
Управление каналами коммуникации проекта
Управление рисками проекта
Управление закупками [23]

ISO 10006 (Guidelines to Quality in Project Management)

Менеджмент качества. Руководство качеством при управлении проектами, 1997 г. Руководство нацелено на обеспечение заданного уровня качества проекта как на уровне процессов, так и на уровне продуктов.
В большой мере по содержанию основано на PMBOK 1996, совпадение вплоть до названий областей знаний управления проектами.
Первый стандарт ISO серии 9000, в котором применен процессный подход.[10]

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

Стандарт ИСО 10006 является основополагающим документом, из целой серии стандартов рассматриваемого профиля, который был подготовлен техническим комитетом ИСО/ТК 176 «Управление качеством и обеспечение качества» всемирной федерации национальных органов стандартизации (члены ИСО).

Основной упор сделан на принцип эффективности проектирования оптимального процесса и контроля этого процесса, чем контроля конечного результата.

В этой серии стандартов процессы сгруппированы в две категории:

Процессы, связанные с продуктом проекта, то есть те процессы, которые касаются исключительно продукта проекта, такие как проектирование, производство, проверка. Описанию последних посвящен стандарт ИСО 9004-1.
Процессы управления проектом, которым посвящен стандарт ИСО 10006.

ИСО 10006 представлен десятью группами процессов управления проектом.

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

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

Стандарт заимствует ключевые определения из ИСО 8402, включая такие термины как: проект, продукт проекта, план проекта, участник проекта, процесс, оценка хода работ. Для всех процессов управления проектом: планирование, организация, мониторинг и контроль применяются процессы и задачи менеджмента качества.[22]

Prince 2

Система знаний о процессах управления проектами Prince 2 (PRojects IN Controlled Environments) – это методология управления проектами, разработанная агентством CCTA (Central Computer and Telecommunications Agency) в 1989 как правительственный стандарт Великобритании для управления проектами в информационных технологиях. С 1996 г. PRINCE2 применяется в качестве стандарта управления проектами в Великобритании, Бельгии, Нидерландах, Люксембурге, Австралии, Новой Зеландии, Гонконге, Сингапуре, Малайзии, ЮАР, Хорватии, Польше и некоторых других странах. Наибольшее распространение PRINCE2 получил в государственном секторе, в финансовой, телекоммуникационной и электронной отраслях. Последние изменения были осуществлены в 2002 году организацией OGC (Office for Government Commerce). CCTA теперь является частью OGCommerce.

Методология Prince 2 является процессно-ориентированной с фокусом на продукт (product-based). Акцент делается на взаимоотношениях Заказчика, Поставщика и Пользователя, хотя Управление Соглашениями в рамках PRINCE не рассматривается.

По PRINCE Проект - это временное предприятие, созданное с целью поставки одного или более коммерческого продукта согласно представленному Бизнес-Кейсу.

Каждый процесс определяется: входными и выходными данными; специфическими целями; предпринимаемыми действиями.

Проект PRINCE2 состоит из восьми основных процессов верхнего уровня: Directing a project (DP); Planning (PL); Старт проекта - Starting up a project (SU); Initiating a project (IP); Controlling a stage (CS); Managing product delivery (MP); Managing stage boundaries (SB); Сlosing a project (CP).

Основными особенностями PRINCE2 являются: планирование, основанное на продуктовом подходе, деление проекта на управляемые и контролируемые стадии, гибкость применительно к масштабам проекта, определенная организационная структура для команды управления проектом.[8]

Принципы методологии PRINCE2:

Постоянная оценка экономической необходимости — остается ли неизменной экономическая выгода от проекта на протяжении всего жизненного цикла проекта
Обучение на опыте – команда проекта должна постоянно искать и изучать опыт предыдущих проектов
Определение ролевой модели – команда проекта должна иметь ясную организационную структуру и вовлекать подходящих людей для решения нужных задач
Управление по этапам – необходимо, чтобы проекты были спланированы, а также подвергались мониторингу и контролю на каждом этапе выполнения;
Управление по отклонениям – следует четко обозначить допустимые границы отклонений в проекте, чтобы установить границы ответственности
Фокус на продуктах – необходимо концентрироваться на определении и достижении качества продуктов (результатах проекта)
Адаптация к проектной среде – следует адаптировать процессы и инструменты управления проектом к требованиям проектной среды, а также к масштабу работ, их сложности, важности, квалификационным требованиям и степени риска

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

Аспекты методологии управления проектами PRINCE2:

Обоснование проекта: какую ценность проект принесёт организации?
Организация: каким образом необходимо распределить роли и ответственность между членами проектной команды для того, чтобы эффективно управлять проектом
Качество: какие имеются требования и критерии к качеству и каким образом можно их обеспечить
Планы: шаги, требуемые для разработки плана, и инструменты PRINCE2, необходимые к использованию
Риски: каким образом менеджмент проекта будет разрешать проблему наличия неопределённостей в плане проекта и во внешней среде
Изменение: как руководство проекта будет оценивать влияние непредвиденных задач и изменений и реагировать на них
Прогресс: реализуемость проекта, выполнение планов и дальнейшее развитие проекта

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

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

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

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

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

2.3 Сравнение национальных и зарубежных стандартов

Являясь крупнейшей в мире организацией по стандартизации, Международная организация по стандартизации (International Organization for Standardization, — ред.) просто обязана была обзавестись своим стандартом в области управления проектами. Им стал ISO 10006 «Управление качеством в проектах». Данный нормативный документ был опубликован в 1997 году и с тех пор выдержал одну редакцию – в 2003 году. Несмотря на довольно продолжительную уже историю использования, этот нормативный документ не сумел завоевать такую же популярность, какой пользуются знаменитые стандарты серии ISO 9000. Не смог ISO 10006 стать и лидером среди стандартов управления проектами, как Руководство PMBOK Prince 2. Более того, даже во многих странах, чьи национальные органы по стандартизации являются членами ISO, есть более популярные национальные нормативы в сфере проектного менеджмента.[27]

Стоит отметить, что ГОСТ во многом похож на свод знаний от PMI. При быстром прочтении даже кажется, что Национальный стандарт – это эссенция из PMBoK, из-за схожести терменалогии. Однако, вдумчивое прочтение с попыткой представить «ну и как это может работать в реальной жизни» вскрывает некоторые «придумки» или просто неудачные сокращения при переносе методологии в отечественный ГОСТ.

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

И в ГОСТ и в PMBoK, проекту предшествует «инициация», а венчает его «закрытие» («завершение»). Между ними — самое основное: планирование, а также контроль и выполнение работ. Однако сами эти стадии при внимательном прочтении – различаются.

Инициация проекта

Рис.4 Инициация согласно PMBoK

Рис.5 Инициация согласно ГОСТ

PMBoK предполагает равноправную дискуссию между менеджером проекта и спонсором (т.е., например, его боссом) при запуске проекта.

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

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

Планирование

Рис.6 Планирование согласно PMBoK

Рис.7 Планирование согласно ГОСТ

Согласно PMBoK, проект идет по воле спонсора — о заданных рамках они с менеджером договорились еще во время инициации. Теперь, если обещанные ресурсы будут выделены, не реализуются супер-риски, а менеджер – профессионал, то проект завершится вовремя.

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

Согласно ГОСТ, во время инициации проект просто оказался «запущен». Никаких планов еще нет. Менеджеру предстоит придумать план (одному, без команды! – см. Приложение А), а затем убедить подписать его Заказчика. Спонсор прохлаждается в сторонке (его как будто не волнует, сколько ресурсов придется выделить на проект в итоге). Команда смиренно ждет. Когда план готов – она приступит к его реализации. Так тоже можно прочитать ГОСТ.

Закрытие

Рис 8 Закрытие согласно PMBoK

Рис.9 Закрытие согласно ГОСТ

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

ГОСТ настаивает – проект можно завершить, только если «проведена и документально оформлена приемка продукта проекта заказчиком». Нет никаких оснований считать этот пункт необязательным (или предположить что приемку можно провести с указанием рекламаций и на этом успокоиться). Только успех. Нет приемки продукта – проект сделан не по ГОСТ. Сомнительно, что в современных реалиях такой подход приживется.[21]

Современные инфокоммуникационные компании реализуют все большее число сложных комплексных проектов, для эффективного управления которыми необходим научно обоснованный инструментарий. Система управления проектами представляет собой набор инструментов, методов, методологий, ресурсов и процедур, используемых для управления проектом. Это ряд процессов и связанных с ними функций контроля, объединенных в функциональное единство. Целью управления проектом является достижение заранее определенных целей при заранееизвестных ограничениях, целесообразном использовании возможностей и реагировании на риски. Общепринятые методы и подходы к управлению проектами описаны в стандартах международных и национальных профессиональных организаций, таких как Институт управления проектами США (PMI), Международная ассоциация управления проектами (IPMA), Ассоциация по управлению проектами Соединенного Королевства (APM), Ассоциация по управлению проектами Японии (PMAJ), Международное объединение по разработке Стандартов управления проектами (GAPPS), Международная организация по разработке стандартов (ISO), других международных и национальных ассоциаций. В России разработаны ГОСТ Р54869 2011— Требования к управлению проектом, ГОСТ Р54870 2011 — Требования к управлению портфелем проектов, ГОСТ Р54871 2011 — Требования к управлению программой. Проводится сравнительный анализ международных и национальных стандартов в проектном менеджменте.

Общепринятые методы и подходы к управлению проектами описаны в стандартах международных и национальных профессиональных организаций, таких как Институт управления проектами США (PMI), Международная ассоциация управления проектами (IPMA), Ассоциация по управлению проектами Соединенного Королевства (APM), Ассоциация по управлению проектами Японии (PMAJ), Международное объединение по разработке Стандартов управления проектами (GAPPS), Международная организация по разработке стандартов (ISO), других международных и национальных ассоциаций. В России разработаны ГОСТ Р54869 2011 — Требования к управлению проектом, ГОСТ Р54870 2011 — Требования к управлению портфелем проектов, ГОСТ Р54871 2011 — Требования к управлению программой. .[5]

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

Заключение

«Методология» управления проектами – это своего рода эталон того как следует выполнять требования по реализации проекта, и чему они должны соответствовать

Список источников:

Новиков Д.А. Управление проектами: организационные механизмы. – М.: ПМСОФТ, 2007.- 50 c
Новиков Д.А. Управление проектами: организационные механизмы. – М.: ПМСОФТ, 2007. – 7 с
Самоучитель «Основы управления проектами». - 21 с
http://www.b-solutions.ru/serv/projects/pmo/services3-PMO-4.html
http://cyberleninka.ru/article/n/sravnitelnyy-analiz-metodicheskih-podhodov-k-upravleniyu-proektami-i-ih-primenenie-v-infokommunikatsiyah
http://economyreview.ru/upravlenie-proektami/osnovnye-fazy-zhiznennogo-cikla-proekta
http://e-mba.ru/school/articles/praktika-primeneniya-gosta-r-54869-2011-upravlenie-proektami-v-gosudarstvennoj-kompanii
http://info.pm-club.org/standarty/55-2008-04-07-10-45-09
http://info.pm-club.org/standarty/55-2008-04-07-10-45-09
http://info.pm-club.org/standarty/55-2008-04-07-10-45-09
http://info.pm-club.org/standarty/55-2008-04-07-10-45-09
http://www.isopm.ru/metodicheskie_osnovy/gosts/gost-r-54871-2011/
http://www.isopm.ru/metodicheskie_osnovy/gosts/gost-r-54870-2011/
http://www.isopm.ru/metodicheskie_osnovy/gosts/gost-r-54869-2011/
http://www.koltunova.com/it-project-management-methodology-classification/
http://market-pages.ru/realnieinvist/6.html
http://www.novsu.ru/file/1213136
http://www.osp.ru/cio/2000/03/170815/
http://www.pmphelp.net/index.php?id=141
http://pmlead.ru/?p=1586
http://pmlead.ru/?p=1586
http://pmpractice.ru/knowledgebase/normative/projectstandarts/iso10006-97/
http://www.pmtoday.ru/project-management/pmbok-pmp/pmbok.html
http://www.pmservices.ru/company-news/top-4-metodologii-upravleniya-proektami/
http://projectimo.ru/upravlenie-proektami/zhiznennyj-cikl-proekta.html
http://topknowledge.ru/investmen/1210-sushchnost-proekta.html
https://1cert.ru/stati/sravnenie-proekta-standarta-iso-21500-i-rukovodstva-pmbok-4