Не метод, а свод практик
Классическое управление проектами — это не методология в том смысле, в каком ими являются Scrum или Kanban. Оно не предписывает ни длину цикла, ни состав встреч, ни способ работы команды. Это свод практик, сгруппированных по областям знаний, из которого руководитель проекта собирает нужное под конкретный проект.
Отсюда и типичное недопонимание. Классический подход часто отождествляют с каскадной моделью, но это разные вещи: каскад — жизненный цикл (фазы идут последовательно), а классический подход — набор дисциплин управления. Управлять содержанием, рисками и заинтересованными сторонами приходится и в итеративном проекте.
Практическая ценность подхода — в полноте перечня. Он напоминает о том, что легко забыть: кто заинтересованные стороны и чего они хотят, какие риски приняты осознанно, кто и как получает отчётность, что происходит при закрытии проекта. Ни одна гибкая методология этих вопросов явно не ставит.
- Проект крупный, с внешним заказчиком и формальными обязательствами.
- Есть требования к отчётности, аудиту или конкурсным процедурам.
- Много заинтересованных сторон с разными и конфликтующими интересами.
- Цена ошибки высокая, а риски надо оценивать и хранить явно.
- Небольшая команда, один заказчик, короткий проект — накладные расходы не окупятся.
- В организации нет роли руководителя проекта и не планируется.
- Требуется скорость реакции, а не полнота документирования.
- Документы будут писаться для проверяющего, а не для управления.
Документы, которые действительно работают
Полный перечень артефактов классического подхода велик, и в небольшом проекте большая его часть избыточна. Ниже — три документа, которые окупаются практически всегда.
Устав проекта
Зачем проект, кто спонсор, какие границы и полномочия у руководителя. Один-два листа, которые снимают половину будущих конфликтов о полномочиях.
Реестр рисков
Что может пойти не так, с какой вероятностью, каким будет влияние, кто владелец и что делаем. Живой документ, а не разовое упражнение на старте.
Матрица ответственности
Кто исполняет, кто отвечает, с кем консультируются и кого информируют по каждому блоку работ. Снимает вопрос «а кто должен был».
| СОБЫТИЕ | ДЛИТЕЛЬНОСТЬ | УЧАСТНИКИ | РЕЗУЛЬТАТ |
|---|---|---|---|
| Совещание по запуску | 2–3 ч | команда, спонсор, ключевые заинтересованные стороны | общее понимание целей, границ и ролей |
| Еженедельный статус | 30–60 мин | руководитель проекта и команда | отклонения, решения, обновление реестра рисков |
| Отчёт заинтересованным сторонам | раз в 2–4 недели | руководитель проекта и спонсор | статус по срокам, бюджету и рискам |
| Закрытие проекта | 2–3 ч | все участники | приёмка, извлечённые уроки, роспуск команды |
Минимальный набор, с которого стоит начать
Внедрять весь свод целиком не нужно и вредно. Порядок ниже даёт основную часть пользы при небольших накладных расходах — а дальше добавляется то, чего конкретно не хватает.
- 1Напишите устав на один-два листаЦель, границы, спонсор, полномочия руководителя проекта, ключевые заинтересованные стороны. Без устава руководитель проекта не имеет формального права принимать решения.до старта
- 2Опишите содержание и исключенияЧто входит в проект и что не входит. Второе фиксируйте так же тщательно: именно вокруг исключений идут споры на приёмке.1–2 дня
- 3Определите заинтересованные стороныКто влияет на проект и кого он затрагивает, чего каждый ждёт и в какой форме хочет получать информацию. Пропущенная сторона — источник поздних требований.0,5 дня
- 4Заведите реестр рисковДесять-пятнадцать позиций достаточно для старта. Главное — назначить владельца каждому и вернуться к списку на следующей неделе, а не через квартал.2–3 ч
- 5Постройте базовый планПакеты работ, зависимости, вехи, резерв отдельной строкой. Относительно него дальше считается любое отклонение.2–3 дня
- 6Договоритесь о формате отчётностиКому, как часто и в каком виде. Отчёт, который никто не читает, — потерянное время; отчёт, которого ждут и не получают, — потерянное доверие.0,5 дня
Что показывает состояние проекта
Где классический подход вырождается в бюрократию
Документы пишутся для проверяющего
Реестр рисков заполнили и забыли
Заинтересованные стороны определены формально
Матрица ответственности не согласована с людьми
Отчётность одинаковая для всех
Закрытие проекта пропущено
Разбор по темам
Как вести классический проект в Shtab
Документы, план и риски держатся в одном пространстве с работой — не приходится сводить состояние из плана, почты и таблиц.
- 01Устав, содержание и матрица ответственности — страницами проекта: доступны команде и не теряются при смене участников.
- 02Реестр рисков ведите отдельным списком с полями вероятности, влияния и владельца — сортировка сразу даёт приоритет.
- 03Календарный план и вехи — на диаграмме Ганта, с зависимостями между работами.
- 04Портфель проектов даёт сводную картину по нескольким проектам — для проектного офиса.
- 05Оценка трудозатрат и трекер времени дают факт по каждому пакету работ и стоимость по ставке в час.
- 06Уровни доступа разделяют внутреннюю работу и то, что видит заказчик.
Частые вопросы
Нет. Каскад — жизненный цикл: фазы идут последовательно с приёмкой. Классический подход — набор дисциплин управления: содержание, сроки, стоимость, риски, коммуникации. По нему можно вести и итеративный проект: управлять рисками и заинтересованными сторонами приходится в любом случае.