Как составить план проекта за восемь простых шагов

Рекомендации по инициации проекта

Будьте готовы ответить, почему этот проект вообще существует

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

• Каковы цели проекта?
• Почему мы начинаем проект именно сейчас?
• Какие преимущества для бизнеса мы получим?

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

Как можно раньше определите круг заинтересованных лиц

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

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

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

В этом деле вам очень поможет так называемая диаграмма RASCI (матрица распределения ответственности)

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

Фиксируйте обязательства заинтересованных лиц

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

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

Используйте контрольный список для фазы инициации проекта

Составить устав проекта

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

Именно поэтому очень важно делать устав максимально понятным и подробным

Включить в устав объем проекта

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

Утвержденный объем проекта должен быть задокументирован в уставе и подписан этими лицами.

Что еще должно входить в устав проекта:  

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

Что посеешь, то и пожнешь

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

Можно ли менять базовый план проекта

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

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

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

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

Удачи в планировании и выполнении базового плана с первой попытки!

Для трекинга времени

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

Toggl — кроссплатформенный тайм-трекер. Есть возможность работы в команде и шеринга для клиентов. Можно менять workplaces — чтобы отдельно считать время, затраченное на несколько сайд-проектов. Эта функция также полезна для тех сотрудников, которые работают part-time. Автоматически строит аккуратные и наглядные отчеты.

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

primaERP — сервис, объединяющий возможности Toggle и Timely. Система учета рабочего времени и перерывов, удобный тайм-трекинг и наглядное планирование. Есть возможность создавать и выставлять счета, а также контролировать оплату. Для команды до 3 человек — бесплатно. Больше — платно. На стоимость влияет количество пользователей и подключенные для них услуги.

Список можно дополнить разве что сервисами Google: почтой Gmail, сервисом для совместной работы с документами Google Docs, облачным хранилищем Google Drive, органайзером Google Calendar и другими инструментами. Для бизнес-целей стоит выбирать аккаунт G Suite (от $5 в месяц за одного пользователя).

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

Так найдете свой оптимальный набор инструментов

И не забывайте анализировать, оправдывает ли инструмент затраты. Так найдете свой оптимальный набор инструментов.

Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации.

Планирование

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

Шаг (контрольное событие в терминологии PMBOK, ISO 21500­2012) — группа заданий (одного или нескольких) в рамках одного проекта, разработка которых должна быть завершена не позже определенного срока.

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

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

Рис. 1. Пример классификатора заданий

Рис. 2. Пример шаблона пошагового плана для различных стадий проекта. Стадия П (проект) и стадия Р (рабочая документация)

Последовательность разработки методики планирования

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

Как происходит планирование

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

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

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

Этап 1. Выявление основных заинтересованных лиц и встреча с ними

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

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

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

Планирование ресурсов

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

Планирование ресурсов — Определение того, какие ресурсы (люди, материалы, оборудование) и в каком количестве будут использованы в проекте.

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

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

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

Планирование трудовых ресурсов

Планирование трудовых ресурсов на данном этапе состоит в назначении специалистов на роли и решение ресурсных конфликтов возникающих при этом.
Ресурсные конфликты возникают из-за того что количество квалифицированных специалистов в компании всегда ограничено и обеспечить все проекты квалифицированными кадрами бывает довольно сложно. Существует пять методов решения ресурсных конфликтов:
1. Добавление ресурсов.
2. Увеличение длительности работ.
3. Сдвиг работ по времени. 
4. Перераспределение времени загрузки.
5. Перераспределение времени загрузки между несколькими однотипными ресурсами.
Выбор того или иного методы решения ресурсных конфликтов зависит от ситуации.

Информация о том, как назначать ресурсы на задачи в плане-графике MS Project Professional 2013, представлена в материале «Назначение ресурсов» 

Назначьте ресурсы на задачи Вашего проекта в плане-графике. Условия назначения приведены ниже:

СДР	Название задачи	Ресурсы
Дог	Разработка и подписание договора на строительство коттеджа	Юрист
Фун.1	Погружение свай	Сваи;Автокран;Сваебойка
Фун.2	Срубка свай	Компрессор;Монолитчики
Фун.3	Армирование ростверка	Арматура;Монолитчики
Фун.4	Бетонирование ростверка	Бетон;Монолитчики;Автокран;Разнорабочие
Кар.1	Кладка из кирпича под плиту перекрытия	Кирпич;Раствор;Каменщики;Автокран
Кар.2	Монтаж плит перекрытия 1 этаж	ЖБИ;Автокран
Кар.3	Кладка стен и перестенков 1-го этажа	Кирпич;Раствор;Каменщики;Автокран
Кар.4	Монтаж плит перекрытия 2 этаж	ЖБИ;Автокран
Кар.5	Кладка стен и перестенков 2-го этажа	Кирпич;Раствор;Каменщики;Автокран
Кар.6	Монтаж плит прикрытия между вторым этажам и чердаком	ЖБИ;Автокран
Кар.7	Кладка парапета и вентиляционных шахт	Кирпич;Раствор;Каменщики;Автокран
Кар.8	Разработка и заключение договора на изготовление окон	Юрист
Кар.10	Заполнение оконных проёмов	Окна;Разнорабочие
Кр.1	Разработка и утверждение коммерческого предложения (Кровля)	Юрист
Фас.1	Утепление фасада и грунтовка	Пенополистирол;Фасадчики;Грунтовка
Фас.2	Декоративная штукатурка фасада	Фасадчики;Штукатурка;Грунтовка
Фас.3	Установка молдинга	Молдинг;Фасадчики
Фас.4	Покраска фасада	Грунтовка;Фасадчики
Фас.5	Облицовка рванным камнем	Рванный камень;Фасадчики
Бл .1	Разработка и подписание договору по благоустройству	Юрист

Как это работает шаг за шагом

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

Менеджер проекта заполняет карточку, т.е. основные свойства проекта:

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

Задачи — это этапы работы с указанием сроков и ответственных:

Ресурсный план — это разнесение плановых часов по ресурсам, задачам и времени:

(5) Запрашиваем ресурсы

Запросы выполняется из ресурсного плана. Выбираем запрашиваемые ресурсы и период, а объем запрашиваемого времени определяется самим ресурсным планом:

(6) Принимаем запрос

В распределении владелец ресурсов указывает на какой проект и период и на какой объем выделяются ресурсы. В нем же отображаются запрошенные на проекты ресурсы. Запрос можно принять или отклонить:

(6) Корректируем ресурсный план

В ресурсном плане проекта отображается распределённый объем (в строке «Распределено»). Если владелец ресурсов принял не весь запрос, то план проекта должен быть скорректирован:

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

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

Как уже было сказано выше, разработка плана управления проектом – процесс итерационный и, как правило, выполняется в следующем порядке:

Определяется, как вы будете планировать (один, с другом, с командой, где, как, когда и проч.)
Определяется список требований к результату проекта и к управлению проектом (с указанием приоритетов)
На основе требований разрабатывается описание содержания проекта или видение проекта (что будет в итоге на выходе проекта?)
Принимаются решения о том, что именно будет приобретаться (в том числе какие работы “как сервис”), а что – делаться силами команды
Создается WBS (ИСР) проекта, декомпозирующая результат проекта на управляемые куски

Это наш будущий базовый план содержания проекта.

Для каждой работы в WBS определяется набор задач для ее выполнения (что нужно сделать, чтобы получить данный конкретный результат?)
Строятся зависимости между задачами (для выполнения задачи 5 должны быть выполнены задачи 2 и 4)
Определяется, какие знания и навыки нужны для выполнения каждой задачи (обратите внимание, что пока речь не о членах команды, а о компетенциях!)
Оцениваются длительность и стоимость выполнения каждой задачи (наконец-то началась знакомая всем часть, правда?)
Определяется критический путь проекта (теперь мы знаем, сколько всего времени нужно на весь проект)
Разрабатывается календарный план проекта (если на предыдущих шагах все сделано верно – то достаточно будет задать начальную или конечную дату и получить результат). Это наш будущий базовый календарный план проекта.

Определяется стоимость проекта (во сколько же обойдется этот конечный результат). Это наш будущий базовый план стоимости проекта.

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

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

Удачи!

Для мозгового штурма и координации

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

MindMup 2 — один из самых популярных сервисов для построения ассоциативных карт. Чистый и интуитивно понятный интерфейс. Есть возможность совместной работы. В бесплатной версии карты можно сохранять только публично. Приватные карты доступны в версии Gold (от $25 в год). Сервис удобен для новичков, также подойдет для не слишком сложных, но регулярных задач.

MindMeister — еще один сервис для майндмэппинга. Он дороже (версия для командной работы — от $9 в месяц), но и функций больше. Иконки, библиотека изображений, история правок, режим презентации, task feed, чат и многое другое. В таком можно спланировать, например, разработку приложения или другого сложного продукта.

Какие накладные расходы нужно закладывать в ресурсный план?

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

Шаринг бойцов с другими проектами

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

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

Шаринг и работа с техподдержкой

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

• Есть ли у вашей техподдержки свои разработчики? Если есть, то как они получают знания о новых фичах, которые вы выкатываете на прод? Как это отражено в WBS? Если нет, то какие члены вашей команды (SA, BA, Dev, QA) и как часто будут отвлекаться на решение вопросов техподдержки? Даже если в составе техподдержки есть свои разработчики, периодическое отвлечение членов команды разработки на техподдержку неизбежно.
• Заложено ли LOE на knowledge transfer сотрудникам техподдержки?
• Заложено ли LOE на гарантийное сопровождение системы? Кто и как будет осуществлять гарантийное сопровождение?

Совещания и коллы

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

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

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

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

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

Более детальный разбор этапов

Планирование

По американской методологии PMBOK планирование занимает порядка 50% всего времени, что особенно подчеркивает его значимость.

Планирование лучше начать с разделения проекта на части (Work Breakdown Structure — WBS), где каждая фаза разделена на более мелкие задачи. Это помогает понять объем работ и учесть все нюансы.

Рис. 2 — Структура разделения проекта на подзадачи (WBS)

Графики работ

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

Самый простой вариант диаграммы можно сделать в Exсel: слева в таблице находится название работ, а все остальные столбцы — даты.

Рис. 3 — Диаграмма Ганта, Microsoft Exсel

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

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

Рассмотрим пример диаграммы Ганта, построенной в MSProject.

Рис. 4 — Диаграмма Ганта, Microsoft Project

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

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

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

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

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

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

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