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

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

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

Введение

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

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

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

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

Научной новизной работы является определение рекомендаций с условием совместного использования различных методологий управления IT-проектами таких, как традиционные методы, методы Agile-методологии и подход, основанный на системной динамике при учете влияния возникновения обратных связей и циклов ПВР.

Объектом исследования является подход в управлении проектами на основе системной динамики; предметом исследование - влияние циклов ПВР на продолжительность IT-проектов.

Методика работы включает в себя теоретическую и практическую части.

В теоретической части:

· Обзор и интеграция существующего знания об управлении проектами на основе системной динамики;

· Обзор и интеграция существующего знания о циклах ПВР и методах их изучения;

· Качественный анализ выявленных в ранее проведенных исследованиях факторов, влияющих на циклы ПВР.

В практической части:

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

· Проведение анкетирования экспертной группы с целью установления причин возникновения циклов ПВР и последствий их возникновения;

· Проведение глубинного интервью с экспертной группой для перепроверки и подтверждения результатов анкетирования и проведенного наблюдения;

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

Глава 1. Использование системной динамики в управлении IT-проектами

1.1 Внедрение управления проектами в IT-области

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

В работе Lee S.L. и Anderson R.M. было доказано, что введение системы управления проектами положительно влияет на возможности, извлекаемые организацией при реализации IT-проектов. Исследователи использовали в своей работе метод Делфи для определения набора факторов, в том числе, оказывающих влияние на продуктивное использование менеджмента. По результатам получилось, что при введении управления проектами в IT-сфере необходимо обращать внимание в первую очередь на командные факторы и организационные. Кроме того, значительное влияние оказывает уровень зрелости компании.

Командные факторы включают в себя такие, как:

· наличие определенных критериев успеха реализации проекта;

· отчетливое понимание каждым участником команды собственной роли в реализации проекта;

· лояльное отношение каждого участника к реализуемому проекту.

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

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

· наличие определенной стратегической цели организации;

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

· соответствие цели реализуемого проекта стратегической цели организации;

· наличие четко определенной для всех подразделений роли управления проектами.

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

Используемые методы управления IT-проектами

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

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

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

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

Таблица 1. Традиционные методы и подходы в УП

	Начальное/базовое определение всего проекта. Оценки стоимости и наброски расписания
Матрица ответственности	Определение ответственностей, организационной структуры проекта
Диаграммы Ганта	Простое и наглядное представление расписания проекта без отображения зависимостей между отдельными событиями
Стоимостные расписания	Оценка и разработка реалистичного бюджета, подходящего под все стандарты, относительно которого отслеживаются все работы проекта
ИСПОЛЬЗОВАНИЕ ВЫШЕПЕРЕЧИСЛЕННЫХ МЕТОДОВ СОВМЕСТНО
PERT, CPM, PDM, GERT и т.д.	Разработка расписания; определения взаимозависимости и уровней влияния событий; определение критических работ; основы стоимостной оценки, распределения ресурсов и анализа рисков

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

Такие методы, как PERT, и инструменты, как WBS, и т.д. подразумевают детальную разработку плана проекта:

· определение работы;

· разработка расписания с точным определением сроков для каждого события;

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

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

Если рассматривать четыре основных этапа, то получается следующее:

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

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

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

· Контроль: рассматриваются проблемы, связанные с отслеживанием нынешнего статуса проекта.

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

В целом, подход к управлению проектами на основе системной динамики имеет достаточно большие преимущества по сравнению с традиционными подходами. Доказательства этого так же можно найти в работе P.E.D. Love, G.D. Holt, L.Y. Shen, H. Li, Z. Irani , где очень четко высказано мнение относительно того, что любой проект постоянно подвергается влиянию окружающей его среды, причем не только каких-то внутренних факторов, как отношения внутри команды и их мотивация, но и различных внешних, так называемых, регрессоров как, например, политическая ситуация в стране и в мире, изменения в социальных и культурных отраслях и т.п. При этом авторы указывают на некоторые недостатки риск-менеджмента, заключающихся в том, что все его методы направлены на риски, которые возможно заранее определить, но в целом система не включает в себя какие-либо методологии относительно того, как предугадать появление риска, индивидуального для данного проекта. Таким образом, авторы высказывают мнение, что подход, основанный на системной динамике, позволяет улучшить процесс принятия решений на стратегическом уровне, в то время как традиционные методы позволяют справиться только с третью основных задач, возникающих в процессе управления проектом.

Например, в работах Rodrigues A, Bowers J. высказано предположение, что управление проектом можно разделить на следующие ступени:

· Уровень 1 - взаимодействие проекта и компании-подрядчика; важным вопрос здесь оказывается то, совпадают ли цели проекта с целями компании;

· Уровень 2 - так называемые, стратегические альтернативы конкретного проекта; например, какие основные задачи определены в проекте, их соответствие основным целям, форма организационной структуры;

· Уровень 3 - здесь определяются конкретные детали проекта, включая в себя объем необходимой рабочей силы, сроки и расписание проекта и т.д.

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

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

Ключевые моменты, характеризующие преимущество управления проектами на основе системной динамики:

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

· Модель, построенная на основе системной динамики, должна приносить полезность и доверие/уверенность конечному пользователю (то есть менеджеру). Полезность зависит от того, затрагивает ли модель ключевые проблемы, которые интересуют менеджера; в то время как наличие доверительного уровня означает способность модели давать результаты, согласующиеся с ментальными моделями самих менеджеров.

Можно выделить несколько проблем, связанных с основными характеристиками проектов, которые решает системная динамика :

1) Разрабатываемые проекты сложны и состоят из множества взаимозависимых компонент.

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

2) Разрабатываемые проекты очень подвижны

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

3) Во всех проектах имеются обратные связи и отдача.

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

· самовоспроизводящиеся;

· вызывающие рост;

· дестабилизирующие систему;

· ускоряющие систему.

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

· противодействующие росту;

· целенаправленное поведение;

· стабилизирующие систему;

· возвращающие систему к балансу.

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

Традиционные инструменты по снижению затрат и управлению расписанием как, например, метод CPM (critical path method) не могут в полной мере справляться с эффектом отдачи и обратной связи. Оценка людей, как правило, субъективна в таких ситуациях, что приводит к недооценке возможных отдач. Никто из людей не застрахован от ошибок. Поэтому, даже методы, направленные на управление расписанием, как диаграммы Ганта, PERT и CPM не могут решить данной проблемы, что, впрочем, не означает, что данные методы не являются важными; наоборот, традиционные инструменты и системная динамика дополняют друг друга.

4) Разрабатываемые проекты состоят из нелинейных связей.

Наличие нелинейных связей вполне логично для сложных систем; это означает, что все причинно-следственные связи не имеют простой, пропорциональной зависимости. Например, рассматривая приведенный выше пример, увеличивая количество рабочих часов с 40 до 44 в неделю, можно увеличить отдачу на 10%. Но, опять же, как говорилось ранее, длительные и частые переработки приводят к быстрому угасанию производительности работников, их невнимательности, снижению мотивации, увеличению совершаемых ошибок и так далее. Системная динамика в своих моделях берет во внимание все возможные варианты развития события.

5) Разрабатываемые проекты включают в себя и «жесткие», и «мягкие» данные.

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

Рисунок 1. Схематичное представление потоков и накопителей; Ист.

С помощью потоков и накопителей очень наглядно изображаются обычные причинно-следственные связи. Накопителями являются «стоки», потоки бывают исходящие и входящие. Облако при исходящем потоке показывает какой-то источник, который в данном исследовании может не конкретизироваться; такое же облако может быть на наконечнике исходящего потока. Есть стандартизированные требования к данным обозначениям :

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

· накопители всегда выражаются в единицах модели;

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

Влияние обратных связей и циклов ПВР на продолжительность IT-проектов

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

· увеличение трудозатрат членов команд (частые переработки);

· давление на членов команд;

· добавление новых участников в команду (привлечение дополнительных человеческих ресурсов).

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

Рисунок 2. Обратные связи при использовании менеджером различных методов для корректировки задержки; Ист.

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

Рисунок 3. Схематичное изображение цикла ПВР; Ист.

Данная схема не является единой, но все циклы в любом проекте протекают примерно одним и тем же образом. Как видно из схемы, цикл состоит из четырех накопителей (стоков). Изначально все работы в проекте относятся к типу «следуемые для выполнения»; далее, после протекания различных процессов, некоторые работы переходят в стадию «выполненных», что в свою очередь истощает первый накопитель, а позже и накопитель, обозначающий известные работы, которые будут повторены. Зачастую, увеличение количества работ, которые несколько раз повторяются, наблюдается в середине и конце проекта.

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

Рисунок 4. Влияние циклов ПВР на сроки и качество; Ист.

Рассмотрим пример . Размер проекта предполагается равным 64 000 DSI (специальная размерная величина для оценки количества строк кода) . Размер номинальной потенциальной производительности обычного рабочего со средним уровнем опыта равен 1 заданию за рабочий день, а значимость 1 задания равна 60 DSI. Таким образом, получается, что размер проекта в терминах выполненных задач равен 64 000/60 = 1,067.

На начальном этапе менеджеру предстоит оценить размер проекта. Никогда не известна настоящая величина, поэтому оценка очень приблизительна. Представим, что проект был недооценен и было предположено, что его размер составит только 33% от реального, т.е. 0,67*64 000 = 42 880 DSI. Далее на основании этого уровня проводится оценка необходимых усилий и расписания с помощью модели COCOMO Это алгоритмическая модель оценки стоимости разработки программного обеспечения, разработанная Барри Боэмом (Barry Boehm). Модель использует простую формулу регрессии с параметрами, определенными из данных, собранных по ряду проектов. Ист. . По данной модели получилось, что необходимое количество рабочих дней равно 2 359 дней, а продолжительность проекта = 296 дней.

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

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

Рисунок 5. Оценочный график 1. Ист.

Рассмотрим более подробно ситуацию с производительностью.

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

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

Рассмотрим еще один график:

Рисунок 6. Оценочный график 2. Ист.

Здесь видно, что в самом начале проекта фактическая доля человеко-дней (рабочих дней) (AFMDPJ) составляла 0,6, что означает, что члены команды тратили по 0,6*8 = 4,8 часов в день на проект. На последнем этапе наблюдается резкий взлет этой кривой, что говорит о значительных переработках, которые, в свою очередь, возникли из-за изначальной недооценки проекта.

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

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

В работе S. B. Yu and J. Efstathiou циклы ПВР делятся на 5 типов:

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

b) прямой цикл ПВР означает, что после того, как какой-то объект или процесс переделан, он не проверяется заново, а включается уже полноценно в поток; соответственно, такая система обусловлена значительными рисками в плане того, что если «ремонт» объекта не исправил каких-то недочетов, то это может оказать негативное влияние на последующую работу;

c) цикл «отбрасывания» - после выявления какого-то дефекта, объект не отправляется на доработку, а выкидывается из работы совсем; это явление может быть обусловлено высокими финансовыми затратами, которые в последующей работе скорее всего не оправдаются;

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

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

Рисунок 7. Нарушение последовательности при наличии цикла ПВР; Ист.

Как видно на Рисунке 1 (а) и (b) во время того, как объект 3 находился на доработке, другие три объекта (6, 5 и 4) успели пройти проверку, поэтому на выходе (с) получилась нарушенная последовательность. В работе введена величина, которая измеряет данное изменение последовательности и равна тому, на сколько «объектов назад» был отброшен исправленный объект - длина беспорядка (в данном случае, равна 3), обозначается.

Ниже приведен рисунок, на котором схематично указаны перечисленные выше типы циклов ПВР:

Рисунок 8. Схематичное изображение типов циклов ПВР;Ист.

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

Таблица 2. Сравнение различных типов циклов ПВР

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

Необходимость наличия подобного буффера обуславливается еще одним фактором - потребность в дополнительном времени на обработку задач, ожидающих повторного выполнения. Исследование Hazhir Rahmandad и Kun Hua предлагает интересный подход к изучению циклов ПВР. Интересна модель, предложенная авторами, которая рассматривает циклы ПВР не только с точки зрения выполняемых задач и задач, отправляемых на «инспекцию», но и с точки зрения самих дефектов. Два процесса могут протекать параллельно: процесс проверки на наличие дефектов самих задач и жизненный цикл самих дефектов, и эти два процесса очень тесно взаимосвязаны.

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

Исследователи предложили очень интересный вариант расчета вероятности выявления дефектов. Для этого было предложено понятие дефектной плотности - общее количество дефектов на полный объем работ. То есть если 100 задач, 113 дефектов, то плотность равна 1,3. На нижнем рисунке данное явление представлено схематично (зеленое поле - общий объем работ, красные точки - разброс дефектов, область в правом нижнем углу - проводимый тест на выявление дефектов, площадь этой области обозначается буквой a и рассчитывается в задачах):

Рисунок 9. Дефектная плотность; Ист.

И это дает возможность расчета вероятности через Пуассоновское распределение. Данное распределение было выбрано в силу двух факторов: вероятность выявления дефектов одинаково на любой области проведения тестов; каждый из дефектов имеет одинаковую вероятность попадания в тест.

Отсюда была выведена формула вычисления вероятности выявления k дефектов в тестовой зоне размера a:

таким образом, если плотность (d) равна 1,3, а a=1, k=0, тогда существует 27 процентная вероятность выявления этих дефектов. Если k=1, тогда вероятность повышается до 35%, что вполне логично. Причем, при увеличении области проверки, вероятность тоже значительно увеличивается, если k мало; если k достаточно велико (примерно соразмерно с количеством проверяемых задач), то вероятность увеличивается, но не значительно.

Кроме того, была выведена формула расчета вероятности безуспешного прохождения тестирования:

Значение обозначает вероятность того, что была протестирована с k дефектами и k дефектов были упущены.

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

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

Моделирование процесса производства на основе непрерывной цепи Маркова позволяет рассмотреть прямое влияние возникновения циклов ПВР на бюджет проекта. В основе лежит идея того, что каждый производственный этап находится в переходном состоянии, которое подразумевает пересмотр незавершенного объекта. Существует два варианта развития событий для каждого объекта на определенном производственном этапе: объект оказывается удачно завершенным и переходит с вероятностью p на следующий производственный этап и объект возвращается на доработку по результатам проведенной проверки с вероятностью q; при этом величина «поглащающий» момент, характеризующий отбрасывание объекта в виду выявленных ошибок, не подлежащих исправлению, исчисляется следующим образом:

Ниже представлена цепь Маркова порядка 2n+1:

Рисунок 10. Цепь Маркова порядка 2n+1; Ист.

Стоимость, затрачиваемая на объект, проходящий через проверку в первый раз, ниже стоимости объекта, проходящего повторную проверку в силу того, что на последний объект затрачиваются материальные средства на исправление идентифицированных ошибок и на «время ожидания», то есть, в случае материального производства, на хранение объекта на складе, на его обслуживание и др. Для определения итоговой стоимости на объект, перешедший в «поглащающий» момент (подразумевает как возможность попадания в брак, так и в финальный - успешный - этап) на том или ином этапе производства необходимо учитывать ожидаемое количество прошедших производственных этапов, ожидаемое время до попадания в это состояние, ожидаемые затраты, ожидаемое количество циклов повторного выполнения работы для устранения ошибок и ожидаемые время и затраты на проведение подобных циклов с данным объектом. Здесь авторами исследования вводится понятие «веса» посещения производственного этапа k = . При, на каждом попадании в очередной производственный этап затраты увеличиваются на 1. Так, - доля объектов, проходящих первую проверку на производственном этапе k со стоимостью, а - доля объектов, проходящих повторную работу со стоимостью. Тогда средняя стоимость прохождения через каждый производственный этап составит:

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

1) Вероятность попадания объекта из первого этапа в финальный - успешный - этап = 0,93;

2) Количество проходимых производственных этапов для каждого объекта перед попаданием в «поглащающий» момент = 2,987, что близко к 3 (полной цепи); здесь небольшое отклонение обусловлено как раз небольшой вероятностью попадания некоторых объектов в брак;

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

4) Ожидаемые затраты на финальный продукт = 6,457, где 0,457 включает в себя затраты на циклы ПВР (которые по результатам исследования = 0,208) и затраты на запуск новой продукции взамен бракованной (т.е. минимальная теоретическая стоимость брака = 0,249).

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

Рисунок 11. Влияние увеличения вероятности перехода на итоговую стоимость; Ист.

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

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

Многими исследователями сейчас изучается и совершенствуется одна из наиболее приближенных к реальному миру моделей под названием RCPSP (Resource-Costrained Project Scheduling model). Одним из наиболее интересных моментов этой модели является идея о «перекрывании» или «нахлестывании». Это явление подразумевает под собой начало выполнения последующего действия еще до получения полной информации, что позволяет значительно сократить время, затрачиваемое на выполнение всего проекта. С другой стороны, это может привести к появлению циклов ПВР в будущем, т.к. полная информация может затребовать выполнения каких-то других действий или выполнения их другим образом.

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

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

Ограничения

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

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

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

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

Обратные связи

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

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

Величина нахлестывания

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

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

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

Расчет величины «переделывания»

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

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

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

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

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

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

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


Информационные системы управления проектами. Классификация и краткий обзор программного обеспечения управления проектами. Внедрение специализированного программного обеспечения при проведении автоматизации управления Фитнес-клубом с выкупом территории.

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


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

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


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

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


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

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


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

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


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

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


Теоретические аспекты международных и национальных стандартов в области управления проектами. Описание международных и национальных стандартов управления проектами. Практическое использование стандартов на примере организации ОАО "Молоко" г. Калининград.

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


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

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


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

На управление проектами оказывает влияние окружение проекта, которое можно разделить на внешнее и внутреннее.

Внешнее окружение:

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

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

Внутреннее окружение. Наиболее существенными факторами "внутреннего" окружения являются:

стиль руководства проектом. Он определяет психологическую атмосферу в команде проекта, влияет на ее творческую активность и работоспособность;

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

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

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

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

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

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

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

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

PMI PMBOK 2015 Guide 4d Edition (оценка проектов на основании британской методики) состоит из двух частей:

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

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

Таблица 1.2.

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

	Процессы
1. Управление Интеграцией	1. Процессы, обеспечивающие координацию между элементами проекта.
2. Управление Замыслом	2. Процессы, обеспечивающие замысел и выполнение всех требуемых и только тре-буемых работ.
3. Управление Временем	3. Процессы, обеспечивающие завершение работ в заданное время.
4. Управление Стоимостью	4. Процессы, обеспечивающие завершение работ в заданном бюджете.
5. Управление Качеством	5. Процессы, обеспечивающие выполнение требований и ожиданий заказчика.
6. Управление Ресурсами	6. Процессы, обеспечивающие наиболее эффективное использование ресурсов, участ-вующих в проекте.
7. Управление Коммуникацией	7. Процессы, обеспечивающие создание, хранение и своевременное распределение информации о проекте.
8. Управление Риском	8. Процессы, связанные с определением, анализом и реакцией на возможный риск, связанные с проектом.
9. Управление Поставками	9. Процессы, необходимые для заказа товаров и услуг у других организаций.

Примечание: источник .

Как правило, для удобства управления, проекты разбиваются на несколько фаз. Все фазы вместе называются жизненным циклом проекта (Project Life Cicle). Внутри каждой фазы и в целом по проекту процессы организованы в пять групп (табл. 1.3).

Таблица 1.3

Процессы внутри фазы по проекту

Примечание: источник .

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

международная организация по стандартизации ISO опубликовала стандарт ISO 10006 «Системы менеджмента качества. Руководящие указания по менеджменту качества проектов». В настоящее время выполняется разработка стандарта ISO 21500 «Руководство по менеджменту проектов». Однако официально данный стандарт будет утвержден только в 2012 году;

международная ассоциация проектного менеджмента (International Project Management Association - IPMA) объединяет 45 национальных ассоциаций и является авторитетной профессиональной организацией в области управления проектами. Россию в IPMA представляет национальная ассоциация управления проектами СОВНЕТ. Основным стандартом, разработанным IPMA, является ICB (IPMA Competence Baseline, 3-я версия выпущена в 2015 году), определяющая требования к квалификации специалистов в области управления проектами и являющаяся основой для международной сертификации. В соответствии с правилами и требованиями IPMA в России разработаны национальные требования к компетенции менеджера проекта и программа сертификации специалистов по управлению проектами. Специалисты, прошедшие сертификацию по этой системе, получают сертификаты международного образца, которые признаются во всем мире;

институт управления проектами США (Project Management Institute - PMI) сегодня «де факто» также можно назвать международной профессиональной организацией. Членами PMI являются специалисты в области управления проектами со всего мира, в различных странах функционируют отделения института. PMI ведет активную разработку стандартов в области управления проектами. В настоящее время опубликовано 3 основных стандарта, регламентирующих процессы управления на уровне проекта, программы, портфеля проектов и более 10 дополнительных стандартов. Дополнительные стандарты определяют как требования к отдельным методикам управления проектами (разработка иерархической структуры работ, разработка календарного плана, управление рисками и другие), так и к применению проектного менеджмента для определенных типов проектов (управление строительными проектами, управление государственными проектами и другие) .

По областям применения стандарты могут быть разделены на следующие группы:

применимые к отдельным объектам управления (проект, программа, портфель проектов) и регламентирующие соответствующие процессы управления;

применимые к субъектам управления (менеджеры проектов, участники команд управления проектами) и определяющие требования к знаниям и квалификации соответствующих специалистов и процессу оценки квалификации;

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

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

Таблица 1.4.

Наиболее известные стандарты международного и национального уровня

Классификация стандартов
Международные стандарты, определяющие общие требования к процессам управления проектом.	ISO 10006 «Системы менеджмента качества. Руководящие указания по менеджменту качества проектов»	ГОСТ Р ИСО 10006-2013 «Системы менеджмента качества. Руководство по менеджменту качества при проектировании», 2015.На практике применяется достаточно редко, поскольку носит общий характер.
Национальные стандарты, определяющие общие требования к процессам управления проектом.	A Guide to the Project Management Body of Knowledge (PMBOK Guide). Руководство к своду знаний по управлению проектами. Четвертое издание. PMI. 2015 PRINCE2 (PRojects IN Controlled Environments). OGC UK, 2001 и другие национальные стандарты	Руководство к своду знаний по управлению проектами. Четвертое издание. PMI. 2015 Русская версия. Не является стандартом в России. Однако PMBOK широко применяется на международном уровне и является стандартом «де факто». В России также применяется достаточно широко.
ЕСУП (Евразийский Стандарт Управления Инновационными Проектами)	Не известны иностранные версии стандарта	Евразийский Стандарт Управления Проектами разрабатывается на основе лучших мировых достижений проектного менеджмента с учётом задач и особенностей Евразийской цивилизации. Основная идея стандарта воплощена в корпоративном прототипе ЕСУП.
Стандарты, определяющие общие требования к процессам управления программой и портфелем проектов.	The Standard for Program Management, Second Edition, PMI 2015. The Standard for Portfolio Management, Second Edition, PMI 2015 Managing Successful Programmes, OGC UK, 2014 P2M. Program and Project Management for Innovation of Enterprises, PMCC, 2002
Стандарты, определяющие требования к последовательности и методикам выполнения отдельных процессов.	Practice Standard for Work Breakdown Structure, 2nd Edition, PMI, 2015 Practice Standard for Earned Value Management, PMI, 2013 Practice Standard for Scheduling, PMI, 2014 Practice Standard for Configuration Management, PMI, 2014	ГОСТ Р 52806-2014 Менеджмент рисков проектов. Общие положения.
Стандарты, определяющие требования к квалификации специалистов в области управления проектами.	ICB IPMA Competence Baseline, Version 3.0, IPMA 2015 PMCDF Project Management Competence Development Framework, PMI, 2013	Основы Профессиональных Знаний и Национальные Требования к Компетентности (НТК 3.0) Специалистов по Управлению Проектами, СОВНЕТ, 2013. Не является официальным стандартом в России, но зарегистрирован в Росстандарте России. Используется для сертификации специалистов в соответствии с требованиями IPMA. ГОСТ Р 52807-2014 Руководство по оценке компетентности менеджеров проектов.
Стандарты, определяющие требования к корпоративной системе управления проектами.	OPM3 Organizational Project Management Maturity Model, PMI, 2015	Нет русскоязычных версий стандартов.

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

В рамках организационно - деятельностей (“менеджерской”) модели (ICB IPMA) проект как понятие определяется через предприятие, усилие и деятельность.

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

те, которые можно описать в виде процессов, объектов, методов;

те, которые не описываемы в принципе или трудно описываемы в виде процессов, объектов, методов.

Современные подходы к стандартизации в области РМ основаны на следующем:

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

для тех областей РМ, описание которых в виде объектов для стандартизации нецелесообразно или невозможно, используются профессиональные квалификационные стандарты (требования) к деятельности специалистов по РМ (Project Management Professional) и менеджеров проектов (Project Manager).

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

Вывод по первой главе

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

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

Название вуза

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

«Инструментарий

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

Выполнил:

Проверил:

Введение 4

1 Основные инструменты управления проектом: теоретические аспекты 5

1.1 Роль инструментария проектного управления 5

1.2 Характеристика и разработка основных инструментов проектного управления 6

2 Применение инструментария проектного управления на примере проекта создания АНО «Рекрутинговое агентство «Старт» 7

2.1 Общая характеристика проекта 7

2.2 Планирование проекта с использованием основных инструментов управления проектами 8

Заключение 9

Список используемых источников 10

Приложения

Приложение А. Структурная декомпозиция работ по проекту

Приложение Б. Сетевая модель по проекту «Рекрутинговое агентство «Старт»

Приложение В. Диаграмма Ганта

Введение

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

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

Для успешного осуществления проекта имеются два значимых фактора:

Техническая сторона проекта: планирование и оценка затрат, управление и контроль за исполнением проекта, управление рисками, управление качеством, проектная документация, оценка результатов.

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

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

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

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

Данная цель обуславливает необходимость решения следующих задач:

изучение теоретических аспектов проектного управления;

1 Основные инструменты управления проектом: теоретические аспекты

1.1 Роль инструментария проектного управления

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

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

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

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

3. Жизненный цикл проекта. Проект в процессе его создания и

1.2 Характеристика и разработка основных инструментов проектного управления

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

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

Структура разбиения работ, или дерево работ, иерархическая структура работ, структурная декомпозиция работ – иерархический граф, узлы которого изображают работы и комплексы работ, а связи, всегда имеющие вид «один к одному», - разбиение вышестоящего элемента на нижестоящие 2 . Общая схема СДР приведена на рисунке 4.

Рисунок 4 – Общая схема структурной декомпозиции работ проекта

2 Применение инструментария проектного управления на примере проекта создания АНО «Рекрутинговое агентство «Старт»

2.1 Общая характеристика проекта

Проект предполагает создание в городе Москва рекрутингового агентства, занимающегося подготовкой и трудоустройством молодых специалистов – выпускников ВУЗов, ССУЗов на предприятия, в организации и в органы власти города Москва и Московской области.

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

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

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

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

2.2 Планирование проекта с использованием основных инструментов управления проектами

В приложении А представлена структурная декомпозиция работ по проекту создания рекрутингового агентства «Старт».

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

В таблице 4 представлена сетевая матрица, в которой отражены основные работы по проекту «Рекрутинговое агентство», ориентировочная продолжительность каждой работы и исполнители этих работ.

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

Теперь рассчитаем для проекта «Рекрутинговое агентство» критический путь.

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

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

1- определение цели и плана действий

2- мониторинг ситуации на рынке труда Москвы и Московской области

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

Таблица 4 – Сетевая матрица по проекту «Рекрутинговое агентство «Старт»

4- регистрация Автономной некоммерческой организации «Рекрутинговое агентство «Старт»

5- разработка программы презентации

7- проведение презентаций в учебных заведениях

8- организация и проведение Дня резюме

9- обработка резюме, сведение в единую базу данных

Заключение

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

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

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

Список используемых источников

Андронов С. А., Макарчук Н. В., Макарчук А. В. Менеджмент в проектной деятельности: учебное пособие. – СПб.: СПбГУАП, 2001. – 126 с.

Бэгьюли Ф. Управление проектом/ Фил Бэгьюли. – Пер. с англ. В. Петрашек. – М.: ФАИР-ПРЕСС, 2002. – 208 с.

Богданов В. В. Управление проектами в Microsoft Project 2007. Учебный курс. – СПб.: Питер, 2008. – 592 с.

Верзух Э. Управление проектами: ускоренный курс по программе МВА. – М.: ООО «И.Д. Вильямс», 2008. – 480 с.

Герасимов В. В., Чередникова Л. Е. Управление проектами: задачи, методы и инструменты. Учебное пособие. – Новосибирск: Сибирская академия финансов и банковского дела, 2007. – 256 с.

Гонтарева И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами: учеб. пособие. – М.: Книжный дом «Либроком», 2009. – 384 с.

Грей К. Ф., Ларсон Э. У. Управление проектами: Практическое руководство. – М.: Изд-во «Дело и сервис», 2003. – 528 с.

Ивасенко А. С., Никонова Я. И., Каркавин М. В. Управление проектами: учебное пособие. – Ростов н/Дону: Феникс, 2009. – 330 с.

Кух С.Х., Тейн К. Управление проектами: учебник. – М.: Поколение, 2007. – 432 с.

Локир К. Управление проектами: ступени высшего мастерства. – Минск: Грувцов Паблиситер, 2008. – 352 с.

Мазур И. И., Шапиро В. Д. Управление проектами: учебное пособие / под общ. ред. И. И. Мазура. – М.: Омега-Л, 2004. – 664 с.

Милошевич Д. Набор инструментов для управления проектами. – М.: Компания АйТи; ДМК Пресс, 2008. – 729 с.

Просветов Г. И. Управление проектами: задачи и решения: учебно-практическое пособие. – М.: Изд-во «Альфа-Пресс», 2008. – 200 с.

Романова М. В. Управление проектами: учебное пособие. – М.: ИД «

1 Хэлдман К. Управление проектами. Быстрый старт: эффективные инструменты и приемы. – М.: Компания АйТи; ДМК Пресс, 2008. – С. 131.

2 Управление проектом. Основы проектного управления: учебник/ кол. авт.; под ред. проф. М. А. Разу. – М.: КНОРУС, 2006. – С. 489. управленческого учета способно обеспечивать... 52. Бюджетирование как инструментарий проектному управлению . Главная задача состоит в...

Управление проектами (2)

Документ

Планирование и контроль), как инструментарий управленческого учета способно обеспечивать... 52. Бюджетирование как инструментарий управленческого учета. Составление и... волнуют руководителей и специалистов по проектному управлению . Главная задача состоит в...

Управление портфелями проектов на основе международных стандартов

Программа

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

«Из всех трудностей, с которыми столкнулись НАСА, отправляя человека на Луну, управление было наверно самой сложной задачей»

— Роджер Лаунис, историк НАСА

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

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

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

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

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

В этой статье мы рассмотрим:

• Классический проектный менеджмент
• Agile
• Scrum
• Lean
• Kanban
• Six Sigma
• PRINCE2

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

Почему «управление проектами»?

Имена Нила Армстронга и Базза Олдрина навсегда войдут в историю как символы одного из величайших достижений человечества – высадке человека на Луну. Однако основной вклад в это событие внесли 400 000 сотрудников НАСА и 20 000 компаний и университетов, работавших вместе над миссией «Аполлон».

В 1961 году Джон Кеннеди поставил задачу высадить человека на спутнике Земли и вернуть его обратно – при том, что на тот момент НАСА отправляли человека в космос лишь на 15 минут. Такая амбициозная цель потребовала невероятного количества ресурсов, кооперации, инноваций и планирования.

Как говорится в книге НАСА «Managing the Moon Program», основная проблема состояла не в том, «что делать?» , а в том, «как сделать столько за такой короткий срок?». По словам доктора Макса Фагета (Dr. Max Faget), главы инжиниринга в Космическом центра имени Линдона Джонсона (The Lyndon B. Johnson Space Center, JSC) , тогда в НАСА не представляли, как уложить все необходимые действия в 10 лет. А потому первым шагом стало «разбить проект на управляемые этапы».

Затем важно было ускорить выполнение каждой отдельной фазы и удостовериться, что команды и компании, работающие на каждой фазе, эффективно взаимодействуют друг с другом и вовремя поставляют результаты. Эта задача была возложена на доктора Джорджа Мюллера (George E. Muller), управлявшего каждой частью проекта «Аполлон», от Белого Дома до поставщика самой мелкой детали. Чтобы контролировать проект было легче, он решил разбить проект на 5 областей: «Контроль Программы», «Системная Инженерия», «Тестирование», «Надёжность и Качество» и «Лётная эксплуатация». Схема управления программой Аполлон представлена на Рисунке 1 .

Эта система из 5 этапов – названных «Этапами GEM» в честь инициалов доктора Мюллера – была разработаны «ради фокусировки на тестировании продукта, и на его разработке с учётом того, что его будут тестировать», как отмечает сам Мюллер. «Контроль Программы» определял, что нужно сделать, управлял бюджетом и требованиями, а также управлял взаимосвязями элементов программы. Область «Системная инженерия» отвечала за разработку новых устройств и узлов, «Тестирование» за то, что эти новые элементы работают, «Надёжность и Качество» проверяли разработанные элементы на соответствие требованиям и стандартам, а «Лётная эксплуатация» отвечала за то, что эти узлы будут работать во время полёта.

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

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

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

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

Однако, если Вы – шеф-повар, и готовите не одно блюдо, а несколько, например, салат (приготовление которого состоит из 3 этапов) и десерт (который нужно только подать), то Вам потребуется инструмент, позволяющий отслеживать временные затраты на каждый из элементов и время, когда они должны быть готовы. И тут на помощь приходит один из первых современных инструментов проектного управления: Диаграмма Гантта, представленная на Рисунке 2 .

Изобретённая независимо Ко ролем Адамеки (Korol Adamecki) и Генри Л. Ганттом (Genry L. Gantt) в начале XX в., диаграмма Гантта показывает расписание проекта основываясь на датах окончания и завершения задач. В неё вносятся задачи, их длительности и взаимосвязи, а затем высчитывается критический путь – самая длинная цепочка взаимосвязанных задач, определяющих длительность проекта. Взаимосвязи между началом и окончанием разных задач очень важны – вы же не можете подать гостям суп, пока вы его не сварили, не так ли?

Так вот, типовой проект очень похож на проект приготовления и подачи ужина, только в нём гораздо больше задач, взаимосвязей, дедлайнов и видов ресурсов. Проектам с жёсткими дедлайнами диаграмма Гантта помогает решить, когда лучше начинать те или иные задачи, чтобы сократить время реализации. А для проектов с сильными ресурсными ограничениями, диаграмма Гантта предоставляет возможность построить схему в форме событийной цепочки процессов (event-driven process chain) для планирования ресурсов.

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

Для таких проектов лучше подходят гибкие методы управления проектами Agile и связанные с ним подходы, такие как Lean, Kanban и другие. Есть и методы, позволяющие управлять как рабочим потоком, так и временем, и ресурсами – 6 Сигм и Scrum.

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

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

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

Базовые термины проектного управления

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

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

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

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

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

Менеджер проекта (руководитель проекта, project manager, PM): Руководитель команды проекта, ответственный за управление проектом (планирование, реализацию и закрытие проекта).

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

Спринт (Sprint): Итерация (рабочий цикл) в Scrum, длящаяся от недели до месяца, в ходе которой создаётся рабочая версия продукта или его элемент, представляющий ценность для заказчика.

«Классическое» или «традиционное» проектное управление: Наиболее широко распространённый метод управления проектами, основанный на так называемом «водопадном» (Waterfall) или каскадном цикле, при котором задача передаётся последовательно по этапам, напоминающим поток.

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

Наиболее очевидный способ сделать свой проект более управляемым – это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. В этом смысле оно напоминает компьютерную игру – нельзя перейти на следующий уровень не завершив предыдущий. Схема рабочего процесса приведена на Рисунке 3 .

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

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

5 этапов традиционного менеджмента:

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

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

Этап 3. Разработка. Данная стадия реализуется не для всех проектов — как правило она является частью фазы планирования. В фазе разработки, характерной для технологических проектов, определяется конфигурация будущего проекта и/или продукта и технические способы его достижения. Например в ИТ-проектах на данном этапе выбирается язык программирования. (В отечественной практике данная фаза обычно не выделяется, а термин «разработка» не используется — прим. пер.)

Этап 4. Реализация и тестирование. На этой фазе происходит собственно основная работа по проекту – написание кода, возведение здания и тому подобное. Следуя разработанным планам начинает создаваться содержание проекта, определённое ранее, проводится контроль по выбранным метрикам. Во второй части данной фазы происходит тестирование продукта, он проверяется на соответствие требованиям Заказчика и заинтересованных сторон. В части тестирования выявляются и исправляются недостатки продукта.

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

То, что описано выше – база, на которой строятся различные методы управления проектами. Разным проектам нужны различные фазы реализации – некоторым достаточно и трёх фаз, другим гораздо больше. Иногда используется так называемый «итеративный водопад», в котором каждый этап представляет собой некий подпроект, в ходе которого задачи реализуются по фиксированным итерациям. Но суть остаётся одна – проект разбит на этапы, которые исполняются в строго определённой последовательности.

Благодаря тому, что классический проектный менеджмент строго привязан ко времени исполнения задач, как правило, заранее определённому на этапе планирования, для реализации проектов в рамках данного подхода отлично подходят инструменты календарно-сетевого планирования. Самым распространённым инструментом календарно-сетевого планирования является уже упомянутая ранее диаграмма Гантта. Существует множество инструментов для её построения – от простых таблиц вроде Excel и Smartsheet до профессиональных программных пакетов вроде Microsoft Project и Primavera.

Сильные стороны классического проектного менеджмента

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

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

Слабые стороны классического проектного менеджмента

Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Руководство компании Toyota, знаменитую созданием таких систем как Lean и Kanban, часто критикуют за то, что они применяют классический подход в разработке софта для своей компании, причём именно за недостаток гибкости.

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

Agile

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

И тут в игру вступает Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на Рисунке 5 .

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

Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова (об истории появления Agile можно прочесть – прим.пер.). Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto) , закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям.

Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки (frameworks): Scrum, Kanban, Crystal, и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам.

Сильные стороны Agile

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

Один из принципов Agile: «Реакция на изменения важнее следования плану». Именно быстрая и относительно безболезненная реакция на изменения является причиной тому, что многие крупные компании стремятся сделать свои процессы более гибкими. Кроме того, Agile отлично подходит для проектов с «открытым концом» — например, запуску сервиса или блога.

Вотчина Agile – разработка новых, инновационных продуктов. В проектах по разработке таких продуктов высока доля неопределённости, а информация о продукте раскрывается по ходу проекта. В таких условиях реализовывать проект по «водопаду» становится невозможно– нет информации для планирования.

Слабые стороны Agile

В отличие от PRINCE2 и PMBOK Agile – не является ни методологией, ни стандартом. Agile — это набор принципов и ценностей. Слабая сторона состоит в том, что каждой команде придётся самостоятельно составлять свою систему управления, руководствуясь принципами Agile. Это непростой и длительный процесс, который потребует изменений всей организации, начиная процедурами и заканчивая базовыми ценностями. Это тернистый путь и не всем организациям он под силу.

Этот путь потребует от лидера изменений не только знаний и упорства, но и серьёзных административных ресурсов, а также затрат. К счастью, существуют готовые наборы практик, которые облегчают Agile-трансформацию организации. К таким наборам относятся фреймворк Scrum, метод Kanban и многие другие – Crystal, LeSS, SAFe, Nexus.

Scrum

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

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «беклог». Затем эти части приоретизируются Владельцем продукта – представителем Заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в Спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце Спринта Заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему Спринту. Длительность у Спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям Заказчика, которые имеют свойство изменяться со временем, перед началом каждого Спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, Scrum Мастер (Scrum Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

Как уже говорилось, Владелец продукта является представителем Заказчика в проекте, или олицетворяет всех клиентов будущего проекта, в случае если Заказчика нет. Для этого он должен досконально знать их потребности и образ мышления, а также разбираться в продукте и технологии его изготовления. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача — следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены.

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

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

Сильные стороны Scrum

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

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

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

Слабые стороны Scrum

Scrum очень требователен к команде проекта. Она должна быть небольшой (5-9 человек) и кроссфункциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга.

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

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

Lean

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

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

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

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

Сильные стороны Lean

Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны Lean

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

А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций ̶ главное помнить об этом.

Kanban

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент.

Кроме того, создатель Kanban вдохновлялся супермаркетами, а именно их принципом – «держи на полках только то, что нужно клиенту». А потому в Kanban разрешается оставить неоконченную задачу на одном из этапов, если её приоритет изменился и есть другие срочные задачи. Неотредактированная статья для блога, подвешенная без даты публикации или часть кода функции, которую возможно не будут включать в продукт – всё это нормально для работы по Kanban.

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

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

Ваша собственная система Kanban может быть настолько гибкой, насколько Вы сами того пожелаете – ведь во многом Kanban является визуализацией идеи Agile. Но у Kanban есть 4 столпа, на которых держится вся система:

1. Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
2. Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
3. Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
4. Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Сильные стороны Kanban

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.

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

Слабые стороны Kanban

Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких дедлайнов. Для жёстких дедлайнов лучше подходит классический подход или Scrum.

6 сигм (Six Sigma)

Компания Motorola, наряду с Toyota, также внесла вклад в развитие мирового проектного управления. Инженер этой компании Bill Smith создал концепцию 6 сигм в 1986 году. Это более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, также снижения количества брака и проблем.

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

Для этого было предложен процесс из 5 шагов, известных как DMEDI:

• Определение (Define): Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.
• Измерение (Measure): 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.
• Исследование (Explore): На стадии исследования менеджер проекта решает, каким же образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. На данном этапе очень важно нестандартное мышление руководителя проектов при решении возникших проблем.
• Разработка (Develop): На данном этапе реализуются планы и решения, принятые на предыдущих этапах. Важно понимать, что на данном этапе необходим детальный план, в котором описаны все действия, необходимые для достижения поставленных целей. Также на данном этапе измеряется прогресс проекта.
• Контроль (Control): Ключевой этап в методологии 6 сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

6 сигм очень похожа на Kanban, только с установленными этапами реализации задач – планированием, определением целей и тестированием качества. Вероятнее всего, встреч команды при применении 6 сигм будет значительно больше, чем при Kanban, но зато процесс реализации проектов более структурирован и команде сложнее сбиться с пути. И, как и Kanban, 6 сигм можно относительно легко адаптировать к нуждам конкретной компании или команды. Жёстким требованием является лишь тщательное измерение и контроль показателей проекта на этапах реализации – без этого невозможно постоянное долгосрочное улучшение процессов реализации проекта.

Сильные стороны 6 сигм

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

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

Слабые стороны 6 сигм

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

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

PRINCE2

НАСА – не единственная государственная организация, которая внесла вклад в развитие проектного управления. Британское Правительство давно оценило эффективность проектного управления, и в 1989 году была создана британская методология PRINCE2. Название произошло от акронима «PR ojects IN C ontrolled E nvironments version 2 », что переводится как «Проекты в контролируемой среде версия 2». В отличие от гибких методов, PRINCE2 не использует итеративный подход к проекту. Если сравнивать PRINCE2 другими продуктами, то его можно сравнить с гибридом классического подхода к проектному управлению и концентрации на качестве из 6 сигм.

Методология PRINCE2 в отличие от, например, свода знаний PMBOK не содержит:

• Специализированных аспектов управления проектом, например, отраслевых;
• Конкретных практик и инструментов управления проектами, таких как диаграмма Гантта, WBS и т.п.

PRINCE2 концентрируется на управленческих сторонах проекта, выраженных в 7 принципах, 7 процессах и 7 темах проекта.

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

В начале проекта PRINCE2 предлагает нам определить 3 основных аспекта проекта:

• Бизнес-аспект (Принесёт ли этот проект выгоду?)
• Потребительский аспект (Какой нужен продукт, что мы будем делать?)
• Ресурсный аспект (Достаточно ли у нас всего, чтобы достичь цели?)

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

Согласно PRINCE2 у каждого члена команды есть своя чёткая роль в каждом из 7 процессов:

• Начало проекта (Start ing up a project ): В ходе данного процесса назначается менеджер проекта и определяются общие требования к характеристикам продукта. Менеджер проекта, чья основная задача – внимание к деталям, отчитывается перед Управляющим комитетом проекта, который отвечает за общее руководство проектом. Именно Управляющий комитет следит за тем, чтобы проект не сбился с курса, и он же полностью отвечает за успех проекта.
• Инициация проекта (Initiation a project ): В ходе данного процесса менеджер проекта составляет «Документацию по инициации проекта», в которой содержится план проекта по стадиям. Стадии могут длиться разное количество времени, но, как и в классическом подходе, они следуют строго друг за другом.
• Руководство проектом (Directi ng a project ): Данный процесс предоставляет возможность Управляющему комитету нести общую ответственность за успех проекта, не погружаясь в детали, которые находятся в границах полномочий менеджера проекта.
• Контроль стадии (Control ling a stage ): При реализации проекта, даже в идеальных условиях, будут вноситься определённые изменения. Процесс «Контроль стадии» реализует один из принципов PRINCE2 – принцип управления по исключениям. В обязанности менеджера проекта входит отслеживать в ходе выполнения стадии отклонения от плановых параметров проекта по срокам, содержанию, бюджету и др. Если эти отклонения превышают данные руководителю проекта Управляющим комитетом полномочия (в терминологии PRINCE2 – допуски), менеджер проекта обязан проинформировать Управляющий комитет и предложить пути выхода из ситуации.
• Управление созданием продукта (Managing Product Delivery): Процесс управления созданием продукта представляет собой взаимодействие менеджера проекта и менеджера команды по созданию одного из продуктов проекта. В обязанности менеджера проекта в данном процессе входит делегирование полномочий по созданию продукта менеджеру команды и приемка созданного продукта.
• Управление границами стадии (Manag ing a stage boundary ): В ходе данного процесса менеджер проекта предоставляет Управляющему комитету всю необходимую информацию для оценки результатов пройденной стадии и принятия решения о переходе на следующую стадию.
• Завершение проекта (Closing a project ): Одно из отличий PRINCE2 в том, что процесс завершения проекта не выделяется в отдельный этап или стадию, как в классическом подходе, а выполняется в рамках финальной стадии создания продукта. Цель процесса – подтвердить, что продукт проекта принят, или проект больше не может принести ничего полезного.

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

Сильные стороны PRINCE2

• Адаптируемость к особенностям организации;
• Наличие чёткого описания ролей и распределения ответственности;
• Акцент на продуктах проекта;
• Определённые уровни управления;
• Фокус на экономической целесообразности;
• Последовательность проектной работы;
• Акцент на фиксации опыта и постоянном совершенствовании.

Слабые стороны PRINCE2

• Отсутствие отраслевых практик;
• Отсутствие конкретных инструментов для работы в проекте.

Лучшая система управления проектами … для Вас!

Управление проектами – это наука, но наука не самая точная. В данной области нет незыблемых основ и универсальных решений. Если вам удастся найти метод, идеально подходящий вашему проекту – считайте, что вам крупно повезло, ведь большинству менее удачливых руководителей приходится прикладывать усилия для создания и настройки собственных систем управления проектами. Эти системы могут быть составлены из элементов существующих систем или даже созданы совершенно с нуля, как в случае с миссией «Аполлон». Главное используйте что-нибудь, что даст вам хоть какую-то структуру и позволит не забыть о том, что главное для вашего проекта.

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

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

1. Битрикс24

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

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

2. Jira

Изначально Jira - это баг-трекер, то есть система для контроля ошибок в программном коде. Но очень много компаний используют ее именно как инструмент управления проектами. Подходит для команд, использующих методологии Scrum и Kanban.

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

3. Asana

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

Отдельно стоит упомянуть, что функциональность продукта расширяется с помощью подключения сторонних сервисов: от Dropbox и Google Drive до Zapier и Bitbucket.

4. ActiveCollab

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

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

5. Slack

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

И, конечно, в Slack доступны боты в больших количествах. Мессенджер попытался взять лучшее от своих прародителей вроде IRC и Jabber.

6. Wrike

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

Отдельно указывается, что есть функция создания отчетов для экономии времени. Дополнение к Outlook и Apple Mail помогает создавать задачи напрямую из писем.

7. MS Project

Старожил рынка, не так давно получивший и онлайн-версию. Очень популярен у западных пользователей и едва ли не синоним диаграммы Ганта. Позволяет планировать проекты, управлять ресурсами, планировать сценарии вида «что, если» и следить за дедлайнами и прогрессом. Плотно интегрируется с Microsoft Office последних версий, SharePoint.

Требует очень много времени на освоение. Его внедрение - целая история для компании.

8. Evernote

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

Сам проект идеально подходит именно для последней задачи.

9. Trello

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

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

10. Basecamp

Один из первопроходцев систем управления проектами «новой волны», запущен в 2004 году. Среди возможностей: ведение списков, просмотр расписания сотрудников и команд, хранение файлов и групповой чат. При помощи API можно подключать сторонние приложения. За14 лет проект сохранил свою главную черту: функциональную простоту.

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

Выводы

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

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