Отличия больших проектов от маленьких

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

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

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

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

Пример Устава на большой проект

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

УСТАВ БОЛЬШОГО ПРОЕКТА

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

Менеджер проекта и уровень полномочий (кто назначен рулить проектом, и может ли определять, управлять, утверждать изменения в бюджет, расписание, команду?). Менеджером проекта будет Иван С. Он вправе выбирать подходящих участников команды, и требовать с их менеджеров назначения на проект. Право подписи дано до $10.000.

Бизнес-кейс (зачем проект затеян? какими финансовыми или иными профитами он обусловлен?). Администрирование текущей системы учета зарплаты обходится компании в $2.4M в год, не считая неизмеримых издержек от неэффективных процессов. В среднем по отрасли, компании нашего масштаба тратят по $100 на работника в год, то есть всего $2M. Ожидаемая экономия в $400.000 в год, с учетом трехлетнего периода окупаемости, и будет обоснованием проекта. Детальный бизнес-кейс к Уставу прилагается.

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

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

Значимость Устава для Project Manager'а

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

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

1. Устав проясняет и укрепляет взаимопонимание РМ и спонсора о ключевых продуктах проекта и временных вехах. Определяет ключевые роли и ответственности. Информация из Устава расшаривается на всех стейкхолдеров
2. Устав формально авторизует и признает проект. То есть проекта без Устава нет
3. Устав дает РМ право проводить расходы
4. Устав дает РМ право назначать корпоративные ресурсы на проект. Этот кейс очень часто встречается на экзамене! В большинстве проектных ситуаций, персонал не подчиняется РМ, что ведет к проблемам в общении и исполнении проекта. Устав помогает это предотвратить
5. Устав дает цели, высокоуровневые требования, и критерии успеха проекта
6. В процессе создания Устава раскрываются предположения о проекте, впоследствии они могут быть развернуты в конкретные усилия по сбору требований, определению содержания, и работе с рисками
7. Устав связывает проект с текущей работой Компании

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

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

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

УСТАВ НЕБОЛЬШОГО ПРОЕКТА

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

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

Процесс Разработки Устава проекта

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

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

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

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

Рассмотрим подробно.

1. Бизнес-кейс. Это обоснование проекта или инициативы. Многие компании требуют сильного бизнес-кейса, чтобы обосновать выделение средств именно на данный проект среди многих. Бизнес-кейс требует анализа; но он дает понять компании, стоит ли лезть в проект. На экзамене предполагаем, что у проекта есть бизнес-кейс, и вообще невозможно выбрать проект к реализации без здорового бизнес-кейса. Бизнес-кейс отражает потребности бизнеса, он объясняет выбор проекта, как проект вливается в стратегические цели компании, как принесет компании ценность. То, что каждая данная компания считает ценностью, может отличаться, но это за рамками подбора проекта. Пример того, как бизнес-кейс влияет на управление проектом. "Компания выбрала проект, поскольку он привнесет в стратегический план освоение новых областей бизнеса. У РМ план управления проектом, в числе которого - расписание и бюджет. РМ обнаруживает, что сумма зааппрувленного бюджета - это ограничение, которое не позволит зайти на рынок. Она предпочтет увеличить бюджет (не резать косты), чтобы остаться внутри плана управления проектом. Если бы она не попросила прибавки бюджета, то цель проекта не была бы достигнута, на новые рынки компания не вышла бы."
2. План управления выгодами. Это документ, фиксирующий выгоды компании от желаемого проекта, будь то экономические или нематериальные выгоды, и объясняющий, как эти выгоды будут достигнуты и максимизированы. Также, план управления выгодами определят метрики и процессы измерения этих выгод. Как вход для Устава, план управления выгодами важен тем, что дает информацию, как цели проекта идут в линии со стратегическими целями компании.
3. Реестр предположений. Очень важно выявить и задокументировать высокоуровневые ограничения и предположения проекта во время инициации. Обычно они документируются как часть бизнес-кейса; можно их включить и в Устав, чтобы спонсор подписался под ними. Также, включаем детальные ограничения и предположения в Реестр предположений. Ограничения это факторы, которые лимитируют число вариантов к выбору для команды. Например это бюджет, или ресурсы, или сроки. Предположения это вещи, которые мы считаем за истину. Например, "считаем, что нам не надо одобрения Главного инженера для старта проекта". Ограничения и предположения это входы во многие процессы управления проектом. Они определяются на высоком уровне во время инициации проекта, и далее проясняются и документируются в деталях в ходе процесса Определения содержания этапа планирования проекта. Как только мы определили ограничения и предположения, ими надо управлять. Спонсор, команда, и иные заинтересованные стороны должны помогать определять ограничения и предположения, а также проводить их ревью для переоценки значимости по ходу проекта. Если ограничения меняются, или предположения поданы неверно, то вероятно изменение плана управления проектом. Анализ предположений - это часть процесса управления рисками.
4. Соглашения и контракты. Все проекты, будь то внутренние или на клиента, должны иметь Устав. Разработка Устава часто начинается с какой-то формы соглашения или понимания. Для внутреннего проекта, это может быть какое-то неформальное письмо, или разговор о производных проекта, или иное соглашение о намерениях. Для внешних проектов нужен контракт, без контракта работать нельзя. На внешних проектах, Устав должен быть и у поставщика, и у покупателя, свой у каждого, отражающий нужную точку зрения. Причины покупателя на проект - получить определенный продукт в рамках ограничений. Причины поставщика на проект - рост выручки, репутации, доп.работы от клиента. При разработке Устава проекта, надо принимать во внимание процессные активы компании, и факторы среды компании. Устав должен разрабатывать РМ вместе со спонсором, предполагаем, что на двоих у них есть экспертиза по предмету проекта и аспектам Устава.