Стандарты управления проектами (Определение и сущность управления проектами)

Содержание:

ВВЕДЕНИЕ

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

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

Проблемные вопросы проектного менеджмента и его стандартизации рассматривались такими учеными, как Е.Н. Анчихров, А.И. Васильев, Н.Н. Киселева, С.Е. Прокофьев, О.Н. Сафонова, А.Ю. Соотляттэ, А.Б. Тлисов, М.К. Фридлянов и ряд других.

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

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

- рассмотреть методологические основы проектного управления;

- провести анализ инструментов управления проектами;

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

Объект исследования – система отношений, сформированных в сфере разработки, принятия и применения стандартов проектного управления.

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

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

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

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

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ УПРАВЛЕНИЯ

ПРОЕКТАМИ

1.1 Определение и сущность управления проектами

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

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

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

В современном мире считается целесообразным ставить цели, которые требуется достигнуть для выполнения проекта ставятся по методике SMART. [15] SMART означает, что цель должна быть конкретной (Specific), измеримой (Measurable), достижимой (Achievable), значимой (Relevant), имеющей конкретный срок (Time Bound). В проектном управлении данная методика используется для того, чтобы максимально конкретизировать задачу, объяснить необходимость ее выполнения, понимать, что задачу в целом возможно выполнить, с учетом профессиональных навыков и ресурсных возможностей, и при наличии показателей, которые можно измерить, а значит, с их помощью, определить результат.

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

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

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

На основе СДР строится сетевой график. Сетевой график, ранее являвшийся частью методологии PERT (Project Evaluation and Review Technique, способ оценки проекта), появившийся в 1958 году. Способ подразумевает технологическую зависимость задач, учитывает время, необходимое для их выполнения, а также ресурсы, задействованные в этом. Одной из отличительных черт сетевого графика, является выделение, так называемых «bottlenecks», «бутылочных горлышек». Явление «бутылочного горлышка» означает наличие блокирующей задачи, для которой, как правило, требуются значительные ресурсы и время. Таким образом, образовавшееся «бутылочное горлышко» становится препятствием для выполнения других задач [21] .

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

Одним из инструментов по работе над проектом, связанным со структурной декомпозицией работ, является диаграмма Ганта, созданная в 1910 году Генри Гантом. Она подразумевает использование графика, на которой ось «Х» является временем, а ось «Y» названием задачи. Таким образом, подобный подход позволяет, используя структурную декомпозицию работ (подробное разбиение больших задач на более мелкие подзадачи), определить время выполнения проекта [19].

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

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

Для успешного достижения цели проекта требуется организовать контроль над ходом работы. В рамках контроля организуется предотвращение отклонений, возникающих в результате работы, контроль над факторами, в результате которых может возникнуть риск и действия, направленных на устранение возможных отклонений. Существуют различные формы реагирования на отклонения: их корректировка, полная заморозка проекта, переопределение критических задач или игнорирование [19]. Игнорирование также является формой реагирования, так как отказ от принятия решения также является решением, с точки зрения теоретического менеджмента. При организации работы над проектом, менеджер может прибегнуть к одной из методик управления проектами. Различные способы достижения поставленной цели имеют свои сильные и слабые стороны, применимы в тех или иных ситуациях и, в некоторых случаях, используются только в определенных отраслях.

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

1.2 Анализ инструментов по управлению проектами

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

Каскадная модель управления проектом или waterfall, в переводе с английского – «водопад» предполагает проведение работ в виде четкой последовательности действий: анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. [17] Модель предполагает строгое следование данной последовательности, это в свою очередь сохраняет сроки, бюджет и качество проекта. Сама формализация последовательности процессов улучшает общую работу над задачей.

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

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

Главным циклом развития итеративной модели является цикл «PDCA»^[2]: планирование, реализация, проверка, оценка. Данная модель имеет следующие положительные стороны: в результате постоянного анализа, снижается воздействие серьезных рисков на начальном этапе работы над проектом, удобство в организации рабочей загрузки участников проекта, постоянное тестирование позволяет увеличить вероятность успеха проекта в целом. Также, данная методика позволяет оценить требования и сопоставить их с реальными возможностями команды, оценить реальное текущее состояние проекта относительно общей фазы работы.

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

Так называемая спиральная модель управления проектом предполагает повышенное внимание к возникающим во внешней и внутренней среде рискам. Большинство рисков, на которые обращает внимание модель связаны непосредственно с командой, занятой в работе над проектом. Так, выделяется так называемый feature creep или постоянный поток изменений в перечень требований проекта, растущий перфекционизм в команде, нехватка квалифицированных специалистов, нереалистичные сроки и бюджет проекта и другие риски. Спираль состоит из четырех витков, каждый обозначает свой цикл в работе над проектом. В свою очередь каждый виток разбит на четыре секции: целеполагание, оценка текущих рисков, создание и тестирование продукта, планирование следующего цикла. [18]. Задача данной системы заключается в скорейшем создании первой версии продукта, направленной на получение дополнительных требований и корректировок со стороны заказчика. Однако, правила модели позволяют переходить на следующий этап не завершив предыдущий, а значит позволяют накапливаться текущим ошибкам и в целом лишают цикличность достаточного формализма. Другими словами, модель недостаточно жестко подходит к организации рабочего процесса.

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

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

Методология управления проектом PRINCE2 (Projects In Controlled Environments 2^[3]), разработанная в Британии не использует итеративного подхода. Для данной методики характерна концентрация на управленческих сторонах работы над проектом и классическом подходе к управлению проектами, выделяя стадии предпроекта, инициации, работы над проектом и финальной стадии проекта [22].

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

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

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

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

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

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

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

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

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

Отправной точкой в создании данной методологии можно считать 1930-е годы двадцатого века. Американский ученый-физик Уолтер Шухарт, работавший в Лаборатории Белла начал применять принцип Plan - Do - Study - Act, что переводится как «Планируй» - «Делай»- «Изучай» - «Действуй». Это стало основой формата «спринта», то есть короткого цикла разработки проекта. Шухарт передал полученные знания своему ученику - Эдвардсу Демингу, который использовал данный метод как основу при работе над восстановлением Японского производства после Второй Мировой Войны. Данную методологию можно считать прототипом одной из частей Agile - бережливого производства. Деминг, нанятый концерном Toyota, использовал ее для обучения менеджеров компании. Основа данного способа управления предприятием (или проектом) состоит в оптимизации управленческих и производственных процессов, в недопущении потерь и в использовании принципа минимакса.

В 1986 году начала зарождаться еще одна часть Agile - подхода. Такэути Хиротака опубликовал статью «The New New Product Development Game» [11] (дословно: совсем новая игра по разработке продукта). Автор выявил, что зачастую, лидерами на рынке являлись компании, которые предпочитают вести работу опираясь на небольшие, полуавтономные команды. В то время, это являлось революционным подходом к разработке продукта.

Примерами успешного применения данной методики в 1986 году являлись компании Xerox, Honda и Cannon. Их идея состояла в том, чтобы вместо традиционного, на тот момент, подхода по передаче продукта от команды к команде, фактически используя конвейерный метод, использовать команду как единое целое и позволять работать от начала и до конца над одной задачей.

С точки зрения управления командой это позволяет создать командный дух, использовать сотрудников, привыкших работать вместе как единое целое. Таким образом, у персонала появляется возможность сфокусироваться на одной задаче и принять участие в полном цикле ее выполнения. Данная методика стало прототипом появившейся позже части Agile - Scrum. [25]

Авиастроительная компания LockheedMartin Corporation использовала следующий подход к проведению научно-исследовательских и опытно-конструкторских работ: организация использовала внешнюю команду, полностью изолированную, автономную и засекреченную, которая называлась “Skunkworks”^[4]. Название было связано с тем, что офис команды располагался рядом с фабрикой по переработке пластика и в помещении всегда присутствовал специфический неприятный запах.

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

Сазерленд решил заимствовать опыт команды Borland Quattro Pro^[5]. Члены команды ежедневно встречались и обменивались мнениями о том, что было сделано за день, с какими трудностями они столкнулись и что планируется сделать завтра. Подобные встречи повышали эффективность, слаженность и синхронизацию в команде. Совместив опыт “Skunkworks”, Borland Quattro Pro и Такэути Хиротаки Сазерленд придумал собственный подход к управлению проектами - Scrum^[6]. [12]

В итоге, поставленная перед Сазерлендом задача была выполнена крайне успешно. Используя человеческую психологию, разумную автономность команды и краткосрочное планирование удалось сохранить бюджет, сделать в срок и достичь хорошего качества продукта. Формализация подхода была закончена в 1995 году совместными усилиями Джеффа Сазерленда и усилиями его коллеги Кена Швабера [24].

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

В 2001 году состоялась первая встреча клуба «Организационных анархистов», на горнолыжном курорте Сноуберд, в штате Юта для того, чтобы поделиться мнениями и опытом в использовании различных методик управления проектами: Scrum, Crystal, подход к разработке, ориентированный на функциональность. Подобные методологии называются облегченными фреймворками, так как легки в применении и изменяются с учетом динамической внешней и внутренней среды. Несмотря на то, что участники форума придерживались различных позиций по управлению проектами и разработке программного обеспечения было решено найти унифицированное название к нескольким обобщенным подходам менеджмента. Так появилось название Agile.

Несмотря на то, что некоторые менеджеры отмечают, что Agile является в первую очередь набором методов по разработке программного обеспечения, на практике, зачастую, подобная методология применяется и в других отраслях коммерческой деятельности. [24] Например, в книге «Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer» (1994 г.) Стивена Голдмана предлагаются примеры использования данной методики компаниями Harley Davidson и Boeing.

В итоге, требуется отметить, что Agile имеет достаточно разветвленную «родословную», начав свое существование как набор принципов в 1930-х годах в Лаборатории Белла, данная методология продолжила свое развитие в послевоенной Японии и была использована при разработке программного обеспечения Джеффом Сазерлендом в США в 1980-х годах. Используя управленческий опыт, применяя на практике некоторые из принципов методологии менеджеры достигали более высоких результатов, чем их коллеги. Оформление принципов Agile в единый манифест позволяет внедрить данную методику в практически любую компанию [25].

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

Перейдем к анализу содержания манифеста. [25] Первой ценностью данного подхода является: «люди и взаимодействие важнее процессов и инструментов» - эта идея подчеркивает то, что на практике, зачастую успешность выполнения технического задания или проекта зависит непосредственно от исполнителей, их мотивированности и слаженности. Следующей ценностью является: «работающий продукт важнее исчерпывающей документации», другими словами, подписавшие манифест Agile говорят о том, что бюрократическая сторона проекта не является приоритетом и иногда ей можно пожертвовать для достижения главной цели. «Сотрудничество с заказчиком важнее согласования условий контракта» - по мнению подписавших манифест, исполнитель должен взаимодействовать с заказчиком минуя бюрократические процедуры для улучшения общего взаимодействия, напротив, требуется более тесное взаимодействие сторон. Четвертая, и завершающая ценность, описанная в манифесте, фактически является кратким описанием всей методологии: «Готовность к изменениям важнее следования первоначальному плану».

Другими словами, краеугольной ценностью гибкого управления проектами является готовность меняться и адаптироваться относительно нестабильной внешней и внутренней среды. Это позволяет организовать работу команды, работающей над проектом, сделать ее более автономной и готовой к «турбулентности» [24]. Принципы Agile-подхода дополняют его ценности, они раскрывают их содержание. Фактически, вся методология строится на использовании данных принципов напрямую в управленческом процессе. Принципы Agile строятся на том, чтобы обеспечить бесперебойное и плотное взаимодействие заказчика и исполнителя. Благодаря регулярному обмену информацией исполнителю удается создать максимально качественный и приближенный к техническому заказчику продукт. Так как искажение информации является естественным в человеческом общении, непрерывное взаимодействие позволяет минимизировать искажение данных, а значит достичь задачи в полной мере.

Другим краеугольным моментом в гибком управлении проектами является возможность предоставления работникам широкой автономии. Более консервативные стили управления подразумевают непрерывный контроль за исполнителем, однако Agile подчеркивает, что команда профессионалов, для которых созданы все необходимые условия, может добиться значительных результатов. «Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им» - говорится в манифесте. Другими словами, менеджер не должен становиться помехой в отрасли, к которой не имеет отношения, потому что мотивированный специалист способен работать, самостоятельно не отвлекаясь на побочные проблемы, находящиеся в компетенции управляющего [24]. Резюмируя, можно сказать, что Agile выступает за создание гибких, автономных команд, созданных для слаженной работы без долгосрочного планирования. Подобный подход позволяет быстро оптимизировать работу над проектом в соответствии с изменениями во внутренней или внешней средой организации. Это позволяет минимизировать потери времени, ресурсов или качества, а значит подойти к выполнению условий триумвирата управления проектами (выполнить проект в срок, в соответствии с бюджетом и качеством) ближе, чем используя другие консервативные модели управления проектами. Agile не отрицает важность документации, инструментов, бизнес процессов или правильного контракта, но ставит их ниже, чем оптимизированное взаимодействие с заказчиком и исполнителями так как это напрямую влияет на созданный продукт, а значит на результаты коммерческой деятельности.

Scrum как часть Agile представляет собой гибкий фреймворк для работы над проектами. [25] Для того, чтобы использовать эмпирические процессы в управлении создатели Скрама выделяют три принципа: прозрачность, инспекция и адаптация. В Скрам существуют следующие роли: скрам-мастер, команда, работающая над проектом и владелец продукта. Скрам-мастер организует работу по правилам Скрама и устраняет проблемы, напрямую не связанные с работой над проектом. Владелец продукта составляет бэклог проекта, то есть перечень требований к выполнению задачи. Команда, занятая в проекте остается автономной, самоорганизующейся и без иерархии. Цикл работы называется спринт и продолжается не более месяца. Посредством последовательных спринтов достигается завершение проекта.

Методика Lean или методика бережливого производства была придумана в Японии, на производстве Toyota. [15] Основа методики стремление к постоянному сокращению потерь, возникающих при работе над проектом, вовлечение в эту работу сотрудников всех уровней и определение фокуса компании на потребителя.

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

Методика Kanban, также появившаяся в Японии на основе методики бережливого производства стремиться к реализации принципа «точно в срок», распределяя задачи равномерно между сотрудниками. [15] Являясь частью Agile-подхода, методика строится на прозрачном взаимодействии внутри команды. Основным инструментом является Канбан доска, на которой находятся списки задач готовых к выполнению, выполняемых и выполненных. Канбан придерживается следующих принципов: использование уже существующих методов разработки (если речь идет о программном обеспечении), важные изменения проводятся только по согласованию, порядок, роли и обязанности превыше всего, инициатива каждого сотрудника критична. Канбан прозрачен для команды, участвующей в проекте и показывает, что, когда и как необходимо выполнить [24] . Таким образом, Agile есть термин, объединяющий значительное количество методологий по работе над проектом. В зависимости от организации и цели используются те или иные его части или их принципы. Гибкая методология управления проектом является многофункциональным центром, правилами и инструментами которого можно воспользоваться в зависимости от поставленной задачи и объема работ. [16] Оперативность, контроль и прозрачность являются сильными сторонами данного подхода. Благодаря возможности быстро реагировать на изменение внешней и внутренней среды Agile-подход позволяет экономить ресурсы, время и сохранять должный уровень качества проекта.

ГЛАВА 2 РОССИЙСКАЯ И ЗАРУБЕЖНАЯ ПРАКТИКА

СТАНДАРТИЗАЦИИ ПРОЕКТНОЙ ДЕЯТЕЛЬНОСТИ

2.1 Зарубежная практика стандартизации проектной деятельности

Общепринятые методы и подходы к управлению проектами описаны в стандартах и руководствах, разработанных ведущими международными и национальными профессиональными ассоциациями, объединяющими специалистов по управлению проектами и программами из разных уголков мира [1, 2]. Эти организации внесли весомый вклад в развитие системы знаний и практик проектного менеджмента, обеспечив его широкое распространение в различных секторах деятельности. К числу наиболее крупных ассоциаций относятся:

1) Американский институт управления проектами (Project Management Institute, PMI);

2) Международная ассоциация управления проектами (International Project Management Association, IPMA), образованная под представительством французской ассоциации AFIRO (Association Fran aisedInformatiqueet de Recherche Op rationnelle);

3) Международная организация по стандартизации - ИСО (International Organization for Standardization, ISO). Является крупнейшей независимой неправительственной международной организацией по разработке стандартов;

4) Ассоциация по управлению проектами Соединенного Королевства (Association for Project Management, APM);

5) Австралийский институт управления проектами (Australian Institute of Project Management, AIPM).

В число национальных профессиональных ассоциаций, оказывающих активную поддержку развитию методологии управления проектами, также входят Союз проектных менеджеров Германии (GPM), Японская ассоциация управления проектами (Project Management Association of Japan, PMAJ), Международное объединение по разработке стандартов управления проектами (Global Alliance for Project Performance Standards, GAPPS) и другие организации, список которых расширяется с огромной скоростью. На протяжении многих лет ведущие школы менеджмента накапливали лучшие практические наработки в данной области и систематизировали их в специализированных справочниках и руководствах [17]. На сегодняшний день в мире разработано и используется множество нормативных документов, стандартов и рекомендаций, позволяющих упорядочить и формализовать проектную деятельность. Это международные и национальные стандарты, а также специально разработанные методики и руководства для конкретных проектов или отдельных компаний, включающие уникальный набор инструментов, шаблонов и правил организации проектной деятельности. Международные стандарты, как правило, широко используются в компаниях, реализующих проекты с участием зарубежных партнеров, так как позволяют формировать единое информационное поле для межстрановой синхронизации понятийного аппарата и устанавливать базовые (основные) принципы управления проектами. Национальные системы стандартов и требований разрабатываются для конкретной страны, зависят от ее культуры и традиций, носят частный характер и регламентируют отдельные аспекты управления проектами. Такие стандарты могут иметь отличия в терминологии и подходах к стандартизации содержания проектного управления. Наибольшую популярность в мире сегодня получил международный стандарт по управлению проектами ИСО 21500:2012 «Руководство по менеджменту проектов». Он входит в новую серию стандартов «Руководство по управлению проектами» (Guidance on project management) и является базовым нормативным документом, регламентирующим проектное управление на международном уровне. ИСО 21500:2012 «обеспечивает общее руководство по концепциям и процессам управления проектами, которые представляют особую важность и влияют на достижение проектами результатов» [14]. Наиболее известные из ранее опубликованных стандартов в данной области – ИСО 10006:2003 «Системы менеджмента качества. Руководящие указания по менеджменту качества проектов» и ИСО 9004:2009 «Менеджмент с целью достижения устойчивого успеха организации. Подход с позиции менеджмента качества» — не являются непосредственным руководством по управлению проектом. Разработка стандарта ИСО 21500 была инициирована Британским институтом стандартов (British Standards Institution, BSI), представляющим Великобританию в ИСО. Организации-члены ИСО поддержали идею создания такого нормативного документа [20].

В настоящее время ведется работа еще над двумя стандартами данной серии: ИСО 21503 – на управление программой (Guidance on Programme Management) и ИСО 21505 – на управление программами и портфелем (Project, Programme and Portfolio Management. Guidance on Governance). Информацию о стадии развития этих руководств можно найти на интернет-странице ИСО/ТК 258. Наиболее известным национальным стандартом управления проектами с расширенной географией применения является PMBOK (Project Management Body of Knowledge). Это базовый национальный стандарт США, описывающий фундаментальные основы проектного управления. Он разработан и администрируется PMI, признан в качестве национального стандарта ANSI и давно приобрел мировое признание. Первое издание PMBOK датируется второй половиной 1980-х гг. Стандарт неоднократно пересматривался, актуализировался и дорабатывался. Самая распространенная его версия – ANSI/PMI 99-001-2004 - переведена на 11 языков и опубликована тиражом свыше 2 млн экземпляров по всему миру. Сегодня более 160 стран используют PMBOK в качестве основы при разработке своих национальных стандартов и сводов правил. Актуальная версия PMBOK (пятая по счету) выпушена в 2013 г. В ней учтены как традиционные практики эффективного управления проектами, так и новые, хорошо зарекомендовавшие себя подходы к решению задач управления [23]. Управление проектами в стандарте базируется на процессном подходе. Выделяются группы процессов, охватывающих все стадии жизненного цикла проекта (инициацию, планирование, организацию исполнения, мониторинг и контроль, завершение), и области знаний, характерные для всех типов проектов (управление интеграцией, содержанием проекта, его сроками и стоимостью, качеством, человеческими ресурсами, коммуникациями, рисками, поставками, заинтересованными сторонами).

Стандарт основан на процессном подходе к управлению проектом. Все множество процессов представляется как некое трехмерное пространство (Рисунок 1).

Рисунок 1 – Пространственное представление процессов управления стандартом PMBOK [13]

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

Всего в PMBOK описаны 47 взаимосвязанных процессов управления проектами. Отличиями пятой версии стандарта также являются выверенная терминология, изменения в описании управления рисками проекта, соответствие стандарту ИСО 21500:2012, акцент на заинтересованных сторонах проекта и их влиянии на проект и др. В целом PMBOK можно считать одной из наиболее проработанных универсальных методологий управления проектом на всех этапах его развития. Однако стандарт имеет свои недостатки: он очень объемный, излишне детализированный и сложный для практического применения. Еще один интересный и хорошо известный стандарт, регламентирующий управление отдельными проектами, – PRINCE2 (PRojects in Controlled Environments), одобренный правительством Великобритании в качестве стандарта управления проектами в социальной сфере [14]. Его первая редакция была представлена в 1989 г. Методология PRINCE2 представляет собой структурированный подход к менеджменту, контролю и организации проектов, т.е. метод для управления (менеджмента) проектами в рамках четко определенной структуры. Основными особенностями стандарта являются: планирование, ориентированное на продукт и качество этого продукта, деление проекта на стадии (управляемые и контролируемые), установленная организационная структура для координации деятельности команды управления проектом, гибкость применительно к масштабам проекта. Этот стандарт подходит для проектов любого типа и, будучи достаточно хорошо адаптивным, успешно интегрируется в деятельность организации. На сегодняшний день его используют не только в Великобритании, но и в отдельных странах Евросоюза, в Австралии, Новой Зеландии, Гонконге, Сингапуре, Малайзии, ЮАР [23].

В высокотехнологичных компаниях, реализующих сложные, комплексные инновационные проекты и программы, особым авторитетом пользуется стандарт P2M (A Guidebook of Project and Program Management for Enterprise Innovation), разработанный Японской ассоциацией развития инжиниринга (ENAA). Первая редакция данного стандарта была опубликована в ноябре 2001 г. В настоящее время стандарт поддерживается PMAJ. Методология P2M базируется на простых принципах, основанных на представлении проектов и программ как главных элементов стратегического управления предприятием. P2M используют в управлении проектами многие национальные и интернациональные корпорации, он служит корпоративным стандартом в области проектного управления в таких известных компаниях, как Toyota, Canon, Mitsubishi Corporation, Takeda Pharmaceutical, Toshiba. Кроме того, на базе стандарта сформировано специальное руководство для оценки профессиональных способностей и сертификации специалистов по управлению проектами (Capability Based Professional Certification Guidelines, CPC Guidelines).

2.2 Российские стандарты проектного управления

Российская Федерация, в отличие от большинства ведущих стран мира, встала на путь национальной стандартизации управления проектами сравнительно недавно – с конца 2012 года, хотя Федеральный закон «О техническом регулировании», устанавливающий необходимость регулирования управления процессами проектирования, был принят еще в 2002 году [1]. Действовавшая в условиях советской экономической парадигмы стандартизация не носила проектного характера, а была основана на иных принципах, главными из которых являлись планирование и народно-хозяйственная значимость. Проектная деятельность в области управления командно-административными методами была формально ориентирована на «все большее удовлетворение потребностей населения» и исчерпала себя вместе с директивным централизованным планированием. В настоящее время в нашей стране действует ряд современных отечественных и международных стандартов управления проектной деятельностью, включая управление качеством проектов, среди которых можно выделить: – ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом» [2]; – ГОСТ Р ИСО 256714.1-2015 «Мультипроектный менеджмент. Управление проектом, портфелем проектов, программой. Часть 1. Основные положения [3]; – ГОСТ Р ИСО 57101-2016 «Системная и программная инженерия. Процессы жизненного цикла. Управление проектом» [4]. Также в России действуют международные стандарты, установленные Международной организацией по стандартизации (International Organization for Standardization, ISO), членом которой является Российская Федерация, относящиеся непосредственно к управлению проектами: – ISO 15188 «Принципы управления проектами, стандартизации, терминологии» [5]; – ISO 21500 «Руководство по менеджменту проектов» [6]. Необходимо отметить существование национальных и международных стандартов в области качества, действующих в Российской Федерации, применимых к управлению проектами (качество управления, качество проекта, качество в проекте), а именно: – ГОСТ 15467-79 «Управление качеством продукции. Основные понятия, термины, определения [7]; – ГОСТ Р ИСО 9000-2015 «Системы менеджмента качества. Основные положения и словарь» [8]; – ГОСТ Р ИСО 9000-2011 [9] и др. В утвержденных стандартах прописаны минимальные требования к управлению проектами, но позволяющие по замыслу их разработчиков выработать единый подход к управлению ими в Российской Федерации, что должно «автоматически» вести к улучшению качества проектного управления в стране. Однако анализ содержания вышеназванных стандартов вносит элемент сомнения в успехе автоматизма их применения уже по той причине, что одни и те же термины в них трактуются по-разному. Так, ГОСТ Р 54869-2011 определяет проект как «комплекс взаимосвязанных мероприятий, направленных на создание уникального продукта или услуги в условиях временных и ресурсных ограничений» [2. С. 2]. Согласно ISO 21500-2012 (его российский аналог – ГОСТ Р ИСО 21500-2014 [10]) «проект состоит из уникального набора процессов. Процессы состоят из координируемых и контролируемых работ с датами начала и окончания, которые выполняются для достижения целей проекта. Достижение целей проекта требует получения определенных результатов, отвечающих конкретным требованиям» [6. С. 4]. В соответствии с ГОСТ Р ИСО 9000-2015 «проект – это уникальный процесс, состоящий из совокупности скоординированных и управляемых видов деятельности с начальными и конечными датами, предпринятый для достижения цели соответственно конкретным требованиям, включая ограничения по срокам, стоимости и ресурсам» [8. П. 3.2.4]. То же самое можно сказать о понятии термина «качество» проекта, равно как и управление качеством в проекте. Так, согласно ГОСТ Р ИСО 9000-2015, «Качество продукции и услуг определяется способностью удовлетворять потребителей и преднамеренным или непреднамеренным влиянием на соответствующие заинтересованные стороны. Качество включает не только выполнение функций в соответствии с назначением и их характеристики, но также воспринимаемую ценность и выгоду для потребителя». ГОСТ 9000-2011 трактует качество как «степень соответствия совокупностей присущих характеристик требованиям. Данный термин может применяться с такими прилагательными, как «плохое», «хорошее» или «превосходное». Требование: потребность или ожидание, которое установлено, предполагается или является обязательным». (Что означает «хорошее», «плохое» и «превосходное», стандартом не проясняется, равно как, и в чем отличие «установленного» и «обязательного» к исполнению – автор.) ГОСТ 15467-79 (с изменениями от 16.01.1985) определяет качество продукции как «совокупность свойств продукции, обусловливающих ее пригодность удовлетворять определенные потребности в соответствии с назначением» [7. С. 1]. ГОСТ Р ИСО 21500-2014 рекомендует иметь в виду под качеством «культуру поведения, отношений, действий и процессов, которые создают ценность управления проектом посредством удовлетворения требований и ожиданий потребителей и других соответствующих заинтересованных сторон» [5. С. 30]

Согласно ГОСТ Р ИСО 21500-2914 управление качеством в проекте рекомендовано осуществлять на этапах, или в процессах планирования и исполнения, а также маркетинга и контроля, который в рамках данного стандарта признается как самостоятельный этап, с чем трудно согласиться и можно предполагать неточный перевод соответствующего международного стандарта ISO. Данный стандарт, как сказано в преамбуле его русскоязычного текста, идентичен международному стандарту ISO 21500-2012. Он получил в Российской Федерации наибольшее употребление на корпоративном и ином уровнях, что позволяет рассматривать его как образец (один из образцов) современного управления качеством в проекте. Соответственно данному ГОСТу, функция планирования качества преследует цель определения требований к оформлению и исполнению проекта, а также требований к результатам реализации проекта и способам их достижения. Планирование качества – это сознательный и целенаправленный, то есть планомерный, процесс, включающий в себя определение Рис. 1. Схема жизненного цикла проекта [16] и согласование таких требований, которые могут быть жестко установленными и обязательными к исполнению, но могут быть и предполагаемыми, ориентированными на конкретного потребителя результата проекта или иметь более-менее общий характер. Функция планирования качества предполагает выбор методологии, методов и ресурсов их обеспечения, включает установление мероприятий и процедур прохождения проекта, а также разработку плана проекта – документа, утверждающего состав и компетенцию его участников, перечень предстоящих мероприятий и календарный план их осуществления. Важна положительная апробация планируемых способов достижения цели, достаточность закладываемых ресурсов и надежность их источников, работоспособность устанавливаемых процедур, их целесообразность. Консолидированное и документальное оформление указанных требований, а также системы мероприятий по их обеспечению представляет собой, согласно выделенной модели проектного менеджмента, первый этап его качественного построения. Разрабатываемый на данном этапе общий План проекта (ПП) должен включать компоненты, гарантирующие его качество, а именно: – ответственность управления, главным образом административная; – систему управления документооборотом, имея в виду то, что документы – главный метод коммуникаций в управлении проектом; – объем, или перечень требований к результату (результатам) проекта; – определение средств и процедур управления, дизайн проекта; 87 ГОСРЕГУЛИРОВАНИЕ – тестирование на возможные дефекты, неопределенности, разработка рекомендаций и инструкций по их устранению; – управление рисками проекта; – систематический внутренний и внешний аудит; – учебные требования к участникам проекта, то есть их специальное обучение перед началом его разработки и исполнения. Вышеназванные компоненты отражаются в Плане управления качеством в проекте (ПУКП), который должен стать неотъемлемой частью (отдельным документом) ПП. Цель ПУКП состоит в том, чтобы описать, как управление качеством будет осуществляться на всем жизненном цикле проекта, чем и как будет гарантировано запланированное качество, как это качество будет управляться, контролироваться и стандартизироваться. Все участники проекта и заинтересованные стороны должны быть знакомы с тем, как качество будет планироваться, гарантироваться и управляться. ПУКП может состоять из нескольких разделов:

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

2. Требования к качеству / стандарты. В этом разделе дается описание того, как Группа качества будет выявлять и документировать требования к качеству и стандартам. Объясняется, каким образом будут соблюдаться требования и стандарты в ходе осуществления проекта в отношении как составляющих его процессов, так и результатов на выходе.

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

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

5. Измерение контроля качества. Эта часть ПУКП должна содержать типовую таблицу или журнал для регистрации проведения измерений качества результатов проекта и их соответствия стандартам и (или) требованиям. Тем самым обеспечивается документирование качества. В случае выявления несоответствий документируются действия, которые были предприняты по их устранению. Действия по устранению принимаются на основе решений, принимаемых уполномоченными лицами на соответствующих совещаниях, проводимых на регулярной основе или по мере необходимости. ПУКП может включать и другие разделы, а также иное содержание в указанные выше разделы. Но его наличие, равно как и наличие в составе исполнителей проекта группы качества, на наш взгляд, является обязательным для качественного управления любым проектом. «Руководством по проектной деятельности» в Российской Федерации (ГОСТ 21500-2014) рекомендуется управление качеством в проекте и на этапе его реализации, то есть в функционале основной и практической части превращения идеи в целевой результат. На этом этапе заявленные требования должны быть согласованы в управляющих звеньях проекта, доведены до сведения непосредственных исполнителей, включая внешних поставщиков и потребителей его промежуточных и конечного результатов, а главное – правильно ими поняты и приняты к неукоснительному исполнению. Готовность к реализации проекта при его повышенной сложности, следовательно, высокой степени неопределенности, а также ответственности менеджмента за результат должна пройти независимую экспертную оценку. Внутренний аудит и маркетинг исполнения проекта как источник информации для принятия управленческих решений должны стать непременным условием реализации данного этапа. Целесообразно документальное сопровождение данного этапа. Ключевая роль в качественной реализации проекта принадлежит его непосредственному руководителю и возглавляемой им рабочей группе специалистов, включая группу качества проекта.

Можно выделить следующие особенности разработанных российских стандартов:

- это первые российские стандарты, содержащие требования к управлению проектами, программами проектов и портфелем проектов;

- стандарты основаны на комплексном подходе - «проект – программа - портфель»;

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

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

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

- процессы управления проектами выстроены в соответствии с жизненным циклом проекта;

- учет лучшей отечественной практики управления и международный опыт;

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

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

- единая структура.

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

- РМВоК (Project Management Body Of Knowledge). Разработчик - РМ1,

США;

- ICB (International Competence Baseline) /NCB (National Competence

Baseline). Разработчик - 1РМА, Швейцария;

- Prince2 (Projects In Controlled Environments). Разработчик - ССТА, Великобритания;

Стандарты International Standartization Organization (ISO).

Национальный стандарт PMBoK - является базовым стандартом РМ1 (Project Management Institute - Институт управления проектами). РМ1 – это всемирная некоммерческая профессиональная организация по управлению проектами, основанная в 1969 году в США.

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Федеральный закон от 27.12.2002 № 184-ФЗ «О техническом регулировании» (ред. 05.04.2016) // Собрание законодательства Российской Федерации. 30.12.2002. № 52 (ч. 1). Ст. 5140
2. ГОСТ 54869-2011. Проектный менеджмент. Требования к управлению проектами.
3. ГОСТ Р ИСО 256714.1-2015. Мультипроектный менеджмент. Управление проектом, портфелем проектов, программой. Часть 1. Основные положения.
4. ГОСТ Р ИСО 57101-2016. Системная и программная инженерия. Процессы жизненного цикла. Управление проектом.
5. ISO 15188 «Принципы управления проектами стандартизации терминологии».
6. ISO 21500 «Руководство по менеджменту проектов».
7. ГОСТ 15467-79 (СТ СЭВ 3519-81). Управление качеством продукции. Основные понятия. Термины и определения.
8. ГОСТ Р ИСО 9000-2015. Национальный стандарт Российской Федерации. Система менеджмента качества. Основные положения и словарь.
9. ГОСТ Р ИСО 9000-2011. Межгосударственный стандарт. Система менеджмента качества. Основные положения и словарь.
10. ГОСТ Р ИСО 21500-2014. Руководство по проектному менеджменту.
11. Буевич С.Ю. Проблемы государственной стандартизации и функции современного управления качеством проекта в Российской Федерации /С.Ю. Буевич // Экономические системы. 2017. Т. 10. № 2 (37). С. 84-92.
12. Бусыгин А.В. Менеджмент: введение в специальность: учебное пособие/ А.В. Бусыгин – М.: Экон-информ, 2014 . – 356 с.
13. Володин В.В. Исследование нормативной базы управления проектами / В.В. Володин, А.Г. Дмитриев, В.И. Хабаров. - М.: Московский финансово-промышленный университет «Университет», 2015. - 128 с
14. Захарова А. Стандарт PRINCE2 как сертифицированный метод управления проектами. / А. И. Захарова. - М.: Высшая школа экономики, 2015.
15. Зиядуллаев Н.С. Современные стандарты проектного управления / Н.С. Зиядуллаев, М.А. Фридлянов М.А. // Стандарты и качество. 2017. № 8. С. 44-48.
16. Миронова С.Б. Проектно-целевое управление и управление проектом / С.Б. Миронова, Н.Л. Зарубина // Вестник Саратовского областного института развития образования. 2016. № 4 (8). С. 68-74.
17. Прима Я.Г. Тенденции развития проектного управления в России /Я.Г.Прима// Экономические и социально-гуманитарные исследования. 2018. № 2 (18). С. 49-57.
18. Сооляттэ А.Ю. Управление проектами в компании: методология, технологии, практика: Учеб /А.Ю. Соотляттэ - М.: Московский финансово-промышленный университет «Университет», 2012. - 816 с
19. Тихомирова А.Т. Управление проектом. Комплексный подход и системный анализ/ А.Т. Тихомирова. - М.: Инфра-М, 2017. - 300 с.
20. Усманова Р.Р. Сравнительный анализ стандартов проектного управления / Р.Р. Усманова, О.Д. Головина // Менеджмент: теория и практика. 2017. № 3-4. С. 73-80.
21. Филимонова, Н.М. Управление проектами. Учебник /Н.М. Филимонова, Н.В. Моргунова, Н.В. Родионова. - М.: ИНФРА -М, 2018.- 349 с.
22. Фридман А. Вы или хаос. Профессиональное планирования для регулярного менеджмента / А. Фридман.- М.: Добрая книга, 2016. - 480 с.
23. Фридлянов М. К. Международные и национальные стандарты построения современных систем проектного управления в промышленности /М.К. Фридлянов // Проблемы теории и практики управления. 2017. № 2. С. 82-90.
24. Хакимов А.Б. Методы управления проектами /А.Б. Хакимов, Е.С. Уваров Е.С. , Д.В.Шалимова //В сборнике: Современные технологии в сфере сельскохозяйственного производства и образования Сборник материалов VIII Международной научно-практической конференции на иностранных языках. 2017. С. 79-81.
25. Черных Е.А. Agile project management - новый подход к управлению инновационными проектами / Е.А. Черных // Менеджмент качества. 2008. № 2. С. 84-94.

1. PMI или PMBOK ↑

2. англ. Plan-do-check-act ↑

3. От англ. - проекты в контролируемой среде 2 ↑

4. Skunkworks - дословно: фабрика скунсов. ↑

5. По состоянию на 2018 год относится к Corel Corporation ↑

6. Перевод с английского - схватка, регби ↑