В августе 2019 прошел курс p3express от Project Management Club и получил по нему сертификат. Теперь рассказываю об этом фреймворке ведения проектов вам – ниже полный конспект курса. Это больше демо-версия, все же рекомендую пройти сам курс – он поживее сухого текста. Для читателей блога доступна скидка в 25% по промо-коду SALAKHMIR – вот ссылка на курс по p3express.
Обзор фреймворка p3express
Всего фреймворк содержит 7 разделов и 37 процессов. На «карте» p3express отмечены все точки, и видно, что три раздела зациклены – это часть, видимо, унаследована из Agile.
Основные разделы:
- Подготовка проекта
- Проведение цикла
- Закрытие проекта
Внутри «проведения цикла» есть процессы, описывающие поведение каждую неделю и каждый день. Внутри каждого цикла есть старт и финиш – как небольшие подпроекты самого проекта.
Есть еще и процессы, которые происходят после закрытия проекта. Они относятся к вопросам оценки получения выгод от проекта и дальнейших действий. Эти процессы выходят за пределы зоны ответственности проджект-менеджера, но фреймворк охватывает проект целиком.
Раздел 1. Подготовка проекта
Первый раздел p3express выделен под подготовку к старту работы над проектом. Здесь мы решаем, что мы делаем, в каком составе, и нужно ли этот проект делать вовсе. Есть общий чек-лист, по которому нужно пройти перед стартом. Пункты достаточно стандартны и знакомы всем.
- Определить спонсора проекта – человека, заинтересованного в его результатах
- Резюме проекта – описание, что за проект и зачем он нужен. Его готовит спонсор
- Определить менеджера проекта
- Развернуть рабочее пространство
- Определить команду проекта
- Запланировать проект (собрать его конфигурацию, выяснить риски)
- Определить внешних исполнителей
- Провести аудит подготовки к старту проекта
- Сделать фокусированную коммуникацию – сообщение коллегам о старте проекта
Во время подготовки к старту проекта желательно привлекать стейкхолдеров – людей, которые получают выгоды от проекта. Стартовать проект нужно быстро, не застревая на этапах. Авторы p3express не рекомендуют пропускать пункты подготовки, но как мне кажется, некоторые моменты можно пропускать – например, не во всех проектах нужны внешние исполнители. Если на старте проекта потребности во внешних исполнителях нет, к этому пункту можно будет вернуться после – далее по тексту этот момент оговаривается.
1. Определение спонсора проекта
Спонсор проекта – тот, кто заинтересован в результатах выполнения проекта. Он помогает менеджеру проекта в их достижении.
Типичные проблемы, которые могут быть со спонсором проекта:
- спонсор может не знать, что он спонсор
- спонсор – генеральный директор компании
- чрезмерная активность спонсора, дублирование работы менеджера
Спонсор проекта здесь больше применим ко внутренним проектам компании. В случае со внешними клиентами, это может быть сам клиент, CEO нашей компании, либо прямой руководитель менеджера. Здесь и далее в цитатах – мои комментарии, с позиции менеджера проектов креативной студии.
2. Составить резюме проекта
Резюме проекта составляет спонсор проекта. Документ содержит ответы на вопросы: что делаем, зачем делаем, в какой срок должны запуститься, и так далее.
Резюме проекта должно содержать:
- Название проекта
- Цель проекта
- Получаемые выгоды
- Основные требования проекта – без чего он не имеет смысла
- Заложенное на проект время
- Выделенный бюджет
- Основные риски
- Кто будет заниматься проектом
Резюме проекта – это его устав в одну страницу, содержащий основную информацию. Его также может составить менеджер проекта, согласовав со спонсором. Дорабатывается резюме проекта итеративно.
В нашем случае, «устав» = задача, с которой пришел клиент. Даже если ее собираешь и конкретизируешь ты сам. В нем прописано, сколько денег и времени у нас есть на проект, и что должно получиться на выходе.
3. Определить менеджера проекта
Менеджер – основное контактное лицо в проекте с момента его запуска до момента передачи проекта и продукта заказчику/проектному офису. Не нужно выбирать руководителем хорошего специалиста или просто хорошего человека – этого недостаточно. Менеджер проекта должен обладать компетенциями:
- Техническое управление проектом
- Стратегическое управление/управление бизнесом
- Лидерство
У нас менеджер – отдельная профессия и единица, потому выборов руководителя не происходит.
4. Рабочее пространство
Рабочее пространство говорит само за себя – это то место, где происходит работа над проектом. Например доска Trello, проект в Jira, Confluence – что угодно, если в нем можно организовать работу.
Пример рабочего пространства – доска Trello для p3express.
Рабочая система готовится заранее, до старта проекта. Всего нам нужно обратить внимание на три вопроса и подобрать инструменты, помогающие их закрыть:
- Общение – мессенджеры, почта
- Контроль прогресса – Trello
- Хранение документов – CRM, Trello
Применяемые решения должно быть простыми, понятными и работать вне офиса.
5. Определить команду
На этапе определения команды привлекаем экспертов-консультантов, кто может быть полезен. Привлекаем тех, кто поможет с ресурсами. Вовлекая людей в планирование, мы получаем мотивированную команду. Команду же собираем исходя из потребностей проекта.
6. Планирование
Планирование должно начаться до того, как мы решили, что будем делать проект. В последствии, оно должно регулярно обновляться – с учетом контекста, изменений и текущей ситуации.
- Рассматриваем целесообразность и альтернативы. Идеи должны быть реализуемы и направленными на достижение целей компании
- Конфигурация проекта. Декомпозируем проект на продукты/результаты. Оценить объем, срок и стоимость
Принципы:
- Продукты, а не работа – не список задач, а результат
- Планируй вместе с командой
- Rolling wave: близкое планируем детально, отдаленное – грубо и в масштабе
При планировании не забываем при приоритеты. Помочь с ними может метод MoSCoW – разделение задач на обязательные (M, Must have), желательные (S, Should have), без которых можно обойтись (C, Could have) и «вишенки на торте» (W, Won’t have).
Планируем расписание – список майлстоунов, значимых вех выполнения работы. Риски – определяем и переопределяем риски на каждом этапе планирования проекта.
7. Определить внешних исполнителей
Потребности некоторых проектов нельзя закрыть внутренними ресурсами. Например, исполнитель нужен только на один проект, и держать его в штате все остальное время не целесообразно. Тем более, если реальная потребность во внешнем исполнителе появится только в середине проекта.
- Разобраться в границах полономочий
- Выяснить доступность внешних исполнителей (какие у него планы, что со временем)
- Подобрать запасные варианты
Значение имеет релевантный опыт внешнего исполнителя, его отзвычивость, готовность отвечать на вопросы еще до старта работы в проекте.
8. Аудит подготовки
Проходим по чек-листу или списку вопросов, помогающим выяснить потенциальные источники проблем. Чек-лист в этому случае – все пункты выше.
9. Да или нет
На этом этапе выносим решение – занимаемся проектом, или нет. Для этого организовывается встреча, на которой участвуют менеджер проекта, спонсор и стейкхолдеры. Обсуждаются бизнес-задачи, цели и выгоды проекта, сроки, бюджет, расписание, роли и обязанности. Решение о старте проекта выносится спонсором и стейкхолдерами, на основании результатов обсуждения.
У нас это применимо ко внутренним проектам. Нецелесообразные внешние проекты отсеиваются на этапе переговоров клиента с менеджером по развитию бизнеса (с нашей стороны).
10. Провести стартовую встречу
Встречи – способ синхронизироваться, получить общее видение проекта. Фокус встреч на видении, роли и рисках. Встреча не должна использоваться для решения проблем, а ее завершение желательно сделать неформальным.
11. Фокусированная коммуникация
Фокусированная коммуникация – сообщение с определенной целью и определенному кругу людей. В этом случае мы сообщаем о старте проекта. Сообщить можно через Slack, почту или корпоративный интранет.
Информация должна быть открытой внутри компании. Рассказываем, как, что и зачем мы делаем. Люди любят чувствовать себя значимыми – так что давай расскажем об их участии в своем проекте. Что мы делаем, зачем, какой результат ожидаем (или уже получили), какая помощь нужна.
Раздел 2. Планирование цикла
P3express определяет цикл длиной в один месяц. Самих циклов может быть много – пока не завершим проект. Для каждого цикла готовится свое техническое задание, планируются исполнители (из числа участников команды и внешних исполнителей), планируются сроки.
К планированию возвращаемся в начале каждого цикла – за месяц могла поменяться ситуация и контекст проекта. За месяц в принципе могла отпасть потребность в реализации проекта.
Еще в каждый цикл можно закладывать логическую часть проекта. И было бы идеально, если бы она закрывалась за месяц.
12. Обновить планы
Обновляем планы в начале каждого цикла. Ситуация может измениться, а планы устареть. Проверяем актуальность планов, сверяем курс с целями проекта, планируем следующий цикл.
Посмотреть, к чему идем и что меняется в проекте и команде. Обновляется план целиком – оценки тоже могут меняться. После обновления выбираем из конфигурации задачи в план на следующий цикл. Назначаем исполнителей и детализируем задачи – составляем чек-листы и критерии приемки. Снова приоритезируем задачи (MoSCoW) внутри нового цикла. Планируем риски цикла.
13. Определить внешних исполнителей
Определение внешних исполнителей может потребоваться, если это не было сделано заранее. Даже если внешние исполнители были определены, нужно убедиться, что они могут подключиться к проекту на этом цикле. Например, если их включили в проект за два цикла до того, как могла потребоваться их помощь, у них могли успеть смениться планы, и нам потребуется переопределить исполнителей. Могли появиться новые планы, под которые не рассчитали исполнителей. Также переопределение может потребоваться, если внешние исполнители не оправдывают ожиданий. Не забываем про вопросы договоров и оплат.
14. Да или нет
Каждый месяц снова задаем себе вопрос о целесообразности проведения проекта. Если в каком-то из циклов ответ окажется «нет», то фиксируем убытки и закрываем проект. Если ответ – «да», то продолжаем работу.
15. Провести стартовую встречу цикла
Эти встречи требуются для поддержания синхронизации и планирования. Рассматриваем планы на цикл, вопросы и ответы, контекст и риски цикла. Такие встречи должны быть неформальными.
Памятка для составления повестки встречи
- Приоритеты – что обязательно нужно сделать
- Результаты, которые нужно достичь
- Участники встречи и работы над циклом
- Последовательность вопросов для обсуждения
- Тайминг встречи
- Дата и время встречи
- Место
16. Фокусированная коммуникация
В первую очередь нужно помнить, на какую аудиторию направлена коммуникация. При планировании цикла пишем:
- Достигнутые результаты
- Планы на ближайший цикл
- Риски цикла
- Помощь, если нужна
Сообщить о статусе владельцу продукта и команде.
Раздел 3. Еженедельные действия
Первое: провести статус и понять, где отклоняемся от плана – делает это менеджер проекта. После проводим еженедельную встречу, с аудитом проекта и отдельной фокусированной коммуникацией.
Чтобы еженедельный аудит проще проходил, нужно
- Добросовестно заполнять рабочее пространство
- Быть последовательным
- Поддерживать фокус команды
17. Оценка прогресса
Проводится раз в неделю – это актуализация статуса проекта. Понимаем текущий статус и отслеживаем продвижение к целям цикла.
- Актуализируем рабочее пространство
- Собираем и заполняем недостающую информацию
Если заполнением занимаются другие участники проекта, а в рабочем пространстве бардак – выясняем почему, помогаем разобраться.
18. Работа с отклонениями
Еженедельно выясняем наличие отклонений от плана цикла. Оцениваем влияние отклонений на проект. Работаем с конкретными исполнителями напрямую. Значимые задачи выносим на обсуждение. Те отклонения, на которые нельзя повлиять, должны быть донесены до спонсора проекта. Задача работы с отклонениями – решить проблему, а не найти и наказать виновных.
19. Еженедельная встреча
Еженедельная встреча нужна для синхронизации на неделю. Обсуждаем вопросы, планы на неделю, текущие сложности и риски – принимаются комментарии команды. Статус проекта и решение проблем проводится отдельно. На еженедельную встречу желательно, но не обязательно собирать всех участников проекта. Длительность такой встречи желательно выдержать в пределах 30-40 минут.
20. Еженедельный аудит
Проверяем выполнение задач и проводим аудит. По шаблону со статусом здоровья проекта (вторая вкладка файла).
21. Фокусированная коммуникация
Завершающий шаг недельного цикла. На этом этапе фокусированная коммуникация нужна для информирования участников команды. Сообщаем о планах, рисках, акцентах. Выражаем благодарности. Не превращаем эту коммуникацию в формальный фоллоу-ап.
Раздел 4. Ежедневные действия
Ежедневно фиксируем риски, проблемы и запросы на изменения. Решаем проблемы и следим за загруженностью команды.
22. Фиксация RICs
RICs – это риски, проблемы, запросы на изменение. Риск – ситуация, которая может возникнуть и повлиять на проект. Формулировать риск нужно в задачу, которой можно заняться. Например: «разработчик задерживает задачу из-за обновления системы». Проблемы отличаются от рисков тем, что они уже наступили и их нужно решать.
Менеджер проекта собирает запросы на изменение, оценивает их влияние на проект. После, решение о принятии или отклонении выносит комитет по изменениям/спонсор проекта. Важно отслеживать, когда такие изменения попали в проект. Фиксировать RICs нужно сразу, как они появились.
Перевожу: фиксируем возможные проблемы, предварительно планируем, что будем делать, если риски реализуются. Мое любимое – запросы на изменение, они случаются даже чаще рисков. Фиксировать именно их нужно в убер-обязательном порядке.
23. Реагирование на RICs
Нужно проверить, что каждый из RICs занесен в реестр, имеет номер и дату возникновения. Чтобы оценить важность риска, используем два критерия: вероятность и воздействие.
Есть следующие стратегии управления рисками:
- Уклонение – устранение угрозы
- Снижение – уменьшение воздействия/вероятности риска
- Передача – перекладывание ответственности (например, страхование)
- Принятие – признать риск, но ничего не делать до наступления риска
- Эскалация – передача ответственности на более высокий уровень (например, спонсору проекта)
При занесении риска в реестр, нужно обозначить его владельца – того, кто будет с ним разбираться.
24. Принять готовые продукты
Не допускать того, чтобы «в процессе» было много незавершенных одновременно задач. При этом, чтобы они не скапливались в «тестировании». Не перезагружать команду незавершенными задачами. Разработать детальную и понятную процедуру приемки выполненных задач. Быстрее давать и получать обратную связь.
Раздел 5. Закрытие цикла
Цель – оценить удовлетворенность и собрать обратную связь, по итогам которой планируем улучшения. Ретроспектива и планирование улучшений.
25. Оценить удовлетворенность заказчика и команды
Помогает выявить проблемы проектов как можно раньше. Нужно использовать чек-лист здоровья проекта (анонимно или нет). Опросник можно использовать в виде гугл-формы с вопросами.
Спросить у команды:
- Все ли участники участвуют в проекте
- Нуждается ли команда в тимбилдинге
- Прислушиваются ли к вашему мнению
- Считаете ли вы, что цели реалистичны
Вопросы заказчику:
- Насколько комфортно с нами работать
- Есть ли четкое понимание того, что мы делаем – планы
Результаты нужно фиксировать, предпринимать действия, реагировать на комментарии. Важно донести цели опроса, давать обратную связь. Завести карточку в рабочем пространстве, где будем хранить все опросы.
26. Запланировать улучшения
Это же – ретроспектива. Выявить процессные проблемы и найти способы улучшения. Воркшоп – обсудить с командой, какие проблемы она считает приоритетными, запланировать решение. Проводить такой воркшоп нужно, участвуя в нем в роли фасилитатора.
Пример техники
- Собрать команду, объяснив цель встречи и ее технику
- Попросить анонимно записать процессные проблемы
- Объединить списки, дополнить их
- Попросить выбрать три самые важные проблемы
- Посчитать голоса, приоритизировать список
- Выбрать проблему, повторить предыдущие шаги для ее решения
- Конкретизировать идею, зафиксировать, договориться о ее внедрении
27. Фокусированная коммуникация
Цель – фокус и мотивация команды. Рассказать, что сделали и о чем договорились.
- Рассказать, чего достигли за цикл
- Закрепить договоренности об улучшениях
Раздел 6. Закрытие проекта
Передача проекта спонсору проекта, оценка удовлетворенности. Проведение аудита закрытия и извлечения уроков. Отмечаем закрытие проекта, фокусируем коммуникацию на команду. Важно: не пропускать шаги, делиться знаниями, отмечать успех.
28. Получить одобрение и передать продукт
- Убедиться, что все готово – конфигурация, чек-листы, нет косяков
- Разобраться, кому передаем получившийся продукт
- Подготовить документацию по проекту
- Провести обучение конечного пользователя
- Запланировать транзит – период передачи проекта
- Придумать план «Б» – на случай если что-то пойдет не так (например, сломается), с кем в этом случае должен коммуницировать заказчик
- Организовать встречу с заказчиком
29. Передать проект
Проект передаем спонсору проекта (либо в проектный офис, если он есть). Передача происходит в рамках встречи. Передаем:
- Проектную документацию
- Доступ к рабочему пространству (с описанием, как оно работает, где что лежит)
- Отмечаем транзитный период – как и когда
- Блок вопросов-ответов
30. Оценить удовлетворенность заказчика и команды
Узнать, как оценивают члены команды свое участие в проекте. Чему научились и чему хотят научиться. Узнать, насколько доволен работой с нами заказчик. Готов ли он нас рекомендовать? Как мы можем стать лучше? Используем результаты опроса для развития команды.
Обратную связь нужно снимать вовремя и не усложнять опрос. Спрашиваем тех людей, кто в курсе проекта.
31. Провести аудит проекта
Убедиться, что все шаги закрытия проведены.
- Передан ли продукт?
- Огранизована ретроспектива?
- Дана обратная связь команде?
- Подготовлено ли рабочее пространство к архивации? Должны быть все связанные документы
- Передан ли проект?
32. Извлечь уроки и заархивировать проект
Цель: сохранить знания, приобретенные в процессе этого проекта, для будущих проектов. Знания бывают явными и не явными.
Явные знания – документы. Должны быть в порядке, расположены системно. Чтобы с ними можно было работать.
Не явные знания – которые не осознаем для себя. Сюда можно отнести, например, моменты наподобие, когда лучше писать фрилансеру – когда он чаще на связи.
Метод извлечения знаний: попросить людей обозначить плюсы и минусы проекта, по их мнению. Дополнить рабочее пространство извлеченными уроками. В рабочем пространстве не должно быть «черных дыр».
Идеи для обмена знаниями:
- Бизнес-завтраки с спикером и коллегами
- Менторство
- Мини-конференция
- Тематические каналы в мессенджерах
- Статьи в корпоративном блоге
33. Объявить и отметить окончание проекта
Цель: не превращать проекты в рутину.
- Объявить об окончании проекта
- Предоставить свободное время
- Провести встречу вне офиса
- Наградить отличившихся
- Поинтересоваться, что хочет команда
Важно: не игнорировать шаг, соблюдать корпоративную культуру, не забывать про удаленных сотрудников.
34. Фокусированная коммуникация
Фокусированная коммуникация на этом этапе – анонсирование закрытия проекта. Спонсор проекта анонсирует завершение проекта всей компании. Пишем: результаты проекта, благодарности, влияние проекта на компанию.
Раздел 7. После проекта
После проекта измеряем полученные выгоды. Для оценки вариантов максимизации выгод, либо для ликвидации негативных последствий. Делает это спонсор проекта.
35. Оценить полученные выгоды
Зачем: оценить успешность, возможности дальнейшего применения. Выгоды или не выгоды, полученные от проекта. О результатах можно сообщить команде – в качестве фидбэка и меры мотивации.
Чтобы измерять выгоды, нам нужен владелец выгод. Лицо, ответственное за мониторинг и ведение документации по выгодам. Скорее всего, им будет спонсор проекта.
- Метрики. Как будем измерять выгоды
- Сроки. Какие выгоды получим сейчас. Когда получим остальные выгоды.
- Риски. Что может пойти не так и как с этим работать.
36. Запланировать дополнительные действия
Это нужно делать для того, чтобы:
- Максимизировать выгоды
- Сократить негативные последствия
Выгоды в проекте для каждого свои. Примеры планирования действий: поделиться кейсом, доработать текущий продукт по фидбэку, пересмотреть планы.
37. Фокусированная коммуникация
Цель: сообщить о реализованных выгодах
-
- В письме/посте копоративного интранета
- Личная благодарность
- Мероприятие – даже не связанное с самим проектом
Post Scriptum
P3express (он же p3x) – легковесный фреймворк ведения проектов. Появился он недавно, и популярности особой заработать не успел. Представляет собой что-то очень похожее на Agile или SCRUM, но при этом без лишних навесов и излишних усложнений. Может, потому что это не методология, а именно фреймворк – примеряешь и ведешь свой проект по нему, как по рельсам.
Почитать о нем больше можно на сайте курса. А об управлении проектами в целом – на канале Project Management Club в телеграме. Еще на ютубе есть запись вебинара о p3express, от одного из авторов и ведущих курса.
