Новое в управлении содержанием
проекта (Scope Management)
PMBOK 4 впервые описал процесс
ведения аналитических работ
В разделе по управлению содержанием новая тенденция на преемственность с
современными методиками внедрения программно-методических решений показала свою
силу.
Что мы имели в PMBOK 3 как начало по управлению
содержанием? Scope Planning - планирование содержания.
Подразумевалось, что нужно описывать процессы по подготовке содержания проекта.
Если непредвзято вчитаться в PMBOK 3, то возникает
много вопросов без ответов.
Кто должен придумать проектные решения для проекта?
Как должен придумать проектные решения?
Как проверить качество проектных решений до их реализации?
Все это были вопросы без ответов. Вместо этого были рекомендации описывать
процессы планирования содержания.
В PMBOK 4 удалили полностью
Scope Planning. В связи с этим и вопросами выше, следует ли считать, что
методические наработки сделанные в строгом соответствии с
PMBOK 3 содержат серьезные недостатки по ведению
аналитических работ?
Это довольно серьезный вопрос. По мнению Влада Березина все зависело от
самого консультанта. Опытные консультанты раскрывали полностью состав проектных
документов и их практика и зафиксирована в PMBOK 4. В
тоже время консультанты могли ограничится и только общими положениями,
PMBOK 3 это не запрещал.
Так это или нет нужно ответить каждому самостоятельно изучив новый процесс
сбора требований к проекту (Collect Requirements) заменивший
Scope Planning.
Теперь в обязанностях консультанта по управлению проектами детально выявить
требования через большое количество специальных мероприятий. Это не может не
радовать, т.к. ссылаясь на требования PMBOK 4
заказчики теперь смогут от консультантов получить более качественные
регламентные документы. По-сути PMBOK 4 теперь может
выполнить роль как СНИП у строителей, когда нужно вытащить из дизайнера и
архитектора не только красивые общие штрихи решения, но и важные детали.
Аналогично требуя исполнения указаний PMBOK 4 можно от
консультанта теперь получить намного больше конкретики.
PMBOK 4 вводит довольно серьезный набор мероприятий
по выявлению требований к проекту.
- Интервью
- Группы экспертов-стейкхолдеров по компетенции (Focus
Group)
- Тематические сессии (Facilitated Workshop).
Формат сессии:
"эксперт и пользователь".
- Креативные техники принятия решений и разрешения
конфликтов интересов стейкхолдеров, в том числе техники принятия решения
меньшинством за большинство.
- Опросники
- Наблюдение за выполнением процесса в реальности, а не
только по бумагам
- Прототипы
Явление Прототипа. Итерационные методы
внутри процессов PMBOK 4
Ключевым является последний в списке - Прототип. В 2008 году
многие заказчики еще не понимают, что отработать методические приемы только на
бумаге нельзя, нужны действующие модели, которые верифицируют идеи и четко
демонстрируют истинный потенциал решения. Причем прототип это именно
аналитический инструмент для выявления требований, а не стадия реализации
каких-то требований.
Прототипы встречались в PMBOK 3 в некоторых
комментариях, но как реальный инструмент (Tools &
Techniques) не значились ни в одном из процессов
PMBOK 3. Как аналитический инструмент в PMBOK 3
нигде прототип не рассматривался даже на уровне замечания.
Появление прототипа в Collect Requirement очень
принципиальный важный момент для проектов по внедрению самого проектного
управления. Согласно PMBOK 4 прототип информационной
системы управления проектами должен быть применен как аналитический инструмент
сразу после Устава проекта и до всякой регламентации и
разработки концептуальных документов.
В связи с этим встает снова важный вопрос. Не является ли текущая практика
написания "Концепций" без проверки их на моделях-прототипах серьезной
методической ошибкой?
Отметим, что многие ведущие поставщики решений и до PMBOK
4 не работали без прототипов, например эксперты
Primavera без прототипирования не выполняет регламентацию. Мы поступаем
ровно также.
PMBOK 4. Состав регламентной
документации перестал быть абстракцией
Очень важными являются результаты фиксации выполненных
аналитических работ по выявлению требований.
Описание требований стейкхолдеров (Stakeholder Requirements Documentation)
- какие
бизнес-проблемы удается разрешить продуктом проекта
- соответствие целей проекта и бизнеса
- функциональные требования включая описание бизнес-процессов и взаимодействие
с конечным продуктом проекта
- требования к качеству
- описание коррекций организационной структуры
- описание изменений в текущих бизнес-процессах
- требования по технической поддержке и обучению
Как видим полная конкретика и никаких абстрактных слов. Также опытные
профессионалы заметят, что PMBOK 4 взял на вооружение
типовой набор описания требований характерный для многих методик управления
проектами из высоких технологий.
Опять же сразу встает вопрос. Большинство методически разработок для
PMBOK 3 не имеют такого четкого перечня постановочных
документов. Еще до выхода PMBOK 4 в стандартах
Microsoft Consulting Services обязательное четкое
моделирование всех бизнес-процессов стало обязательным.
Однако многие методические наработки для PMBOK 3
декларируют только принципы, но не содержат таких конкретных пошаговых описаний.
Следует ли тогда считать, что наработки сделанные по PMBOK 3
не гарантируют заказчику уровень детализации решения зафиксированный в
PMBOK 4?
План управления требованиями (Requirements Management Plan)
Данный документ описывает как требования будут
планироваться, отлеживаться и как это будет связано с конфигурацией проекта.
На первый взгляд что-то похожее на уничтоженный Scope
Planning в этом есть, но при сравнении содержания выясняется что это не
так.
Scope Planning обязательно требовал
предварительного описания содержания, как уже отмечалось это удалено в
PMBOK 4.
Scope Planning полностью отдавал отслеживание
содержания в конфигурационный менеджмент.
Requirements Management Plan требует разработать специальную процедуру по
планированию, отслеживанию и отчетностью в требованиях к проекту. В
PMBOK 4 подчеркивается связь с управлениями
изменениями, но отмечается, что это теперь отдельная процедура.
Матрица трансформации требований (Requirements Traceability Matrix)
Матрица того как
требования будут отражены на WBS, описании продукта и
системе контроля качества. Довольно важный документ, который позволяет
эффективно трансформировать результаты обследования в разные документы проекта.
Прочитав все эти новые процедуры и документы вы должны задать себе вопрос.
Устарело ли все что сделано для PMBOK 3 в управлении
содержанием, а тем более требованиями?
Мы для себя ответили, что устарело и переделали и шаблоны документов и
процессов.
Новые навыки в управлении персоналом (Human Resource Management)
Очевидно PMBOK 4 будет весьма коварен в новой
сертификации PMP. Многие разделы внешне схоже выглядят
с PMBOK 3. Однако при внимательном чтении видны
многочисленные мелкие правки, за которые конечно будут "цепляться" вопросы в
новом экзамене. Но даже для тех для кого PMBOK 4 это
справочник знаний об управлении проектами довольно легко не заметить сильные
принципиальные расхождения с PMBOK 3.
Внешняя схожесть текста обманчива. Раздел по управлению персоналом как раз
такой. После беглого просмотра можно не заметить отличий. А если вчитаться, то
окажется, что и тут все кардинально поменялось.
Новые навыки персонала (Interpersonal skills, Soft Skills)
в PMBOK 3 уже были продекларированы во вводной
части. В PMBOK 4 они поставлены во главу угла.
Добавлен новый навык по генерации решений (Effective
Decision Making). Довольно легко проглядеть ссылку на Приложение
X, где все эти навыки и расписаны.
Как легко догадаться, пропустив эти "мелочи" даже с хорошим знанием
PMBOK 3 новый экзамен PMP не
сдать.
Коммуникация нового уровня:
выявление стейкхолдеров и искусственный интеллект (Project Communications Management)
Методики обнаружения влиятельных лиц (Identify
Stakeholders)
В PMBOK 3 существовало предположение, что все заинтересованные лица проекта
явятся сами и искать их не нужно.
В реальности такой подход без идентификации стейкхолдеов подвергал проект
серьезным рискам. Многие стейкхолдеры нужные проекту или же потенциальные
противники проектами самостоятельно непроявлялись. В результате можно было не
получить поддержку там где она возможна, а также получить удар в спину от
противников проекта.
Microsoft приводит в своей статистике, что
80% причин провала внедрения проектного управления это сопротивление персонала.
В связи с этим сразу вопрос. Является ли отсутствие таких работ по
идентификации заинтересованных лиц серьезным методическим недостатком
PMBOK 3 в управлении коммуникацией и управлении
рисками?
Влад Березин отмечает, что хотя в PMBOK 3 не были
прописаны четкие процессы по идентификации стекхолдеров и учету их при
управлении рисками, но в PMBOK 3 практически в каждом
разделе была общая ссылка на необходимость внимание на заинтересованных лиц ("Stakeholders
Management is critical for success"). Опытные эксперты несмотря на
отсутствие детальных указаний в PMBOK 3 самостоятельно
разрабатывали и использовали методики по идентификации заинтересованных лиц и
использования этих данных для управления рисками. Поэтому
PMBOK 4 не вносит нового в практику экспертов высокого уровня, но
фиксирует "де-юре" такую практику на уровне стандарта.
Слова Влада подтверждает известный эксперт PMI
Бонни Биафоре, в своей книге она сразу же приводит методики идентификации
стейкхолдеров так как это сделано в PMBOK 4.
По PMBOK 4 Действие по идентификации
стейкхолдеров носит стратегический характер для проекта и должно производится на
самых первых шагах, практически одновременно с созданием Устава проекта.
Новый Регистр стейкхолдеров довольно эффективное средство для их выявления и
выработки стратегии для работы с ними.
Также очень эффективны методики классификации заинтересованных лиц и
выбор на их основе правильной стратегии для работы с ними.
Диаграмма ниже позволяет выбрать оптимальную стратегию в зависимости от
возможностей (Power) и интереса (Interest)
стейкхолдера.
Отчетность об исполнении и прогнозы на
базе Искусственного Интеллекта (Report Performance)
В PMBOK 3 были вводные слова о том, что неплохо бы
иметь отчетность об исполнении проекта с прогнозированием развития проекта.
В PMBOK 4 это наполнилось более чем конкретикой.
PMI взял на вооружение методику прогнозирования на
базе Искусственного Интеллекта известную как Временные Ряды (Time Series Method).
Причем данная методика прогнозирования считается теперь базовой и стоит на
первом месте в списке инструментов.
Применение инструментария такого уровня показывает, что бумажное
управление проектами осталось в прошлом.
Следует отметить, что выбор Time Series показывает
что над PMBOK 4 работали действительно профессионалы
высочайшего уровня в IT-технологиях.
Microsoft стал поддерживать методику
прогнозирования Time Series только в 2005 году, но
даже моя личная практика показывает высокую перспективность этого решения.
В данный момент мы с компанией Систематика выполняем правительственный
контракт, в котором применяется технология прогнозирования
Time Series.
Хотя мы сертифицированы Microsoft на внедрение
такого инструментария прогнозирования изначально на запрос клиента отреагировал
довольно скептически.
Практика продаж систем искусственного интеллекта часто выглядит как попытка
продажи боевых андроидов. В смысле что клиент согласен что это "круто", но
относит к области фантастики или же считает что нужен для такой системы персонал
с докторской степенью.
Все это близко к реальности относительно систем искусственного интеллекта, но
Time Series это исключение. Дело в том, что данный
алгоритм прогнозирования очень прост в эксплуатации и интуитивно понятен. После
многочисленных демонстраций я вижу лояльность пользователей данному инструменту.
Технологии определения корреляций заложенные в Time Series
делают его очень надежным, практически это единственная технология
построения трендов корректность которой математически доказана. Собственно
PMI неслучайно выбрал не какие-то абстрактные тренды,
а именно тренды Time Series
Мы включим тренды для прогнозирования на базе Time Series
по PMBOK 4 в новую версию
Turbo Project.
Управление рисками. PMI
сравнил PERT и Монте Карло (Risk
Management)
В раздел по управлению рисками было внесено много изменений.
PMI исправил проблему с главным
риском идущим от сопротивления персонала и сделал связь с Регистром стейкхолдеров
На идентификации рисков стали обязательными методы SWOT
и экспертная
оценка
В отслеживание рисков добавили новое мероприятие для обзора
текущего статуса проекта (status meeting)
В PMBOK 4 эксперты PMI
наконец включили PERT-метод и .... по сути объявил вне
закона. Точнее PMI официально на уровне
PMBOK правильно разъяснил, почему
PERT вреден. Верно указаны две основные причины. Первая это низкая
точность PERT, а вторая, что сам
PERT не столько средство борьбы с рисками, сколько сам по себе риск, т.к.
его оценки слишком оптимистичны.
Цитата из PMBOK 4 об PERT
с указанием на эти проблемы:
"While such non-interactive models do not take merge bias into account (as
Monte Carlo does), they do provide alternative (and more optimistic) approaches
for relative risk of a project."
Как видим PMI остается сторонником только метода
Монте Карло. Пользователям MS Project, где есть только
PERT не стоит огорчаться, используя
Turbo Project
вы можете получить систему прогнозирования на базе Монте Карло, которая
дает и точность и не страдает избыточным "оптимизмом"
Управление закупками без "весовой"
модели (Project Procurement
Management)
В управлении закупками число процессов сократилось с 6 до
4:
- Планирование закупок (Plan procurements)
- Проведение закупок (Conduct procurements)
- Администрирование закупок (Administer procurements)
- Закрытие закупок (Close procurements)
Убран процесс по запросу информации у продавцов,
но добавлены разные методы по поиску продавцов включая
использование Интернет.
Однако самое главное изменение это исключение из обязательного применения
методики закупки на весовых показателях (Weighting System).
Смысл этой методики в PMBOK 3 заключался в том, что
нужно придумать критерии оценки поставщиков, назначить максимальные баллы по
каждому критерию. Расставить оценки и просто выбрать поставщика с максимальным
баллом.
Вроде бы логично, хотя даже участники тендерных комитетов часто себе задавали
примерно такой вопрос без ответа: "Почему мы по этому критерию ставим оценку
с весом 4, а не скажем с весом 5?"
Мне приходилось наблюдать как персонал обученный на курсах по
PMBOK 3 выбирая через такую методику поставщиков
теряет большие деньги и подписывается на большие риски. Причем сам персонал
понимал, что тут "что-то не так", но доверие к PMBOK 3
брало вверх.
Причина почему модель весовых показателей обычно только вредила в том, что
это модель для повторных выборов поставщиков. Иными
словами, если закупается что-то часто, то можно по базе истории прошлых закупок
подобрать и проверить весовые коэффициенты. Например,
Microsoft имеет хорошую и надежную систему рейтингов
своих партнеров. Однако адекватность рейтинга построена на том, что
Microsoft из других источников еще знает об истинном
уровне партнеров и поэтому может всегда на реальных данных проверить
корректность методики весовых коэффициентов и внести в коэффициенты и критерии
необходимые поправки.
Если же компания делает выбор (покупку) какого-то вида редко,
то применение модели весовых показателей скорее всего путь к серьезным
ошибкам.
Опять зададим вопрос о "непогрешимости" PMBOK 3 и
разработок на его базе.
Следует ли считать, что в PMBOK 3 была заложена
ошибочная концепция управления закупками и это было исправлено в
PMBOK 4?
В PMBOK 4 (п. 12.2.3.1) указан
следующий процесс для стратегических закупок.
1) Отобрать лучших поставщиков (selected sellers)
2) Решение о покупке принять топ-менеджменту (senior management)
Для такой стратегической покупки как система управления проектами это тоже
верная методика. Первые лица компании должны найти время послушать презентации
поставщиков и принять решение.
В связи с полным изменением процессов закрытия в PMBOK 4
появился отдельный процесс по закрытию закупок.
Как и в PMBOK 3 обязательно использование
систем документооборота (Records Management System)
для работы с контрактами.
Последствия PMBOK 4 для тех кто собирается сдавать
на PMP
Думаю многих волнует именно такой вопрос. Ответ кроется в том, что вы хотите.
По моему мнению и мнению Влада Березина для подготовки к новой сертификации
PMP потребуется переделка существующих учебных курсов.
Существенные отличия в порядке составления Устава, ведения аналитических
работ, работы с заинтересованными лицами и т.п. делают проблематичным применение
старых учебных курсов к новой сертификации PMP.
Разделы типа управления персоналом внешне схожи с PMBOK 3,
а в реальности сильно переработаны и отличаются во множестве мелочей, за
которые по традициям PMI и будут цепляется на
экзамене.
Стал ли PMBOK 4 более естественным и меньше
страдать "PMIизмами" в терминологии Риты также решать Вам, на мой взгляд
PMBOK 4 более хорошо ложится в традиции управления
проектами существующими на реальной практике. Обратите
внимание, как велико удовлетворение от создания итеративности в
PMBOK 4 у менеджеров, которые используют такие
методики в своей практике постоянно.
Кроме этого, как вы могли заметить из комментариев Влада Березина в
PMBOK 4 явно описаны многие лучшие практики и не
требуется догадываться как они должны выглядеть.
Если вы хотите получить, не только сертификат, но и реальные знания, то
вероятно лучше ждать новой версии экзамена PMP.
Вероятно его будет и легче сдать опытному менеджеру, т.к. "PMIизмов" станет
существенно меньше и можно обращаться больше к собственному опыту.
С другой стороны курсов по PMBOK 4 еще долго не
будет. Поэтому другая стратегия сдачи PMP это сдавать
сейчас и максимально быстро пока не отменен экзамен по PMBOK
3, т.к. преподавали сертифицированы по устаревшей версии
PMBOK 3 и быстро переучится на новый
PMBOK 4 несмогут.
Имеет ли смысл сейчас учится по
PMBOK 3?
Для тех кому нужна культура управления управления проектами,
а не просто сертификация, это вопрос открытый.
Я и Влад Березин пришли к одному выводу, что для базовых и элементарных
знаний по управлению проектами вполне пригодны и довольно старые материалы.
Для расширенных навыков в управлении проектами все зависит от того насколько
существенны для вас изменения PMBOK 4 в подготовке
Устава, описания содержания проекта, изменения в
методике организации закупок, а также впервые описанные методики
идентификации стейкхолдеров и т.д.
Также важным является, сможете ли вы как Влад применяя свой практический опыт
"додумать" положения PMBOK 3 или же хотите сразу
получить готовые процедуры из PMBOK 4.
Как партнерам Microsoft эффективно применять
PMBOK 4
Партнерам Microsoft следует уже начинать эффективно
применять PMBOK 4 даже до официального выхода.
"Повышенная совместимость" PMBOK 4 с передовыми
методиками управления IT-проектами позволяет его уже
начать применять на практике.
Несекрет, что многие IT-менеджеры не принимали
PMBOK 3 так как не могли догадаться как Влад Березин
как "додумать" PMBOK 3 для реализации нужных
процессов.
Сейчас все это исправлено. Формально зафиксированное итеративное планирование
и создание прототипа- это PMBOK 4. Плюс
PMBOK 4 имеет очень качественное описание процессов
организации аналитических работ, чего стоит только Collect
Requirements. В этом плане PMBOK 4 смог не
только догнать, но и перегнать многие частные IT-методики.
Потом другой важный плюс для партнеров Microsoft
это возможно использовать PMBOK 4 как средства
контроля консультантов, которые выступают постановщиками. Компания которая
выполняет заказ на бизнес-моделирования может быть достаточно хорошей, однако
отдельные консультанты могут искать более легкий путь абстрактных регламентов.
Как правило консалтинговые компании заинтересованы в повышении качества работ,
поэтому на уровне начальников консультанта вы скорее всего найдете поддержку в
использовании PMBOK 4 как стандарта.
Требования PMBOK 4 жесткие и конкретные, поэтому
выбрав его как стандарт можно избавить себя и клиента от рисков некачественных
регламентов. Кроме этого, PMBOK 4 позволяет (и даже
обязывает!) вам прямо во время регламентации испытать на прототипа проектные
решения консультанта и доказать что это работает или же это все
нежизненные схемы.
Использовать ли заказчикам PMBOK 4 как стандарт
уже сейчас?
Заказчикам решений по управлению проектами стоит PMBOK 4
внедрять уже сейчас. За оставшиеся несколько месяцев уже изменений не
предвидится.
PMBOK 4 защищает на порядок лучше интересы тех, кто
заказывает решения по проектному управлению, т.к. обязательства подрядчиков
прописаны четче и заблокированы многие риски.
Заказчик проектного управления как правило не в состоянии "додумать"
PMBOK 3 и нуждается в четких процедурных указаниях на
уровне стандартов.
Я бы также обратил внимание на создание прототипа из PMBOK 4,
как средство ранней диагностики качества проектных решений консультантов.
Еще раз обращаю внимание, что разработка прототипа по PMBOK 4
начинается сразу после Устава проекта
(Project Charter) и даже
до всяких "Концепций". Сначала
проектные решения должны быть найдены и первично проверены на модели, а потом
уже документированы.
Интегрируем MSF
для MS Project и PMBOK 4
Мы стали заранее готовится к выходу PMBOK 4,
т.к. как уже отмечалось выше сочетать итеративную методику
Microsoft Solution Framework можно без натяжек только с
PMBOK 4.
Обращаем внимание, что для внедрения MS Project
имеется специальная адаптация MSF с
готовыми методическими наработками, их хотелось сохранить, но при этом соблюсти
стандарты PMI.
Мы уже
скорректировали свою методику внедрения проектного управления в следующих
моментах:
- Подготовка Устава по требованиям PMBOK 4 с
акцентом на демонстрацию поддержки спонсора менеджеру проекта
- Ведение идентификации заинтересованных лиц и применение стратегий
управления стекйхолдероами по требованиям PMBOK 4
- Проведение всех видов мероприятий по сбору требований, заявленных в
PMBOK 4, включая создание прототипа и фокус-группы.
- Описание отраслевых бизнес-процессов управления проектами согласно
требованиям PMBOK 4
- Использование документов PMBOK 4 по
трансформации выявленных требований, включая матрицу трансформации.
- Введение прогнозирования на трендах Time Series
в коммуникацию о текущем состоянии проекта.
- Применение методики Монте Карло при управлении рисками и разъяснение
недостатков PERT на основе требований
PMBOK 4
- Приведение в соответствие с PMBOK 4
наших шаблонов документов по отдельным процессам
PMBOK 4 потребовал практически полной переделки
методических наработок
PM Consulting
Services сделанных в соответствии с PMBOK 3
и MSF. Мы хотели иметь
методические достижения PMI и Microsoft
в виде интегрированного методического пакета, только
PMBOK 4 позволил сделать "сшивание" методик без вольных
трактовок PMBOK.
Вероятно столь же сложный процесс адаптации к новым условиям ожидает и
другие компании специализирующиеся на внедрении решений в области проектного
управления.
Считаете ли вы что должны как можно скорее перейти на передовой стандарт
PMI решать Вам. Сравнительная информация для
размышлений изложена.
| 
