Классическое управление проектами: процессы и области знаний

Не метод, а свод практик

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

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

Сам свод за последние годы изменился. До шестой редакции PMBOK описывал управление проектом как пять групп процессов и десять областей знаний; седьмая редакция перешла к принципам и доменам исполнения, а процессы вынесены в отдельное практическое руководство. Набор дисциплин от этого не поменялся — поменялся способ изложения. Ниже мы держимся привычного деления по областям: именно на него ссылаются российские договоры и регламенты, по нему же требуют отчётность, и его использует ГОСТ Р 54869-2011.

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

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

Труднее всего здесь дать руководителю проекта полномочия. В большинстве компаний человек подчиняется своему функциональному руководителю, а руководитель проекта в этой цепочке не стоит нигде, поэтому конфликт за время людей возникает на второй неделе. Регламент его не разрешает. Разрешает ответ на вопрос, кто именно вмешивается в такой конфликт и за какой срок: «спонсор, в течение двух дней» — управление работает; «договаривайтесь между собой» — не поможет никакой стандарт.

Документы, которые действительно работают

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

Минимальный набор, с которого стоит начать

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

1. 1Напишите устав на один-два листаЦель, границы, спонсор, полномочия руководителя проекта, ключевые заинтересованные стороны. Без устава руководитель проекта не имеет формального права принимать решения.до старта
2. 2Опишите содержание и исключенияЧто входит в проект и что не входит. Второе фиксируйте так же тщательно: именно вокруг исключений идут споры на приёмке.1–2 дня
3. 3Определите заинтересованные стороныКто влияет на проект и кого он затрагивает, чего каждый ждёт и в какой форме хочет получать информацию. Пропущенная сторона — источник поздних требований.0,5 дня
4. 4Заведите реестр рисковДесять-пятнадцать позиций достаточно для старта. Главное — назначить каждому владельца и вернуться к списку уже на следующей неделе: список, который открывают раз в квартал, устаревает раньше, чем до него доходят руки.2–3 ч
5. 5Постройте базовый планРазбейте работы на пакеты, свяжите зависимости, расставьте вехи и вынесите резерв отдельной строкой. Относительно этого плана дальше считается любое отклонение.2–3 дня
6. 6Опишите процедуру измененийКто подаёт запрос, кто оценивает влияние на срок и бюджет, кто принимает решение и с какой суммы — спонсор. После утверждения базовый план меняется только через эту процедуру, иначе через два месяца не с чем сравнивать факт.0,5 дня
7. 7Договоритесь о формате отчётностиКому, как часто и в каком виде. Отчёт, который никто не читает, — потерянное время; отчёт, которого ждут и не получают, — потерянное доверие.0,5 дня
8. 8Договоритесь, чем проект заканчиваетсяРезультаты приняты по критериям, договоры с подрядчиками закрыты, результат передан тому, кто будет его эксплуатировать, люди возвращены в линейные подразделения, документация сдана в архив, уроки записаны. Тот же порядок применяется к прекращённому досрочно проекту — иначе висят незакрытые обязательства.2–3 дня

Что показывает состояние проекта

Где классический подход вырождается в бюрократию

Темы про классический подход

Как вести классический проект в Shtab

Состояние проекта не приходится сводить из плана, почты и трёх таблиц.

Частые вопросы