PMBOK 6 - уже скоро. Пока драфт
PMI недавно опубликовали драфт версию PMBOK 6 - раздел со Стандартом.
Я его проревьюил и оставил авторам 24 ремарки. Можно было бы и больше, но там 90% однотипные и их нужно оставлять на каждый второй процесс, поэтому я надеюсь что рассмотрев и приняв их они поправят аналогично и в других местах, либо отклонят их все ;)
В целом же мое впечатление хорошее. Кардинальных изменений нет. А по тем изменениям, что есть, видно, что хорошо думали, когда делали изменения.
Ниже список изменений и замечаний:
Область знаний Time Management переименовали в Schedule Management, видимо, чтобы соответствовало названию стандарта по Scheduling. Это хорошо. Я за консистентность
Область знаний Human Resource Management переименовали в Resource Management. Видимо постарались обобщить. Это хорошо. В частности, переименовали процесс Acquire Project Team в Acquire Resources. Develop Team и Manage Team остались прежние, но также появился процесс Control Resources - чтоб ресурсы не растащили ;) - это правильно.
Процесс Perform Quality Assurance переименовали в Manage Quality. Тут у меня претензия, т.к. в управлении качеством уже принято разделение: QA / QC. А manage это все вместе. Но, видимо, авторы постарались сделать более консистентный текст - т.к. все другие процессы со словом “Manage” и слово “Assurance” выделялось.
В некоторых процессах заменили слово “Control” на “Monitor”: переименовали Control Communications в Monitor Communications, и Control Risks в Monitor Risks, и Control Stakeholders … в Monitor Stakeholders…. При этом некоторые процессы остались без переименования: Control Quality, Control Procurements, Control Costs, Control Schedule, Control Scope, Control Resources. В тексте отмечено, что это для того чтобы показать различие между пассивным наблюдением/анализом и более активным контролем, когда нужно предпринимать корректирующие воздействия. Ok.
Так как риски больше не контролируются, а пассивно мониторятся, то добавился новый процесс Implement Risk Responses. Логично.
Процесс Plan Stakeholder Management переименовали в Plan Stakeholder Engagement. Это хорошо, так как управление стейкхолдерами отличается от управления другими частями проекта, тем что стейкхолдеры неподконтрольны РП и поэтому слово “manage” к ним применять был бы через-чур смело.
Процесс Close Procurement убрали. Его активности теперь встроены в процесс Close Project or Phase. И это хорошо, т.к. никогда проект нельзя считать закрытым пока по нему все контракты не закрыли. И помимо закрытия контрактов нужно закрыть еще много чего.
В разделе про связь между Organizational Governance и Project Governance упоминаются Portfolio Governance и Program Governance и, на мой взгляд, здесь становится более запутанная связь между OPM, PMO, Organizational Governance, Portfolio Governance, Portfolio Management, Program Governance, Program Management, Project Governance, Project Management. Наверняка тут у читателей возникнет много вопросов.
По всем процессам сделали попытку глобального изменения - раньше часто во входах и выходах перечислялись компоненты Project Management Plan и другие артефакты проекта. Сейчас их попытались сгруппировать в Project Management Plan и в Project Documents, и ниже по тексту перечислить компоненты Project Management Plan и примеры Project Documents которые имеются ввиду во входе/выходе данного процесса. Пока получилось недоделано - где-то объединили, где-то нет, где-то что-то забыли, где-то что-то лишнее. На мой взгляд такая группировка это хорошая задумка, т.к. одними документами занимается РП/команда управления проекта, а другими вся команда проекта. Но нужно все-таки и явно перечислить на всех картинках все компоненты и примеры.
- Иначе мы рискуем скатиться к тому что в следующем PMBOK 7 у всех процессов на входе будет: Project Management Plan, Project Documents, Enterprise Environmental Factors, Organizational Process Assets, а на выходе везде будет: Project Management Plan updates, Project Documents updates. Это все будет абсолютно правильно, только бессмысленно.
У меня было несколько претензий к прошлому PMBOK - они сохранились и к новому:
- Portfolio Management по определению почему-то всегда идет во множественном числе - управление портфелями. Тогда как Program Management и Project Management - управляют единственной программой / проектом. Понятно что могут быть подпортфели. Но могут и у программы быть подпрограммы и у проекта подпроекты. Так что тут пока неконсистентность.
- Мне в целом не нравится использование слова manage в названиях процессов проекта, потому что у нас уже есть главные - интеграционные процессы Plan … Management. Т.е. мы спланировали управление, и далее мы данный план реализуем посредством нескольких других процессов. И поэтому нельзя чтобы один из этих нескольких процессов теперь назвался Manage …, ведь тогда становится не ясно, а чем же другие процессы еще могут заниматься - им ведь ничего больше не оставили.
- На всех картинках двухнаправленные стрелочки между процессами. Я уже и ранее писал - считаю что авторам PMBOK 5 просто не хватило смелости определить правильный порядок процессов. Такая смелость была у авторов более ранних PMBOK. Я понимаю что все процессы связаны со всеми. Но вот только это делает эти стрелочки абсолютно бессмысленными. Считаю что нужно набраться смелости и определить порядок в котором стартуют процессы. Если внимательно изучить все входы и выходы, то такой порядок вполне себе логично определяется. И я уже определял его на своей схеме: http://trunin.com/2013/03/pmbok5-schema-design-update.html
А еще добавили процесс Manage Project Knowledge. Это здорово! Это актуально.
Смотрите также:
- Схема процессов PMBOK открыта для членов МО PMI
- Продолжаем изучение Software Extension to the PMBOK® Guide или косяки в стандарте
- Software Extension to the PMBOK или PMBOK для ИТ
- PMBOK 5 на русском языке и верификация перевода.
- МО PMI ищет волонтеров для перевода стандарта PMI по Управлению Портфелями на русский язык