Показано с 1 по 30 из 147
-
20.04.2009, 20:26 #1
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
PMBoK 2008: обзор по главам
Решил завести обсуждение для PMBoK 2008, буду кратко рассказывать, что нового увидел, в первую очередь для себя (а рассказывать буду для других). Кстати, несмотря на то, что он на английском, читается он легко. Читаю я PMBoK 2008 Exposure Draft, ибо другого ничего не нашел.
Буду рад замечаниям и комментариям, а также поправкам.
Пока прочел первую главу, но уже несколько откровений.
Начнем по порядку. Всё начинается с введения, и цели стандарта. Опять слова про best practices и ответственность организации/project management team за его применение. Цель стандарта - дать обзор практикам проектного управления. Также сходу дано упоминание про Code of Ethics, что они есть и что он описывает ожидания от самих себя практиков проектной деятельности.
Определение проекта не поменялось, это по-прежнему временное предприятие по созданию уникальных продукта, услуги или результата. Утверждается, что управление временным предприятием по созданию нечто уникального как проектом, позволяет достичь набора бизнес-целей более эффективно (efficiently and effectively).
Понятие управления проектом немного изменилось, и включает в себя инициирование, планирование, исполнение, мониторинг и контроллинг (надеюсь дальше пояснят), закрытие. И что самое интересное (наконец-то!), стали говорить совместно о четырех составляющих: о балансе содержания, расписания, качества и бюджета. Насколько я помню, ранее говорилось о трёх. Также сразу упомянуто об итеративности процессов проектного управления.
Сразу же также говорится о взаимосвязи управления портфелем, программой и проектами. Портфель включает в себя портфели, программы и проекты, программа включает в себя проекты. ВНИМАНИЕ. Сразу говорится о взаимосвязи стратегического планирования и проектной деятельности. "Проекты часто используются как способ реализации (достижения) стратегических планов" (Projects are often utilized as a means of achieving an organization's strategic plan). Задачи портфельного же управления следуют за задачами стратегии.
Вот появилось и упоминание о проектном офисе. Управление разделяемыми ресурсами, развитие и регламентация методологии проектного управления, координация межпроектных коммуникаций.
Связь проектного управления и операционной деятельности. Утверждается, что результаты (имеется ввиду deliverables) проекта передаются в операционную деятельность в определенных точках ЖЦ проекта.
Роль менеджера проектов. Ну, тут тоже самое что и 2004ом PMBoK по-моему. Все те же skills.
Далее описание Project Management Body of Knowledge и пересечение с другими понятиями (неинтересно...). Standard describes project management processes, tools and techniques for managing scope, schedule, quality and cost, as well as any project environment aspects that influence the project's outcome. Блаблабла.
Заканчивается первая часть кратким перечнем факторов организационной среды, которые могут ограничивать возможности проектного управления.
На том пока всё. Завтра возьмусь за вторую главу.Последний раз редактировалось Andruxa; 20.04.2009 в 20:50.
-
21.04.2009, 18:22 #2
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Глава вторая
Жизненный цикл проекта и Организация. Эта глава описывает базовые представления о структуре проекта и как организация связана с проектом.
По поводу ЖЦ - ничего принципиально нового: жизненный цикл по PMBoK2008 - совокупность последовательных фаз, название и число которых определяется нуждами вовлеченной в управление организации(й). ЖЦ предоставляет базовую основу для управления проектом независимо от специфики его работ.
Потом речь заводится о характеристиках ЖЦ проекта. Ничего особенного кроме утверждения, что любой проект бьётся на Старт, Подготовку и Организацию, Выполнение работ и Окончание проекта. Типа для топ-менеджмента глубже и не надо (в общем-то да). Опять старые картинки про то, что затраты и число привлеченного персонала в ходе проекта сначала растут потом падают, картинка про стоимость изменений - в конце изменения обходятся очень дорого.
Старый добрый принцип - продукт - результат проекта или проектов. Ну и вообще взаимосвязь продукта и проекта - она есть. В ИТ так, из моего опыта, вообще есть взаимосвязь клиенты-продукты-проекты-технологии-ресурсы. Ну это ладно, в PMBoK этого нет
Далее идёт речь о фазности проекта. Мол, может быть одна или много фаз. Это не то, о чем говорилось в структуре ЖЦ, фаза - это совокупность логически связанных активностей, которые обычно заканчиваются поставкой. Что самое интересное, утверждается что нет одного пути для определения идеальной структуры проекта (да, стратегии).
Руководство проектом может подразумевать прерывание проектов по завершению фазы. Так-то. И ещё какие-то неглубокие мысли в разделе Project Governance Across Life Cycle.
А вот теперь - новости. Отношения фаз. Помимо стандартных последовательного выполнения и быстрого прохода (когда вторая начинается раньше конца первой), появилось итеративное отношение, когда дальнейшие работы планируются уже по завершению поставки фазы. Утверждается, что это используется в часто менющихся средах, или для таких работ как Research and Development... но это влечет за собой необходимость в содержании проектной команды на всём протяжении итеративных фаз, а также упоминается о рискованности подхода.
Опять какие-то слова про различия и сходства проектной и операционной деятельности. Наверное для тех, кто вообще впервые сталкивается с понятием проекта.
Стэйкхолдеры. Их много. Мне понравилась фраза: Likewise, project managers who ignore stakeholders can expect a negative impact on project outcomes. Также теперь четко проговорено про позитивных и негативных аффилированных лиц - мол одним от проекта хорошо, а другим - плохо.
Как и в ITIL (или ISO), PMBoK проводит различие между Заказчиком и Потребителем. Что не может не радовать. Кстати хорошо отмечено про то, что эти ребята сильно влияют на содержание проекта (я бы сказал - практически они его и определяют).
Пару слов про спонсора, управляющего портфелем, менеджера программы (опять сказано, что программа - это когда есть выгода от управления несколькими проектами как единым целым). Офис Управления Проектами также выделен в отдельного стэйкхолдера, как и проджект-менеджер, как и проектная команда, как и функциональные менеджеры. Далее описываются некто операционные менеджеры (кто отвечает за производство), что они могут предоставлять народ и другие ресурсы для проектов, как и проект в их руки передает результаты и документацию например. Вобщем, вода. Ещё про вендоров налили напоследок раздела стэйкхолдеры.
Влияние организации на проектное управление. Сначала говорится, что в организации есть культура и нормы, и что PM должен знать, кто конкретно в организации самый ЛПР, и работать с ним, чтобы достичь влияния на project success. Далее идут организационные матрицы, все их мы видели ещё в 2004 PMBoK, ничего нового.
Активы организационного процесса. Волшебная мантра предыдущего PMBoK, предполагалось что они чуть ли не каждый процесс обуславливали. Что новенького, так то, что здесь они бьются на две категории - процессы и процедуры, и корпоративная база знаний. И то и другое хорошо расписано.
В целом, ничего. Пишут подробнее, чем в прошлый раз, хотя много и воды, чего-то и не достаёт (например, про стэйкхолдеров слабо описано, не сказано явно - только на примере, что это все, кого проект затрагивает).
-
22.04.2009, 18:37 #3
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Глава третья - процессы управления проектом для проекта.
Управление проектами - приложение знаний, навыков, инструментов и техник к активностям проекта для удовлетворения требований проекта.
Определение процесса отличается от ИСОшного, и представляет собой взаимосвязанную совокупность действий и активностей по получению заранее определенного продукта, результата или услуги. И уже в качестве характеристик приводится наличие входов и выходов. Занятно.
И самое главное. Проектные процессы бьются на две категории: процессы управления проектом (описываются областями знаний) и продуктово-ориентированные процессы (определяются ЖЦ продукта).
Группы процессов управления (далее речь будет идти только о них) следующие, это те же самые:
- Процессы инициации,
- Процессы планирования,
- Процессы исполнения,
- Процессы мониторинга и контроллинга. Нужны для отслеживания, обзора (пересмотра), и регулирования прогресса и исполнения проекта.
- Группа процессов закрытия проекта.
Вот пошли и процессы инициации, первый процесс - разработка устава проекта. Второй - идентификация аффилированных лиц (очень хорошо, по-моему новый процесс). Выходы его - реестр стэйкхолдеров и Stakeholder Management Strategy. Вот даже так.
Процессы планирования - нужны для установления содержания, определения целей, определения курса действий (стратегии?..) для достижения целей. Разработка плана управления проектом. Сбор требований (один из выходов - план управления требованиями). Определение содержания. Создание Work Breakdown Structure. Определение активностей (специфичные действия по созданию поставок - delivarables - проекта). Упорядочивание активностей. Оценка ресурсов активностей. Оценка длительности активностей (работ). Разработка расписания. Оценка затрат. Определение бюджета. Планирование качества. Разработка HR-плана. Планирование коммуникаций. Планирование управления рисками. Идентификация рисков, качественный и количественный анализ рисков, планирование реагирования на риски. План поставок. Фух.
Процессов исполнения поменьше. Управление исполнением проекта. Контроль качества. Набор проектной команды. Развитие проектной команды. Управление командой проекта. Распространение информации. Управление ожиданиями стэйкхолдеров. Руководство поставками.
Процессы мониторинга: мониторинг и управление проектной работой (включая отчетность и прогнозирование), управление изменениями, проверка содержания (этот зверь о приемке уже готовых deliverables(!)), управление содержанием, управление расписанием, управление затратами, выполнение управления качеством, сбор отчетности, управление рисками, администрирование поставок.
Процессы закрытия. Закрытие проекта или фазы. Закрытие поставок.
В итоге. Произошли изменения, причем в лучшую сторону очевидно (кому нужны детальные подробности - они тут). По-крайней мере, новый PMBoK мне уже субъективно и по памяти нравится больше. Он стал более жизненный, что ли.
Что ж, общие главы закончены, остались лишь области знаний. Оттуда я не буду выдирать все подряд, а лишь то, что запомнится по прочтению.Последний раз редактировалось Andruxa; 23.04.2009 в 10:58.
-
23.04.2009, 08:03 #4
- Регистрация
- 22.11.2005
- Сообщений
- 315
Скромный комментарий: никак не могу уловить систему в вашем изложении
-
23.04.2009, 08:15 #5
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Система простая - вылавливаю основное (для управления проектами, IMHO конечно же, но думаю что недалек от истины) + излагаю последовательность, приведенную там
В основном, пытаюсь выловить что-то новое в проектном управлении, чего до PMBoK 2008 не видели, или от него не ожидалось вообще. Впереди ещё будут прототипы, я их с нетерпением жду. Из опыта и из HBR - это очень важная деталь любого проекта.
А какую систему бы хотелось?
-
23.04.2009, 09:18 #6
- Регистрация
- 25.11.2005
- Сообщений
- 1,731
Сообщение от Еремченко Сергей
Не требуйте многого от инициативы постующего. Выстраивайте систему у себя, на основе его информации.
Андрей просто фиксирует увиденные им основные отличия от предыдущего, третьего классического издания PMBOK 2004 года.
Андрей, продолжайте, лично мне это важно.
-
23.04.2009, 11:28 #7
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Давайте уточним...
Сообщение от Andruxa
То, что "выловите" ценное для Вас, может не подойти для других, или оказаться неполным. Так что лентяям придется самим читать РМВоК, а не ждать от Вас дайджест, или цитатник.
Проект, проекту - рознь. Слишком они разные бывают, а PMBoK - сборник всяких правил, но горе тому, кто попытается применить ВСЕ правила РМВоК в проекте "покупка батона хлеба, по дороге с работы".
А ведь это тоже проект.
С уважением Виталий.
-
23.04.2009, 12:08 #8
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Сообщение от eliferov
Проект, проекту - рознь. Слишком они разные бывают, а PMBoK - сборник всяких правил, но горе тому, кто попытается применить ВСЕ правила РМВоК в проекте "покупка батона хлеба, по дороге с работы".
А ведь это тоже проект.
С уважением Виталий.
Мне нравится сам процессный его подход (в IPMA скажем не так всё строится), + деление на области знаний. В общем, это просто большой качественный интересный стандарт, для меня скорее даже книжка. Еще важна помимо подхода - сама терминология. Которой я тоже делюсь, в своём правда корявом переводе.
-
23.04.2009, 12:27 #9
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Да, кстати, в стандарте так и сказано:
Good practice means there is a general agreement that the application of those project management processes has been shown to enhance the chances of success over a wide range of projects. This is does not means that the knowledge, skills and processes should always be applied uniformly on all projects. For any given project, the project manager, in collaboration with the project team, is always responsible for determining which processes are appropriate, and the appropriate degree of rigor for each process.
Как всегда - всё на совести читающего и применяющего. Но для меня это показалось столь известным, это было и в прошлом, что я не стал останавливаться подробно на этом.
Главное - процессы и их выходы. Кстати первые три главы - это самая основа для всего остального. Всё остальное строится в PMBoK на том, что описано и представляет собой лишь детальное описание процессов - как их выполнять, с помощью какого инструментария. Вот этот инструментарий тоже составляет (мой) интерес.
-
23.04.2009, 13:59 #10
- Регистрация
- 22.11.2005
- Сообщений
- 315
Сообщение от Евгений_Кс
-
23.04.2009, 15:36 #11
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Сообщение от Еремченко Сергей
-
23.04.2009, 23:20 #12
-
23.04.2009, 23:46 #13
- Регистрация
- 10.02.2009
- Сообщений
- 1,257
Сообщение от Bend
-
24.04.2009, 12:31 #14
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Если системно излагать - то получится сам PMBoK
Завтра продолжу...
-
25.04.2009, 17:05 #15
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Глава четвертая - Управление интеграцией
Подход следующий: управление интеграцией проекта включает в себя процессы и работы по идентификации, определению, объединению, унификации и координации различных процессов и работ по управлению проектом различных групп управления проектом.
В принципе, процессов этой области знаний уже достаточно для управления проектом
Включает в себя следующие процессы: разработка устава проекта, разработка плана управления проектом, управление исполнением проекта (выходы - deliverables), мониторинг хода выполнения, управление изменениями, закрытие проекта или фаз.
Надо отметить, что картинки, сопутствующие описаниям процессов стали лучше - стала отображаться связь со всеми связанными процессами. Это большой плюс нового PMBoK.
По большей части, ничего нового, но на чем хотелось бы остановиться. По прежнему, устав - это то, что инициирует проект, в качестве одного из входов выделяется:
Statement of Work (положение о выполнении работ):
- "Бизнес-потребность" (Business need) - то, что инициирует проект со стороны бизнеса,
- Описание содержания,
- Стратегический план (Strategic plan). "Все проекты должны поддерживать организационные стратегические цели", стратегический план выполняющей проект организации должен рассматриваться как фактор при принятии решений по выбору и приоритезации проектов.
Больше ничего хоть сколько-нибудь волнующего (IMHO конечно) в данной главе не встретил. Всё тот же подход, всё то же управление интеграцией.
-
25.04.2009, 20:55 #16
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
-
26.04.2009, 18:29 #17
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Глава 5 - Управление содержанием
Управление содержанием проекта включает процессы, необходимые для уверенности в том, что проект включает все необходимые работы (и только их) для достижения успеха проекта.
Процессы этой области знаний: сбор требований, определение содержания, создание СРР (структуры разбиения работ), проверка содержания, управление содержанием.
Это глава концептуально интересная сама по себе, и очень важная для проектов. Сразу же указывается на различие между содержанием продукта и содержанием проекта, что их необходимо разделять, первое - описание продукта, второе - это работы по выполнению проекта.
Самое интересное - это инструменты для сбора требований.
В качестве таких инструментов выделяются
- интервью - стандартно и привычно,
- фокус-группы! интересно и свежо,
- воркшопы - группы по разработке,
- техники групповой работы (брэйнстормы, делфи, майнд-мэппинг! и др.)
- групповое принятие решений,
- опросники и опросы,
- наблюдение... говорят ещё также job shadowing, что показывает как оно должно происходить
- прототипы. говорят, удобно для быстрого получения обратной связи от стэйкхолдеров. более того, сразу говорится что прототипы поддерживают концепцию progressive elaboration - итеративной разработки.
update Также сказано что важно разграничивать как то, что входит в содержание, так и ясно проговаривать то, что не входит.
Насчет определения содержания и составления WBS - всё то же самое (только про WBS появились примеры). Интересная штука - Verify Scope. Это проверка того соответствует ли продукт изначально заявленным требованиям (выполняет после проверки качества). Отличается от контроля качества, потому что контроль качества направлен (по PMBoK) на проверку соответствия продукта требованиям по качеству, но не по содержанию продукта.
Ну и последний процесс - Control Scope. Очень интересно и по-моему, вполне достаточно, про него сказано: uncontrolled changes are often reffered to as project scope creep. Короче говоря, если содержанием не управлять, то оно расползётся
Интересная глава вобщем, рекомендую к прочтению. Кстати, по прочтению этой главы промелькнула мысль - процессы-то все несложные, и не так уж сложно подходящей автоматизацией добиться их выполнения (всех). Достаточно даже по абзацу текста ввести на каждый процесс, чтобы утверждать полную поддержку PMBoK. То есть принципиально это реализуемо... на практике -- требует обоснования необходимости введения каждого дополнительного процесса.Последний раз редактировалось Andruxa; 27.04.2009 в 10:23.
-
28.04.2009, 07:23 #18
- Регистрация
- 25.11.2005
- Сообщений
- 1,731
Сообщение от Andruxa
Если же осталась - поясните.
Как это автоматизацией добиться от людей выполнения? Под дулом автомата что ли?
Спасибо за презентацию различий между буками, и за наводку на блог К. Трунина.
-
28.04.2009, 07:46 #19
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Сообщение от Евгений_Кс
Да и вообще, чтобы это структурированно выглядело, все документы по проекту оформить в виде электронных форм. Это удобно по-моему. Я кроме MS Project других КСУП не знаю, наверняка в какой-нибудь Primavera так и делается.
-
28.04.2009, 09:14 #20
- Регистрация
- 25.11.2005
- Сообщений
- 1,731
Не годится.
Так Вы можете добиться легкого , но, увы, формального исполнения чего угодно.
-
28.04.2009, 09:19 #21
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Хм... PM'ы должны обладать какими-то знаниями предварительно, проникнуться пониманием значимости выполнения процессов, иметь целостную картину. А иначе это будет свалка, согласен.
-
29.04.2009, 10:53 #22
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Глава 6 - управление расписанием.
Честно говоря, эта глава показалась мне скучной - вообще-то ничего нового.
Процессы: определение работ, определение порядка выполнения работ, оценка ресурсов работ, оценка длительностей работ, разработка расписания, управление расписанием.
Из интересного - так это картинки. Их стало больше, они стали нагляднее. Хотелось бы также обратить внимание на такой момент, как атрибуты работ. Они появляются в результате процесса определения работ (тесно пересекающегося с составлением WBS), и эти атрибуты служат входами для остальных процессов.
Также более подробно освещено планирование набегающей волной - rolling wave planning, как техника определения работ. Утверждается, что можно при progressive elaboration детализировать пакеты работ не сразу, и лишь по достижении этих самых пакетов. Что, в общем-то, стандартный приём того же Agile.
Интересно расписано про определение зависимостей процесса определения порядка выполнения. Предлагают три типа зависимостей - обязательные (mandatory), зависимости по усмотрению (discretionary) и внешние (external). Также говорится и про то, что при определении последовательности, можно применять шаблоны. Так, например, Most Valuable Specialist в Microsoft Project с сайта microsoftproject.ru (запямятовал имя-фамилию) в своём видео MS Project за 100 минут утверждает, что шаблоны - очень нужная для корпоративной проектной деятельности вещь. Мол, без шаблонов и MS Project не очень ценен. Наверное, он прав, хотя я никогда шаблоны не использовал - всё всегда с нуля.
Исчез метод PERT. В разработке расписания помимо critical path method указан ещё critical chain method (по-моему, это Голдраттовское). Если честно - о чем это, я не врубился. Кто пояснит - тому большое спасибо! Как я понял, так это тот же критический путь, только с учетом доступности ресурсов и "выдачей" буферов работам не на критическом пути для "утряски" ресурсов. Как-то так...
После прочтения главы осталось впечатление, да и вообще оно уже давно есть - что PMBoK - не что иное, как очень детальное разбиение обычных работ по проекту. Практически все описанные действия в том или ином виде - пусть не со всем доступным инструментарием - но выполняются в проектах. А PMBoK просто явно их описывает, конкретизирует.
-
29.04.2009, 12:10 #23
- Регистрация
- 25.11.2005
- Сообщений
- 1,731
Сообщение от Andruxa
Есть книжка в Сети на русском языке:
Э. Голдратт. Критическая цепь.
Это применение ТОС к Управлению проектами.
-
29.04.2009, 13:16 #24
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Спасибо! Нашел тут описание.
http://result.by/pages/novoe-v-uprav...proektami.aspx
Там заодно про инфороботы какая-то... еретическая концепция
И всё-то они умеют, и всё-то они знают, и когда надо - напомнят.
Не верю :/
-
29.04.2009, 21:45 #25Сообщение от Andruxa
Это один из тех случаев, когда лучше не прочитать вообще. И по "Критической цепи" не нужно изучать CCPM, но там хоть Голдратт пишет, нет мути от непонимания.
НЕ НАДО ИЗУЧАТЬ ТЕОРИЮ ОГРАНИЧЕНИЙ ПО БИЗНЕС-РОМАНАМ, и по самопальным статьям. Есть куча специальной литературы, тем более, что Вы читаете по английски.
-
30.04.2009, 00:00 #26
- Регистрация
- 10.02.2009
- Сообщений
- 1,257
То: Andruxa
Андрей!
С интересом читаю Ваш обзор РМВоК!
Скажите, с какими программами по управлению проектами Вы работаете?
-
30.04.2009, 04:45 #27
- Регистрация
- 10.04.2009
- Сообщений
- 20
Сообщение от Andruxa
-
30.04.2009, 06:05 #28
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Да, по бизнес-романам TOC изучать не очень. У меня после Deadline ничего в голове не осталось, кроме счастливой концовки и утопического начала. Но у меня есть Деттмер! И я на него лето своё потрачу.
Насчет программ. Я работал с Project Expert - не по работе, по собственным проектам, по работе работал с MS Project (в общем и в целом, не так уж с ним всё и плохо при коллективной работе). Сейчас работаю в компании, в которой используют скорее issue tracking, который более удобен для Agile-процессов, нежели Project. Скажем так, управлять бюджетом лучше в Project, поручениями - в issue-tracking-системах.
-
30.04.2009, 07:39 #29
- Регистрация
- 25.11.2005
- Сообщений
- 1,731
Сообщение от Георгий Лейбович
У бизнес-романов - своя цель и своя ниша. Они дают первоначальное, общее и, что важно, эмоциональное впечатление о предмете. Как аннотация к книге или трейлер к фильму.
Если человек чтением бизнес-романа не начинает, а заканчивает изучение предмета, это не значит, что бизнес-романы вредны.
Ну, а первоисточники, тем более на английском - святое дело. (лично Георгию) Даже если некоторые говорят, что It is hard to teach an old dog tricks
-
30.04.2009, 09:17 #30Сообщение от Andruxa
Кроме того, у меня есть в электронном виде большая статья Деттмера о стратегическом менеджменте, а может и две.
Успехов,
Георгий