Упражнение: тесты по Фреймворку проектной работы

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

• А. Глобальных компаниях
• В. Производственных компаниях
• С. Маленьких компаниях
• D. Гибких компаниях

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

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

• А. Рапортует нескольким начальникам
• В. Не получает лояльности к проекту
• С. Рапортует функциональному менеджеру
• D. У нее нет "дома" (домашнего департамента)

Ответ D. В проектно-ориентированной структуре сотрудники не имеют домашнего департамента, по факту завершения проекта они или в другом проекте, или покидают компанию.

Часто используемые инструменты и техники

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

1. бенчмаркинг (тестирование)
2. брейнсторм
3. списки, анкеты
4. чек-листы
5. интервью
6. исследования рынка
7. опросники и исследования

Анализ данных. В зависимости от данных, с которыми работаем, и необходимой глубины анализа, используем:

1. альтернативные оценки
2. предположения и ограничения
3. анализ маржинальности
4. анализ документации
5. анализ добавленной стоимости
6. ревью исполнения задач
7. анализ резервов
8. анализ первопричин
9. симуляция
10. SWOT-анализ
11. анализ трендов
12. анализ отклонений
13. анализ "Что-если"

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

1. диаграммы родства
2. причинно-следственные диаграммы
3. диаграммы контроля
4. флоучарты
5. исторические диаграммы
6. гистограммы
7. логические модели данных
8. матричные диаграммы и таблицы
9. майнд мэпы
10. матрицы возможностей и влияния
11. диаграммы корреляции
12. матрицы вовлеченности стейкхолдеров
13. мэппинг стейкхолдеров
14. текстовые описания

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

1. решение по анализу многих критериев
2. голосование

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

1. активное слушание
2. обратная связь
3. презентации
4. организации собраний
5. методы и технология коммуникации

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

1. управление конфликтами
2. понимание культурных разниц
3. понимание политики
4. принятие решений
5. эмоциональный интеллект
6. поддержка усилий
7. влияние
8. лидерство
9. управление собраниями
10. мотивация
11. переговоры
12. оценка окружения
13. тимбилдинг

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

1. оценки
2. аналоги
3. оценки сверху-вниз и снизу-вверх
4. экспертные оценки

Информационная система для учета по проекту (Project Management Information System, PMIS) - это один из факторов среды компании. Система включает инструменты автоматизации, для расчета расписания, управления конфигурациями, рабочего пространства, тайм-трекинга, системы управления закупками, а также репозитарий для исторической информации. ИС используется в большинстве процессов планирования, исполнения, мониторинга и контроля проекта.

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

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

Документация: Данные по выполнению работ, информирование и отчетность

Огромное количество данных и информации возникает, используется, и коммуницируется в ходе жизненного цикла проекта, от начальных оценок и измерений до аналитического контента и отчетов.
PMBoK использует различные термины для определения стадий, через которые эта информация проходит. Данные об исполнении работ включают базовые значения, и детали того, как задачи исполнялись в ходе процесса управления работами. Во время контроля и мониторинга работ, нужно анализировать данные, чтобы убедиться, что все идет в соответствии с планом управления проектом. Также, нужно понимать, как интерпретировать данные проекта в целом; результатом этого будет информация об исполнении работ. Ее можно потом организовать в отчеты об исполнении, которые предоставляются тем или иным заинтересованным сторонам, которые будут принимать решения на основе их.
Допустим, команда оценивает исполнение против плана, и дает данные по прогрессу: некая работа заняла 10 часов, и закончилась 21 июля. Значит, надо сверить ее с планом. По плану, видим, что она планировалась на 12 часов, и завершиться должна была 22 июля. Значит, разбираемся, почему времени затрачено меньше, и результат получен раньше. Означает ли это, что и остальной проект будет исполняться быстрее плана? Следует ли команда плану коммуникаций? Уведомлены ли ресурсы о том, что они освободились, и могут начать следующую задачу? Сделали ли мы переоценку будущих задач, при условии того, что схожие ресурсы выполняют схожие работы? Все это - результат анализа информации об исполнении. Эти данные организуются в Отчеты об исполнении работ, которые рассылаются в соответствии с планом коммуникаций.
А если вдруг задача с критического пути заняла времени сверх запланированного, то необходим запрос на изменение на корректировку остатка расписания.

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

Заинтересованные стороны включают не только Project Manager'а, Заказчика, Спонсора и команду проекта; стейкхолдерами может выступить множество людей или даже организаций, чьи интересы могут быть затронуты проектом или его продуктом в позитивном или негативном ключе. Это могут быть люди или группы, о которых вы ранее и не догадывались, такие как команда управления проектом, проектный офис, менеджеры портфелей и программ, функциональные подразделения компании (юристы, продажники, ...), функциональные и операционные менеджеры, и т.д. Заинтересованные стороны могут быть активно вовлечены в проект, или выполнять консультирующую роль. Заинтересованные могут также быть и внешними для компании, например государственными регуляторами, поставщиками, конечными пользователями, налогоплательщиками, банками, и прочими финансовыми институтами. Структуры, которые могут оказать влияние на проект, но не являются его частью, также заинтересованные сороны.
Нужно хорошенько продумать, как вовлечь интересантов в проект. Правильное управление заинтересованными сторонами подразумевает, что они информированы, вы требуете их вклада в проект, и работаете на удовлетворение их потребностей и ожиданий. Без всего этого, проект может провалиться. РМ должен анализировать и управлять влиянием заинтересованных сторон в ходе проекта.

Документация: Реестр предположений проекта

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

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

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

Факторы среды компании (Enterprise Environmental Factors, EEFs) - схожи с Процессными активами компании в том, что они обуславливают контекст, в котором планируется проект. Но, факторы среды компании обычно за гранью контроля команды проекта.
Факторы среды компании, внешние по отношению к ней, включают государственные или иные правила и регуляции, которые относятся к данной компании.

1. внутренние факторы среды компании включают структуру, культуру, системы, и географию расположения компании
2. факторы, связанные с ресурсами, включают технологии и ресурсы, доступные для назначения в проект
3. факторы, связанные с управлением проектами, могут включать систему управления ресурсами, систему закупок, и систему управления качеством

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

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

Большинство компаний поддерживают два типа процессных активов (Organizational Proceess Assets, OPAs):

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

Историческая информация может включать:

1. Списки активностей
2. Иерархическую структуру работ (ИСР)
3. Результаты тестирования
4. Отчеты
5. Риски и планы реагирования на них
6. Оценки
7. Использованные ресурсы
8. Планы управления проектами
9. Документацию по проекту
10. Исходные условия
11. Переписку

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

Прочие репозитарии знаний компании включают:

1. Управление конфигурациями, включая файловую структуру, соглашение об именовании файлов, основные стандарты компании, и шаблоны проектных документов
2. Финансовые данные, включая бюджеты и фактические расходы завершенных проектов
3. Реестры проблем и документацию по дефектам проекта
4. Метрики, которые могут быть использованы в других проектах
5. Планы и стандарты управления проектами, и сами проектные документы, например сетевые диаграммы, списки рисков и стейкхолдеров

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

Роль Менеджера портфеля

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

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

Роль Менеджера программы проектов

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

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

Роль Менеджера в проекте

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

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

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

Уровень власти РМ варьируется в зависимости от структуры компании ряда факторов, например, он на постоянке или на контракте. Тем не менее на экзамене подразумевается, что РМ:

1. Назначается на проект не позднее его инициации
2. Помогает с написанием устава
3. Отвечает за проект (но не всегда за его ресурсы)
4. Не обязан быть техническим экспертом
5. Выявляет и анализирует предпосылки и ограничения проекта
6. Возглавляет и направляет усилия по планированию проекта
7. Выявляет зависимости между задачами
8. Анализирует нереальные требования к срокам, и берет на себя построение нормального расписания
9. Прорабатывает временные и денежные резервы по проекту
10. Обладает властью и ответственностью, достаточными, чтобы вообще заниматься проектной работой
11. Говорит "Нет", когда необходимо
12. Интегрирует компоненты проекта в сплоченную поставку, удовлетворяющую требованиям заказчика
13. Финализирует план управления проектом, добивается его утверждения
14. Воздействует на проектную команду и атмосферу, в которой она работает, организую позитивные коммуникации, ограждая команду от политики, сглаживая культурные аспекты межнациональных команд, и решая проблемы команды
15. Проводит больше времени в проактивной работе с проблемами, нежели в реактивной (то есть стремится предотвращать их)
16. Понимает, как культурные различия могут повлиять на проект, особенно в случае глобальных команд, виртуальных команд, или проектов, в которых участвуют несколько компаний
17. Устанавливает продуктивные взаимоотношения между проектной командой и стейкхолдерами
18. Понимает и усиливает профессиональную и социальную ответственность команды
19. Помогает команде и другим стейкхолдерам во время исполнения проекта
20. Общается со всеми
21. Развивает команду
22. Награждает и поощряет
23. Определяет и обеспечивает требуемый уровень качества
24. Выявляет стейкхолдеров, поддерживает вовлечение стейколдеров в процесс, и управляет ожиданиями стейкхолдеров в течение всего проекта
25. Управляет знаниями по проекту, включая извлеченные уроки
26. Решает проблемы
27. Принимает решения
28. Демонстрирует этику и лидерство
29. Управляет ресурсами, контролирует их
30. Контролирует проект, оценивая его исполнение и отклонения против плана
31. Мониторит риски, коммуникации, и вовлечение стейкхолдеров, чтобы быть уверенным, что их ожидания коррелируют с проектом
32. Определяет необходимость запросов на изменения, включая рекомендацию корректировок, превентивных действий, исправления дефектов
33. Одобряет или отклоняет изменения в рамках своей власти, управляет списком изменений, и часто присутствует на совещаниях по изменению проекта
34. Использует метрики для определения отклонений и трендов в проектной работе, и отвечает за анализ импакта этих отклонений и трендов
35. Работает с участниками проектной команды, чтобы уменьшить отклонение от плана управления проектом
36. Фокусирует участников команды на риск-менеджменте, и потенциальной ответственности за риски
37. Организует закрытие проекта в конце каждой фазы и в конце собственно проекта
38. Исполняет или делегирует большинство активностей, описанных выше
39. Применяет знание проектного менеджмента, и использует персональные лидерские качества, чтобы привести проект к успеху
40. Отвечает за успех или провал проекта

Роль функционального менеджера в проекте

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

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

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

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

1. назначение конкретных сотрудников на проект, переговоры с РП о ресурсах
2. информирование РП о других текущих или проектных задачах, на которые будут отвлекаться ресурсы
3. участие в планировании работ, до того момента, пока задачи не будут уже назначены
4. предоставление экспертизы по проблемам
5. утверждение финального расписания проекта, если оно включает подконтрольные руководителю ресурсы
6. рекомендации к изменению проекта, включая корректирующие действия
7. управление работами внутри своей функциональной области
8. помощь в проблемах, связанных с подконтрольными ресурсами
9. повышение утилизации ресурсов
10. участие в награждении и поощрении работников
11. участие в идентификации рисков
12. участие в управлении качеством
13. контроль изменений

Роль заинтересованных сторон в проекте

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

1. созданию Устава и Описания содержания проекта
2. разработке Плана управления проектом
3. утверждению изменений по проекту
4. определению ограничений и предпосылок проекта
5. выявлению требований
6. управлению рисками

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

1. проверка и приемка наработок по проекту
2. ответственность за риски
3. участие в ревью по фазам проекта
4. участие в управлении проектом
5. разбор ошибок
6. документация вынесенных уроков
7. вынесение экспертных оценок

Роль Проектной команды

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

1. выявление и вовлечение стейкхолдеров
2. определение требований
3. определение предпосылок и ограничений проекта
4. создание ИСР
5. декомпозиция пакетов работ до конкретных активностей и далее задач
6. определение зависимостей между задачами
7. оценка трудоемкости и стоимости
8. участие в управлении рисками
9. обеспечение согласия с Планом управления качеством и Планом управления коммуникациями
10. выполнение основных правил работы
11. выполнение работ по плану, отслеживание того, чтобы результаты соответствовали содержанию
12. назначение собраний команды
13. рекомендация изменений в проекте, включая корректирующие действия
14. имплементация одобренных изменений
15. распространение новых знаний
16. вклад в базу знаний и извлеченные уроки

В agile компаниях, команда проекта также ответственна за:

1. проработку user stories с клиентом до той детальности, когда они могут быть оценены, и по ним спланированы релизы
2. проведение ревью и ретроспектив
3. апдейт информации по проекту, с помощью например Канбан доски и диаграммы исполнения

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

Роль Спонсора проекта

Основное назначение Спонсора - давать денег и ресурсов, побочное - поддерживать проект и охранять команду от незапланированных изменений. На экзамене подразумевается и то, и другое. В роли спонсора могут быть и два человека, работающих в контакте.
В случае закупки, покупатель может выступать как спонсор; тогда спонсор назначается и у продающей стороны.
Без спонсора проект страдает, расходуя время и ресурсы. Менеджмент должен охранять проект; менеджмент это единственный, кто круче РМ, менеджеров программ и портфелей в проектной структуре.
Что делает Спонсор проекта.

До или во время инициации проекта:

1. определился со своими пожеланиями на верхнем уровне
2. заинтересован в проекте
3. дает информацию по проекту вообще и для написания Устава в частности
4. участвует в определении предпосылок проекта
5. помогает определить измеримые цели проекта
6. защищает сподвижников проекта, особенно на стадии компиляции пожеланий
7. информирует всех, кто не знает о проекте, в т.ч. прочий менеджмент
8. способствует утверждению проекта у прочих стейкхолдеров
9. оказывает поддержку проекту
10. акцептует закупки
11. диктует вехи, ключевые события, дату завершения проекта
12. расставляет приоритеты, если это не исходит от Заказчика, по проекту и меж проектами
13. дает РМ власть, согласно Устава
14. заведует процессов акцепта и формализации проекта, если надо - то вместе с РМ

Во время планирования проекта:

1. отводит команде время на план
2. может согласовывать ИСР (иерархическую структуру работ)
3. определяет риски
4. определяет отчеты, нужные менеджменту для присмотра за проектом
5. дает экспертные оценки
6. способствует выходу на компромиссы
7. утверждает финальный план проекта

Во время исполнения, мониторинга и контроля:

1. поддерживает РМ
2. охраняет проект от внешних воздействий
3. требует качества
4. дает экспертные оценки
5. способствует компромиссам, решает конфликты за рамками полномочий РМ
6. подтверждает, отклоняет, или задвигает на потом изменения, или дает борду право делать это
7. может требовать ревизии качества
8. проясняет вопросы по содержанию проектов
9. вместе с РМ, мониторит прогресс

Во время закрытия проекта:

1. осуществляет формальную приемку результатов
2. обеспечивает эффективную передачу результата Заказчику
3. поддерживает сбор исторических данных по проекту

Оргструктура компании

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

Типы оргструктур:

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

Роль РМ в функциональной структуре или слабой матрице сводится к:

1. Проектный экспедитор - помогает в работе и коммуникациях, решений не принимает
2. Проектный координатор - в добавок к описанному выше, принимает некоторые решения, отчитывается своему менеджеру за них

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

Tight matrix (жесткая матрица) - это способ рассадки в помещении, не имеет ничего общего с сабжем по сути, но ввиду созвучия часто выступает вариантом ответа!

Проектный офис

Проектный офис (Project Managenet Office, PMO) - это орг.единица компании, которая обеспечивает комплайенс с проектным управлением, присматриваем за проектами, стандартизирует проектную работу. Варианты существования Проектного офиса:

1. Поддерживающий. С него политики, методики, шаблоны, и учет вынесенных уроков по проектам компании. Уровень контроля над проектами низкий.
2. Контролирующий. Обеспечивает поддержку и руководство по применению проектного менеджмента; обучает работе и софту для нее, помогает с подбором специфичных инструментов проектного менеджмента, обеспечивает синхронизацию проектной работы с политиками компании. Уровень контроля над проектами вышесредний, как правило является в них модератором
3. Директивный. Управляет проектами и отвечает за результаты (либо всеми вообще, либо проектами "не менее чем..."). Уровень контроля - полный.

В задачи Проектного офиса может входить:

1. управление зависимостями проектов, программам, портфолио
2. сбор информации по всем проектам, чтобы понимать, ведут ли они компанию к ее целям
3. помощь с подбором ресурсов
4. рекомендации к закрытию проектов, если уж такое случилось
5. мониторинг соответствия процессам компании
6. помощь в сборе ретроспективы, и организации ее доступности для новых проектов
7. темплейты документов
8. гайдлайны и управление проектами
9. централизация коммуникаций по проектам
10. повышение участия в инициации проекта, в противовес проекту самому
11. управление изменениями
12. приоритезация проектов
13. + ПО может выступать стейкхолдером

Орг.вопросы построения проектного менеджмента

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

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

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

Портфели и программы проектов

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

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

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

Признаки проекта:

1. он всегда имеет временные рамки, то есть начало и конец
2. в ходе проекта создается уникальный продукт, сервис, или еще какой-то результат

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

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

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