Лучшие практики для Rillsoft Project¶

Эта статья описывает проверенные подходы для четырёх критических точек принятия решений в планировании проектов с Rillsoft Project: построение структуры проекта, планирование потребности в ресурсах, подготовка портфельного обзора и правильное сохранение базового плана.

Строим структуру проекта аккуратно¶

Аккуратная структура проекта — основа надёжного календарного планирования, прослеживаемого балансировки мощностей и достоверного план-факт анализа. Ошибки структуры в начале порождают вторичные ошибки на каждом последующем этапе планирования.

Основное правило: сначала структура, потом сроки

Определите содержательное членение проекта прежде, чем вводить длительности, сроки или ресурсы. Плохо структурированный план не станет лучше от проработки деталей.

Признаки хорошей структуры проекта:

• каждый подпроект представляет собой содержательно завершённую единицу (фаза, группа ролей, объект поставки, площадка или подразделение);

• названия работ описывают результат или завершаемую деятельность — а не действие без конца;

• структура одинаково понятна руководителю проекта, менеджеру ресурсов и руководству;

• вехи отмечают реальные точки принятия решений, а не промежуточные шаги.

Типичные ошибки структуры и как их избежать:

Связи как проверка структуры:

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

Планируем потребность в ролях прежде назначения сотрудников¶

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

Принцип:

1. Работам сначала присваиваются роли (профессиональные квалификации), а не имена.

2. Балансировка мощностей показывает, достаточно ли доступно людей с этой квалификацией.

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

Когда этот путь оправдан:

• на одну и ту же деятельность претендуют несколько сотрудников;

• важны рабочее время, отпуска или отсутствия;

• несколько проектов конкурируют за один и тот же пул ресурсов;

• перегрузки нужно выявить до утверждения плана.

Когда достаточно прямого назначения:

• небольшой проект с немногими чётко назначенными людьми;

• руководитель проекта знает доступность людей «наизусть»;

• нет конкуренции с другими проектами.

Квалификация прежде имени — практическое применение:

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

После назначения сотрудников проверьте:

• возникает ли недогрузка/перегрузка при балансировке мощностей?

• соответствует ли профессиональная квалификация сотрудника назначенной роли?

• корректно ли ведутся рабочее время и нерабочие дни сотрудника?

• правдоподобно ли назначение в контексте портфеля?

Готовим портфельный обзор¶

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

Что подготовить перед обзором:

Заранее актуализируйте следующие данные:

• статус всех активных проектов (запланирован / активен / критичен / приостановлен / завершён);

• приоритеты проектов в портфеле;

• состояние базового плана и текущий процент выполнения по каждому проекту;

• загрузку ресурсов в периоде портфеля (балансировка мощностей по всем проектам);

• межпроектные связи с задержками.

Три ключевых вопроса для обзора:

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

2. Какие проекты под угрозой? Где возникают срывы сроков или дефицит ресурсов?

3. Что нужно решить? Какой приоритет, ресурс или срок нужно изменить?

Готовим материал для решения из Rillsoft Project:

1. Откройте портфель, отсортируйте все проекты по приоритету.

2. Проверьте балансировку мощностей персонала по проектам — какой проект сильнее всего задействует ту или иную квалификацию?

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

4. Проверьте сроки и пересечения на диаграмме Ганта портфеля.

5. Подготовьте результат в виде снимка экрана или выгрузки в Excel для обзора.

Типичные ошибки при проведении обзора:

• обзор проводится, но данные в системе не актуальны;

• представляются отчёты о статусе проектов, но решения не принимаются;

• дефицит ресурсов называется, но не связывается с приоритетами;

• сценарии симуляции обсуждаются, но не документируются.

Подробнее о портфельном анализе: Углублённый анализ портфеля

Правильно сохраняем базовый план¶

Базовый план — это эталон сравнения для план-факт анализа. От момента его сохранения зависит качество каждого последующего анализа отклонений.

Сохранён слишком рано:

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

Сохранён слишком поздно:

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

Правильный момент:

Сохраняйте базовый план, когда:

• календарный план содержательно проверен и утверждён;

• потребность в ресурсах и балансировка мощностей завершены;

• выполнены существенные назначения сотрудников;

• затраты, трудоёмкость и вехи зафиксированы;

• проект официально переходит в фазу реализации.

Используем несколько базовых планов целенаправленно

Rillsoft Project позволяет сохранять несколько базовых планов. Используйте это осознанно:

• Базовый план 1: изначально утверждённый план.

• Базовый план 2: пересмотренный план после согласованного изменения плана.

• Базовый план 3: план после расширения или изменения содержания (scope-change).

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

Что базовый план не заменяет

Базовый план не заменяет документирование изменений плана. Фиксируйте существенные изменения дополнительно в протоколе проекта или отчёте о статусе — сам по себе базовый план не объясняет, почему план был изменён.

Подробнее о работе с базовым планом: Сохранить базовый план и внести прогресс

Смежные темы¶

• Планирование проекта

• Проведение балансировки мощностей

• Углублённый анализ портфеля

• Провести план-факт анализ

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

лучшие практики, рекомендации, типичные ошибки планирования, план-факт анализ, базовый план, прогресс, контрольная дата, отклонение, project-manager, pmo