Бесплатный фрагмент - Как сдать экзамен PMP (Project Management Professional)

От автора

На момент написания книги я имею более, чем 13-ти летний практический опыт управления проектами и внедрения систем управления в разных сферах бизнеса (ИТ, производство, строительство, розница, медиа, логистика, фармацевтика, сделки по слиянию и поглощению, инновации и т.д.). В роли Руководителя проекта я успешно реализовал более 100 проектов различного объема и сложности.

В этой книге я расскажу о том, как готовился к сдаче экзамена PMP (Project Management Professional, PMI), с какими сложностями столкнулся, почему не сдал с первого подхода. Дам советы как быстро и правильно подготовиться, что нужно изучать, а на что не стоит тратить время.

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

Книга будет полезна как для опытных Руководителей проектов, так и для тех, кто только планирует пойти по этому сложному и тернистому пути.

Андрей Береговенко, PMP (Project Management Professional, PMI)

Регистрация и заполнение профиля на сайте PMI

На механике заполнения останавливаться не буду, это описано в куче источников. Требования к кандидатам на прохождение экзамена тоже подробно описаны, в том числе и на сайте PMI.

Что действительно интересно — это верификация представленной вами информации. Она осуществляется рандомно, тут уж как повезет. Меня не верифицировали, но знакомые рассказывали, что их информацию проверяли. Звонили контактам, которые указаны в профиле, задавали вопросы по опыту управления проектами и о стаже, собственно основные требования PMI.

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

Заполняйте профиль самостоятельно, даже если у вас слабый английский. Благо он-лайн переводчиков предостаточно. Там все просто. Не ведитесь на предложения «профессионалов», которые за небольшие деньги готовы заполнить профиль за вас.

Когда профиль заполнен — ждем до 30 дней, пока проходит проверка и проверяем почту в надежде получить разрешение на экзамен.

Подготовка к экзамену

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

Скажу сразу, что с первого раза я экзамен не сдал.

Моя наивность, не повторяйте ошибок.

Изначально, получив подтверждение и разрешение пройти экзамен, я оплатил его (не дешевое удовольствие, особенно с курсом доллара) и запланировал дату, отведя полтора месяца на подготовку, что мне казалось вполне достаточным промежутком времени на подготовку. Ведь я профи, сделал сотни проектов, внедрил десятки корпоративных систем управления проектами, прошел тысячи реальных кейсов в бою и т. д. А полистать PMBoK и освежить в памяти области знаний и процессы особого труда и времени не составит. Пару часов в неделю по выходным будет с головой — думал я. Плюс купил подписку на онлайн тренажер для подготовке к сдаче PMP от одной известной российской консалтинговой компании. Многие рекомендуют готовиться в мини группе, наверно, это реально эффективно, но партнеров я себе не нашел.

Что в итоге?

PMBoK проштудировал, даже сделал для себя краткое изложение данного творения (этому посвящена отдельная глава данной книги). Онлайн тренажер прошел вдоль и поперек, даже нашел несколько ошибок в вопросах и ответах, о чем сообщил разработчикам, доказал свою правоту и ошибки оперативно поправили.

Сдача экзамена

В назначенный день с уверенностью направился в Prometric, это сертифицированный центр для сдачи, в том числе, и экзамена PMP (да, изначально заказал дублирование вопросов на русском языке и PMBoK тоже читал в русском переводе). При входе в центр попросили все вещи положить в локкер (шкафчик с замком) до окончания экзамена, даже тряпку для протирки очков не дали взять с собой. Перед входом в аудиторию обыскали, попросив поднять рукава и штанины. Зал утыкан камерами и общего ракурса и те, которые смотрят тебе в монитор и в ваши честные глаза.

Экзаменационные вопросы были совсем не по PMBoK и не по тому тренажеру, который я заизучал вдоль и поперек. В основном вопросы были ситуационные и на метематические расчеты. До 150-го вопроса из 200 возможных я даже не дошел.

Как итог — экзамен был провален.

Совет — не изучайте подробно PMBoK, достаточно будет основ, например, моего краткого изложения. Очень осторожно подходите к выбору он-лайн тренажеров, часто они не имеют ничего общего с экзаменом. Вопросы на экзамене носят не теоретический, а практический ситуационный характер + много вопросов на математические расчеты (калькулятор выдают орги экзамена). Не вздумайте списывать, забанят пожизненно. Хотя и списывать то особо нечего, теоретических вопросов крайне мало.

Второй подход к снаряду — подготовка

После неудачной сдачи, есть возможность платной пересдачи (дешевле, чем первая попытка, но все-равно сумма внушительна и не забываем про курс доллара).

Собственно этой платной второй попыткой я и воспользовался, при этом категорически пересмотрел подход к подготовке. Изучив интернеты я решил положить в основу подготовки книгу Риты (Rita Mulcahy). Она была одним из составителей вопросов к экзамену и по ее книге готовились и готовятся практически все претенденты на PMP сертификат.

Сложность заключалась в том, что книга на английском языке. Мой уровень не позволял мне готовиться по первоисточнику. Нужен был или перевод или быстро повышать уровень английского. Хороший был бы наверно кейс на этой книги и прокачать английский, но это было бы очень долго и утомительно. Таким временем, да и желанием, я не располагал. Поэтому приступил к поиску перевода. Тогда это было очень не просто, но в итоге я нашел перевод, правда очень и очень корявый. Но это все-равно была победа (краткое изложение книги Риты в отдельной главе).

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

Какие понятия вам нужно досконально изучить и понять как это работает в реальных условиях:

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

— Роли менеджера проекта, спонсора и команды.

— Историческая информация от предыдуших проектов.

— Накопленные знания от предыдущих проектов.

— Сохранение накопленных знаний по вашему проекту.

— Устав проекта.

— Что такое иерархическая структура работ (не список в графике) и как ее разработать.

— Как вручную создать сетевую диаграмму.

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

— Трехточечная оценка.

— Метод Монте-Карло.

— Освоенный объем.

— Уплотнение графика, сжатие, сокращение сроков выполнения проекта за счет совмещения работ.

— Управление временным резервом.

— Выполнимый график (невыполнимый график — вина менеджера проекта).

— Процесс управления рисками проекта (управление рисками — не просто использование контрольной карты).

— Ожидаемая денежная стоимость.

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

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

— Осуществлять контроль над проектом в соответствии с планом управления проектом.

— Управление процессом запроса на изменение.

— Контроль над изменениями.

— Профессиональная и социальная ответственность менеджера проекта

Вот очень важный перечень PMI-змов

Общие PMI — змы (базовые принципы):

1. Менеджеры проектов могут спасти планету, они «чудесные» и «замечательные», и должны быть очень опытными (тема «Да здравствует проектный менеджмент!»).

2. Менеджер проекта ставит интересы проекта выше своих собственных интересов.

3. На экзамене задаются вопросы с точки зрения больших проектов. Таким образом, менеджер проекта работает над большим проектом, который включает в себя 200 человек из многих стран, длится по крайней мере один год, никогда раньше не выполнялся в организации, и его бюджет составляет 100 миллионов долларов США или выше.

4. Менеджеры проектов держат всю власть и в реальности выполняют все операции, как описано в руководстве PMBOK.

5. Менеджер проекта назначается во время инициации проекта, а не позже.

6. Менеджер проекта понимает процесс управления проектом: например, что делать сначала, потом и т. д. и для чего! (Смотрите таблицу процессов и игру процессов в главе «Процессы управления проектом»).

7. Менеджер проекта всегда знает почему ее/его проект был выбран руководством и убеждается, что те цели соблюдены во время планирования и управления проектом.

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

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

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

11. У организации есть записи (историческая информация) от всех предыдуших проектов, которые включают в себя пакеты работ, стоимость каждого пакета работ, и какие риски не были выявлены (сейчас относится к руководству PMBOK в качестве активов процесса организации). Менеджер проекта использует записи из предыдуших проектов для планирования текущего проекта.

12. Менеджер проекта работает в сушествуюших системах и культуре компании (факторы среды предприятия), и один из результатов проекта — предоставить вход к улучшению этих систем.

13. Иерархическая структура работ (ИСР) используется в каждом проекте.

14. План управления проектом — не просто гистограмма, но серия планов управления. Менеджер проекта знает, что входит в разработку настоящего плана управления проектом.

15. Менеджер проекта разрабатывает другие документы (проектные документы) в добавление к плану управления проектом для помощи в планировании, управлении и контроля проекта.

16. Заинтересованные стороны принимают участие на протяжении всего проекта. Их нужды принимаются во внимание во время планирования проекта и разработки плана управления коммуникациями. Они также могут помочь в определении рисков и их управлении.

17. Людям должна быть предоставлена компенсация за работу. (Я серьезно; такой вопрос появился на экзамене).

18. PMI не одобряет дополнительные услуги (добавление сверх функциональности).

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

Планирование проекта.

20. Планирование очень важно, все проекты должны быть спланированы.

21. Менеджер проекта планирует проект не самостоятельно, а с помощью команды и заинтересованных сторон.

22. В часть планирования входит решение какие процессы из руководства PMBOK должны использоваться в каждом проекте.

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

24. Если возможно, вся требуемая работа и заинтересованные стороны проекта определяются перед началом проектной работы.

25. Менеджер проекта определяет метрики для измерения качества.

26. У менеджера проекта есть план для постоянного усовершенствования процессов.

27. Менеджер проекта разрабатывает систему поощрения членов команды и зантересованных сторон.

28. Все роли и обязанности ЧЕТКО задокументированы и поручены отдельным личностям в проекте. Они могут включать в себя отчет об обязанностях, передачу управления рисками, посещение собраний, так же как и проектную работу.

29. Так как проект никогда раньше не выполнялся в организации, менеджер проекта полностью концентрируется на выявлении рисков.

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

31. Менеджер проекта понимает, что управление рисками экономит время и деньги проекта.

32. Расписание и стоимость проекта не могут определиться без завершения управления рисками.

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

34. Менеджер проекта планирует когда и как измерять исполнение в соответствии с базовым планом измерения исполнения, как указано в плане управления проектом, но у него/нее также есть другие меры измерения для определения уровня исполнения проекта во время проведения работы.

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

36. Определение установочной встречи на экзамене может отличаться от вашего понимания того, что такое установочная встреча (Смотрите главу «Управление интеграцией проекта»).

В течение проекта:

37. Проект управляется в соответствии с планом управления проектом.

38. Менеджер проекта осуществляет измерения в соотетствии с планом управления проектом, чтобы помочь в определении статуса проекта на протяжении жизни проекта.

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

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

41. Менеджер проекта обладает полномочиями и властью. Он/она может сказать «нет» и контролирует проект в пользу заказчика.

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

43. У менеджера проекта достаточно данных о проекте для этого анализа. Менеджер проекта осознает, что, с течением времени, не у всех, вовлеченных в проект, будет одинаковое понимание того, каким должен быть проект и что должно происходить в течение жизни проекта. Таким образом, менеджер проекта постоянно следит за тем, чтобы все знали что происходит и имели соответствующие ожидания.

44. Менеджер проекта знает и принимает всерьез обязанности человеческих ресурсов в проекте.

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

46. Менеджер проекта проактивен и обнаруживает проблемы на ранней стадии, ищет изменения и предотвращает проблемы.

47. Менеджер проекта больше фокусируется на предотвращении проблем, а не на их решении.

48. Для многих возникаюших проблем уже есть план управления рисками.

49. Риски — основная тема на каждом собрании команды.

50. Собрания не фокусируются на статусе (о котором можно узнать другими способами).

51. Все изменения в плане управления проектом проходят через процесс управления изменениями и интегрированный контроль за изменениями.

52. Менежер проекта следит за соблюдением организационной политики в проекте.

53. Менеджер проекта рекомендует улучшения к стандартам, политике и процессам исполняющей организации. Такие рекомендации ожидаемы и приветствуются руководством.

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

55. Качество должно проверяться перед завершением операции или пакета работ.

56. Менеджер проекта тесно сотрудничает с отделом по обеспечению качества/контролю качества при исполнении некоторых операций по качеству, которые обсуждались в руководстве PMBOK.

57. Менеджер проекта активно участвует в процессе закупок и помогает в управлении закупочной деятельностью.

58. Менеджер проекта понимает язык контракта.

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

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

60. Менеджер проекта архивирует все проектные записи.

61. Ни один проект не считается завершенным, пока он окончательно не принят заказчиком.

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

И наконец, сдача экзамена — второй подход

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

Ответил на все 200 вопросов и даже успел вернуться к нескольким отложенным. По внутренними ощущениям была уверенность что почти все вопросы я осилил, только по нескольким сомнения закрадывались. Но даже если сомнения подтвердились бы, то баллов мне все равно должно было хватить для сдачи экзамена.

И вот кульминация — после экзамена ты подходишь к администратору и он в онлайн запрашивает твои результаты со стороны PMI и сразу дает ответ прошел или нет, странно, но расшифровок что правильно, а что нет, не дают, только успешный или не успешные проценты по областям знаний.

УРА, экзамен сдан успешно, практически со 100% попаданием по каждой из области знаний. Через 2—3 недели оригинал сертификата пришел на почту и дубль электронного — на email.

Удачи на экзамене!

Краткое изложение PMBok

Введение

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

Проект может создать:

— продукт, представляющий собой компонент другого изделия, улучшение изделия или конечное изделие;

— услугу или способность предоставлять услугу (например, бизнес-функция, поддерживающая производство или дистрибуцию);

— улучшение существующей линейки продуктов или услуг (например, проект по методике «шести сигм» (Six Sigma), предпринятый для уменьшения дефектов);

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

Управление проектом — это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Управление проектом осуществляется посредством надлежащего применения и интеграции логически сгруппированных 47 процессов управления проектом, объединенных в 5 групп процессов. Эти 5 групп процессов следующие:

— инициация,

— планирование,

— исполнение,

— мониторинг и контроль,

— закрытие.

Ограничений проекта:

— содержание,

— качество,

— расписание,

— бюджет,

— ресурсы,

— риски.

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

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

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

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

Управление программой уделяет основное внимание взаимозависимостям проектов и помогает определить оптимальный подход к управлению ими.

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

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

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

Офис управления проектами (ОУП) — организационная структура, стандартизирующая процессы руководства проектами и способствующая обмену ресурсами, методологиями, инструментами и методами. Сфера ответственности ОУП может варьироваться от оказания поддержки в управлении проектами до прямого управления одним или более проектами.

В организациях существует несколько типов структур ОУП, каждый из которых различается степенью контроля и влияния, оказываемого на проекты внутри организации, а именно:

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

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

— Руководящий. Руководящие ОУП контролируют проекты путем непосредственного управления данными проектами. Степень контроля со стороны ОУП высокая.

Основная функция ОУП заключается в поддержке руководителей проектов различными способами, которые могут включать в себя, среди прочего:

— управление общими ресурсами всех проектов, администрируемых ОУП;

— определение и разработка методологии, лучших практик и стандартов управления проектами;

— коучинг, наставничество, обучение и надзор;

— мониторинг соответствия стандартам, политикам, процедурам и шаблонам управления проектами посредством аудитов проектов;

— разработка и управление политиками, процедурами, шаблонами проекта и другой общей документацией (активами процессов организации);

— координация коммуникаций между проектами.

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

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

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

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

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

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

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

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

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

Компетенции РП:

— Компетенции в знаниях — то, что руководитель знает об управлении проектом.

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

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

Навыки РП:

— лидерство,

— укрепление командой,

— мотивация,

— коммуникация,

— влияние,

— принятие решений,

— политическая и культурная осведомленность,

— переговоры,

— построение доверительных отношений,

— урегулирование конфликтов,

— коучинг.

Влияние организации и жизненный цикл проекта

Активы процессов организации — это планы, процессы, политики, процедуры и базы знаний, специфичные для исполняющей организации и используемые ей. Они включают в себя любые артефакты, методы и знания некоторых или всех организаций, участвующих в проекте, которые могут быть использованы для исполнения или руководства проектом. Кроме того, активы процесса включают базы знаний организации, такие как извлеченные уроки и историческую информацию. Активы процессов организации могут включать в себя завершенные расписания, данные о рисках и данные об освоенных объемах. Активы процессов организации являются входами для большинства процессов планирования. На протяжении проекта члены команды могут обновлять и дополнять активы процессов организации по мере необходимости. Активы процессов организации могут быть разбиты на две категории:

— процессы и процедуры

— корпоративная база знаний

Факторы среды предприятия широко различаются по типу или характеру. Факторы среды предприятия включают в себя, среди прочего:

— организационную культуру, структуру и руководство;

— географическое распределение оборудования и ресурсов;

— государственные и промышленные стандарты (например, предписания контролирующих органов, кодексы поведения, стандарты на продукцию, стандарты качества, стандарты изготовления);

— инфраструктуру (например, существующие сооружения и основное оборудование);

— имеющиеся человеческие ресурсы (например, навыки, знания, специализации, такие как проектирование, разработка, юридические вопросы, заключение договоров и закупки);

— управление персоналом (например, руководящие указания по приему на работу и увольнению, анализ эффективности и результативности работы и записи об обучении персонала, политика вознаграждений и сверхурочной работы, а также учет рабочего времени);

— корпоративная система авторизации работ;

— ситуация на рынке;

— толерантность к риску заинтересованных сторон;

— политический климат;

— каналы коммуникаций, принятые в организации;

— коммерческие базы данных (например, стандартизированные сметные данные, данные изучения промышленных рисков и базы данных рисков);

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

Члены команды проекта выполняют следующие роли:

— Персонал, отвечающий за управление проектом. Члены команды, выполняющие операции управления проектом, такие как составление расписания, разработка бюджета, ведение отчетности и контроль, коммуникации, управление рисками и административная поддержка. Эту функцию может выполнять или поддерживать офис управления проектами (ОУП).

— Персонал проекта. Члены команды, которые выполняют работу по созданию поставляемых результатов проекта.

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

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

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

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

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

Жизненный цикл проекта — набор фаз, через которые проходит проект с момента его инициации до момента закрытия.

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

— начало проекта;

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

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

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

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

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

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

Адаптивные жизненные циклы (также известные как управляемые изменениями или гибкие (agile) методы) направлены на реагирование на высокие уровни изменений и требуют постоянной высокой степени вовлеченности заинтересованных сторон. Адаптивные методы являются также итеративными и инкрементными, но отличаются тем, что итерации происходят очень быстро (продолжительность обычно составляет 2–4 недели) и фиксированы по срокам и стоимости. В адаптивных проектах во время каждой итерации обычно выполняются несколько процессов, хотя ранние итерации могут больше концентрироваться на планировании операций. Общее содержание проекта разбивается на набор требований, а работа, которая должна быть выполнена, иногда называется бэклогом (журналом требований). В начале итерации команда определяет, сколько высокоприоритетных элементов из бэклога могут быть получены во время следующей итерации. В конце каждой итерации продукт должен быть готов для анализа заказчиком.

Процессы управления проектом

Управление проектом — это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Это приложение знаний требует результативного управления процессами управления проектом.

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

Процессы проекта можно разделить на две основные категории:

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

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

Процессы управления проектом разделяются на пять категорий, известных как группы процессов управления проектом (или группы процессов):

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

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

— Группа процессов исполнения. Процессы, применяемые для выполнения работ, указанных в плане управления проектом, с целью соответствия спецификациям проекта.

— Группа процессов мониторинга и контроля. Процессы, требуемые для отслеживания, анализа, а также регулирования исполнения проекта; выявления областей, требующих внесения изменений в план; и инициирования соответствующих изменений.

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

Группы процессов не являются фазами жизненного цикла проекта!

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

Следующие руководящие указания сводят к минимуму недопонимание и помогают команде проекта использовать надлежащую терминологию:

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

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

— Отчеты об исполнении работ. Физическое или электронное представление информации об исполнении работ, собранное в документах проекта, предназначенное для вынесения решений или формулирования проблем, выполнения действий или формирования осведомленности. Примеры включают отчеты о статусе, служебные записки, обоснования, информационные бюллетени, электронные информационные панели, рекомендации и обновления.

Описанные в Руководстве PMBOK® 47 процессов управления проектом разбиты на 10 отдельных областей знаний. Область знаний является всеобъемлющей системой понятий, терминов и действий, составляющих профессиональную область, область управления проектами или область деятельности. Эти 10 областей знаний практически постоянно используются в большинстве проектов. Команды проектов должны по мере необходимости использовать эти 10 областей знаний и другие области знаний для своего конкретного проекта. Области знаний включают в себя:

— управление интеграцией проекта,

— управление содержанием проекта,

— управление сроками проекта,

— управление стоимостью проекта,

— управление качеством проекта,

— управление человеческими ресурсами проекта,

— управление коммуникациями проекта,

— управление рисками проекта,

— управление закупками проекта,

— управление заинтересованными сторонами проекта.

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

Управление интеграцией проекта включает в себя процессы и операции, необходимые для определения, уточнения, комбинирования, объединения и координации различных процессов и операций по управлению проектом в рамках групп процессов управления проектом.

Устав проекта содержит:

— назначение или обоснование проекта;

— измеримые цели проекта и соответствующие критерии успеха;

— высокоуровневые требования;

— допущения и ограничения;

— высокоуровневые описание и границы проекта;

— высокоуровневые риски;

— укрупненное расписание контрольных событий;

— укрупненный бюджет;

— список заинтересованных сторон;

— требования к одобрению проекта (т. е. что именно составляет успех проекта, кто решает, что проект оказался успешным, и кто подписывает проект);

— назначенный руководитель проекта, сфера ответственности и уровень полномочий;

— Ф.И.О. и полномочия спонсора или другого лица (лиц), авторизующего (авторизующих) устав проекта.

Описание работ (statement of work, SOW) проекта — это словесное описание продуктов, услуг или результатов, которые должен произвести проект.

SOW отражает:

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

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

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

Бизнес-кейс

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

— требование рынка (например, автомобилестроительная компания авторизует проект по изготовлению более экономичных автомобилей в ответ на дефицит бензина);

— потребность организации (например, в связи с высокими накладными расходами компания может объединить функции персонала и оптимизировать процессы для сокращения затрат);

— требование заказчика (например, электрическая компания авторизует проект по строительству новой подстанции для электроснабжения нового промышленного района);

— технологический прогресс (например, авиакомпания авторизует новый проект по разработке электронных билетов для замещения билетов, отпечатанных на бумаге, основываясь на технологических достижениях);

— юридическое требование (например, производитель красок авторизует проект для разработки руководящих указаний по обращению с токсичными материалами);

— экологические воздействия (например, компания авторизует проект для уменьшения своего воздействия на окружающую среду);

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

Соглашения

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

Факторы среды предприятия

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

— государственные и промышленные стандарты или предписания (например, кодексы поведения, стандарты качества или стандарты по защите трудящихся);

— организационную культуру и структуру;

— ситуацию на рынке.

Активы процессов организации

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

— стандартные процессы организации, политики и описания процессов;

— шаблоны (например, шаблон устава проекта);

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

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

Базовые планы проекта включают в себя, среди прочего:

— базовый план по содержанию;

— базовое расписание;

— базовый план по стоимости.

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

— план управления содержанием;

— план управления требованиями;

— план управления расписанием;

— план управления стоимостью;

— план управления качеством;

— план совершенствования процессов;

— план управления человеческими ресурсами;

— план управления коммуникациями;

— план управления рисками;

— план управления закупками;

— план управления заинтересованными сторонами.

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

— выбранный для проекта жизненный цикл и процессы, которые будут применяться в каждой фазе;

— детали решений по адаптации, вынесенных командой управления проектом, а именно:

— процессы управления проектом, выбранные командой управления проектом;

— уровень реализации каждого выбранного процесса;

— описания инструментов и методов, которые будут использованы для выполнения данных процессов;

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

— порядок выполнения работ для достижения целей проекта;

— план управления изменениями, документирующий порядок мониторинга и контроля изменений;

— план управления конфигурацией, документирующий порядок управления конфигурацией;

— описание порядка поддержания целостности базовых планов;

— требования и методы коммуникации между заинтересованными сторонами;

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

Прогнозы в отношении расписания

Прогнозы в отношении расписания составляются с учетом прогресса относительно базового расписания и расчетного времени прогноза до завершения (ПДЗ). Они обычно выражаются в виде отклонения по срокам (ОСР) и индекса выполнения сроков (ИВСР). Для проектов, которые не используют управление освоенным объемом, указываются отклонения от запланированных и прогнозируемых дат финиша.

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

Прогнозы в отношении стоимости

Прогнозы в отношении стоимости составляются с учетом прогресса относительно базового плана по стоимости и расчетного прогноза до завершения (ПДЗ). Они обычно выражаются в виде отклонения по стоимости (ОСТ) и индекса выполнения стоимости (ИВСТ). Прогноз по завершении (ППЗ) можно сравнить с бюджетом по завершении (БПЗ), чтобы определить, находится ли проект в области допустимых значений, или необходимо составление запросов на изменения. Для проектов, которые не используют управление освоенным объемом, указываются отклонения от запланированных и фактических расходов, а также прогнозируемая окончательная стоимость.

Ниже приведены некоторые операции по управлению конфигурацией, входящие в процесс интегрированного контроля изменений:

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

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

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

Управление содержанием проекта

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

В контексте проекта термин «содержание» может обозначать:

— Содержание продукта. Свойства и функции, которые характеризуют продукт, услугу или результат.

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

Классы требований:

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

— Требования заинтересованных сторон, описывающие потребности заинтересованной стороны или группы заинтересованных сторон.

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

— Функциональные требования описывают поведение продукта. Примеры включают в себя процессы, данные и взаимодействия с продуктом.

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

— Требования к переходу описывают временные возможности, такие как требования к преобразованию данных и обучению, необходимые для перехода из текущего состояния «как есть» в состояние «как должно быть» в будущем.

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

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

Управление сроками проекта

Управление сроками проекта включает в себя процессы, необходимые для того, чтобы обеспечить своевременное выполнение проекта.

Типы зависимости операций:

— Финиш-старт (finish-start, FS). Логическая связь, при которой старт последующей операции зависит от финиша предшествующей операции. Пример: церемония награждения (последующая операция) не может быть начата, пока не закончится гонка предшествующая операция).

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

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

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

Оценка по трем точкам

Точность оценок длительности операций по одной точке может быть улучшена путем рассмотрения неопределенностей оценок и рисков. Данная концепция происходит из метода оценки и анализа программ (program evaluation and review technique, PERT). Для определения приблизительного диапазона длительности операции PERT использует три оценки:

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

— Оптимистичная (tO). Длительность операции основывается на анализе наиболее благоприятного сценария для операции.

— Пессимистичная (tP). Длительность операции основывается на анализе наиболее неблагоприятного сценария для операции.

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

Формулы:

— Треугольное распределение. tE = (tO + tM + tP) / 3

— Бета-распределение (из традиционного метода PERT). tE = (tO +4tM + tP) / 6

Метод критического пути

Метод критического пути — метод, используемый для оценки минимальной длительности проекта и определения степени гибкости расписания на логических путях в сети в рамках модели расписания. Метод анализа сети расписания позволяет рассчитать даты раннего старта и финиша, а также даты позднего старта и финиша для всех операций без учета ресурсных ограничений путем проведения анализа прямого и обратного прохода по сети проекта, как показано на рис. 6—18. В данном примере самый длительный путь включает в себя операции A, C и D, и поэтому последовательность A-C-D является критическим путем. Критический путь — это последовательность операций, представляющая собой самый длительный путь в расписании проекта, который определяет самую короткую возможную длительность проекта. Полученные даты раннего старта и финиша не обязательно являются расписанием проекта; они скорее указывают периоды времени, в рамках которых может быть выполнена операция, используя параметры, введенные в модель расписания, связанные с длительностью операций, логическими связями, опережениями, задержками и другими известными ограничениями. Метод критического

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

Метод критической цепи

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

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

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

Управление стоимостью проекта

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

Управление освоенным объемом

Управление освоенным объемом (EVM) — методология, сочетающая оценки содержания, расписания и ресурсов с целью измерения прогресса проекта и достигнутой эффективности. Это широко распространенный метод измерения исполнения проекта. Он объединяет базовый план по содержанию с базовым планом по стоимости, а также с базовым расписанием проекта, формируя базовый план исполнения, который позволяет команде управления проектом оценивать и измерять исполнение проекта и прогресс. Это метод управления проектом, который требует формирования интегрированного базового плана, относительно которого может измеряться исполнение на протяжении проекта. Принципы EVM могут применяться ко

всем проектам в любой отрасли. С помощью EVM разрабатывают и осуществляют мониторинг следующих трех ключевых показателей для каждого пакета работ и контрольного счета:

— Плановый объем. Плановый объем (ПО) — авторизованный бюджет, выделенный на запланированные работы. Это авторизованный бюджет, выделенный для работы, которую необходимо выполнить в рамках операции или компонента иерархической структуры работ, за исключением управленческого резерва. Данный бюджет распределяется по фазам в жизненном цикле проекта, но в определенный момент запланированный объем определяет физическую работу, которая должна была быть выполнена. Совокупный ПО иногда называется базовым планом исполнения (performance measurement baseline, PMB). Общая величина планового объема проекта также известна как бюджет по завершении (БПЗ).

— Освоенный объем. Освоенный объем (ОО) — объем выполненных работ, выраженный в показателях авторизованного бюджета, выделенного на данные работы. Это бюджет, связанный с авторизованной работой, которая была выполнена. Измеряемый ОО должен быть связан с PMB, и измеренный ОО не может превышать авторизованный бюджет ПО для данного компонента. ОО часто используется для вычисления процента выполнения проекта. Для каждого компонента ИСР должны быть установлены критерии измерения прогресса выполняемых работ. Руководители проектов осуществляют мониторинг ОО, как инкрементно для определения текущего статуса, так и кумулятивно для определения долгосрочных тенденций исполнения.

— Фактическая стоимость. Фактическая стоимость (ФС) — фактически понесенные затраты на выполнение работ в рамках операции за определенный период времени. Это общие затраты, понесенные при выполнении работ, измеренных ОО. ФС по определению должна соответствовать тому, что было заложено в ПО и измерено ОО (например, только прямые затраты рабочего времени, только прямые затраты или все затраты, включая косвенные). У ФС отсутствует верхняя граница; измеряется все, что расходуется для достижения ОО.

Также осуществляется мониторинг отклонений от одобренного базового плана:

— Отклонение по срокам. Отклонение по срокам (ОСР) — показатель исполнения расписания, выражаемый как разница между освоенным объемом и плановым объемом. Количество времени, на которое проект отстает от запланированной даты поставки или опережает ее в определенный момент времени. Это измерение исполнения расписания проекта. Значение его равно освоенному объему (ОО) за вычетом планового объема (ПО). Отклонение по срокам в методе EVM представляет собой метрику, полезную тем, что она демонстрирует, когда проект отстает по срокам от своего базового плана или когда он опережает его. Отклонение по срокам в EVM в конечном итоге будет равно нулю при завершении проекта, так как все плановые объемы к тому времени должны быть освоены. Отклонение по срокам лучше всего использовать вместе с составлением расписания по методу критического пути (CPM) и управлением рисками. Формула: ОСР = ОО — ПО

— Отклонение по стоимости. Отклонение по стоимости (ОСТ) — сумма дефицита или излишка бюджета в определенный момент времени, выражаемая как разница между освоенным объемом и фактической стоимостью. Это измерение эффективности выполнения проекта по стоимости. Оно равно освоенному объему (ОО) за вычетом фактической стоимости (ФС). Отклонение по стоимости в конце проекта будет равно разнице между бюджетом по завершении (БПЗ) и фактически израсходованной суммой. ОСТ чрезвычайно важно, так как оно демонстрирует связь между физическим исполнением и израсходованными средствами. Отрицательное ОСТ зачастую невозместимо для проекта. Формула: ОСТ = ОО — ФС.

Значения ОСР и ОСТ могут быть преобразованы в показатели эффективности для отражения выполнения стоимости и сроков любого проекта по сравнению со всеми другими проектами или в рамках портфеля проектов. Отклонения полезны для определения статуса проекта.

— Индекс выполнения сроков. Индекс выполнения сроков (ИВСР) — показатель эффективности расписания, выражаемый как соотношение освоенного объема к плановому объему. С помощью него измеряется, насколько эффективно команда проекта использует свое время. Иногда он используется вместе с индексом выполнения стоимости (ИВСТ) для прогнозирования окончательных оценок завершения проекта. Значение ИВСР меньше 1,0 указывает на то, что выполнено меньше работ, чем было запланировано. Значение ИВСР больше 1,0 указывает на то, что выполнено больше работ, чем было запланировано. Так как ИВСР измеряет все работы проекта, также необходимо проанализировать исполнение на критическом пути, чтобы определить, будет проект завершен до или после своей плановой даты финиша. ИВСР равен отношению ОО к ПО. Формула: ИВСР = ОО/ПО

— Индекс выполнения стоимости. Индекс выполнения стоимости (ИВСТ) — показатель эффективности ресурсов, включенных в бюджет, по стоимости, выражаемый как соотношение освоенного объема к фактической стоимости. Он считается наиболее важной метрикой EVM и измеряет стоимостную эффективность выполненной работы. Значение ИВСТ меньше 1,0 указывает на перерасход средств для выполненной работы. Значение ИВСТ больше 1,0 указывает на недоосвоение средств при исполнении на конкретную дату. ИВСР равен отношению ОО к ФС. Индексы полезны для определения статуса проекта, а также предоставляют основу для оценки итоговых сроков и стоимости проекта. Формула: ИВСТ = ОО/ФС

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

Прогнозирование

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

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

ППЗ обычно рассчитываются как фактическая стоимость, учтенная для завершенных работ, плюс прогноз до завершения (ПДЗ) оставшихся работ. На команду проекта возложена обязанность прогнозировать, с чем она может столкнуться во время выполнения ПДЗ, на основании имеющегося в данный момент опыта. Метод EVM хорошо работает вместе с прогнозами требуемого ППЗ, разработанными вручную. Наиболее широко используемым подходом прогнозирования ППЗ является ручное суммирование «снизу вверх», проводимое руководителем проекта и командой проекта.

Метод ППЗ «снизу вверх», используемый руководителем проекта, основан на учтенной фактической стоимости и опыте, полученном на выполненных работах, и требует построения нового прогноза до завершения в отношении оставшихся работ проекта. Формула: ППЗ = ФС + ПДЗ «снизу вверх».

ППЗ, разработанный вручную руководителем проекта, быстро сопоставляется с рядом рассчитанных ППЗ, представляющих разнообразные сценарии рисков. При расчете значений ППЗ, как правило, используются кумулятивные значения ИВСТ и ИВСР. Хотя данные EVM позволяют быстро получить множество статистических ППЗ, ниже описаны только три наиболее распространенных метода:

— ППЗ для работ ПДЗ, выполненных по заложенным в бюджет ставкам. Данный метод ППЗ использует фактическое исполнение проекта на конкретную дату (благоприятное или неблагоприятное), представленное фактической стоимостью, и предсказывает, что все будущие работы ПДЗ будут выполнены по заложенным в бюджет ставкам. В тех случаях, когда фактическое исполнение неблагоприятно, допущение, что будущее исполнение улучшится, должно быть принято только в том случае, если это подтверждается анализом рисков проекта. Формула: ППЗ = ФС + (БПЗ — ОО)

— ППЗ для работ ПДЗ, выполненных с текущим ИВСТ. Этот метод допускает, что проект продолжится в будущем так же, как он протекал до этого момента. Допускается, что работы ПДЗ будут выполняться на том же уровне кумулятивного индекса выполнения стоимости (ИВСТ), какой был достигнут в проекте к этому моменту. Формула: ППЗ = БПЗ/ИВСТ

— ППЗ для работ ПДЗ с учетом обоих факторов ИВСР и ИВСТ. В данном прогнозе работы ПДЗ будут выполняться с эффективностью, которая учитывает индексы выполнения как стоимости, так и сроков. Данный метод наиболее полезен в случае, когда одним из факторов, влияющих на ПДЗ, является расписание проекта. Вариации данного метода рассматривают ИВСТ и ИВСР в различных соотношениях (например, 80/20, 50/50 или в других пропорциях), в соответствии с мнением руководителя проекта. Формула: ППЗ = ФС + [(БПЗ — ОО) / (ИВСТ x ИВСР)]

Каждый из этих подходов может быть применен для любого конкретного проекта и подавать команде управления проектом сигнал «раннего предупреждения», если ППЗ выходят за рамки принятых допустимых вариаций.

Индекс производительности до завершения (ИПДЗ)

Индекс производительности до завершения (ИПДЗ) — расчетный показатель эффективности выполнения проекта по стоимости, который необходимо достичь с оставшимися ресурсами, чтобы добиться установленного управленческого показателя, выражаемого в виде отношения стоимости выполнения оставшейся части работ к оставшемуся бюджету. ИПДЗ представляет собой вычисляемый индекс выполнения стоимости, который необходимо обеспечить на оставшихся работах для достижения определенной управленческой цели, такой как БПЗ или ППЗ. Если становится очевидным, что БПЗ больше не является реалистичным, руководитель проекта должен рассмотреть ППЗ. После одобрения ППЗ может заменить БПЗ при расчете ИПДЗ. Формула для ИПДЗ, основанного на БПЗ: (БПЗ — ОО) / (БПЗ — ФС). ИПДЗ концептуально представлен на рисунке ниже. Формула для ИПДЗ показана в левом нижнем углу — оставшаяся работа (определена как БПЗ минус ОО), деленная на оставшиеся средства (которые могут рассчитываться либо как БПЗ минус ФС, либо как ППЗ минус ФС).

Если кумулятивный ИВСТ ниже базового плана (как показано на рисунке ниже), все будущие работы по проекту немедленно должны выполняться в соответствии с ИПДЗ (БПЗ) (что отражено в верхней линии рисунке ниже), чтобы оставаться в рамках авторизованного БПЗ. Суждение о том, является ли данный уровень исполнения достижимым, принимается на основе ряда соображений, включая риски, расписание и техническое исполнение. Этот уровень исполнения изображен в виде линии ИПДЗ (ППЗ). Формула для ИПДЗ, основанного на ППЗ: (БПЗ — ОО) / (ППЗ — ФС). Формулы EVM представлены в таблице ниже.

Анализ исполнения

Анализ исполнения предусматривает сравнение выполнения стоимости в динамике по времени, операций расписания или пакетов работ, по которым присутствует перерасход или недоосвоение бюджета, и оценок денежных средств, необходимых для завершения выполняемых работ. Если используется EVM, то определяется следующая информация:

— Анализ отклонений. Анализ отклонений при использовании в EVM — это разъяснение (причина, влияние и корректирующие воздействия) отклонений для стоимости (ОСТ = ОО — ФС), расписания (ОСР = ОО — ПО) и отклонения по завершении (ОПЗ = БПЗ — ППЗ). Наиболее часто анализируются отклонения по стоимости и по срокам. Для проектов, в которых не применяется управление освоенным объемом, может быть выполнен аналогичный анализ отклонений путем сравнения запланированной стоимости операции с фактической стоимостью операции для определения отклонений фактического исполнения проекта от базового плана по стоимости. Дальнейший анализ может быть выполнен для определения причины и степени отклонения от базового расписания и необходимых корректирующих воздействий или предупреждающих действий. Измерения выполнения стоимости используются для оценки величины отклонения от первоначального базового плана по стоимости. Важные аспекты управления стоимостью проекта включают в себя определение причины и степени отклонения относительно базового плана по стоимости и принятие решений о необходимости корректирующих воздействий или предупреждающих действий. По мере выполнения все большего объема работ процентный диапазон допустимых отклонений будет иметь тенденцию к уменьшению.

— Анализ тенденций. Анализ тенденций предполагает изучение данных об исполнении проекта с течением времени для определения того, улучшается или ухудшается исполнение проекта. Методы графического анализа ценны для понимания исполнения на конкретную дату и для сравнения с целевыми показателями дальнейшего исполнения в форме БПЗ в сравнении с ППЗ и в форме дат завершения.

— Исполнение освоенного объема. Исполнение освоенного объема предусматривает сравнение базового плана исполнения с фактическим выполнением сроков и стоимости. Если EVM не используется, то для сравнения выполнения стоимости используется анализ базового плана по стоимости относительно фактической стоимости выполненных работ.

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

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

Качество и сорт — это концептуально различные понятия. Качество как поставляемый выход или результат — это «степень соответствия совокупности присущих характеристик требованиям» (ISO 9000) [10]. Сорт как конструктивный замысел — это категория, присваиваемая поставляемым результатам, имеющим одно и то же функциональное назначение, но различные технические характеристики. Руководитель проекта и команда управления проектом отвечают за достижение компромиссных решений в отношении обеспечения требуемых уровней как качества, так и сорта. Уровень качества, который

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

В контексте достижения соответствия требованиям ISO современные подходы к управлению качеством стремятся минимизировать отклонения и достигать результатов, соответствующих определенным требованиям. Эти подходы признают важность следующих положений:

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

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

— Постоянное совершенствование. Цикл «планирование-выполнение-проверка-действие» (plan-do-check-act, PDCA) — модель, описанная Шухартом и усовершенствованная Демингом, — является основой для улучшения качества. Кроме того, инициативы по улучшению качества, такие как всеобщее управление качеством (Total Quality Management, TQM), методика «шести сигм» и совместное применение методики «шести сигм» и бережливого производства (Lean Six Sigma), могут улучшить качество управления проектом, а также качество продукта проекта. Среди моделей совершенствования процессов можно привести модель качества Малкольма Болдриджа, модель зрелости организационного управления проектами (Organizational Project Management Maturity Model, OPM3®) и комплексную модель производительности и зрелости (Capability Maturity Model Integrated, CMMI®).

— Ответственность руководства. Для достижения успеха требуется участие всех членов команды проекта. Тем не менее, руководство сохраняет за собой, в рамках ответственности за качество, соответствующую ответственность за предоставление подходящих ресурсов в соответствующем объеме.

— Стоимость качества (cost of quality, COQ). Стоимость качества — это общая стоимость работы над соответствием и работы над несоответствием требованиям, которая должна быть выполнена в качестве компенсационного усилия, поскольку при первой попытке выполнения этой работы существует потенциальная возможность, что какая-то часть требуемого объема работ может быть выполнена или была выполнена неправильно. Затраты на выполнение работ по обеспечению качества могут возникать на протяжении всего жизненного цикла поставляемого результата. Например, решения, принятые командой проекта, могут повлиять на операционные затраты, связанные с использованием выполненного поставляемого результата. Затраты, связанные с обеспечением качества после закрытия проекта, могут возникать в результате возвратов продуктов, претензий по гарантии и кампаний по отзыву продукции. Таким образом, вследствие временного характера проекта и потенциальной выгоды, которая может быть получена в результате снижения послепроектной стоимости качества, спонсирующие организации могут принять решение об инвестировании средств в улучшение качества продукта. Данные инвестиции, как правило, делаются в области работы над соответствием требованиям с целью предотвращения дефектов или снижения стоимости дефектов путем инспекции несоответствующих требованиям единиц продукции. Более того, вопросы, связанные с постпроектной COQ, должны решаться в процессе управления программой и управления портфелем, например офисы управления проектами, программами и портфелями должны применять соответствующие методы анализа, шаблоны и способы выделения финансовых средств для этой цели.

Семь основных инструментов качества

Семь основных инструментов качества, также известные в отрасли как инструменты 7QC, используются в контексте цикла PDCA для решения проблем, связанных с качеством. Рис. ниже представляет собой концептуальную иллюстрацию семи основных инструментов качества, которые включают в себя:

— Диаграммы причинно-следственных связей, также называемые диаграммами «рыбий скелет» или диаграммами Исикавы. Описание проблемы, расположенное в голове «рыбьего скелета», используется в качестве отправной точки для отслеживания источника проблемы до первопричины, требующей принятия мер. Описание проблемы, как правило, представляет собой изложение проблемы как недоработки, которую необходимо устранить, или цели, которую необходимо достигнуть. Поиск причин осуществляется путем изучения описания проблемы и поиска ответов на вопрос «почему» до тех пор, пока не будет идентифицирована первопричина, требующая принятия мер, или до тех пор, пока не будут исчерпаны все обоснованные возможности на каждой части рыбьего скелета. Диаграммы «рыбий скелет» часто оказываются полезными во время поиска связи нежелательных эффектов, рассматриваемых как особая вариация, с установленной причиной, в отношении которой команды проекта должны выполнить корректирующие воздействия для устранения данной особой вариации, обнаруженной на контрольной карте.

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

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

— Диаграммы Парето представляют собой вертикальные столбчатые диаграммы особой формы и используются для определения нескольких наиболее важных источников, вызывающих большинство эффектов проблемы. Категории, показанные на горизонтальной оси, представляют собой существующее распределение вероятностей, учитывающее 100% возможных наблюдений. Значение соответствующей частоты возникновения каждой обозначенной причины, показанной на горизонтальной оси, уменьшается вплоть до достижения источника по умолчанию, называемого «другое», который отвечает за неустановленные причины. Как правило, диаграмма Парето организована по категориям, измеряющим либо частоту возникновения, либо последствия.

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

— Контрольные карты используются для определения того, является ли процесс стабильным или нет и характеризуется ли он предсказуемым исполнением. Нижние и верхние границы, заданные спецификацией, основаны на требованиях, закрепленных в соглашении. Они отражают максимальные и минимальные допустимые значения. Могут налагаться штрафы, связанные с выходом значений за границы, заданные спецификацией. Верхняя и нижняя контрольные границы отличаются от границ, заданных спецификацией. Контрольные границы устанавливаются с использованием стандартных статистических расчетов и принципов с целью окончательного определения естественной возможности стабилизации процесса. Руководитель проекта и соответствующие заинтересованные стороны могут использовать статистически рассчитанные контрольные границы для определения точек, в которых будут предприниматься корректирующие воздействия с целью предотвращения неестественного исполнения. Целью корректирующего воздействия, как правило, является сохранение естественной устойчивости стабильного и действенного процесса. Для повторяющихся процессов контрольные границы обычно составляют ± 3 сигмы от среднего значения процесса, которое было установлено на 0. Процесс считается вышедшим из-под контроля в том случае, если: (1) точка данных находится вне контрольных границ; (2) семь последовательных точек находятся выше средней линии; или (3) семь последовательных точек находятся ниже средней линии. Контрольные карты могут быть использованы для контроля различных типов выходных переменных. Хотя наиболее часто контрольные карты используются для отслеживания повторяющихся операций, требуемых для производства промышленных изделий, они также могут использоваться для контроля отклонений по стоимости и расписанию, объема и частоты изменений содержания или иных управленческих результатов, что помогает определить, находятся ли процессы управления проектом под контролем.

— Диаграммы разброса — это нанесенные на график упорядоченные пары (X, Y), иногда называемые графиками корреляций, поскольку они используются для объяснения изменения в зависимой переменной, Y, относительно изменения, наблюдаемого в независимой переменной, X. Направление корреляции может быть пропорциональным (положительная корреляция), обратным (отрицательная корреляция), либо корреляционной модели может не существовать (нулевая корреляция). Если корреляция может быть установлена, можно определить линию регрессии и использовать ее для оценки того, каким образом изменение независимой переменной изменит значение зависимой переменной.

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

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

— Диаграммы сходства. Диаграмма сходства подобна методу построения ассоциативных карт, так как она используется для генерирования идей, которые могут быть объединены с целью формирования упорядоченного образа мыслей о проблеме. В процессе управления проектом создание ИСР может быть улучшено путем использования диаграммы сходства для придания структуры декомпозиции содержания.

— Диаграммы процесса осуществления программы (process decision program charts, PDPC). Используются для понимания цели относительно действий, предпринимаемых для достижения цели. PDPC — полезный метод для планирования с учетом возможных потерь, так как он помогает командам предвидеть промежуточные шаги, которые могут препятствовать достижению цели.

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

— Древовидные диаграммы. Также известные как систематические диаграммы, которые могут использоваться для отображения декомпозиции иерархий, таких как ИСР, иерархическая структура рисков (risk breakdown structure, RBS) и организационная структура работ (organizational breakdown structure, OBS). В процессе управления проектом древовидные диаграммы полезны для визуализации отношений типа «родитель — потомок» в любой иерархии декомпозиции, которая использует систематический набор правил для определения отношений подчиненности. Древовидные диаграммы могут быть горизонтальными (например, иерархическая структура рисков) или вертикальными (например, иерархия команды или OBS). Поскольку древовидные диаграммы делают возможным создание вложенных ответвлений, которые заканчиваются в одной точке принятия решения, они полезны в качестве деревьев решений для определения ожидаемой ценности ограниченного числа родственных отношений, систематически представляемых в виде диаграммы.

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

— Диаграммы сети операций. Ранее известные как стрелочные диаграммы. Они включают в себя такие форматы диаграммы сети, как операции на дугах (activity on arrow, AOA) и наиболее часто используемый формат операции в узлах (activity on node, AON). Диаграммы сети операций используются с методами составления расписания проекта, такими как метод оценки и анализа программ (PERT), метод критического пути (CPM) и метод диаграмм предшествования (PDM).

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

Управление человеческими ресурсами проекта

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

Организационные диаграммы и должностные инструкции

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

План управления человеческими ресурсами включает в себя, среди прочего:

— Роли и сферы ответственности. При перечислении ролей и сфер ответственности, необходимых для выполнения проекта, необходимо учитывать следующее:

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

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

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

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

— Организационные диаграммы проекта. Организационная диаграмма проекта — это графическое представление состава команды проекта и отношений подотчетности между ее членами. В зависимости от требований проекта она может быть формальной или неформальной, подробной или обобщенной. Например, организационная диаграмма проекта для команды реагирования на чрезвычайные ситуации, состоящей из 3 000 человек, будет значительно более подробной, чем организационная диаграмма внутреннего проекта с командой в 20 человек.

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

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

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

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

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

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

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

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

Одна из моделей, используемых для описания развития команды — это Tuckman ladder (Tuckman, 1965; Tuckman & Jensen, 1977), которая включает пять стадий развития, через которые должны пройти команды. Обычно эти стадии наступают по порядку, но нередко команда может «застрять» на определенной стадии или вернуться на более раннюю. В проектах, члены команд которых ранее работали вместе, определенные стадии могут быть пропущены.

— Формирование. На данной стадии команда собирается вместе и узнает о проекте и о своих формальных ролях и сферах ответственности в нем. Члены команды на данной фазе, как правило, независимы друг от друга и не особенно открыты.

— Шторм. В течение данной стадии команда начинает изучать работы по проекту, технические решения и подход к управлению проектом. Если члены команды не настроены на сотрудничество и не открыты различным идеям и перспективам, обстановка может стать непродуктивной.

— Урегулирование. На стадии урегулирования члены команды начинают работать вместе и подстраивают свои рабочие привычки и модели поведения так, чтобы содействовать командной работе. Члены команды учатся доверять друг другу.

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

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

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

Существует пять основных методов, используемых для разрешения конфликтов. Поскольку каждый из них имеет свое собственное предназначение и применение, методы приведены в произвольном порядке:

— Уклонение/избегание. Отступление от фактической или потенциальной конфликтной ситуации, перенос решения проблемы на более поздний срок, чтобы лучше подготовится к ее разрешению или передать ее разрешение другим лицам.

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

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

— Принуждение/указания. Лоббирование чьей-либо точки зрения за счет других, предлагая только решения «один выиграл — все проиграли», обычно со стороны позиции власти, чтобы разрешить критическую ситуацию.

— Сотрудничество/разрешение проблем. Объединение множества точек зрения и взглядов с различных перспектив, необходимость в готовности к сотрудничеству и открытому диалогу, которая обычно приводит к достижению консенсуса и поддержанию решения всеми сторонами.

Примеры навыков межличностного общения, которые наиболее часто использует руководитель проекта, включают в себя:

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

— Влияние. Поскольку руководители проектов зачастую обладают лишь незначительными прямыми полномочиями в отношении членов своих команд в матричных условиях или вовсе не обладают таковыми, их способность своевременно оказывать влияние на заинтересованные стороны проекта является критически важной для успеха проекта. Ключевые навыки оказания влияния включают в себя:

— способность убедительно и четко излагать точку зрения и позицию;

— высокий уровень навыков активного и результативного выслушивания;

— понимание и рассмотрение различных перспектив в любой ситуации;

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

— Результативное принятие решений. Это подразумевает способность проведения переговоров и оказания влияния на организацию и команду управления проектом. Ниже представлены некоторые из рекомендаций в отношении принятия решений:

— необходимо сосредоточиться на целях, которые предстоит достичь;

— необходимо придерживаться процедуры принятия решений;

— необходимо изучать факторы среды;

— необходимо анализировать имеющуюся информацию;

— необходимо развивать личностные качества членов команды;

— необходимо стимулировать творческий подход команды к работе;

— необходимо управлять рисками.

Управление коммуникациями проекта

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

Факторы, которые могут оказывать влияние на выбор коммуникационных технологий, включают в себя:

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

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

— Простота использования. Необходимо удостовериться в том, что выбранные коммуникационные технологии подходят участникам проекта и что при необходимости запланированы соответствующие обучающие мероприятия.

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

— Секретность и конфиденциальность информации. Необходимо определить, является ли передаваемая информация секретной или конфиденциальной и требуется ли принять дополнительные меры для ее защиты. Также необходимо учесть наиболее подходящий способ передачи такой информации.

Базовая коммуникационная модель имеет следующую последовательность шагов:

— Кодирование. Преобразование (кодирование) мыслей или идей в кодовый язык отправителем.

— Передача сообщения. Отправка информации отправителем с использованием информационного канала (среды передачи информации). Передаче этого сообщения могут помешать различные факторы (например, расстояние, незнакомая технология, недостаточная инфраструктура, культурные различия и недостаток дополнительной информации). Эти факторы в совокупности называются шумом.

— Декодирование. Сообщение переводится получателем обратно в значимые мысли и идеи.

— Подтверждение. После получения сообщения получатель может послать сигнал (подтверждение) о получении сообщения, но это не обязательно означает согласие с сообщением или понимание сообщения.

— Обратная связь/ответ. Когда полученное сообщение декодировано и понято, получатель преобразует (кодирует) мысли и идеи в сообщение и передает данное сообщение оригинальному отправителю.

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

— Интерактивные коммуникации. Между двумя или более сторонами, осуществляющими многосторонний обмен информацией. Данный метод является наиболее эффективным для обеспечения общего понимания определенных вопросов всеми участниками; он включает в себя совещания, телефонные переговоры, мгновенные сообщения, видеоконференции и т. д.

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

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

Методы и аспекты эффективного управления коммуникациями включают среди прочего:

— Модели «отправитель-получатель». Внедрение циклов обратной связи с целью обеспечения благоприятных возможностей для взаимодействия/участия и устранения барьеров коммуникаций.

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

— Стиль написания. Применение действительного либо страдательного залога, структура предложения, подбор слов.

— Методы управления совещаниями. Подготовка повестки и работа с конфликтами.

— Методы презентаций. Осведомленность о воздействии языка тела и разработка визуальных средств.

— Методы организации групповой работы. Достижение консенсуса и преодоление препятствий.

— Методы слушания. Активное слушание (подтверждение, уточнение и проверка понимания) и устранение барьеров, которые могут исказить понимание.

Управление рисками проекта

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

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

План управления рисками — это компонент плана управления проектом, описывающий, каким образом действия по управлению рисками будут структурироваться и выполняться. План управления рисками включает в себя следующие элементы:

— Методология. Определение подходов, инструментов и источников данных, которые будут использоваться для управления рисками в данном проекте.

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

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

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

— Категории рисков. Предоставляют средства для распределения потенциальных источников риска по группам. Могут быть использованы несколько подходов, например, структура, основанная на целях проекта по категориям. Иерархическая структура рисков (RBS) помогает команде проекта рассмотреть множество источников, из которых могут проистекать риски проекта, во время выполнения процедуры идентификации рисков. Различным типам проектов соответствуют различные структуры RBS. Организация может использовать разработанную заранее схему категоризации рисков, которая может принимать форму простого списка категорий или оформляться в виде RBS. RBS — это иерархическое представление рисков согласно категориям рисков.

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

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

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

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

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

Методы диаграмм

К методам диаграмм рисков относятся:

— Диаграммы причинно-следственных связей. Эти диаграммы, также известные как диаграммы Исикавы или диаграммы «рыбий скелет», используются для определения причин возникновения рисков.

— Блок-схемы процесса или системы. Этот вид графического отображения демонстрирует порядок взаимодействия различных элементов системы между собой и их причинно-следственные связи.

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

Анализ SWOT

Данный метод позволяет провести анализ проекта с точки зрения каждого из аспектов: сильных и слабых сторон, благоприятных возможностей и угроз (strengths, weaknesses, opportunities, and threats, SWOT), что делает идентификацию рисков более полной, учитывая риски внутри проекта. При использовании данного метода начинают с определения сильных и слабых сторон организации, уделяя особое внимание либо проекту, либо организации, либо области бизнеса в целом. Затем в процессе анализа SWOT идентифицируют любые благоприятные возможности проекта, обусловленные сильными сторонами организации, а также любые угрозы, появляющиеся вследствие ее слабых сторон. При помощи данного анализа также исследуют, насколько сильные стороны организации компенсируют угрозы, и идентифицируют лагоприятные возможности, которые можно использовать для преодоления слабых сторон.

Реестр рисков

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

— Список идентифицированных рисков. Идентифицированные риски описываются с достаточной степенью детализации. В данном списке может использоваться определенная структура для описания рисков, например: может произойти СОБЫТИЕ, которое окажет ВОЗДЕЙСТВИЕ, или если существует ПРИЧИНА, то может произойти СОБЫТИЕ, которое будет иметь ПОСЛЕДСТВИЕ. Кроме того, при построении списка идентифицированных рисков могут стать более очевидными первопричины данных рисков. Это фундаментальные условия или события, которые способны вызвать наступление одного или нескольких идентифицированных рисков. Они должны регистрироваться и использоваться для поддержки идентификации рисков в будущем в рамках данного и других проектов.

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

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

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

Методы сбора и представления информации

— Проведение интервью. Методы проведения интервью позволяют получить опыт и исторические данные для количественной оценки вероятности и воздействия рисков на цели проекта. Требуемая информация зависит от используемого типа вероятностного распределения. Например, для некоторых наиболее широко используемых моделей распределений необходимо собрать информацию об оптимистическом (низкая вероятность), пессимистическом (высокая вероятность) и наиболее вероятном сценарии. Документирование обоснований диапазонов рисков и связанных с ними допущений является важным элементом интервью по поводу рисков, поскольку эти документы позволяют сделать вывод о надежности и достоверности анализа.

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

Методы количественного анализа и моделирования рисков

Широко применяемые методы используют как событийно-ориентированные, так и проектно-ориентированные подходы к анализу, включающие в себя:

— Анализ чувствительности. Анализ чувствительности помогает определить риски с наибольшим возможным воздействием на проект. Он помогает понять, каким образом вариации в целях проекта коррелируют с вариациями в различных неопределенностях. С другой стороны, он устанавливает, в какой степени неопределенность каждого элемента проекта влияет на изучаемую цель, в то время как все другие неопределенные элементы находятся в своих базовых значениях. Одним из типичных способов отображения анализа чувствительности является диаграмма «торнадо» (рис. ниже), которая полезна при сравнении относительной важности и воздействия переменных, обладающих высокой степенью неопределенности, с другими, более стабильными переменными. Диаграмма «торнадо» также полезна при анализе сценариев принятия рисков, применяемых при определенных рисках, количественный анализ которых указывает на то, что возможные выгоды больше, чем соответствующие идентифицированные отрицательные воздействия. Диаграмма «торнадо» — особый вид линейчатой диаграммы, используемый в анализе чувствительности для сравнения относительной важности переменных. В диаграмме «торнадо» на оси Y располагается каждый тип неопределенности в базовых значениях, а на оси X — разброс или корреляция неопределенности в отношении изучаемого выхода. На этом рисунке каждая неопределенность содержит горизонтальную полосу (линию), а по вертикали показаны неопределенности с уменьшающимся разбросом от базовых значений

— Анализ ожидаемого денежного значения. Анализ ожидаемого денежного значения (expected monetary value, EMV) — это статистический метод, с помощью которого вычисляется средний результат, когда в будущем имеются сценарии, которые могут произойти или не произойти (т. е. анализ в условиях неопределенности). EMV благоприятных возможностей, как правило, выражается в положительных величинах, а угроз — в отрицательных. Для EMV требуется нейтральное по отношению к рискам допущение — ни склонное к чрезмерному риску, ни, наоборот, полностью его отвергающее. Чтобы рассчитать EMV для проекта, необходимо умножить значение каждого возможного результата на вероятность его наступления, а затем сложить вместе полученные значения. Обычно данный тип анализа используется в виде анализа дерева решений.

— Моделирование и имитация. При имитации проекта используется модель для определения возможных воздействий подробно описанных неопределенностей на цели проекта. Имитации, как правило, проводятся с помощью метода Монте-Карло. При имитации модель проекта рассчитывается множество раз (итеративно), при этом для каждой итерации входные значения (например, оценки стоимости или длительности операций) выбираются произвольно из распределений вероятностей этих переменных. В ходе итераций рассчитывается гистограмма (например, общая стоимость или дата завершения). При анализе рисков стоимости методом имитации используются оценки стоимости. При анализе рисков расписания используется диаграмма сети расписания и оценки длительности. Выход из имитации рисков стоимости с использованием модели по трем элементам и диапазонов рисков показан на рис. ниже. Рисунок демонстрирует соответствующую вероятность достижения определенных целей по стоимости. Подобные кривые могут быть разработаны для других целей проекта.

Стратегии реагирования на отрицательные риски (угрозы)

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

— Передача. Передача риска — стратегия реагирования на риск, посредством которой команда проекта перекладывает последствия наступления угрозы вместе с ответственностью за реагирование на третью сторону. При передаче риска ответственность за управление им перекладывается на другую сторону; риск при этом не устраняется. Передача риска не означает отказ от ответственности за него путем передачи его будущему проекту или другому лицу, без уведомления последнего или заключения с ним соглашения. Передача риска практически всегда подразумевает выплату премии за риск стороне, принимающей на себя риск. Передача ответственности за риск наиболее результативна в отношении финансовых рисков. Инструменты передачи могут быть весьма разнообразными и включают в себя, среди прочего: использование страховки, гарантии выполнения обязательств, гарантийные обязательства и т. д. Для передачи ответственности за определенные риски другой стороне могут использоваться договоры или соглашения. Например, когда у покупателя есть возможности, которые отсутствуют у продавца, может оказаться разумным с помощью договора передать часть работ и их сопутствующие риски назад покупателю. Во многих случаях в договоре с возмещением затрат стоимостной риск может передаваться покупателю, а в договоре с фиксированной ценой риск может передаваться продавцу.

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

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

Стратегии реагирования на положительные риски (благоприятные возможности)

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

— Увеличение. Стратегия увеличения используется для повышения вероятности и/или положительного воздействия благоприятной возможности. Идентификация и максимизация ключевых факторов, обусловливающих появление данных положительно-воздействующих рисков, могут повысить вероятность их наступления. Примеры увеличения благоприятных возможностей включают в себя выделение дополнительных ресурсов для операции с целью ее раннего завершения.

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

— Принятие. Принятие благоприятной возможности — это желание воспользоваться преимуществом благоприятной возможности в случае ее наступления без активного ее преследования.

Управление закупками проекта

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

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

Типы договоров

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

— Договоры с твердой фиксированной ценой (Firm Fixed Price Contracts, FFP). Наиболее широко используемым типом договоров является FFP. Большинство организаций-покупателей предпочитает именно этот тип договора, так как цена товаров устанавливается в самом начале и не подвержена изменениям, если не меняется содержание работ. Любое увеличение стоимости, вызванное негативным исполнением, является ответственностью продавца, который обязан закончить работу. В соответствии с FFP покупатель обязан точно определить приобретаемый продукт или услуги, а любые изменения закупочной спецификации могут увеличить затраты покупателя.

— Договоры с фиксированной ценой и поощрительным вознаграждением (Fixed Price Incentive Fee Contracts, FPIF). Данное соглашение с фиксированной ценой предоставляет покупателю и продавцу некоторую гибкость, поскольку допускает отклонение от исполнения и предусматривает финансовое поощрение за достижение оговоренных метрик. Как правило, такие финансовые поощрения связаны с выполнением стоимости, расписания или с техническим исполнением со стороны продавца. Целевые значения показателей исполнения устанавливаются в начале, а конечная цена договора определяется после завершения всех работ в зависимости от их исполнения продавцом. В рамках FPIF устанавливается потолок цен, и ответственность за все затраты выше потолка цен возлагается на продавца, который обязан завершить работу.

— Договоры с фиксированной ценой и оговоркой о возможной корректировке цены (Fixed Price with Economics Price Adjustment Contracts, FP-EPA). Данный тип договора используется в том случае, если исполнение договора продавцом растягивается на значительный период времени, к чему обычно стремятся при долгосрочных отношениях. Договор с фиксированной ценой, но со специальным положением, позволяющим вносить предопределенные окончательные корректировки в стоимость договора в связи с изменившимися условиями, такими как инфляция или повышение (понижение) цен определенных товаров. Оговорка о корректировке цены должна быть привязана к достоверному финансовому индексу, используемому для точной корректировки конечной цены. FP-EPA призван защищать как покупателя, так и продавца от внешних условий, которые они не могут контролировать.

— Договоры с возмещением затрат. Этот тип договора подразумевает оплату (возмещение) продавцу всех законных фактических затрат, понесенных в результате исполнения работы, плюс вознаграждение, составляющее его прибыль. В договоры с возмещением затрат часто включаются пункты, предусматривающие поощрительные вознаграждения за превышение или улучшение запланированных показателей проекта (например, стоимости, расписания или технического исполнения). Тремя наиболее распространенными типами договоров с возмещением затрат являются: договор с возмещением затрат плюс фиксированное вознаграждение (Cost Plus Fixed Fee Contract, CPFF), договор с возмещением затрат плюс поощрительное вознаграждение (Cost Plus Incentive Fee Contract, CPIF), договор с возмещением затрат плюс премиальное вознаграждение (Cost Plus Award Fee Contract, CPAF). Договор с возмещением затрат обеспечивает гибкость проекта, позволяя изменять указания для продавца в том случае, если содержание работ не может быть точно описано в начале и нуждается в корректировке или существуют высокие риски во время выполнения работ.

— Договоры с возмещением затрат плюс фиксированное вознаграждение (CPFF). Продавцу возмещаются все оговоренные затраты на выполнение работ по договору, а также выплачивается фиксированное вознаграждение, составляющее определенный процент от первоначальной оценочной стоимости проекта. Вознаграждение выплачивается только за завершенную работу и не изменяется в зависимости от исполнения продавца. Суммы вознаграждения не меняются, если не меняется содержание проекта.

— Договоры с возмещением затрат плюс поощрительное вознаграждение (CPIF). Продавец получает возмещение всех оговоренных затрат на выполнение работ по договору, а также заранее определенное поощрительное вознаграждение за достижение конкретных показателей исполнения, оговоренных в договоре. В договорах CPIF оговаривается, что если конечные затраты оказываются больше или меньше первоначальной оценочной стоимости, то сэкономленные/перерасходованные средства распределяются между продавцом и покупателем в заранее оговоренном соотношении, например, в соотношении 80/20 от разницы между запланированными затратами и фактическим исполнением продавца.

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

— Договоры «время и материалы» (Time and Material Contracts, T&M). Договоры «время и материалы» являются смешанным типом договорных соглашений, содержащим положения как договоров с возмещением затрат, так и договоров с фиксированной ценой. Они часто используются при дополнительном наборе персонала (staff augmentation), привлечении экспертов и для любой сторонней поддержки в тех случаях, когда невозможно быстро создать точное описание работ. Данные типы договоров напоминают договоры с возмещением затрат тем, что они допускают поправки и увеличение стоимости для покупателя. В момент заключения договора покупатель может не указывать общую стоимость по договору и точное количество предметов, которые необходимо поставить. Таким образом, стоимость договоров T&M может увеличиваться, как и в договорах с возмещением затрат. Для предотвращения неограниченного роста стоимости многие организации требуют включения во все договоры T&M предельных значений цены и сроков. C другой стороны, договоры T&M также могут напоминать соглашения с фиксированной ценой, когда в договоре указываются определенные параметры. Ставки оплаты рабочих часов или стоимость материалов, в том числе прибыль продавца, могут быть заранее установлены покупателем и продавцом, если обе стороны достигли соглашения по поводу стоимости определенных категорий ресурсов, например определенной ставки почасовой оплаты труда главных инженеров или определенной цены за единицу материала.

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

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

При проведении анализа заинтересованных сторон используются различные модели классификации, такие как:

— матрица власти/интересов, группирующая заинтересованные стороны на основе их уровня полномочий («власть») и уровня заинтересованности («интерес») в отношении результатов проекта;

— матрица власти/влияния, группирующая заинтересованные стороны на основе их уровня полномочий («власть») и активного вовлечения («влияние») в проект;

— матрица влияния/воздействия, группирующая заинтересованные стороны на основе их активного вовлечения («влияние») в проект и их возможности приводить к изменениям в планировании или исполнении проекта («воздействие»);

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

Уровни вовлечения заинтересованных сторон можно классифицировать следующим образом:

— Неосведомленный. Заинтересованная сторона не осведомлена о проекте и потенциальных воздействиях.

— Сопротивляющийся. Заинтересованная сторона осведомлена о проекте и потенциальных воздействиях и сопротивляется изменениям.

— Нейтральный. Заинтересованная сторона осведомлена о проекте, но не поддерживает изменения и не сопротивляется им.

— Поддерживающий. Заинтересованная сторона осведомлена о проекте, потенциальных воздействиях и поддерживает изменения.

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

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

— Идентификационную информацию: Ф.И.О., должность в организации, местоположение, роль в проекте, контактная информация.

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

— Классификацию заинтересованной стороны: внутренняя/внешняя, поддерживает/нейтральна/сопротивляется и т. д.

В дополнение к данным из реестра заинтересованных сторон план управления заинтересованными сторонами зачастую также содержит:

— желаемый и текущий уровень вовлечения ключевых заинтересованных сторон;

— объем и воздействие изменения на заинтересованные стороны;

— выявленные взаимосвязи и потенциальное пересечение заинтересованных сторон;

— требования заинтересованных сторон к коммуникациям на текущей фазе проекта;

— сведения о распространяемой среди заинтересованных сторон информации, включая язык, формат, содержание и степень детализации;

— причину распространения данной информации и ожидаемое влияние на уровень вовлечения заинтересованных сторон;

— время и периодичность распространения требуемой информации заинтересованным сторонам;

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

Советы от создателей сертификации, упражнения и примеры экзаменационных вопросов с подробным анализом правильных ответов

Краткое изложение книги Rita Mulcahy PMP Exam Prep на русском языке.

Секреты мастерства в подготовке к данному экзамену
Зачем сдавать экзамен?

Когда вы получаете сертификат PMP, можно сказать, вы сдали международный экзамен, специально созданный в доказательство ваших знаний в области управления проектами. Экзамен фокусируется на ситуациях, с которыми вы могли бы столкнуться в реальности, а не на повторении изученных вами данных. Таким образом, сдав экзамен, вы подтверждаете свои настоящие знания и опыт в прикладном искусстве и науке управления проектом. Сертификат PMP — способ выгодно отличаться.

Исследования в области заработной платы Института по Управлению Проектами показали, что в Соединенных Штатах и некоторых других странах, сертифицированные менеджеры проектов получают по крайней мере на 10 процентов больше, чем несертифицированные. Многие мои студенты получили бонус в размере 15 000 долларов США И повышение зарплаты на 15 процентов после сдачи экзамена. Другие были выбраны среди 200 претендентов на рабочее место благодаря сертификату. В данном экономическом климате, наличие сертификата может быть причиной получения работы, сохранения работы, или продвижения по карьерной лестнице. А это хорошие стимулы наконец-то подготовиться к сдаче экзамена.

Что нужно знать для экзамена

Чтобы сдать экзамен, вам необходимо соответствовать требованиям, обозначенным PMI (the Project Management Institute, Институтом по Управлению Проектами).

Текущие требования описаны в следующей таблице.

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

Готовы ли вы к экзамену?

50 процентов не сдали экзамен, потому что не прошли достаточную подготовку в сфере управления проектом, которая использует терминологию Института Управления Проектами (PMI). Примите это всерьез! Понимание подхода PMI к управлению проектами не так легко, как чтение руководства PMBOK. Руководство PMBOK помогает вам улучшить знания; оно не учит вас управлению проектами. И во время изучения процесса управления проектом c помощью этой книги для подготовки к экзамену, если вы обнаруживаете, что большинство понятий и терминологии для вас новы, возможно, вам необходимо дополнительное изучение управления проектом перед продолжением подготовки.

Большой процент людей, не сдавших этот экзамен, не имели достаточно практического опыта. Возможно, они управляли справочной службой или маленькими проектами (подробнее об этом вы найдете далее в этой книге) или вообще не работали менеджерами проектов. Многие люди не осознают, что этот экзамен разработан выявлять тех, кто не прошел достаточную подготовку в сфере управления проектами или не имеет опыта. Этот экзамен не для начинающих менеджеров проектов и не для тех, кто хочет ими стать. Чем больше опыта работы над большими проектами вы имеете, тем лучше вы подготовитесь к экзамену, так как вопросы составлены с точки зрения управления большими проектами.

— Разработка нового колл-центра (вместо управления маленькими проектами колл-центра).

— Разработка нового производственного процесса (вместо производства стандартного продукта для заказчика).

— Установка программного обеспечения для персонального компьютера и присоединенного обновления (вместо установки рекламного программного обеспечения внутри компании).

— Дизайн и построение нового здания (вместо перекрашивания уже существующего здания).

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

— Большое превышение стоимости или графика.

— Невыполнимые графики.

— Чрезмерные изменения в содержании или расписании.

— Плохая коммуникация и постоянные конфликты.

— Нехватка времени к завершению проекта.

— Неудовлетворительное качество.

— Низкая моральная ценность.

— Члены команды не уверены в том, что необходимо делать.

— Чрезмерная доработка и работа сверх установленного времени.

— Слишком много собраний по проекту.

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

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

— Роли менеджера проекта, спонсора и команды.

— Историческая информация от предыдущих проектов.

— Накопленные знания от предыдущих проектов.

— Сохранение накопленных знаний по вашему проекту.

— Устав проекта.

— Что такое иерархическая структура работ (не список в графике) и как ее разработать.

— Как вручную создать сетевую диаграмму.

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

— Трехточечная оценка.

— Метод Монте-Карло.

— Освоенный объем.

— Уплотнение графика, сжатие, сокращение сроков выполнения проекта за счет совмещения работ.

— Управление временным резервом.

— Выполнимый график (невыполнимый график — вина менеджера проекта).

— Процесс управления рисками проекта (управление рисками — не просто использование контрольной карты).

— Ожидаемая денежная стоимость.

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

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

— Осуществлять контроль над проектом в соответствии с планом управления проектом.

— Управление процессом запроса на изменение.

— Контроль над изменениями.

— Профессиональная и социальная ответственность менеджера проекта.

Как выглядит PMP экзамен?

Запомните три очень важных вещи об этом экзамене. Во-первых, PMP ЭКЗАМЕН- ЭТО НЕ ТЕСТ ПО ИНФОРМАЦИИ руководства PMBOK! Во-вторых, вы не можете полагаться только на свой опыт. В-третьих, тренинг в профессиональном управлении проектами, который проводится по руководству PMBOK, весьма критичен. Однако, не позволяйте любой организации вводить вас в заблуждение о том, что вам необходимы недели обучения или диплом с квалификацией в управлении проектами, чтобы сдать экзамен.

PMP экзамен включает в себя 200 вопросов, в каждом из которых по четыре варианта ответов. На экзамен отводится 4 часа. Двадцать пять из 200 экзаменационных вопросов — «предварительные вопросы», что означает, они не включены в вашу экзаменационную оценку. Эти вопросы будут расположены в произвольном порядке. Вы не узнаете, какой из них какой. Они будут использоваться PMI для утверждения вопросов и последующего включения их в главную базу данных. Ваша оценка будет рассчитываться на основе оставшихся 175 вопросов. В настоящий момент, проходной балл экзамена — 106 из 175, что составляет примерно 61 процент.

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

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

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

Будьте внимательны на экзамене:

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

— Важно понимать, что экзамен имеет дело с настоящим использованием управления проектом. Он включает в себя до 150 вопросов типа «Что бы вы сделали в данной ситуации?» (ситуационные вопросы). Эти вопросы чрезвычайно сложны если вы не использовали инструменты управления проектом в реальности, или если ваше управление проектом включает общие ошибки. Вам необходимо быть в этих ситуациях, чтобы сдать экзамен.

— Есть примеры, где те же самые данные используются для нескольких вопросов, как, например, вопросы о сетевой диаграмме.

— Для тестируемого всегда кажется больше, но только лишь для нескольких вопросов требуется ЗАУЧИТЬ пошаговые процессы руководства PMBOK. Изначально, только 10—12 вопросов требуют ЗАУЧИВАНИЯ входов и выходов процессов из руководства PMBOK О них говорится в следующих главах.

— Ожидайте на экзамене 8—10 вычислений по формуле.

— На экзамене ожидайте 10—12 вопросов по освоенному объёму. Не все из них требуют вычислений по формулам.

— Большинство сокращений будут расшифрованы (например, на экзамене будет использоваться полный термин «иерархическая структура работ», а не ИСР).

— Правильные ответы не должны содержать прямые выдержки из руководства PMBOK.

— Многие чувствуют неуверенность только насчет 40 или менее из 200 вопросов на PMP экзамене.

— Многим необходимо только два с половиной часа на выполнение экзамена, а затем, в оставшееся время, они проверяют ответы.

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

1. Ситуационные вопросы. Эти вопросы требуют наличия опыта в управлении проектами в реальных ситуациях.

Вопрос. Вы получаете уведомление о том, что главный предмет который вы закупаете для проекта, будет доставлен с задержкой. Что ЛУЧШЕ всего сделать?

A Проигнорировать. Это пройдет.

B Поставить в известность начальника.

C Оповестить заказчика и обсудить возможные варианты дальнейших действий.

D Встретиться с командой и обозначить альтернативы.

Ответ D

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

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

Давайте снова вернемся к предыдущему вопросу. Мы бы ведь могли выбрать все варианты ответов. Правильный ответ, безусловно, D, но не будет ли верным оповестить заказчика? Да, но это не то, что нужно сделать в первую очередь. Первоначально вопрос звучит так, «Что ЛУЧШЕ всего сделать дальше?»

3. Вопросы с лишней информацией. Очень важно осознавать, что не вся информация, включенная в вопрос, будет относиться к делу. В следующем вопросе числа лишние. Вопрос. Опыт показывает, что каждый раз, когда вы удваиваете производство дверей, цена за единицу снижается на 10 процентов. Основываясь на этом, компания устанавливает, что продукция в 3000 дверей должна стоить 21 000 долларов США. Этот случай иллюстрирует:

A Обучающий цикл

B Закон убывающей приростной отдачи.

С Правило 80/20.

D Параметрическая оценка стоимости.

Ответ D

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

Ваша компания — главный производитель дверей, и получила огромное количество наград за качество. Как глава производственного отдела, у вас в подчинении 230 людей в 23 разных проектах. Опыт показывает, что каждый раз, когда вы удваиваете производство дверей, цена за единицу снижается на 10 процентов. Основываясь на этом, компания определяет, что производство 3000 дверей должно стоить 21 000 долларов США. Этот случай иллюстрирует…

Видите ли вы, что дополнительные данные не добавляют ценности вопросу? Они отвлекают. На экзамене вы можете увидеть целые параграфы информации, которая не нужна для ответа на вопрос. Нужно смотреть на каждый вопрос, чтобы определить «О чем спрашивается в этом вопросе?», а не теряться в предоставленной информации. не расстраивайтесь при появлении сложностей с этими длинными многословными вопросами. Просто отметьте их и вернитесь к ним позже. Если вы знаете чего ожидать, вы не расстроитесь и не потеряете уверенность при виде этих вопросов.

4. Вопросы с вымышленными терминами. Многие люди, сдающие экзамен, ожидают, что все термины, используемые в вариантах ответов, должны что-то означать. Это не так! На экзамене часто используются вымышленные термины. Возможно, составителю вопроса необходим был еще один вариант ответа, или, возможно, вымышленные термины добавляются, чтобы запутать тех, кто не знает правильный ответ. Если вы считаете себя хорошо подготовленными и на экзамене видите термин, который вам незнаком, вероятно, это неправильный ответ. Например:

Вопрос. Форма проектной организации, где власть делится между функциональным менеджером и менеджером проекта, называется:

A Узкая матрица.

B Слабая матрица.

C Сбалансированная матрица.

D Сильная матрица.

Ответ С

В этом вопросе, вариант А, узкая матрица, ненастоящий термин, используемый в проектном менеджменте.

5. Вопросы, где важно понимание. Сначала, взгляните на следующий вопрос.

Вопрос. Процесс разделения поставок на более мелкие и управляемые части завершен, когда:

A Установлено обоснование проекта.

B Появились запросы на изменения.

C Когда может быть разработана детальная оценка стоимости и длительности для каждого рабочего элемента.

D Каждый рабочий элемент находится в словаре ИСР.

Ответ С.

Чтобы ответить на этот вопрос, вам необходимо понимать все термины. Запоминания недостаточно!

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

Вопрос. В матричной организации распространение информации ВЕРОЯТНЕЕ ВСЕГО эффективно, когда:

A Информация распространяется как горизонтально, так и вертикально.

B Потоки коммуникации простые.

C В выбранном типе матрицы есть характерная логика.

D Менеджеры проекта и функциональные менеджеры взаимодействуют.

Ответ А.

7. Вопрос с более чем одним пунктом в каждом варианте ответа. Посмотрите на следующий пример.

Вопрос. Продавец проекта официально уведомил менеджера проекта, что операции покупателя нанесли ущерб продавцу. Продавец заявляет, что медленный ответ покупателя в отправке подтверждения продавцу приостановил проект и повлек неожиданные издержки продавца. ПЕРВОЕ, что должен сделать менеджер, это:

A Собрать все необходимые данные, отправить данные юристу компании, и проконсультироваться с юристом по поводу исковых требований.

B Просмотреть контракт на предмет особых согласованных пунктов, относящихся к проблеме, посмотреть, есть ли там ясный ответ, и при необходимости проконсультироваться с юристом.

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

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

Ответ В.

Эти вопросы могут казаться сложными пока вы не узнаете секрет: используйте процесс одновременного исключения одного пункта. Рассмотрите первый пункт в каждом варианте ответа и исключите те варианты ответа, в которых первый пункт неправдоподобен. Затем посмотрите на второй пункт в каждом варианте ответа и исключите все неправдоподобные варианты ответа. Продолжайте, пока у вас не останется один вариант.

Будьте внимательны, иногда пункты в каждом варианте ответа показывают поток или процесс. Смотрите пример ниже.

Вопрос. При управлении проектом, в каком порядке ЛУЧШЕ всего справляться с возникающими проблемами?

A Идти к команде, идти к руководству, идти к менеджерам ресурсов.

B Идти к менеджерам ресурсов, идти к руководству, идти к заказчику.

C Решать самому, идти к заказчику, идти к руководству.

D Решать проблемы за счет контролируемых ресурсов, идти к менеджеру ресурсов, идти к заказчику.

Ответ D

В данном случае, вам необходимо рассматривать каждый вариант ответа в отдельности, чтобы увидеть, правильный ли процесс.

8. Чрезмерно многословные вопросы. Вместо высказывания «Проект отстает от графика», экзамен должен использовать более многословные фразы, такие как, «Резерв времени проекта был нулевым и сейчас опустился до минус 2». Вместо «Команда не предоставляет требуемых отчетов», на экзамене используется «Команда потеряла из виду план управления коммуникациями». Первый шаг к ответу на многие вопросы — определить, что в вопросе спрашивается и затем перевести многословную фразу. Если вы не говорите по-английски, это становится огромной проблемой, но также остается сложным даже для англоговорящих. Просто попрактикуйтесь в чтении многословных вопросов перед сдачей экзамена.

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

Основные положения:

— Заинтересованная сторона проекта.

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

— Организационная структура:

— Матричная.

— Сильная.

— Слабая

— Сбалансированная

— Функциональная

— Проектная

— Экспедитор проекта.

— Координатор проекта.

— Ограничения.

— Накопленные знания.

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

— Определение управления проектом.

— Определение программы.

— Определение портфеля.

— Офис управления проектами (ОУП)

— Жизненный цикл продукта.

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

— Операционная работа.

— ОРМ3

— Сжатая матрица.

— Цели.

— Целевое управление.

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

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

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

Проект:

— Это временное предприятие с началом и завершением.

— Создает уникальный продукт, услугу или результат.

Спрашивается ли на экзамене, «Что такое проект?» Нет, но здесь будут описываться ситуации, и часть вашего анализа описанных ситуаций должна включать в себя «Является ли данное описание проектом?» Позвольте объяснить.

Что такое проект? Если бы ваш начальник зашел к вам в офис и сказал: «Возникли неполадки в системе. Не могли бы вы выяснить, в чём дело и устранить их?» Будет ли это проектом?

Вы продолжаете читать, не поразмыслив над вопросом, который я задала? Пожалуйста, прочтите еще раз и подумайте над ответом. Эта концепция очень важна для экзамена и реальных условий работы!

Я обучала тысячи студентов, но лишь немногие из них ранее изучали концепцию, что вы должны брать то, что вам даётся и организовывать работу в соответствующие проекты. Процесс планирования проектов порождает расписания и бюджеты. Можете ли вы запланировать «устранить их», если не знаете, что не так? Конечно, нет, так что в предыдущей истории как минимум два проекта.

Запомните, что менеджер проекта должен появляться с планом управления проектом, который может быть согласован, т.е. люди верят в то, что реалистично, но важнее всего, что менеджер проекта может поставить на кон свою репутацию Действительно ли вы работаете над проектами? Если ваши «проекты» длятся менее трёх месяцев и в команде менее 20 человек, возможно, они не являются проектами. Скажем, вы работаете в отделе обслуживания клиентов. Кто-то связывается с вами по поводу возникшей проблемы, и ваша обязанность её устранить. Конечно, такая вещь как ИСР очень сильно поможет, но нужна ли вам сетевая диаграмма? А план управления содержанием, временем и стоимостью? Возможно, нет. Как насчёт проектов установки программного обеспечения? Все ли они одинаковые? Может быть, они вообще не являются проектами.

— Вам необходимо помнить о больших проектах при ответе на вопросы на экзамене. Подумайте о проекте, который является новым для организации (никогда раньше не выполнялся), использует ресурсы из разных стран, в его команде более 200 человек, длится более одного года, и его стоимость свыше 1 000 000 долларов США. Независимо от того, работаете ли вы над такими проектами, на экзамене будет необходимо отвечать на такие вопросы, предполагая, что работаете. Существует большая разница в управлении большими и маленькими проектами. Например, в маленьких проектах, вы подходите к человеку, с которым вам нужно поговорить, когда возникает проблема, и решаете проблему. В больших проектах вы можете потратить недели, планируя коммуникации.

Когда возникает проблема, вам необходимо выяснить, кто вовлечён в проблему и где они находятся, посмотреть предпочитаемый ими метод коммуникации и контактную информацию в реестре заинтересованных сторон и затем связаться с ними таким образом. На экзамене задаются вопросы с точки зрения больших проектов. Если вы помните об этом, пока читаете книгу, вы увидите, что описываемая здесь информация, как часть управления проектом, имеет смысл. А если это имеет смысл, нет необходимости запоминать — вы можете использовать логику!

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

Операционная деятельность

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

Что такое управление проектами?

Многие люди думают, что управление проектами это просто управление, или, что еще хуже, вы можете купить некое программное обеспечение и стать менеджером проекта. Управление проектом — это профессия, которая быстро развивается. Она включает в себя науку и искусство, и следует систематическому процессу. Институт управления проектами делит управление проектами на группы процессов, области знаний, и профессиональную и социальную ответственность. Группы процессов следуют процессам управления проектом: инициация, планирование, исполнение, мониторинг и контроль, и завершение. Области знаний — это жизненный цикл проекта и организация, процессы управления проектом, и интеграция, содержание, время, стоимость, качество, человеческие ресурсы, коммуникации, риски и управление закупками.

Ответ на вопрос «Что такое управление проектом?» раскрывается на протяжении всей книги. Он может включать в себя технические термины и процессы, но также включает в себя роли и ответственности, и уровень власти. Знаете ли вы, что такое управление проектом? Возможно, есть такие ключевые аспекты, которых вы не знаете. Многие люди с учёной степенью в области управления проектом не могут сдать этот экзамен, потому что не знают, что такое на самом деле управление проектом. Постарайтесь найти ответ во время прочтения всей книги. Если вы прочитываете это во второй раз, обнаружили ли вы, что управление проектом может включать в себя больше, чем вы думали?

Что такое программа?

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

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

Что такое портфель?

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

Офис управления проектами (Project Management Office PMO)

Этот отдел централизует управление проектами. РМО обычно занимает одну из трёх позиций:

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

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

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

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

— Управлять взаимозависимостью между проектами.

— Оказывать помощь в предоставлении ресурсов.

— Завершать проекты.

— Осуществлять мониторинг соответствия организационным процессам.

— Оказывать помощь в сборе накопленного опыта и осуществлять его доступность для других проектов.

— Предоставлять шаблоны (т.е. для иерархических структур работ)

— Предоставлять наставничество.

— Обеспечивать централизованную коммуникацию на тему проекта.

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

— Быть частью совета по управлению изменениями.

— Быть заинтересованной стороной проекта.

Существует ярко выраженная тенденция организации РМО. Но организации должны осознавать риск. Если РМО плохо выполняют свою работу, они вызывают отрицательные чувства по отношению к профессиональному управлению проектом. Чтобы они заработали, организации должны помнить следующие ключевые моменты:

— Роль РМО должна быть чётко определена.

— РМО должен занять одну из трёх позиций, о которых говорилось выше, и придерживаться этой позиции.

— Все члены РМО должны быть сертифицированы.

— Требуется участие исполнительного управления.

— РМО не усовершенствует исполнение проекта без использования надлежащих процессов и методов управления проектом, таким образом, должно поощряться профессиональное управление проектом.

Цели.

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

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

— Цели проекта содержатся в уставе проекта.

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

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

— Более полное понимание целей происходит на протяжении проекта.

— Достижение целей проекта является обязанностью менеджера проекта.

— Показатель качества операций заключается в уверенности, что проект достигает своих целей.

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

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

— Проекты часто нуждаются в компромиссе между требованиями и целями.

— Цели проекта ставятся в группе инициации процессов и дорабатываются в группе планирования процессов.

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

Целевое управление (Management by Objectives MBO)

В этой философии управления три ступени:

— Ставить чёткие и реалистичные цели.

— Периодически оценивать, достигаются ли цели.

— Проводить корректирующее воздействие.

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

Ограничения

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

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

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

ОРМ3

ОРМ3 — это модель уровня развития управления проектами в организации. Эта модель разработана в помощь организациям для определения их уровня развития в управлении проектом. Для ОРМ3 существует отдельный стандарт РМI. Вам должен быть знаком термин ОРМ3, и вы должны знать, что он означает.

Заинтересованные стороны проекта, управление заинтересованными сторонами

Подумайте о заинтересованных сторонах в ваших настоящих проектах. Осознаете ли вы, что заинтересованные стороны проекта это не только менеджер проекта, заказчик, спонсор и команда? Заинтересованные стороны проекта — это люди или организации, на чьи интересы, положительно или отрицательно, влияет проект; они могут включать в себя частных лиц или группы, о которых, возможно, вы раньше не думали, такие как исполняющая организация, команда управления проектом, офис управления проектами, менеджеры портфелей, функциональные руководители, операционные менеджеры и продавцы. Они также могут включать в себя тех, кто мог оказать положительное или отрицательное влияние на проект, но, тем не менее, не считаться заинтересованной стороной. Теперь подумайте о том, как вы относитесь к заинтересованным сторонам вашего проекта. Считаете ли вы их дополнительными членами команды? Если нет, возможно, у вас огромный пробел в знаниях, из-за которого вы неправильно ответите на вопросы на экзамене. Считая заинтересованных сторон дополнительными членами команды, означает, что вы держите их в курсе дела, настойчиво просите их участия, и работаете на удовлетворение их потребностей и ожиданий. Без этой трудоемкости, проект может потерпеть неудачу.

Вы увидите, что тема заинтересованных сторон проекта повторяется и расширяется на протяжении всей книги, так как их потребности и уровень влияния анализируются и управляются на протяжении всего проекта. Обратите особое внимание на главу «Управление коммуникациями» (большая часть определения заинтересованных сторон проекта и мер в области управления являются частью управления коммуникациями) и главу «Управление человеческими ресурсами» (эта глава дает вам возможность проверить, понимаете ли вы, какую роль играют заинтересованные стороны в проекте).

ПРИМЕЧАНИЕ: Как объясняется в главе «Управление человеческими ресурсами», члены команды проекта могут также помочь завершить операции управления проектом. Руководство РМВОК ссылается на этих людей, как на команду управления проектом. Чтобы избежать путаницы, в этой книге говорится только о менеджере проекта (подразумевая и менеджера проекта, и команду управления проектом) или команду (имея в виду всех в команде проекта, а не только тех, кто осуществляет операции управления проектом).

Организационная структура

Проект не управляется в вакууме. На проекты оказывают влияние, и они сами влияют на культурные нормы, политику управления и процедуры организации, частью которого они являются. Самые лучшие менеджеры проекта ищут эти влияния и управляют ими в пользу проекта и организации.

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

— Как правило, экзамен не устанавливает вашу форму организации. Если он не определяет форму, то принимает матрицу. Запомнив это, вы должны правильно ответить еще на несколько вопросов.

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

— Кому принадлежит власть в каждом виде организации — менеджеру проекта или функциональному руководителю?

— Какие преимущества имеет каждый вид организации?

— Какие недостатки имеет каждый вид организации?

Функциональная организационная структура. Это самая распространённая форма организации. Организация сгруппирована по специальностям внутри различных функциональных подразделений (т.е. бухгалтерский учёт, маркетинг и производство). Когда вы столкнётесь с функциональной формой организации на экзамене, подумайте «силос». Проект обычно возникает внутри одного отдела. Если необходима информация или работа по проекту от другого отдела, направляется запрос к начальнику отдела, который сообщает запрос другому начальнику отдела. В противном случае, коммуникация остаётся внутри проекта. Члены команды выполняют работу над проектом в добавление к своей обычной работе, относящейся к деятельности отдела.

Проектная организационная структура. В данной структуре вся компания организована по проектам. Менеджер проекта осуществляет контроль над проектами. Назначается персонал, который предоставляет отчёты менеджеру проекта. Когда вы столкнётесь с проектной формой организации на экзамене, подумайте «нет исходной позиции». Члены команды выполняют только работу над проектом, и когда проект завершается, у них нет отдела, в который нужно вернуться. Им необходимо быть назначенными в другой проект, либо искать другую работу с другим работодателем. Коммуникация обычно осуществляется только внутри проекта.

Матричная организационная структура. Эта форма — попытка максимизировать силу функциональной и проектной форм. Когда вы столкнётесь с матричной формой организации на экзамене, подумайте «два начальника». Члены команды отчитываются перед двумя начальниками: менеджером проекта и функциональным руководителем (т.е. главным инженером и т.д.). Коммуникация направляется от членов команды к обоим начальникам. Члены команды выполняют работу над проектом в добавление к своей обычной работе, относящейся к деятельности отдела.

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

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

— Экспедитор проекта. Экспедитор проекта действует в основном, как ассистент персонала и координатор коммуникаций. Экспедитор не может лично принимать, или исполнять решения.

— Координатор проекта. Эта должность похожа на должность экспедитора проекта, только координатор имеет право принимать решения, имеет некоторую власть и отчитывается менеджеру более высокого уровня.

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

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

Функциональная

Проектная

Матричная

Ответ. Ниже перечислено несколько возможных ответов. Читая этот список, вы, возможно, поинтересуетесь «Преимущества и недостатки в сравнении с чем?» Когда на экзамене вы столкнётесь с таким вопросом, то здесь сравнивается организационная форма с функциональной организацией.

Функциональная

Проектная

Матричная

Жизненный цикл. Этот жизненный цикл длится от начала нового продукта до его завершения. Продукт может требовать или порождать множество проектов на протяжении всей жизни. Во время начала, проект должен определить потребности заказчика; во время развития, проект должен анализировать конкурентоспособность.

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

Существует множество различных видов жизненных циклов проекта, в зависимости от той области, в которой вы работаете или предпочтений компании. Вот некоторые примеры жизненных циклов проекта:

— Устройство. Осуществимость, планирование, разработка, производство, товарооборот и запуск.

— Информационные технологии. Высокоуровневое проектирование, детальное проектирование, кодирование, тестирование, установка, конверсия, и смена операций.

В ИТ проекте, высокоуровневым проектированием можно управлять как проектом и следовать полному процессу управления проектом от разработки устава проекта до завершения. Детальным проектированием можно управлять как ещё одним отдельным проектом.

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

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

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

Инициация должна быть выполнена для осуществления и принятия проекта, используя высокоуровневое планирование, для определения, должен ли быть выбран проект. Как только проект одобрен, он переходит в детальное планирование, где разрабатывается план того, как вы будете планировать, исполнять, осуществлять мониторинг и контроль проекта. Затем проект переходит к исполнению и работа выполняется в соответствии с процессами и процедурами, детально описанными в плане управления проектом. Во время выполнения работы, её результаты передаются в группу мониторинга и контроля для того, чтобы удостовериться, что проект следует плану (базовому плану). Если появляются отклонения, которые требуют изменений, не влияющих на базовый план, одобренные изменения передаются обратно в группу исполнения, где исполнение проекта знает, как помочь устранить отклонения. Иногда отклонения требуют более значимых изменений, или изменения необходимы для проекта. Когда эти изменения приняты, они передаются обратно в группу планирования, чтобы определить влияние на базовый план проекта и соответственно этому исправить план управления проектом. Как только определены изменения к базовому плану, и план скорректирован, он передаётся обратно в группу исполнения, где, снова, проект исполняется в соответствии с обновлённым планом, и мониторинг и контроль осуществляется соответственно исправленному базовому плану. Если проект так сильно отклонился от базового плана, что требует анализа, нужно ли вообще его продолжать, он отправляется обратно к инициации для принятия данного решения. В конечном итоге, когда работа выполнена (или проект завершён), проект отправляется в группу процессов завершения.

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

Жизненный цикл для маленького проекта. Жизненный цикл для большого проекта

Накопленные знания (постпрограмма) за весь период времени.

Если вы читали первую главу этой книги, вы должны помнить, как я описывала накопленные знания (как часть активов организационного процесса) в качестве PMI-змов.

Упражнение. Проверьте себя! Какой вид информации включают в себя накопленные знания?

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

— Технические аспекты проекта.

— Управление проектом (Как мы справились с созданием ИСР, планированием рисков и т.д.).

— Управление (Как я, как менеджер проекта, справился с коммуникациями и лидерством?)

— Многие менеджеры проекта не понимают роли накопленных знаний в проектах. Следующий график должен помочь объяснить их функцию:

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

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

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

Вам не нужно ждать завершения проекта, чтобы поделиться накопленными знаниями с другими проектами. Накопленные знания можно отправить, как только они созданы, как часть процесса распространения информации проекта (смотрите главу «Управление коммуникациями проекта»).

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

Примерные экзаменационные вопросы

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

A Усиленный контроль менеджера проекта над ресурсами.

B Более одного начальника для команд проекта.

C Легче взаимодействие.

D Легче представление отчёта.

2 Два менеджера проекта только что осознали, что они находятся в слабой матричной организации и что их власть, как менеджеров проекта, достаточно ограничена. Один из них обнаруживает, что он на самом деле экспедитор проекта, а другой — на самом деле координатор проекта. Чем отличается экспедитор проекта от координатора проекта?

A Экспедитор проекта не может принимать решения.

B Экспедитор проекта может принимать больше решений.

C Экспедитор проекта представляет отчёт менеджеру более высокого уровня.

D У проектного экспедитора есть немного власти.

3 В проектированной организационной структуре команда проекта:

A Представляет отчёты многим начальникам.

B Не выражает преданности проекту.

C Представляет отчёты функциональному руководителю.

D Не всегда будет иметь «исходную позицию».

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

A Функциональная.

B Матричная.

C Экспедиторская.

D Координаторская.

5 У проектного менеджера очень мало опыта, но он был назначен менеджером нового проекта. Так как он будет завершать проект в матричной организационной структуре, каких взаимоотношений он может ожидать?

A Простых.

B Открытых и точных.

C Сложных.

D Трудных в автоматизации.

6 Участник команды проекта разговаривает с другим участником и жалуется, что многие люди дают ему указания. Если он работает в функциональной структуре организации, кто имеет право давать ему указания?

A Менеджер проекта.

B Функциональный руководитель.

C Команда.

D Ограниченная матрица.

7 У кого больше всего власти в проектированной структуре организации?

A У менеджера проекта.

B У функционального руководителя.

C У команды.

D Они все разделяют власть.

8 Все пункты, данные ниже, являются характеристиками проекта, КРОМЕ:

A Временность.

B Определённое начало и конец.

C Взаимосвязанные виды деятельности.

D Повторение каждый месяц.

9 Все пункты, данные ниже, являются частью работы заинтересованных сторон команды, КРОМЕ:

A Предоставления заинтересованным сторонам дополнительных услуг.

B Выявления заинтересованных сторон.

C Определения нужд заинтересованных сторон.

D Управления ожиданиями заинтересованных сторон.

10 Менеджер и главный инженер обсуждают изменения к главному объёму работ. После собрания, менеджер связывается с вами и говорит вам завершить работу с документами для осуществления этого изменения. Это пример:

A Внимания к управлению содержанием проекта.

B Планирования управления

C Позиции экспедитора проекта.

D Системы изменения контроля.

11 Проект находится в процессе планирования, когда три заинтересованных стороны приходят к менеджеру проекта и интересуются новой методикой управления проектом компании. Они хотят знать, откуда она и почему отличается от предыдущей. Эти заинтересованные стороны также дружат с менеджером проекта и долгие годы работали вместе. Проект использует такие новые термины, как «корректирующее действие», которые заставляют некоторых заинтересованных сторон нервничать, так как они не уверены, изменится ли способ управления проектами вместе с новыми терминами. Что должна делать менеджер проекта?

A Посоветовать заинтересованным сторонам, что она будет держать их в курсе событий, относительно проекта.

B Подготовить список новых терминов и их определений.

C Сообщить в офис управления проектами (ОУП).

D Убедиться, что она сохраняет власть как менеджер проекта, даже если заинтересованные стороны её друзья.

12 Проектный менеджер управляет своим вторым проектом. Он начался через месяц после первого и оба проекта продолжаются. Хотя первый проект маленький, кажется, что второй растёт день за днём. Каждый день менеджер проекта начинает чувствовать, что он всё больше нуждается в помощи. Недавно проектный менеджер услышал, что год назад в компании был проект, идентичный его второму проекту. Что он должен делать?

A Связаться с другим менеджером проекта и попросить помощи.

B Получить архивные записи и руководство в офисе управления проектами.

C Посмотреть, влияет ли увеличение содержания на проект.

D Убедиться, что содержание проекта принято всеми заинтересованными сторонами.

13 Жизненный цикл проекта отличается от жизненного цикла продукта тем, что жизненный цикл проекта:

A Не включает в себя методику.

B Различный для каждой промышленности.

C Может порождать множество проектов.

D Описывает виды деятельности управления проектом.

14 Целевое управление работает только если:

A Оно поддерживается руководством.

B Правила записаны.

C Проект не влияет на цели.

D Проект включает цели в устав проекта.

15 Ваше руководство решило, что все заказы будут считаться «проектами» и менеджеры проекта должны ежедневно обновлять заказы, решать вопросы, и следить за тем, что заказчик официально принимает продукт в течении 30 дней после завершения. Доход от частных заказов может варьироваться от 100 долларов США до 150 000 долларов США. Осуществление планирования и предоставление документации, кроме ежедневного отчёта, не будет входить в обязанности менеджера проекта. Как бы вы объяснили эту ситуацию?

A Так как частный заказ — это «временная работа», каждый заказ является проектом.

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

C Это повторяющийся процесс.

D Только те заказы, доход от которых составляет свыше 100 000 долларов США, могут считаться проектами и включать в себя управление проектами.

16 Предыдущий менеджер вашего проекта не слишком хорошо осуществлял организацию проекта. Есть недостаток контроля управления, и нет чётко обозначенных результатов проекта. Что из ниже перечисленного НАИЛУЧШИМ образом поможет в организации вашего проекта?

A Применить подход жизненного цикла к проекту.

B Разработать обучающие курсы для каждой фазы.

C Разработать специальные рабочие планы для каждого объёма работ.

D Разработать описание продукта проекта.

17 Команда проекта работает над созданием нового продукта. Но они столкнулись со сложностью в создании устава проекта. Что ЛУЧШЕ ВСЕГО определяет реальную проблему?

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

B Они работают над процессом, а не над проектом.

C Конечная дата не установлена.

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

18 Один из участников вашей команды сообщает вам, что он не знает, какой из тех многих проектов, над которыми он работает, является самым важным. Кто в компании должен расставлять приоритеты среди проектов?

A Менеджер проекта.

B Команда управления проекта.

C Офис управления проектами.

D Команда.

19 Рыночный спрос, деловая потребность, и/или законодательные требования являются:

A Причинами для принятия на работу менеджера проекта.

B Причинами начала проектов.

C Примером того, как люди или предприятия становятся заинтересованными сторонами.

D Причинами спонсирования проекта.

20 Операционная деятельность отличается от проектной тем, что она:

A Уникальная.

B Временная.

C Продолжительная и повторяющаяся.

D Является частью каждого вида деятельности проекта.

21 Регламенты компании требуют создания документов о накопленном опыте. Что из ниже перечисленного является ЛУЧШИМ использованием накопленного опыта?

A Архивная документация для будущего проекта.

B Планирование документации текущего проекта.

C Информирование команды о том, что сделал менеджер проекта.

D Информирование команды о планах менеджера проекта.

22 Накопленный опыт ЛУЧШЕ ВСЕГО представляется:

A Менеджером проекта.

B Командой.

C Спонсором.

D Заинтересованными сторонами.

23 Обсуждение технического обслуживания и эксплуатации принципиально важно для продуктов проекта. Текущее техническое обслуживание и эксплуатация:

A Должны быть включены в качестве видов деятельности для выполнения во время закрытия проекта.

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

C Не должны рассматриваться как часть проекта. Проект является временным с определённым началом и завершением.

D Должны рассматриваться как отдельный проект.

24 Программа — это:

A Инициатива, установленная руководством.

B Способ извлечения прибыли и контроля над зависимыми проектами.

C Группа независимых проектов, управляемых согласованно.

D Правительственное регулирование.

25 Компания пытается улучшить выполнение проекта и создает архив предыдущих проектов. Как ЛУЧШЕ ВСЕГО это осуществить?

A Создать планы управления проектом.

B Обобщить накопленный опыт.

C Создать сетевые диаграммы.

D Создать отчёты о состоянии работ.

Ответы.:

1 Ответ А.

Объяснение. Запомните, если в вопросе не указано, с чем она сравнивается, то сравнивается с функциональной системой организации.

2 Ответ А.

Объяснение. Координатор проекта докладывает менеджеру более высокого уровня и имеет право принимать некоторые решения. У экспедитора проекта такого права нет.

3 Ответ D.

Объяснение. Главный недостаток проектированной организационной структуры заключается в том, что по окончании проекта, команда рассредоточена и у неё нет функционального отдела «исходной позиции», куда можно вернуться.

4 Ответ А
Объяснение

В функциональной организационной структуре менеджер проекта практически не поддерживает проект и имеет мало власти для назначения ресурсов. Варианты С и D — роли в слабой матричной организационной структуре.

5 Ответ С.

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

6 Ответ В.

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

7 Ответ А.

Объяснение. В проектной организационной структуре целая компания организована проектами, что дает менеджеру проекта наибольшую власть.

8 Ответ D.

Объяснение. Ответ D предполагает, что весь проект повторяется каждый месяц. На самом деле, только некоторые виды деятельности в проекте повторяются, а не целый проект.

9 Ответ А.

Объяснение. Предоставление заинтересованным сторонам дополнительных услуг, известно как удовлетворённость потребностей заказчика. Это не является эффективной заинтересованной стороной или управлением качеством.

10 Ответ С.

Объяснение. Это пример позиции экспедитора проекта, потому что вы не оцениваете изменение, не ищете влияния и т. д. Вы всего лишь выполняете указания. В этом случае, вы действуете в качестве экспедитора проекта.

11 Ответ С.

Объяснение. Некоторые студенты могут подумать, что в этом вопросе несколько правильных ответов. Это не так. Менеджер проекта может сделать многое, но что должно быть сделано? Политика компании управляется офисом управления проектами и менеджер проекта должен убедиться, что заинтересованные стороны владеют чёткой информацией, отправив их непосредственно к ответственным лицам за политику компании в управлении проектом.

12 Ответ В.

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

13 Ответ В.

Объяснение. Жизненный цикл проекта не включает в себя методику — для выполнения работы — таким образом, вариант А не может быть самым лучшим. Именно жизненный цикл продукта порождает множество проектов, таким образом, вариант С не может быть самым лучшим. Виды деятельности управления проектом описаны в процессе управления проектом, таким образом, вариант D — не самый лучший. Жизненный цикл проекта различен для каждой индустрии, таким образом, вариант В — самый лучший ответ.

14 Ответ А.

Объяснение. Самый лучший ответ — необходимость руководства поддерживать цели.

15 Ответ С.

Объяснение. Так как заказы многочисленны и краткосрочны, эта ситуация является процессом, а не проектом.

16 Ответ А.

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

17 Ответ В.

Объяснение. Эта работа вступила в стадию производства. Как правило, производство считается процессом, а не проектом, так как оно не является временным. Устав проекта здесь не подойдёт.

18 Ответ С.

Объяснение. Так как в вопросе говорится о приоритетах между проектами, это не может входить в обязанности менеджера проекта (вариант А), команды управления проектом (вариант В), или команды проекта (вариант D).

19 Ответ В.

Объяснение. Это всё является причиной инициации проекта.

20 Ответ С.

Объяснение. Операционная работа — это работа, которая осуществляется для поддержки организационной структуры.

21 Ответ А.

Объяснение. Обратите внимание, что в этом вопросе спрашивается об использовании инструментов управления проектом. Многие люди могут узнать из этой книги, что такое документ накопленного опыта. Но на такие вопросы можно ответить с большей готовностью, если вы используете инструменты и по опыту знаете их ценность. Спросите себя о других инструментах управления проектом. Почему они полезны? САМОЕ ЛУЧШЕЕ использование накопленного опыта — это вариант А. Для завершения того, что перечислено в других вариантах, существуют другие инструменты.

22 Вариант D.

Объяснение. Самый лучший ответ — заинтересованные стороны, так как их вклад критичен для сбора накопленного опыта по каждому проекту. Термин «Заинтересованные стороны» включает в себя все другие группы.

23 Ответ С.

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

24 Ответ В.

Объяснение. Вы выбрали вариант С? Если да, вы пропустили слово «независимый». Программы — это группы зависимых проектов.

25 Ответ В.

Объяснение. Накопленный опыт помогает избегать будущих ошибок и использовать хорошие идеи предыдущих проектов. Это приводит к усовершенствованию будущих проектов.

Процессы управления проектом

Основные положения:

— Что происходит во время каждого процесса управления проектом.

— Инициация

— Планирование

— Исполнение

— Мониторинг и контроль

— Завершение

— Чего вы не делаете в реальности во время каждого процесса управления проектом.

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

В то время как жизненный цикл проекта (описанный в главе «Жизненный цикл проекта и организация») описывает, что вам нужно сделать, чтобы закончить работу, процессы управления проектом описывают, что вам нужно делать, чтобы управлять проектом. Люди часто думают, что им необходимо понимать различные сферы промышленности, чтобы сдать этот экзамен, так как экзамен ссылается на различные виды проектов, выполняемых в различных сферах промышленности (например, «Вы строите мост» или «Вы разрабатываете новую систему для вашей компании»). Однако, эта информация в основном исходные данные. Экзамен не спрашивает вас, как выполнять работу в различных сферах промышленности, например, каким должен быть особый жизненный цикл проекта, или как выполнять ИТ, строительный, инженерный или любой другой вид проектов; вместо этого, он спрашивает об управлении проектами. Эти вопросы общие и на них можно ответить без понимания промышленности, если вы знаете управление проектом.

Поймите, что существует процесс для управления проектами. Он включает в себя:

— Инициацию проекта (Начало).

— Планирование проекта (План).

— Исполнение проекта (Осуществление)

— Мониторинг и контроль проекта (Проверка и действие)

— Завершение проекта (Окончание)

Как объяснено в главе «Жизненный цикл проекта и организация», для маленьких проектов вам нужен именно процесс, чтобы управлять проектами. Для больших проектов, разделённых на фазы, этот процесс может повторяться множество раз. Например, в проекте с фазой исследования, вы завершаете фазу инициации, затем снова начинаете весь процесс в фазе разработки.

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

Игра «Что предшествует» Эта игра, поможет вам узнать, на самом ли деле вы понимаете эти основные положения, после того, как вы как минимум три раза провели игру процессов.

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

Ответ.

Группа процессов инициации.

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

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

Входы в группу процессов инициации. Вам не нужно заучивать входы. Позвольте мне помочь вам это доказать. Попытайтесь выполнить следующее упражнение.

Упражнение. Как вы думаете, что вам необходимо знать или иметь перед запуском проекта?

ПРИМЕЧАНИЕ: Возможно, вы бы хотели, чтобы ответы не находились сразу под вопросами. Если это вам мешает, просто возьмите чистый лист бумаги, подходящий для ответов на вопросы. Мой анализ показывает, что расположение ответов сразу же после вопросов, приносит больше пользы, чем вреда.

Ответ. Если вы знаете, что такое процессы инициации, о входах легко догадаться.

— Бизнес кейс.

— Описание продукта, или описание содержания продукта с подробными требованиями к продукту, если они известны на данном этапе. Другими словами, что нужно сделать в проекте?

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

— Какие предпочтительные заинтересованные стороны.

— Контракты, если работа выполняется по контракту.

— Промышленные стандарты.

— Система контроля изменений компании.

— Как компания осуществляет бизнес; определенные процессы и процедуры.

— Прошлые взаимоотношения со спонсором проекта, предпочтительные заинтересованные стороны и команда.

— Шаблоны от предыдущих проектов.

— Исторические ИСР

— Историческая оценка.

— Что происходит в компании сегодня, главные проекты и какое они могут оказать влияние на данный проект.

— Будущее компании.

— Культура компании.

— Люди, которые могут быть хорошими членами команды.

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

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

Упражнение. Давайте пойдем дальше, входы, выходы, и инструменты и методы. Какие особые ДЕЙСТВИЯ необходимы для завершения процессов инициации проекта?

Ответ. Если вы думаете соответственно руководству РМВОК, возможно, вы пришли к следующему:

— Разработать устав проекта. (Глава «Управление интеграциями»)

— Определить заинтересованные стороны. (Глава «Управление коммуникациями)

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

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

Ниже некоторые пункты из предыдущего списка, которые могли бы использовать дальнейшее прояснение.

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

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

Бизнес кейс. Знаете ли вы, почему был начат ваш проект? Имеет ли это значение? Как описывалось в раннем обсуждении таблицы процессов, причина начала проекта будет приниматься во внимание на протяжении всего проекта. Она будет влиять на планирование проекта, на допустимые изменения и разработку содержания проекта. Проекты инициируются по многим причинам. Вам необходимо знать эти причины.

Высокоуровневое планирование выполняется во время процессов инициации. Еще один важный момент, который необходимо отметить в предыдущем упражнении — это то, что высокоуровневое планирование может осуществляться во время процессов инициации. Такое планирование может включать в себя создание высокоуровневой ИСР, порядок параметров оценивания, и высокоуровневое определение рисков. Устав проекта требует решений об измеримых целях проекта, расписаниях контрольных событий и основном бюджете. Их создание требует использования методов планирования управления проектом. Как еще вы можете придумать проектные цели расписания, стоимости, содержания и т.д.?

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

Группа процессов планирования

Насколько лучше был бы ваш последний проект, если бы вы могли волшебным образом его выполнить снова? Это сила планирования, потому что оно позволяет пройти через весь проект и организовать его перед тем, как он фактически выполнен. Именно во время планирования проекта, в добавление к выполнению работы, ресурсы, время и деньги можно сэкономить.

Планирование проекта определяет, можно ли достичь целей, поставленных в уставе проекта, так же, как проект будет завершен, и ссылается на все подходящие процессы планирования проекта и области знаний. Это значит, что менеджер и команда проекта определят, какие процессы в руководстве РМВОК подходят для потребностей проекта, во избежание бесполезных растрат ресурсов проекта на операции, не относящиеся к определенному проекту.

Упражнение. Какие особые действия необходимы для завершения группы процессов планирования проекта?

Ответ. Если вы думаете только в соответствии с руководством РМВОК, возможно, вы предположили следующее:

— Разработка плана управления проектом (глава «Управление интеграцией проекта»).

— Сбор требований (глава «Управление содержанием проекта»).

— Определение содержания (глава «Управление содержанием проекта»).

— Создание ИСР (глава «Управление содержанием проекта»).

— Определение операций (глава «Управление сроками проекта»).

— Оценка стоимости (глава «Управление стоимостью проекта»).

— Планирование качества (глава «Управление качеством проекта»).

— И т. д.

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

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

ПРИМЕЧАНИЕ: Не теряйте основную мысль, прорабатывая эти длинные списки. Этот список содержит много информации для экономии вашего времени в чтении сотен страниц скучного текста. На обдумывание каждого списка должно уходить около 15 минут.

Результатами процессов планирования являются план управления проектом и проектные документы (описанные в главе «Управление интеграцией проекта). Планирование проекта итеративно. Каждый последующий процесс может использовать результаты предыдущих процессов, и каждый процесс может влиять на предыдущие процессы, или вызывать в них изменения. Идея в реальности — следовать этим процессам в группе процессов планирования, пытаясь завершить каждый как можно более полно. Затем, после идентификации рисков, качественного и количественного анализа рисков, и планирования реагирования на риски, вернуться для завершения всех компонентов плана управления проектом и проектной документации. Данный подход к планированию эффективен и экономит время. Понимаете ли вы, почему повторение цикла начинается после управления рисками? Потому что именно после завершения управления рисками можно определить финальную стоимость и график. Управление рисками могло бы также повлечь за собой изменения в ресурсах, когда они используются, в какой последовательности выполняются операции и почти все другие части группы процессов планирования.

Имеют ли смысл два последних предложения? Если да, тогда вы в отличной форме. Если нет, вам необходимо внимательно прочитать главу «Управление рисками проекта», чтобы понять, почему те два предложения должны иметь смысл.

Обратите внимание на использование планов управления в предыдущей таблице. Помните ли вы, что это PMIзмы? Так много раз менеджеры проекта погружаются во все, что бы они ни делали, хорошенько перед этим не подумав. Такие действия приводят к неэффективности, исправлениям, ошибкам, конфликту, бесполезной сверхурочной работе и просто плохому управлению проектом. Используйте более формальный подход к решению «Как я буду это делать?» перед выполнением работы и зафиксируйте эту информацию в плане управления.

Существует множество компонентов к планам управления, но обычно они отвечают на вопросы «Как я займусь планированием содержания, графика, стоимости и т.д.?» и «Как я буду управлять и контролировать содержание, график, стоимость и т.д., сейчас, когда я спланировал, что необходимо сделать?» Ответы на эти вопросы определены в группе процессов планирования. Для ясности, предыдущая таблица объединяет вместе планы управления, вместо того, чтобы перечислить каждый план управления в отдельности. Она также перечисляет итерации планов управления, разделив их на части: планирование, управление и контроль. Индивидуальные планы управления объединены в общий план управления. (Более подробную информацию о планах управления и плане управления проектом вы найдете в главе «Управление интеграцией проекта». )

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

Представьте себе, что вы выбрали разделить проект на фазы (фаза тестирования, фаза установки и т.д.). Было бы невозможно детально спланировать каждую фазу, пока предыдущая фаза практически полностью не завершена. Это называется «планирование методом набегающей волны». Даже хотя каждая часть «проекта» называется фазой, каждая фаза могла, или, возможно, должна планироваться как проект, со своим уставом, описанием содержания, ИСР и т. д.

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

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

Когда мы находимся в группе процессов планирования? Планирование проекта не просто появляется при начале проекта. Мы вступаем в планирование проекта по различным причинам, как показано в следующей диаграмме.

Просмотрите описание каждого процесса в группе процессов планирования в оставшейся части книги, в особенности роль менеджера в создании плана управления проектом в главе «Управление интеграцией проекта».

Группа процессов исполнения

Цель процессов исполнения — завершить работу, определенную в плане управления проектом и достичь целей проекта. Это шаг процесса «выполнить», описанный в начале этой главы (начать, спланировать, выполнить, проверить и действовать, завершить.). Центр внимания на управлении людей, последующих процессах и распределении информации. Необходимо сопровождение, проактивная роль, завершенная при помощи постоянного обращения к плану управления проектом и проектной документации.

Подумайте снова о планировании проекта. Создаете ли вы реальный и одобренный план управления проектом? Содержит ли ваш план управления проектом планы управления для каждой области знаний, как описано выше? Многие менеджеры проекта не создают такой план управления проектом. Таким образом, экзаменационные вопросы из этой области могут им показаться невероятно трудными и запутанными. Для экзамена вам нужно предположить, что тщательное планирование проекта было завершено перед началом работы над проектом. Подумайте о критическом расхождении в планировании, и, при ответе на вопрос, представьте, что проект спланирован как следует (если только в вопросе не указано обратное).

Упражнение. Представьте себе, что вы готовы приступить к группе процессов исполнения проекта. Какие действия необходимо предпринять?

Ответ. Если вы думаете только в соответствии с руководством РМВОК, возможно, вы предположили следующее, как часть группы процессов исполнения:

— Направить и управлять исполнением проекта (глава «Управление интеграцией проекта»)

— Осуществить обеспечение качества (глава «Управление качеством проекта»).

— Собрать команду проекта (глава «Управление человеческими ресурсами проекта»).

— Организовать команду проекта (глава «Управление человеческими ресурсами проекта»).

— Управлять командой проекта (глава «Управление человеческими ресурсами проекта»).

— Распределить информацию (глава «Управление коммуникациями проекта»).

— Управлять ожиданиями заинтересованных сторон (глава «Управление коммуникациями проекта»).

— Ведение закупок (глава «Управление закупками проекта»).

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

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

ПРИМЕЧАНИЕ: Это еще один длинный список. Сосредоточьтесь и потратьте, по крайней мере, 5—15 минут на его обдумывание. Список намеренно изменяется.

Содержит ли ваш список пункты, которых нет в предыдущей таблице? Если да, убедитесь, что эти пункты на самом деле должны быть частью исполнения хорошо управляемого проекта. Включили ли вы такие пункты, как помощь команде взаимодействовать, обнаружение добавочного содержания или координирование незапланированной дополнительной работы? Хотя данные пункты могут иметь место в проекте, они возникают из-за недостаточно хорошего управления проектом. Как насчет решения проблем? Обратите внимание, что это всего лишь один из 48 пунктов в списке операций, который выполняется во время группы процессов исполнения. Менеджер проекта должен затратить время на предотвращение проблем, таким образом, он/она не должен тратить много времени на их решение. Экзамен признает, что проблемы не должны возникать очень часто, или не должны иметь большого влияния на проект. Помните, на экзамене вы должны предполагать, что осуществляется хорошее управление проектом, пока в вопросах не говорится иначе!

Перечислили ли вы собрания? Собрания являются частью исполнения проекта, но многие люди не осознают, что хорошее планирование может сократить необходимое количество собраний, превращая собрания всего лишь в незначительную операцию. Если вы думали о видах собраний «Ходите по комнате и представляйте отчет о том, что вы сделали», вы должны осознать, что статуса можно добиться другими способами. Случаи, когда команда собирается вместе, слишком важны, чтобы просто добиваться статусности. Как насчет пересмотра рисков или составления плана действий в непредвиденных обстоятельствах во время собраний, вместо обсуждения статуса? Текущие совещания приводят к потере поддержки от команды из-за бесполезной траты их времени.

— Убедитесь, что вы выяснили, что вы делаете «не так» в своих реальных проектах перед сдачей экзамена!

Помните о таких словах, как «работайте над планом управления проектом», «будьте проактивными», «управляйте» и «направляйте», как способ обобщения операций исполнения во время сдачи экзамена, для уверенности, что вы являетесь частью института управления проектом (PMI).

Процессы управления проектом не всегда исполняются в одинаковой последовательности. Исполнение означает следование плану управления проектом или самый последний просмотр плана управления проектом. Следующая схема наглядно показывает, когда вы приступаете к исполнению проекта.

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

Группа процессов мониторинга и контроля

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

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

Упражнение. Какие особые действия необходимы для завершения группы процессов мониторинга и контроля?

Ответ. Если вы думаете только в соответствии с руководством РМВОК, возможно, вы предположили следующее:

— Осуществить мониторинг и контроль работы проекта (глава «Управление интеграцией проекта»).

— Осуществить общее управление изменениями (глава «Управление интеграцией проекта»).

— Проверить содержание (глава «Управление содержанием проекта»).

— Управлять содержанием (глава «Управление содержанием проекта»).

— Управлять графиком (глава «Управление сроками проекта»).

— Управлять стоимостью (глава «Управление стоимостью проекта»).

— Осуществлять контроль качества (глава «Управление качеством проекта»).

— Составлять отчеты об исполнении (глава «Управление коммуникациями проекта»).

— Осуществлять мониторинг и контроль рисков (глава «Управление рисками проекта»).

— Управлять закупками (глава «Управление закупками проекта»).

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

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

ПРИМЕЧАНИЕ: Так как это одна из самых плохо оцениваемых групп процессов на экзамене, вам необходимо потратить на нее немало времени. Не отвлекайтесь во время чтения. Если необходимо, сделайте перерыв в середине списка, и помните, список намеренно изменяется.

Для экзамена удостоверьтесь, что:

— У вас есть реалистичный и завершенный план управления проектом.

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

— Вы ответственны за соблюдение базовых показателей измерения исполнения.

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

— Вы также принимаете меры по исправлению любых расхождений, которые требуют действий.

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

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

Контроль содержания:

— Следуйте изменению плана управления.

— Измеряйте исполнение в соответствии с базовым планом измерения исполнения.

— Измеряйте исполнение работы.

— Контролируйте фактические изменения.

— Контролируйте влияние изменений содержания.

— Анализируйте отклонения.

— Запрашивайте изменения.

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

— Задокументируйте накопленные знания.

Контроль расписания:

— Следуйте изменению плана управления.

— Измеряйте исполнение в соответствии с базовым планом измерения исполнения.

— Контролируйте фактические изменения.

— Контролируйте влияние изменений содержания.

— Запрашивайте изменения.

— Анализируйте отклонения.

— Задокументируйте накопленные знания.

— Обновляйте план управления проектом и проектные документы.

— Управляйте резервом времени.

— Используйте анализ освоенного объема.

Контроль стоимости:

— Следуйте изменению плана управления.

— Измеряйте исполнение в соответствии с базовым планом измерения исполнения.

— Контролируйте фактические изменения.

— Контролируйте влияние изменений стоимости.

— Запрашивайте изменения времени, содержания и т. д.

— Запрашивайте изменения к базовому плану стоимости.

— Анализируйте отклонения.

— Задокументируйте накопленные знания.

— Обновляйте план управления проектом и проектные документы.

— Пересчитайте прогноз по завершении.

— Добейтесь дополнительного финансирования, если это необходимо.

— Управляйте бюджетным резервом.

— Используйте анализ освоенного объема.

Контроль качества:

— Проводите периодические инспекции.

— Убедитесь, что установленные подходы и процессы соблюдаются.

— Запрашивайте изменения или улучшения к работе и процессам.

— Принимайте решения по принятию или отклонению работы.

— Оцените эффективность выполненных изменений.

— Пересмотрите эффективность систем контроля проекта.

— Улучшайте качество.

Отчет об исполнении:

— Постоянно измеряйте исполнение проекта, используя анализ отклонений или тенденций изменения и полученный анализ стоимости.

— Проводите обзор исполнения.

— Определяйте и анализируйте тенденции изменения и отклонения.

— Зафиксируйте запросы на изменение.

Мониторинг и контроль рисков:

— Реагируйте на триггеры рисков.

— Создавайте и осуществляйте обходы.

— Оценивайте эффективность планов реагирования на риски.

— Работайте согласно плану управления рисками.

— Обновляйте списки рисков и планы реагирования на риски.

— Используйте процедуры управления рисками.

— Зафиксируйте запросы на изменение.

Администрирование закупок:

— Проводите мониторинг, чтобы убедиться, что обе стороны контракта достигают контрактных обязательств.

— Защитите свои законные права.

— Утвердите работу.

— Отчитывайтесь об исполнении.

— Проинспектируйте и заверьте продукт.

— Управляйте изменениями.

— Покупатель производит оплату.

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

Группа процессов завершения

Вы завершили все содержание продукта. Проект завершен? Нет, осталась еще работа. Группа процессов завершения может иметь место только когда проект закончен. Это одна из самых игнорируемых частей процесса управления проектом. Если вы поймете эти важные концепции, 14 вопросов о завершении, как правило, легки.

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

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

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

Упражнение. Какие особые ДЕЙСТВИЯ необходимы для закрытия группы процессов завершения проекта?

Ответ. Если вы думаете только в соответствии с руководством РМВОК, возможно, вы предположили следующее:

— Закрытие проекта или фазы (глава «Управление интеграцией проекта»).

— Закрытие закупок (глава «Управление закупками проекта»).

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

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

Заметили ли вы что-либо очень важное в предыдущей таблице? Для некоторых людей, празднование и отчет о финальном выполнении проекта кажутся незначительными частями проекта, но не для самых лучших менеджеров проекта! Поэтому вы увидите эти пункты на экзамене. Празднование и финальный отчет показывают, вне всяких сомнений, что вы были успешны и сообщает всем заинтересованным сторонам, что ваша команда завершила проект. Это же хорошо? Подпишитесь ли вы под последними несколькими проектами, которые вы завершили? Если нет, то почему? Как насчет вечеринки, где целая команда подписывает проект?

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

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

В добавление к получению официального принятия, еще одна важная часть проекта — измерение удовлетворенности заказчика. Был ли у вас когда-нибудь заказчик, который принимал вашу работу, хотя и не был доволен проектом? Это обычное явление. Умные менеджеры проектов также будут оценивать уровень удовлетворенности заказчика во время завершения проекта. Также как и накопленные знания, измерение удовлетворенности заказчика должно осуществляться на протяжении всего проекта. Но оно ОБЯЗАНО происходить во время завершения проекта.

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

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

Как только административные части завершения проекта закрыты, и официальное подтверждение принятия проекта получено от заказчика, и/или спонсора, проект завершен.

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

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

Упражнение: Шифровальная игра управления проектом

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

Ответ: