Основы проектной деятельности Лекция 1

Презентация к лекции

---

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

Одно из самых простых определений гласит: проект это все, что имеет «начало, конец и цель».

Таким образом, когда в организации предполагают запуск нового ПРОЕКТА - речь всегда идет о чем-то «конечном» и имеющим цель. «Разрабатывать программные продукты» - это не проект.

Проект - это, например, «создание и внедрение информационной системы АБВГД к 1 декабря следующего года».

Еще один аспект - масштабы проекта. 

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

Роль менеджера (для краткости будем иногда использовать для его обозначения аббревиатуру ПМ -

«проектный менеджер») можно описать двумя фразами:

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

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

Внутри треугольника присутствует еще одно условие - «удовлетворенность заказчика» или «качество».

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

Что считать успехом проекта? Если к моменту закрытия работ ни одна из граней не нарушена (мы уложились в срок, не перебрали бюджет, мы сделали все, о чем просил заказчик), а сам заказчик доволен результатом - ваш проект успешен и это неоспоримо.  

В Российской федерации управление проектом регламентируется

ГОСТ 54869-2011.

Проектный менеджмент

ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПРОЕКТОМ

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

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

Настоящий стандарт устанавливает требования к управлению проектом для обеспечения эффективного достижения целей проекта.

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

ГОСТ даёт следующее определение проекта:

Организация управления проектом

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

- заказчик проекта - физическое или юридическое лицо, которое является владельцем результата проекта;

- руководитель проекта - лицо, осуществляющее управление проектом и ответственное за результаты проекта;

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

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

Типы организаций

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

Будет ли у Руководителя проекта или Менеджера проекта доступ к необходимым ресурсам? Появится ли возможность финансово поощрять или штрафовать сотрудников? Кто и как нанимает людей на проект и увольняет с него?

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

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

функциональная, матричная, проектная.

Функциональные организации

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

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

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

Матричная структура

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

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

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

Проектная структура

Не предполагает наличия каких-либо отделов. В таких компаниях сотрудники набираются «под проект» и их единственным руководителем является менеджер проекта.

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

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

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

Большая часть ИТ-компаний имеет матричную структуру.

Методологии управления проектами

Давайте признаем – занимаясь «управлением проектом», мы (ПМ) сами для себя определяем методологию управления проектом.

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

Методологии в проектном менеджменте, при правильном использовании, снижают неопределенность.

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

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

В простых коротких «прогулках» «карта» может ни разу и не потребоваться. Однако я не рекомендовал бы пускаться в более или менее серьезное путешествие без навигации.

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

В настоящий момент, к числу наиболее распространенных практик и подходов к управлению в ИТ- проектами можно отнести следующие:

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

В основу российского ГОСТ 54869-2011 так же заложена методология  PMI и положения свода знаний PMBoK.

 

 

Компоненты проекта

Мы уже говорили об ответственности менеджера проекта (за «треугольник» и за «проект в целом»). Настало время точнее определить оба тезиса и пояснить саму сущность проекта

Рассмотрим два термина: «продукт» и «проект».

Продукт - результат (или набор результатов) поставки по контракту. Продукт - это то, что хочет получить заказчик.

 Проект - это процесс создания продукта. Это то, что делает команда, чтобы выдать заказчику продукт. Заказчику, обычно, проект не интересен. Его в основном интересует продукт

Любой проект предпринят с целью получить продукт.

Заказчик согласен заплатить и подождать.

Причем и то и другое - в ограниченном количестве.

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

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

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

1.       Управление временем (мы должны уложиться в срок)

2.       Управление стоимостью (мы не должны превысить бюджет)

3.       Управление содержанием (нам нужно уточнить желания заказчика и правильно их реализовать)

Другие - менее очевидны:

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

5.       Управление рисками

6.       Управление закупками (если мы используем субподрядчиков)

7.       Управление персоналом

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

9.       Управление интеграцией

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

Некоторые исполнители также плотно работают с коммуникациями. Однако руководителю проекта придется удерживать в поле зрения весь спектр вопросов (в терминологии PMBoK они называются «областями знаний»).

Два других важных аспекта, которые часто ускользают от внимания ПМ, но имеют прямое отношение к успеху проекта: «удовлетворенность заказчика» и «документирование лучших практик».

Удовлетворенность заказчика - удерживает его как клиента.

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

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

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

Начало проекта принято называть «инициацией», а окончание – «закрытием».

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

Таким образом, жизненный цикл проекта можно представить в виде «удава»:

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

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

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

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

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

Итак, теперь мы понимаем, что наш проект инициирован (или будет инициирован) и вплоть до его закрытия будем заниматься управлением девятью «областями знаний»

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

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

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

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

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

Сейчас, в данный момент на Выходе мы получаем:

-         определен подход к управлению проектами.

Инициация проекта

Мы с вами определили подход к управлению проектами.

Теперь нам надо определиться со спонсором нашего проекта

Лучшие практики управления проектами (и в частности PMI) предполагают, что потенциальный ПМ участвует и влияет на принятие таких решений. Допустим, вы получили приглашение на совещание, где будет решаться вопрос о старте вашего проекта.

Давайте сейчас введем понятие «спонсора».

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

Ведь мы с вами отныне смотрим на проект газами ПМ. Значит спонсором для нас является тот, кто НАМ утверждает стоимость проекта (а также что за эту стоимость стоит сделать).

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

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

Всегда определяйте спонсора на проекте! Это знаковая фигура для вас, как для ПМ.

Договариваемся со спонсором проекта

Итак, мы получили приглашение на совещание со спонсором (кем бы он ни был). О чем нам стоит позаботиться?

Во-первых - об ограничениях.

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

У нас нет «треугольника» и нам не за что пока отвечать.

Помните, о чем мы говорили в насале?

Об ответственности ПМ!

На Проектном менеджере лежит вся ответственность в рамках «проектного треугольника».

Создавайте его. Не позволяйте сделать вас ответственным за проект, не имеющий рамок!

В противном случае  или фиксируйте их отсутствие.

Имейте в виду, что спонсор не всегда думает «на вашем языке». У него свои проблемы.

Он склонен «забывать» о некоторых ограничениях или не вспоминать о них вовсе.

Просите и настаивайте на обсуждении ограничений!

Во-вторых - о предварительных оценках.

Мы понимаем, что в фазе инициации возможно только высокоуровневое планирование, «грубые оценки»

Грубые оценки (ROM-estimate) - предполагают отклонение до 50%.

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

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

Настаивайте на приблизительности оценок.

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

В-третьих - о достижимости по ставленных целей.

Мы четко понимаем свою роль.

Менеджер проекта отвечает за проект в целом.

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

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

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

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

Сделайте это до принятия решения об участии в проекте.

В-четвертых - о формализации договоренностей.

Важнейшим выходом группы процессов инициации является документ под названием «устав проекта». Этому документу мы уделим особое внимание.

Формируем устав проекта

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

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

Фундаментальное свойство устава - его неизменность. Это самый стабильный документ проекта (именно потому, что он задает базовые рамки). Нередко, когда у спонсора или у команды возникает необходимость «поменять устав» - принимается решение просто закрыть текущий проект и запустить новый (с новым уставом).

Почему устав так важен? Причин две.

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

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

Причина вторая: устав фиксирует треугольник.

Вы ПМ и вы договорились со спонсором.

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

Вас это не волнует!

У вас есть устав.

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

 Цель процесса инициации: формальное открытие проекта.

Выходы процесса определяются и документируются следующими параметрами проекта:

- наименование проекта;

- причины инициации проекта;

- цели и продукты проекта;

- дата инициации проекта;

- заказчик проекта;

- руководитель проекта;

- куратор проекта.

Кто пишет устав?

Лучшие практики гласят: устав создается ПМ и утверждается спонсором. Как будет показано ниже - руководитель проекта максимально заинтересован в уставе (а с ним и вся команда, которой он руководит). Посему создание устава - дело ваших рук; если не проявите инициативу - документ не появится.

Как вам написать свой устав проекта? Один из возможных примеров приведен на рисунках. Многие аспекты пояснены внутри самого шаблона.

Некоторые разделы устава могут оказаться неактуальными на вашем проекте. Другие - стоит заполнять всегда, перечислим их:

1.       ФИО ПМ

2.       Тройственное ограничение:

a.       Срок

b.       Бюджет

c.       Содержание работ по проекту (укрупненно)

3.       Заинтересованные лица (самые ключевые - как минимум спонсор и заказчик)

Пункты 2 и 3 иллюстрируют, что вклад в планирование проекта начинается задолго до его начала.

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

Чрезвычайно полезный раздел устава - «что не является» требованием к продукту.

Несмотря на то, что его нельзя назвать обязательным - не пренебрегайте им, по возможности.

Чего не стоит делать в ходе инициации проекта

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

Перечислим некоторые возможные ошибки менеджера проекта в данной фазе:

 Нельзя пресекать помощь в по строении грубой о ценки.

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

Хорошего в этом мало.

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

 Нельзя использовать раздувание оценок ( padding).

Как бы ни была сложна ваша оценка - не перестраховывайтесь, завышая ее.

Оцените проект как можете и назовите диапазон колебания (+/- 50%). Если диапазон получается больше - ищите способ повысить точность оценок, или предложите спонсору разбить его на несколько подпроектов.

Не бойтесь давать оценку с диапазоном.

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

Нельзя бояться увольнения.

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

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

Не шантажируйте работодателя - следите, чтобы ваши требования оставались честными и обоснованными.

Выходы:

-         спонсор утвердил руководителя проекта

-         объявлено о запуске проекта

-         утвержден устав проекта

Стадия планирования

Для чего нужны планы?

Устав подписан. «Хвост удава» миновал. Следующий наш шаг - планирование.

Ему в проектном управлении отводится особое место. Одна из парадигм гласит - «если это нельзя спланировать, это нельзя и сделать».

Для чего нам нужны планы:

1.       Чтобы не забыть что-то существенное во время выполнения проекта

2.       Чтобы любой член команды сам, не «дергая» менеджера, в любой момент времени ПОНИМАЛ, «что ему делать сейчас»

3.       Чтобы общаться.

Для чего планы не нужны:

-         Для наказания

-         Как самоцель.

Необходимо осознать что планы - это средство коммуникации .

Значимость коммуникаций неизмерима, а сбой - всегда бедствие.

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

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

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

Как писать правильные планы

Создавая планы - важно правильно к ним относится.

 План - это не «клятва», а «прогноз».

Во многих сферах (в том числе и в сфере информационных технологий) невозможно совершенно точно прогнозировать продолжительность, а порой и состав работ.

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

 Планируйте с «диапазоном».

Не выдавайте (и не требуйте) точную оценку там, где ее дать нельзя. Донесите до всех членов команды и экспертов, которые помогают вам планировать проект, что вы не просите с них клятву «уложиться к определенной дате», вам нужна реалистичная оценка и возможные отклонения от нее. Однако настаивайте на реалистичности оценок. Говоря об инициации проекта, мы отмечали, что приемлемой является «грубая» оценка (с диапазоном колебания до +/-50%).

В ходе планирования такая точность нас не устраивает.

В зависимости от того, как глубоко мы продвинулись - приемлемым диапазоном может быть +25/-10% или +/-10% и так далее.

 Опасайтесь раздувания оценок (padding).

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

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

К счастью - этот навык тренируем. Начните вырабатывать его уже на первом проекте.

 Планы будут изменяться. На это необходимо ориентироваться сразу.

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

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

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

«План управления проектом»

Введем новый термин

 «План управления проектом»

 План управления проектом - это совокупность всех проектных планов.

Вдумайтесь в определение.

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

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

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

Помните «области знаний»? 

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

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

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

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

Корректировка «плана управления проектом» - осуществляется в течение всего проекта, в ответ на изменившиеся внешние условия, реализовавшиеся риски и т.д.

Предсказать, где и когда понадобятся изменения заранее невозможно, посему их не планируют заранее, а осуществляют при помощи механизма «контроля изменений» О нём разговор будет позже..

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

Один из вариантов «лучшей практики» приведен ниже

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

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

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

Определите, устраивает ли вас приведенный выше сценарий (или просто решите опробовать его в своем проекте).

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

«План управления проектом» и контракт

Многие элементы «планов» уже прорабатывались во время инициации и были включены в устав.

Тут нет противоречия.

В фазу инициации мы создавали грубые (ROM), высокоуровневые оценки.

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

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

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

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

Один из наиболее приемлемых вариантов изображен на схеме. 

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

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

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

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

Выходы:

-       определен состав «плана управления проектом»