Разработка графика реализации проекта. Управление проектами (Project Management). Часть 5

Данная статья – пятая часть одной большой статьи по Управлению Проектами. Чтобы начать читать статью с самого начала, пожалуйста, перейдите по этой ссылке.

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

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

Поскольку у каждой задачи есть начало и конец, существует четыре типа зависимостей задач:

1. Зависимости между концом и началом являются наиболее распространенными. Завершение одной задачи контролирует, когда запускается другая.
2. При зависимости от начала к началу запуск одной задачи инициирует запуск другой.
3. Зависимость «От конца до конца» означает, что завершение одной задачи контролирует завершение другой.
4. Зависимости между началом и концом встречаются не очень часто. Это хорошо, потому что они могут сбить вас с толку. Начало одной задачи приводит к завершению другой. Таким образом, в этом случае контролируемая задача возникает после той, которую она контролирует.

Вы можете выяснить, какой тип зависимостей использовать, задав несколько вопросов:

• Какая задача контролирует другую? Это говорит вам, какая задача является первой в цепочке зависимостей.
• Дата начала или окончания первой задачи контролирует вторую задачу? Это определяет, начинается ли зависимость с начала или конца.
• Управляет ли первое задание началом или завершением второго задания? Это определяет, является ли вторая половина зависимости началом или концом.

Как определить необходимые ресурсы для задач?

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

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

Предположим, вы подсчитали, что на установку оборудования конференц-центра у пяти человек уйдет четыре дня. Это восемь часов в день на человека, а значит 40 рабочих часов в день в течение четырех дней, или 160 рабочих часов. Что случится, если вы получите только четыре человека? Сколько времени займет задание?

Теперь команда из четырех человек может работать только 32 часа каждый день. Если вы поделите 160 часов на количество часов в день, то есть 32, вы получите новую продолжительность в пять дней. Работа остается прежней, но продолжительность задачи варьируется. Тот же расчет применяется, если кто-то переключается на работу на полставки вместо полной. Поскольку вы делите объем работы на половину количества часов в день, задача займет вдвое больше времени.

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

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

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

Что такое вехи проекта?

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

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

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

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

Понимание критического пути

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

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

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

Например, какая-то конкретная задача может начаться уже 3 октября и завершиться 14 октября. Поздний старт и позднее окончание – это самые поздние возможные даты, когда задача может начинаться и заканчиваться, без задержки последующих задач. Даты позднего старта и окончания – 24 ноября и 7 декабря соответственно. Это означает, что задача имеет несколько недель, поэтому она не находится на критическом пути, а значит, имеет провисание. С другой стороны, если ранние и поздние даты совпадают, тогда эта задача не имеет провисания.

Понимание критической цепи

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

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

Как сократить график проекта?

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

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

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

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

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

Применение метода сбоя на критическом пути

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

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

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

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

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

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

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

Базовая линия проекта

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

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

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

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

Шестую часть вы можете почитать в статье: "Реализация проекта. Управление командой проекта. Часть 6"