Отличие управления проектами от других видов управления
Под управлением проектом понимается целенаправленная деятельность по созданию «нового продукта/услуги» или достижению «нового результата» в условиях ограниченных ресурсов и за определенное время. При этом природа самого создаваемого «продукта/услуги» не имеет особого значения. Например, в ИТ-отрасли понятие «управление проектом» прежде всего подразумевает комплекс действий по подготовке, проектированию, разработке, тестированию и внедрению программного продукта или интернет-сайта.
Существует много различных определений управления проектами. Приведем лишь одно из них, наиболее универсальное.
Управление проектами — это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения предъявляемых к нему требований.
Управление проектами необходимо, потому что:
· отдельный индивидуум не может справиться с решением большого объема задач (предполагается участие специалистов и разделение труда, а значит, обеспечение организационной структуры и системы управления проектом);
· достижение определенных целей требует обеспечения, координации и эффективного использования ресурсов;
· для достижения целей необходимо организованное оформление протекания процессов работы, коммуникаций и принятия решений как внутри системы, так и за ее пределами.
Управление проектом — это своего рода искусство. В реальной практике оно включает совокупность любых творческих идей и приемов, позволяющих достичь целей проекта, а также и формализованный подход, когда ряд факторов может быть предсказан и все варианты заранее проанализированы.
На практике управление проектом часто сводят только к созданию самого продукта/результата проекта, забывая о необходимости административного управления процессом «создания». Чаще пристальное внимание уделяется вопросам разработки ПСД, проектно-изыскательским, строительно-монтажным и пусконаладочным работам и т. п. Но на вопрос, кто и как формирует команду, как осуществляется управление рисками, кто ведет организацию тендера, кто несет ответственность за правильное и своевременное проведение совещаний, организацию документооборота, исполнители проекта ответить не могут. Однако по статистике это «съедает» от 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) позволяет решить некоторые типовые управленческие задачи, такие, как задача путешествующего коммивояжера (с помощью алгоритмов «ближайшего соседа» и эвристической экономии Кларка и Райта), задача составления маршрута транспорта и пр.
| Сбор/доставка |
| Сбор/доставка |
2 км
8 км 4 км
Сбор/доставка
Сбор/доставка
Рисунок 6 - Маршрутная сеть
Ориентированные графы в виде сетевых моделей используются в качестве основных инструментов управления проектами, программами и сложными комплексами работ.
Как ориентированный, так и неориентированный графы могут иметь иерархическую структуру.
Иерархический граф (рисунок 7) состоит из вершин, расположенных на различных иерархических уровнях, и соединяющих их дуг (ребер). Такого рода граф иногда называют деревом.
x0
x01 x02 x03
x011 x012 x013 x021 x022 x031 x032 x033
Рисунок 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)
в) работы штукатурки
Рис 13 - Изображение в сетевой модели ожидания (а), технологического ожидания (б) и зависимости (в)
Зависимость используется в сетевых моделях не только как технологическая или организационная связь, но и как элемент, необходимый для правильного построения сетевых моделей.
Событие — это результат выполнения одной или нескольких работ, позволяющий начинать следующую работу. Как правило, в сетевых моделях событие изображается в виде кружка.
Событие не является процессом и не имеет длительности, т.е. совершается мгновенно. Поэтому каждое событие, включаемое в модель, должно быть полно и точно определено (с точки зрения логической связи работ), его формулировка должна включать результат всех непосредственно предшествующих ему работ.
Событие, стоящее в начале сетевой модели, в которое не входит ни одна работа, называется исходным событием. Событие, стоящее в конце сетевой модели, из которого не выходит ни одной работы, называется завершающим событием.
События делятся на простые и сложные. Простые события — это такие события, в которые входит только одна работа. Сложные события — это такие события, в которые входят две или более работы.
Событие может являться частным результатом отдельной работы или суммарным результатом нескольких работ. Оно может свершиться только тогда, когда закончатся все работы, ему предшествующие. Последующие работы могут начаться только тогда, когда произойдет это событие. Поэтому события (кроме исходного и завершающего) носят двойственный характер: для всех непосредственно предшествующих событию работ оно является конечным, а для всех непосредственно следующих за ним начальным (рисунок 14).
Простое событие
2 6 Сложное событие
Исходное событие Завершающее событие
Рисунок 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.
2 3 8 10
Рисунок 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% работ.