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

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

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

Проект обладает определенными свойствами .

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

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

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

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

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

Управляемыми параметрами проекта являются:

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

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

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

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

Управление проектом состоит из трех основных этапов:

формирование плана проекта,
контроль за реализацией плана и оперативная его коррекция,
завершение проекта.

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

В настоящее время для автоматизированного управления проектами используется методология сетевого планирования и управления. Эта методология была разработана в 1956 г. специалистами фирм "Дюпон" и "Ремингтон Ред" М.Уолкером и Д.Келли для проекта по модернизации заводов фирмы "Дюпон". Впечатляющим результатом ее использования является проектирование корпорацией "Локхид" ракетной системы "Поларис" для оснащения подводных лодок ВМС США. В результате применения методов сетевого планирования работы были выполнены на два года раньше намеченного срока! Одним из примеров успешного применения этого метода в России является восстановление храма Христа Спасителя в Москве.

Сетевое планирование и управление состоит из структурного и календарного планирования и оперативного управления.

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

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

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

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

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

Стандарт, разработанный Институтом управления проектами (Project Management Institute) принят в качестве национального стандарта в США (стандарт ANSI).
Стандарт по качеству в управлении проектами ISO 10006.

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

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

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

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

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

MS Office Project Standart – пакет начального уровня для управления простыми проектами;
MS Office Project Professional – пакет для профессионального управления проектами любой сложности на любом уровне управления;
MS Office Project Server – серверный продукт, который используется для взаимодействия менеджеров проекта при управлении распределенными проектами;
MS Office Project Web Access – веб-интерфейс MS Project, позволяющий участникам проектов получить доступ к проектной информации через Internet Explorer.

Spider Project Professional (также существуют версии Desktop и Lite, разработчик "Технологии управления Спайдер") - пакет управления проектами, спроектированный и разработанный с учетом практического опыта, потребностей, особенностей и приоритетов Российского рынка. Этот пакет - единственная отечественная разработка среди популярных в России систем управления проектами.

Данный пакет в отличие от западных аналогов, имеет следующие особенности:

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

Программные продукты компании Primavera Inc :

Primavera Project Planner Professional – профессиональная версия, предназначенная для автоматизации процессов управления проектами в соответствии с требованиями PMI (Project Management Institute) и стандартами ISO. В первую очередь этот пакет предназначен для использования в составе корпоративной информационной системы, хотя вполне может работать и автономно, помогая решать задачи календарно-сетевого планирования, определения критического пути, выравнивания ресурсов, и других задач моделирования проектов, групп проектов, портфелей и программ.
SureTrack Project Manager ориентирован на контроль выполнения небольших проектов или фрагментов крупных проектов. Может работать как самостоятельно, так и совместно с Project Planner в корпоративной системе управления проектами.

Open Plan (разработчик Welcom Software Technology, сейчас Deltek) обеспечивает полномасштабное мультипроектное управление, планирование по методу критического пути и оптимизацию использования ресурсов в масштабах предприятия. Может эффективно использоваться на всех уровнях контроля и управления проектами – от высшего руководства и менеджеров проектов, до начальников функциональных подразделений и рядовых исполнителей.

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

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

Welcom предлагает использовать профессиональную и "облегченную" версию продукта в совокупности (OpenPlan Professional + OpenPlan Desktop), так как они полностью интегрированы.

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

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

В процессе исполнения проекта данные системы позволяют.

Вести учет.
Анализировать отклонения исполнения от запланированного.
Прогнозировать будущие параметры проекта.
Моделировать управленческие воздействия.
Вести архивы проекта.

1.3. Контрольные вопросы

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

Теоретический курс

2.1.1. Структурное планирование

Структурное планирование включает в себя несколько этапов:

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

Основную роль на этапе структурного планирования играет сетевой график.

Сетевой график – это ориентированный граф, в котором вершинами обозначены работы проекта, а дугами – временные взаимосвязи работ.

Сетевой график должен удовлетворять следующим свойствам .

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

Пример . В качестве примера рассмотрим проект "Разработка программного комплекса". Предположим, что проект состоит из работ, характеристики которых приведены в табл.2.1.

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

Рис. 2.1. Сетевой график проекта

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

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

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

Нахождение критического пути сводится к нахождению критических работ и выполняется в два этапа.

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

Критические работы имеют одинаковое значение раннего и позднего времени начала.

Обозначим – время выполнения работы , – раннее время начала работы , – позднее время начала работы . Тогда

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

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

Здесь – множество работ, непосредственно следующих за работой .

Схематично вычисления раннего и позднего времени начала изображены, соответственно, на рис. 2.2 и рис.2.3.

Рис. 2.2. Схема вычисления раннего времени начала работы

Рис. 2.3. Схема вычисления позднего времени начала работы

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

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

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

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

Рис. 2.4. Вычисление раннего времени начала работ

Рис. 2.5. Вычисление позднего времени начала работ

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

Рис. 2.6. Критический путь проекта

После вычисления величин и для каждой работы вычисляется резерв времени :

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

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

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

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

В приведенном примере проекте работы 3, 4 и 9 имеют резерв времени согласно табл.2.2.

2.1.2. Календарное планирование

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

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

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

Таблица 2.3.
№ работы	Название работы	Исполнитель
	Начало реализации проекта	-
	Постановка задачи	Постановщик
	Разработка интерфейса	Программист1
	Разработка модулей обработки данных	Программист1
	Разработка структуры базы данных	Программист2
	Заполнение базы данных	Программист2
	Отладка программного комплекса	Программист1 Программист2
	Тестирование и исправление ошибок	Программист1 Программист2 Постановщик
	Составление программной документации	Постановщик
	Завершение проекта	-

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

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

Увеличить изображение
Рис. 2.7.

Увеличить изображение
Рис. 2.8.

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

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

Пример графиков загруженности ресурсов проекта "Разработка программного комплекса" изображен на рис.2.8. Он построен, исходя из предположения, что каждый работник занят на 100% выполнением запланированной ему задачи. Из графиков видно, что Постановщик перегружен в период с 16 по 23 октября, поскольку в этот промежуток ему назначены две параллельные работы. Область его перегруженности выделена на соответствующем графике штриховкой.

Оперативное управление

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

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

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

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

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

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

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

2.1.4. Контрольные вопросы

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

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-16

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

Цели и задачи использования систем управления

Рассмотрим основные цели использования систем управления:

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

Базовые задачи, которые ставятся перед системами управления:

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

К СВЕДЕНИЮ! Очевидно, что системы управления важны как с точки зрения решения текущих задач, так и с точки зрения стратегии компании. Они незаменимы в том случае, если фирма ведет сразу несколько проектов. Если один проект можно полноценно контролировать без автоматизации, то в случае множественности заданий - это нерешаемая задача.

ВАЖНО! Различные отрасли предполагают использование систем управления со своей спецификой. К примеру, особые системы требуются для строительных, инвестиционных, инновационных, организационных проектов.

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

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

Преимущества

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

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

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

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

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

Высокая стоимость программ по управлению при низкой результативности. Приобретение систем управления предполагает повышение дохода компании. Однако полученная прибыль в некоторых случаях не окупает затраты. Нужно иметь в виду, что тратить средства придется не только на саму программу, но и на ее регулярные обновления, индивидуальные доработки.
Риск усложнения простых проектов. При ведении простых проектов использование системы управления необязательно. Более того, оно даже нежелательно, так как простая задача может усложняться.
Трата большого количества времени на составление планов. Руководителю и сотрудникам приходится тратить много времени на расстановку статусов, изменение приоритетных задач, обновление сведений. Иногда за подобной работой «теряются» реальные дела.

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

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

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

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

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

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

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

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

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

Существует огромное количество СУП. Они могут быть базовыми или профессиональными. Рассмотрим наиболее востребованные системы:

Wrike. Функционал: группировка задач по проектам, контроль над исполнением. Основной плюс – профессиональный функционал, обеспечивающий удобство совместной работы. Дополнения: напоминания, установка сроков исполнения задачи.
«Мегаплан». Используется в малых и средних организациях. Удобна для удаленной работы. Функционал: менеджер задач, выставление счетов, контроль над сделками, локальная почта.
Basecamp. Отличается эффективностью и простотой. Функционал: профайлы, календарь, задачи. Обеспечивает удаленный доступ. Может использоваться не только сотрудниками, но и клиентами компании.
Worksection. Функционал: учет времени, тэги, хранилище файлов, менеджер задач, ПО.
Asana. Мобильный доступ. Возможность интеграции с электронной почтой.

Среди базовых систем имеет смысл отметить MS Project (разработчик — Microsoft). Как правило, базовые СУП имеют стандартный набор функций.

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

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

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

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

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

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

Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
Постоянное улучшение («кайзен» (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

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

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

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

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

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

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

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

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

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

(нажмите для увеличения)

На модели видно разграничение ПП по трем основным секторам.

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

Задачи и функции информационной системы

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

Среди основных задач ИСУП можно выделить следующие:

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

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

Календарно-сетевое планирование.
Управление ресурсами: персоналом, финансами, оборудованием, материалами.
Отчетность по работам с позиции трудозатрат.
Документационное обеспечение проектного управления.

(нажмите для увеличения)

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

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

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

Программное обеспечение в информационной системе

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

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

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

(нажмите для увеличения)

Из-за Российской специфики для бизнес-планирования и оценки экономической эффективности проектов лучше всего применять один из флагманских отечественных ПП компаний Expert Systems или Альт Инвест. Эти продукты более 20 лет успешно используются, позволяют работать в программном и портфельном режиме, отрабатывая всю гамму вопросов моделирования на предынвестиционной стадии. Для информационного сопровождения инвестиционного и постынвестиционного этапов можно применять и ПП западного производства, и отечественные разработки. На рыке лидирует линейка средств компании Microsoft.

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

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

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

Программы для эффективного управления стоимостными аспектами и бюджетированием проекта обеспечивают:

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

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

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

Основой СУП являются перечисленные ниже элементы.

Определение ответственности менеджера проекта и его полномочий.

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

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

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

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

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

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

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

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

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

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

Рис. 11.1. Базовые составляющие эффективного УП в компании

Организационная зрелость в области проектного менеджмента (см. п. 11.5) определяется наличием, степенью развития и эффективностью применения на практике корпоративной системы управления проектами (КСУП) (см. п. 11.3).

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

Цели и задачи использования систем управления

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

Преимущества

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

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

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

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

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

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

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

Agile

Scrum

Lean

Kanban

6 сигм (Six Sigma)

PRINCE2

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

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

Задачи и функции информационной системы

Программное обеспечение в информационной системе