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

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

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

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

• понять их потребности;

• определить, что ожидается от отчетности и производительности;

• узнать, какие есть вопросы и затруднения;

• выявить предпочитаемые процессы общения;

• сократить потенциальные конфликты;

• выработать настрой на сотрудничество.

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

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

Вот что одна студентка рассказала о схеме заинтересованных лиц.

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

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

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

ХОСЕ: В конце 2006 года я присоединился к высокотехнологичной компании, став руководителем отдела разработки возможностей учета продукта «Программа как услуга» (SaaS), который компания хотела запустить к середине 2007 года, то есть через девять месяцев. Одновременно компания пыталась освоить приобретение, которое она сделала год назад, и столкнулась с серьезным вызовом — проблемой совмещения с системой Oracle ERP. Прошел год после покупки, совмещения систем ERP так и не произошло, и руководство IT вынуждено было сфокусироваться на этой задаче.

РЭНДИ: Почему это стало приоритетом?

ХОСЕ: Было сложно разобраться со счетами. Приобретенная компания оказалась почти такой же большой, как та, что ее купила. К тому же рынок акций не радовал. Так что CEO требовал решить эту задачу. Невозможность совмещения с системами ERP означала, что бухгалтерии приходилось работать вручную, что влияло на эффективность работы всей организации. Поэтому все остальные проекты, включая мой, отложили на неопределенный срок. Однако дата запуска продукта SaaS оставалась прежней — май 2007-го!

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

Я забросил идею использования Agile в комитет управленческого анализа, вице-президентам из IT и заказчику. Поскольку компания потратила немало времени и ресурсов на то, чтобы разработать собственную каскадную методологию, я услышал предсказуемый ответ: «Вы будете использовать нашу [каскадную] методологию!» Что мне было делать? Часики тикали, а наш проект все еще откладывали.