Pmbok кратко и по сути

Обновлено: 04.07.2024

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

Краткие вводные:

PRINCE2 (Projects in a Controlled Environment) – структурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании.

PMBoK – фреймворк (свод знаний) по управлению проектами, разработанный в 1996 году Project Management Institute (PMI) в США.

Как можно заметить, первое главное отличие – собственное позиционирование в проектном управлении. Остальные основные отличия с некоторыми субъективными выводами приведены в таблице.

PRINCE2

PMBoK (6 издание, 2017г.)

ISO 21500:20112

Определение проекта

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

Временное предприятие, направленное на создание уникального продукта, услуги или результата.

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

Процессы

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

49 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, мониторинг и контроль, закрытие.

39 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, управление, завершение.

Предметные темы / группы (курсивом отмечены различающиеся темы)

7 тем:

1. Экономическое обоснование,

3. Управление качеством,

5. Анализ и управление рисками,

6. Управление изменениями содержания,

7. Принятие решений.

10 областей знаний:

1. Управление интеграцией проекта,

2. Управление содержанием,

3. Управление сроками,

4. Управление стоимостью,

5. Управление качеством,

6. Управление человеческими ресурсами,

7. Управление коммуникациями,

8. Управления рисками,

10. Управление заинтересованными сторонами.

10 предметных групп:

2. Заинтересованные стороны,

Жизненный цикл проекта

Структура стадий проекта:

1. Стадия инициации,

2. Последующие стадии (создание продуктов, соответствующих требованием),

3. Финальная стадия (приемка результатов, подведение итогов проекта).

Минимальное количество стадий в проекте – 2 (инициация и финальная).

Все проекты могут иметь следующую структуру жизненного цикла:

1. начало проекта;

2. организация и подготовка;

3. выполнение работ проекта;

4. завершение проекта.

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

Принципы

7 принципов (универсальны и не требуют обоснования):

1. Постоянная оценка целесообразности,

2. Учет предыдущего опыта,

3. Определенные роли и обязанности,

4. Управление по стадиям,

5. Управление по исключениям,

6. Фокус на продукте,

7. Адаптация к внешним условиям.

Шестое издание PMBoK основано на процессной составляющей с четкими входами, выходами и инструментарием.

Ожидается, что новое седьмое издание будет ориентировано на принципы.

ISO 21500 по аналогии с PMBoK основан на процессной составляющей.

Ответственность за результат проекта

Ответственный руководитель (куратор/спонсор проекта) полностью отвечает за успех проекта.

Менеджер проекта управляет проектом на ежедневной основе в рамках полномочий, делегированных Управляющим советом.

Руководитель проекта = единый ответственный за результат.

Руководитель проекта обеспечивает общее руководство и управление работами проекта и отвечает за получение результатов проекта.

Инструменты управления

В методологии отсутствуют примеры инструментов, данная область отдается на откуп Руководителю проектов.

Предоставляет расширенный список инструментов и методов по каждому процессу управления проектом.

Стандарт не описывает конкретных инструментов для реализации процессов управления.

Возможность гибкого применения

Допускает использование минимального количества документов с минимальным требуемым содержанием, гибкое использование метода с соблюдением всех 7 принципов позволяет подготавливать упрощенную отчетность и минимизировать процессы управления (с учетом целей и задач, которые соответствуют процессам PRINCE2).

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

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

В начале сентября 2017 года вышла шестая редакция PMBoK (Project Management Body of Knowledge). PMBoK — свод знаний по проектному менеджменту, выпускающийся организацией PMI (Project Management Institute).


Это офигенно здоровый талмуд справок по ведению проектов, регулярно при том обновляющийся. Первая публикация свода вышла в 1996 году, за 20 лет — шесть редакций. В довесок к выпуску свода знаний, организация проводит сертификации проектных менеджеров. Увы, по некоторым причинам, я её пройти пока не могу. Ещё одна фентифлюшка PMI — участие в “клубе”, нафиг в жизни не нужна. Кроме легального доступа к PMBoK 6, она ничего не даст. Потому я и не могу рассказать, что там, в шестой редакции. Только что читать краткие ревью, чего там появилось нового.

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

Проект — набор действий, направленных на создание уникального продукта. Последним проект отличается от “процесса” — где конечный продукт не будет уникальным. Пример: рисование картины — проект, печать тысячи копий — процесс. Сдача экзамена TOEFL — проект, но изучение английского языка — процесс. Проект также имеет стадии и ограничения. Процесс может длится бесконечно. Ограничения проекта — срок, стоимость и качество. PMBoK расширяет количество ограничений до шести: добавляются содержание, риски и удовлетворённость клиента. Как правило, ограничения взаимосвязаны: например, если сокращаются время и стоимость, высокого качества можно не ожидать (и удовлетворённости клиента тоже).

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

Инициация проекта, человеческим языком, это когда понятно, что есть задача и понятно, что нужно стартовать. Основных процессов внутри этого этапа два: вычисление заинтересованных лиц и составление устава проекта.

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

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

Составление устава проекта. Здесь решаются вопросы с документами: руководство по ведению проекта, примерный тайм-план и техническое задание. Основной вопрос устава проекта — что решает продукт, создаваемый в процессе проекта, что должны получить на выходе (например, “на выходе нужен дом на 250 квартир”).

PMI отводит большой пласт именно планированию. Большинство проблем проекта возникает из-за ошибок при планировании проекта. Посудите сами: если в начале проект спланирован так, что прописано и предусмотрено абсолютно всё — какие могут быть проблемы в будущем? Планирование проекта содержит процессы: риск-менеджмент, определение проектных задач (и их декомпиляция), расписание проекта (тайм-план), формирование команды проекта.

Риск — одно из неопределённых событий, которое может произойти. Риски бывают негативными, создающими проблемы (например, в проекте по строительству автобана, разорился подрядчик), так и позитивными, которые помогают проекту. Управление рисками происходит в 4 шага.

  1. Определение рисков.
  2. Анализ найденных рисков.
  3. Разработка плана работы с рисками.
  4. Предупреждение рисков.

В рамках шага “определение” происходит анализ похожих проектов — своих и чужих, на предмет того, с какими проблемами столкнулись там. Например, конкурент делал электромобили, но разорился, потому что поставщик н-ных деталей не смог предоставить требующийся объём детали, а других поставщиков нет.

Разработка плана работы с рисками — что ты будешь делать в случае, если риск наступит?

Предупреждение рисков — что можно сделать, чтобы риск не наступил? Здесь же нам нужно оценить триггеры, по которым мы сможем оценить, что риск наступил и с ним нужно что-то делать. Это как когда у вас дома выбивает пробки, вы ищете потребитель, “кладущий” электросеть.

Характеристиками рисков являются “последствия” и “вероятность наступления”, где 1 — минимальное значение, 5 — максимальное.

Оценка рисков на старте IT-проекта. Вписав риски в таблицу и посчитав “тоталы” последствия/вероятности, мы видим, что нам стоит заняться поиском выхода на лицо, принимающее решение и поиском заменяющего программиста (если уж зачем-то подключаем программиста, который вот-вот уходит в отпуск). “Метеорит” вставил для утрированного примера, когда последствия риска максимальны, но вероятность нулевая.

Здесь берутся задачи, ставящиеся перед проектом в целом и декомпилируются на этапы, подзадачи и зависимости. Техническое задание превращается в задачи, которые требуют прямого решения. Для этого составляется ИСР — Иерархическая структура работ (WBS в оригинале).

В качестве примера иерархической структуры — проект разработки веб-сайта. Проект состоит из трёх этапов, каждый из этапов (фаз выполнения проектов) содержит или не содержит свои подэтапы, а те, в свою очередь, содержат конечные задачи. Проект декомпилируется до уровня задач, где каждая задача занимает от 4 до 40 часов работы конкретного исполнителя (рекомендуется PMBoK). В проектах наподобие разработки сайтов, задача может занимать от получаса до 16 часов — я так считаю.

Определение задач происходит так:

  1. Определить желаемые результаты.
  2. Определить, что нужно сделать для достижения этого результата.

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

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

Структура взаимосвязей может составляться на основе верхних уровней иерархической структуры. На примере разработки сайта, взаимосвязи линейны и выглядят так: дизайн => вёрстка => программирование. В случае проекта той же постройки детского сада, количество взаимосвязей стремится к бесконечности, их следует учитывать.

По поводу маршрута хода проекта (ака сетевой трафик) в PMBoK есть несколько инструментов — Float Time и Critical Time. Я их [пока] не использую, а желающие могут почитать об этом в интернете. Пример структуры — диаграмма PERT.

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

Для того, чтобы составить тайм-план в виде диаграммы Гантта, нужно:

  1. Перенести задачи в расписание — основные этапы + их детализацию
  2. Добавить длительность задач
  3. Расставить зависимости и отношение
  1. Добавить поздний и ранний сроки старта и финиша
  2. Добавить добавочную информацию — например, имена исполнителей

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

Диаграмма Гантта ещё тем хороша, что легко составляется — её можно хоть от руки рисовать. На компьютере её можно создать в Ms Project или Ms Excel. Я воспользовался сервисом draw.io — рекомендую.

Если базовая линия проекта изменилась и планирование посыпалось, PMBoK предлагает нам два инструмента в помощь в борьбе с проблемой: “Crashing the Project” и “Fast Tracking”. Альтернативные пути, подходящие нам и помогающие оставаться в рамках изначального тайм-плана — это уменьшение содержания проекта и уменьшение качества — время здесь равняется бюджету.

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

Формирование команды проекта может происходить двумя путями:

  1. Рекрутинг
  2. Наём исполнителей через функциональных менеджеров (тим-лидов)

Например, в диджитал-разработке это может выглядеть так: в компании есть дизайнеры, есть веб-программисты. У каждой из групп специалистов есть свой тим-лид — арт-директор у дизайнеров и тех.директор у программистов. Приходит заявка на разработку мобильного приложения. В таком случае, мы “нанимаем” дизайнера и веб-программиста у тим-лидов, а мобильного разработчика нанимаем из вне на время создания проекта — например, фрилансера.

После набора в команду проекта требующихся специалистов, требуется провести знакомство членов команды проекта (особенно, если часть их привлечена к проекту из вне). Знакомство команды с проектом состоит из четырёх фаз:

  1. Знакомство между собой
  2. Прояснение целей проекта.
  3. Прояснение плана проекта.
  4. Ответы на вопросы.
  1. Может ли он выполнить эту задачу?
  2. Выполнит ли он эту задачу?
  3. Будет ли он доступен в то время, когда потребуется выполнение задачи?

Под “может” подразумевается квалификация и навыки исполнителя. Под “выполнит” — будет ли он её делать. “Будет ли доступен” — в том случае, если команда собирается сразу, а этап работы этого специалиста произойдёт через месяц. Подразумевается, что члены рабочей группы проекта не сидят на одном месте вокруг одного проекта, что до старта проекта у него были другие задачи (проектные или нет), также могут быть задачи во время хода проекта (во время, когда он не вовлёчен в работу).

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

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

А вот ещё чуток про human resources и выбор исполнителя под проект, чек-лист вопросов по оценке возможностей.

  1. Насколько ежедневные обязанности исполнителя пересекаются с задачами проекта.
  2. Обладает ли человек специальными навыками, требующимися в проекте.
  3. Какой у человека бэкграунд и образование.
  4. Каково с этим человеком работалось ранее.
  5. Готовность принять назначенные задачи.
  6. Общий уровень доверия.
  7. Личные амбиции и желания исполнителя.

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

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

Причины быть “быстрее и дешевле”

  1. Приближающийся дедлайн.
  2. Желание увеличить прибыль.
  3. Желание опередить конкурентов.
  4. Увеличение жизненного цикла продукта.

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

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

  1. Мониторинг
  2. Оценка ситуации
  3. Установка контролирующих действий (если требуется)
  4. Доставка результатов работы заказчику

Главные инструменты тут — расписание проекта (тайм-план с майлстоунами и дедлайнами) и коммуникационный план. И сама коммуникация. Хорошая коммуникация — основа успеха проекта.

В чек-листе менеджера на этапе контроля выполнения проекта стоит три вопроса:

  1. С кем нужно держать коммуникацию?
  2. Почему и зачем нужно с ним коммуницировать?
  3. Как можно держать участников проекта информированными?

Участники проекта — и рабочая команда проекта и заказчики.

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

Трекинг проекта происходит путём сравнения точки, в которой мы находимся на данном этапе с той, в которой должны были быть по плану. Так мы оценим, насколько мы сейчас в плюсе/в минусе по бюджету/времени, сможем провести управление стоимостью проекта:

  1. Насколько запланированный объём отличается от действительно завершенного?
  2. Насколько “расхождение” отличается от реального объёма?

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

  • Цели проекта
  • Стратегия
  • Оценки
  • Планируемое расписание
  • Человеческие ресурсы (команда, организация, клиент)

Как я писал ранее, 80–90% проблем возникают по причине ошибок планирования. Только 10–20% проблем по причине ошибок команды проекта.

В случае проблем обращаемся к процессам Crashing the Project и Fast Tracking. А вот “лайтовый” список, подходящий для небольших проектов:

  1. Уменьшаем качество продукта, чтобы успеть в срок
  2. Уменьшение объёма продукта с той же целью
  3. Повышение бюджета (!)
  4. Разработка новой стратегии
  5. Замена участников команды проекта

Если изменились ожидания клиента (при плохом обсуждении планирования с клиентом):

  • Переговоры. Естественно — многое можно решить, всего лишь обсудив
  • Обсудить регулировку содержания проекта
  • Переопределить цели и отношения проекта

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

Честно скажу, я всегда с некоторой настороженностью открываю разные "чересчур умные" книжки. Особенно их переиздания (в данном случае аж 7-ая версия). Ибо очень часто разрыв между высокими концепциями и реальностью оказывается чересчур огромным (особенно в этом плане меня позабавил катастрофический непонятный вебинар на тему понимания).

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

О чем вообще речь?

Как известно, в августе 2021 года вышла 7-ая версия руководства к Своду знаний по управлению проектами, изрядно переработанная.

В чем суть изменений?


Составители принципиально переделали логику, ушли от описания 49 процессов (для многих проектов слишком громоздких и избыточных) к 8 доменам исполнения (актуальных для проектов любого масштаба).
Руководство ориентировано на работу по Agile не в меньшей степени, чем на “классические” подходы, а то и в большей (что логично, учитывая, что число Agile проектов неуклонно возрастает).
Размер книги существенно сократили (примерно в три раза), многое вынесли на онлайн-платформу.
Руководство стало еще менее предписывающим, и более рекомендующим (в любом случае, каждый проект - уникален, и универсальных советов не бывает).


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

Более подробно о том, чем новое издание радикально отличается от предыдущего я уже немного писала в своей предыдущей статье: Новый PMBoK 7®: Неужели заговор его составителей против простых людей все-таки раскрыт?

Но это были общие тезисы. А здесь - немного конкретики, что лично мне показалось наиболее полезным в новом издании, и что я порекомендую взять с собой в работу РП любого уровня. Сразу оговорюсь, не надо думать, что авторы Руководства (чего-то меня так утомили противники англицизмов в комментах к предыдущей статье, что я уже избегаю аббревиатуры PMBOK, заменяя ее какими-то русскими словами, ну да ладно) мало предлагают “свежих гениальных идей”. В первую очередь они рассказывают существующие и проверенные временем концепции, методы и модели. И это прекрасно. Потому что “новые и уникальные методики” при ближайшем рассмотрении обычно оказываются куда менее действенными, чем выглядят на первый взгляд, и сопряжены с гораздо большим числом побочных эффектов, чем хочется. Ну, а волшебные пилюли существуют только в нашем воображении.

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


Модель ситуационного лидерства Кена Бланшара

(Строго говоря, она называется Модель II, потому что есть еще Модель I - так как двое соавторов: Пол Херси и Кен Бланшар не поделили права на концепцию и зарегистрировали две разных названия).

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

Где же истина? Истина, как обычно, во вникании в данную конкретную ситуацию. Для одних ситуаций подойдет один метод, для других - другой. И не надо видеть мир в черно-белых цветах: либо у нас директивное управление, либо самоуправление.

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


Что из этого следует в реальности? Пока у новичков брызжет энтузиазм и они уверены в своей способности покорить Эверест (R1: не компетентны, но мотивированы), безопаснее их вовремя останавливать, чем давать проявлять инициативу. При этом их необязательно вдохновлять, они сами себя прекрасно вдохновляют. Лучше для всех директивно руководить (S1 - директивный стиль). А на следующем шаги они уже разочаровались после первых неудач (R2: недостаточно компетентны и демотивированы - см. кривую Данинга-Крюгера, она примерно про это же). Тогда нужно сменить директивный стиль поведения на наставнический, “продавая” свои (по-прежнему все еще директивные) решения и поддерживая сотрудников (S2 - наставнический стиль). Иначе разочарованные сотрудники просто уйдут. По мере того, как компетентность растет, лидеру всё важнее уметь ситуацию “отпускать” - (R3: сотрудники компетентны, но не достаточно мотивированы) здесь уместен менее директивный стиль руководства - поддерживающий. Ну а когда у команды высокая компетентность совмещается с высокой вовлеченностью (R4), здесь уже можно реализовать мечту хорошего руководителя - отпустить ситуацию. Команда сама разберется (стиль руководства делегирующий - S4). Примерно так и работает идеальная Agile-команда. Главное - понимать стадии развития команды и сотрудников, способствовать росту и постепенно давать всё большую инициативу, а не замереть навечно на директивном уровне со словами, что “эти без меня никогда ни в чем не разберутся, вечно приходится их контролировать”.



Понятно, что модель Бланшара всё упрощает (любая модель всё упрощает - они для этого и создаются). Но в моей практике она достаточно удобна, чтобы хотя бы в общих чертах понять, что происходит, и как лучше действовать на данном этапе.


Модель изменений Коттера

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


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

Один сотрудник франчайзи как-то делился, что наблюдал два крупных проекта по внедрению в организации MS Project. Оба проекта были серьезно организованными, были потрачены крупные деньги, проведено серьезное обучение… И оба проекта получили один и тот же результат: менеджеры, с которых требовали отмечать работы в Project’е, отмечали там что попало, а работали при помощи более привычных инструментов. Так что завершилось это всё крупным скандалом с увольнением ответственных лиц и полной неудовлетворенностью результатом…

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



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

• Сформировать группу поддержки. Чтобы была команда, понимающая, в чем преимущество этого изменения. Без этого саботаж неизбежен.

• Сформулировать видение изменений. Картинка красивого светлого будущего, понимание к чему мы идем. Очень многие аналитики жалуются, что руководство продвигает внедрение новой ИС не озвучивая, а зачастую и не очень понимая само, а в чем смысл преобразования. “Морально устарело… Это используют конкуренты… Это необходимо”. - и ничего более конкретного.

• Информировать все заинтересованные стороны. На этом этапе нужно как можно более частое подробное обсуждение, что и зачем мы делаем. Типичное заблуждение, когда топ-менеджмент считает: “они обязаны перейти на новый формат работы, потому что иначе мы их уволим - какая здесь еще нужна мотивация. ”. К сожалению, такой подход не работает.

• Устранить преграды. В описанных выше история с Project’ом, проблемы и сопротивление всплывали на поверхность уже в конце проекта. Чем раньше мы понимаем сложности и ограничения, и чем оперативнее предпринимаем шаги для их разрешения, тем больше шансов, что всё получится.

• Обеспечить краткосрочные победы. Это важный пункт при внедрении чего угодно нового. Взрослым, также как детям или животным (всем рекомендую книгу - Не рычите на собаку! Книга о дрессировке людей, животных и самого себя! Карен Прайор) нужен быстрый успех. Пускай маленький, но успех. А дальше - серия успехов. С трудностями будем бороться не в самом начале пути, а когда мотивация уже будет укреплена.

• Поставить цели для дальнейших улучшений. После первых успехов неминуемо будут попытки отката назад. Не надо праздновать победу после тех самых маленьких успехов - изменения - это всегда длительный процесс. Скажем, Agile-трансформация в организации проходит не быстрее, чем за 2-3 года - нужно быть к этому готовым.

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


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


У тех, кто прочитал эту статью может возникнуть резонный вопрос - а в чем ценность книги, если она представляет собой в большей степени структурированную компиляцию, чем какой-то уникальный материал? А именно в качестве этой компиляции. Да, в современном мире есть гигантское количество теорий, статей, книг, посвященных управлению проектами и смежным темам. Можно пытаться прочитать их все, и надеяться, что от этого станешь умнее… А можно посмотреть краткую выжимку рекомендаций от профессионалов в проектном управлении, и иметь готовый набор инструментов на все случае жизни. Впрочем, в Руководстве есть, конечно, и уникальная информация - просто будучи связана ограничениями по нераспространению уникального содержания без разрешения, я не стала рассказывать про них в этой статье…


Если вам интересно узнать про PMBOK® 7 подробнее, и, главное, разобраться, какая в нём может быть польза для практической работы, то у меня для вас хорошая новость

Напоминаю, что осенью стартует целых три курса, построенных на основе 7 PMBOK®:

  • Для начинающих РП - Базовый курс (первая часть Комплексного курса 3в1)
  • Для РП с серьезными намерениями - Продвинутый курс по PMBOK® (2-ой модуль) (первая часть курса Подготовка к PMP в трёх частях)
  • Для тех, кто хорошо знает старые версии PMBOK® - (в частности, для выпускников, уже закончивших Продвинутый курс по PMBOK® 6) - Cпецкурс, посвященный отличиям в 7-ом PMBOK®.

Сразу предупреждаю, приходить на курс имеет смысл только тем, кто хорошо освоил и умеет применять 5-ое или 6-ое издание на практике - так как иначе картинка проектного управления получится лоскутной. Всё-таки, что бы мы не говорили, большая часть инструментов и методов перекочевала в 7-ое издание из 6-ого в неизменном виде (повторюсь, каких-то радикальных изменений - с завтрашнего дня у нас революция и мы управляем проектами по новому), поэтому более привычные инструменты и техники знать тоже надо. Поэтому тех, кто пока не проходил Продвинутый курс - приглашаю более внимательно посмотреть на предложения выше.
Кстати, актуальное расписание моих курсов по управлению ИТ-проектами всегда (ну, почти всегда) доступно из левого меню сайта Инфостарта, раздел "Курсы".
Ну, и еще раз приглашаю всех на открытый вебинар 8 сентября в 19:00 мск. “Как быть, когда с Заказчиком невозможно договориться: Что на эту тему советует новый 7-ой PMBOK Guide?”
Приносите свои кейсы, обсудим.

Project Management Body of Knowledge (PMBoK) — свод знаний, максимально полное изложение информации по управлению проектами.

По сути, это своеобразная энциклопедия управления, в которой содержатся описание методов и рекомендации к работе. PMBoK разработан американским Институтом управления проектами (PMI).

Эксперты называют PMBOK классификатором управленческих процессов. Всего их 47, и эти процессы объединены в пять групп: инициирование, планирование, реализация, контроль и завершение.

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

Этот свод знаний популярен из-за своей универсальности: он подходит для большинства проектов, вне зависимости от сферы бизнеса. Однако все же PMBOK — это не готовая методология, а скорее фреймворк для методологии, который можно (и нужно) адаптировать, подгонять по себя и только тогда уже использовать.

Ошибки в употреблении

Читайте также: