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

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

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

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

Управление проектами необходимо, потому что:

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

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

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

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

На практике управление проектом часто сводят только к созданию самого продукта/результата проекта, забывая о необходимости административного управления процессом «создания». Чаще пристальное внимание уделяется вопросам разработки ПСД, проектно-изы­скательским, строительно-монтажным и пусконаладочным работам и т. п. Но на вопрос, кто и как формирует команду, как осуществляется управ­ление рисками, кто ведет организацию тендера, кто несет ответственность за правильное и своевременное проведение совещаний, организацию до­кументооборота, исполнители проекта ответить не могут. Однако по статистике это «съедает» от 5 до 15% всей сметы проекта. В связи с этим просто необходимо выделить руководителя проекта и создать команду управления проектом, отвечаю­щую за администрирование проекта.

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

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

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

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

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

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

2.1 Основные понятия и элементы сетевых моделей

Линейные модели. Управление большими и сложными комплексными программами, активно развивавшееся с начала XX века до середины 50-х годов, не имело эффективных моделей. Наиболее часто используемым инструментом управления являлся график (диаграмма) Гантта.

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

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

№	Содержание работ	Календарь
январь	февраль
	Работа а Работа б Работа в Работа г Работа д Работа е Работа ж Работа з Работа и Работа к Работа л Работа м

Рисунок 2 – Общий вид графика Гантта

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

На рисунке 3 изображен линейный график выполнения работ по обслуживанию пассажирского самолета.

Группа работ	Работа	Время, минуты
Пассажиры	Высадка
Транспортировка
Требование багажа
Работа команды	Высадка
Багаж	Выгрузка контейнера
Транспортировка контейнера
Погрузка на ленту доставки
Заправка горючего	Расположение, соединение
Подключение насоса
Проверка загрузки
Разъединение
Заправка водой
Груз и почта	Выгрузка контейнера
Транспортировка контейнера
Выгрузка основой массы
Обслуживание камбуза	Главная дверь кабины, 4l
Главная дверь кабины, 1R
Главная дверь кабины, 2R
Обслуживание уборной	В кормовой части
В центре
Впереди
Питьевая вода	Загрузка
Чистка каюты	Секция первого класса
Секция эконом-класса
Салон
Летная палуба
Груз и почта	Загрузка контейнера
На борту
Обслуживание полета	Проверка камбуза
Прием пассажиров
На борту
Обслуживающая команда	Проверка самолета
Запуск машины
Багаж	Транспортировка контейнера
Погрузка контейнера
Вес и баланс	Подготовка
На борту
Пассажиры	Транспортировка
Посадка
5 10 15 20 25 30 35 40 45 50

Рисунок 3 – Линейный график выполнения работ по обслуживанию пассажирского самолета

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

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

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

Из рисунка (см. рис. 4) видно, что работа «Разработка восстановительных процедур...» по состоянию на 21 июня не завершена, хотя должна была быть завершена еще 1 июня. Работа «Тестирование программного обеспечения системы» еще не начата. Задержки по проекту видны, хотя никаких прогнозов график Гантта сделать не позволяет.

Работа

апрель

май

июнь

июль

август

сентябрь

Инсталляция нового мини-компьютера

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

Тестирование оборудования и операционной системы

Документирование изменений программного обеспечения

Обучение обслуживающего персонала

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

Тестирование программного обеспечения системы

Финальное тестирование

Дата составлений: 21 июня

Рисунок 4 – Линейный график работ по инсталляции компьютера

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

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

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

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

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

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

Теория графов. В связи с недостатками линейных моделей возникла необ­ходимость создания новых моделей. И в середине 50-х годов XX века были созданы модели, основанные на теории графов, которая является разде­лом дискретной математики. Теория графов активно используется при решении многих задач управления в рамках так называемого исследова­ния операций. Объектом изучения теории графов является граф.

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

Существуют неориентированные графы (просто графы) (рисунок 5а), в ко­торых вершины соединяются ребрами, и ориентированные графы (или орграфы) (рисунок 5б), в которых вершины соединяются дугами.

а) 3 б)

Дуга

2 2

4 Ребро 4

Вершина

Вершина

Рисунок 5 – Неориентированный (а) и ориентированный (б)графы

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

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

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

Сбор/доставка

Сбор/доставка

12 км

2 км

Базовый узел

8 км 4 км

10 км

Сбор/доставка

Сбор/доставка

Рисунок 6 - Маршрутная сеть

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

Как ориентированный, так и неориентированный графы могут иметь иерархическую структуру.

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

x₀

x₀₁ x₀₂ x₀₃

x₀₁₁ x₀₁₂ x₀₁₃ x₀₂₁ x₀₂₂ x₀₃₁ x₀₃₂ x₀₃₃

Рисунок 7 - Иерархический граф

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

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

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

Генеральная цель

Цель 2

Цель 1

Цель 3

Подцель 11 Подцель 12 Подцель 13 Подцель 21 Подцель 22 Подцель 31 Подцель 32 Подцель 33

Рисунок 8 - Дерево целей

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

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

Все эти модели активно используются в рамках подсистемы управления содержанием проекта. Часто дерево целей и структура работ объединяют­ся и получается одна модель — дерево целей и задач.

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

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

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

Внедрение информационной системы

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

Повышение инвестиционной привлекательности

Сокращение затрат на управление

Сокра- щение штат-ной числен-ности

Сокра-щение хозяй-ствен-ных расхо-дов

Сокраще-ние продолжительности производ-ственного цикла

Улуч-ше-ние системы учета

Централизация инфор-мационных потоков

Повы-шение откры-тости показа-телей

Внедре-ние между-народ-ных показа-телей

Повы-шение прести-жа

Рисунок 9 - Дерево целей проекта внедрения информационной системы

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

Генеральный директор

Руководитель казначейства

Руководитель отдела анализа

Главный бухгалтер

Финансовый директор

Руководитель отдела ИТ

Главный юрисконсульт

Руководитель отдела кадров

Административный директор

Руководитель отдела рекламы

Руководитель отдела закупок

Руководитель отдела продаж

Коммерческий директор

Рисунок 10 - Организационная структура

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

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

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

Дерево решений позво­ляет найти оптимальный вариант решения в условиях неопределенности.

Решение

Результат решения

Рисунок 11 - Дерево решений

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

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

Методы

Оборудование

Использование различных Как передвигалось Разделяемые устройства

комплектующих для принтера оборудование?

Постановка Модем Процессор

вопроса Винчестер

Замена оборудования Перемещалось ли Бэкап (дублирующий

оборудование? накопитель на ленте) Рабочая станция

Обеспечение альтернативного Получение Клавиатура

решения задачи информации Монитор

Описание Кто последний пользовался Системный

Понимание задачи проблемы оборудованием? мини-компьютер Принтеры

Изменение настройки

Проблемы с ИКС

Функционирование Бездисковая станция

компьютера

Прием проблемы по телефону Прикладное

Электропроводка ПО

Время обслуживания Обучение Текстовый редактор

Электронный таблицы

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

ответить на звонок помощь Базы данных

Руководство

Ленты

Доступность дополнительной Квалификация Серверы

внешней помощи Бумага Принтеры Системное ПО

Записи предыдущих проблем Терминалы

Материалы и ПО

Люди

Аппаратное обеспечение

Рисунок 12 – Причинно-следственная диаграмма

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

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

Основными элементами сетевой модели являются:

• работа;

• событие;

• путь.

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

К понятию «работа» относится понятие процесса ожидания, т.е. процесса, не требующего затрат труда, но требующего затрат времени. Ожидание изображают пунктирной стрелкой, над которой указывают его продолжи­тельность (рисунок 13а).

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

К понятию «работа» также относится понятие «зависимость». Зависимость — это связь между двумя или несколькими событиями, не требую­щая ни затрат времени, ни затрат ресурсов, например зависимость начала одной или нескольких работ от результатов другой работы. В сетевой модели зависимость (или, как часто ее не совсем правильно называют, фиктивная работа) показывается в виде пунктирной стрелки без указания времени (рисунок 13в).

a)

10 2 7 б) 10 7

Штукатурные Сушка

в) работы штукатурки

14

Рис 13 - Изображение в сетевой модели ожидания (а), технологического ожидания (б) и зависимости (в)

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

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

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

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

События делятся на простые и сложные. Простые события — это такие события, в которые входит только одна работа. Сложные события — это такие события, в которые входят две или более работы.

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

Простое событие

2 6 Сложное событие

3 5

Исходное событие Завершающее событие

Рисунок 14 – События в сетевой модели

Как видно из рисунка (см. рисунок 14), событие 2 есть результат работы 0—2, событие 3 — результат работ 1—3 и 2—3. Работа 1—3 может быть начата только после выполнения работы 0—1, т.е. для начала работы необходимо, чтобы свершилось событие 1. Событие 0 — исходное событие сетевой модели, так как в него не входит ни одна работа. Событие 3 явля­ется завершающим событием, так как из него не выходит ни одной рабо­ты. Событие 1 является простым событием, так как в него входит только одна работа — 0—1. Событие 3 является сложным событием, так как в него входят две работы: 1—3 и 2—3. Событие свершится, если будут завершены все входящие в него работы. Так, событие 2 свершится после завершения работы 0—2, т.е. через три дня.

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

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

Пример выявления критического пути изображен на рисунке 15.

5

2 3 8 10

6 7 6

Рисунок 15 – Критический путь в сетевой модели

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

• путь 1, проходящий через события 0—1—3—5, имеет продолжительность 17 дней;

• путь 2, проходящий через события 0—1—2—3—5, имеет продолжительность 23 дня;

• путь 3, проходящий через события 0—1—2—4—5, имеет продолжительность 18 дней;

• путь 4, проходящий через события 0—2—4—5, имеет продолжительность 19 дней;

• путь 5, проходящий через события 0—2—3—5, имеет продолжительность 24 дня.

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

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

Как показывает практика, чем больше работ охватывает сетевая модель, тем меньше удельный вес работ, лежащих на критическом пути. Напри­мер, в модели, включающей 100 работ, на критическом пути будут нахо­диться 10—12% работ; в модели, включающей 1000 работ, — 7—8% работ; в модели, включающей 5000 работ, — 3—4% работ.