• Поскольку всегда могут возникнуть неожиданные препятствия, следует анализировать риски, чтобы быть готовым к наиболее вероятным из них (см.
главу 6
). На случай, если не сработает план А, всегда имейте план Б. Почему же не использовать план Б с самого начала? Потому что план А лучше, но имеет несколько слабых моментов. У плана Б такие моменты тоже есть, но они отличаются от аналогичных моментов плана А, иначе нет смысла расценивать план Б как альтернативу.
• Самый простой способ проанализировать риски – это задать себе вопрос «Что может пойти не так?» и отнести его к расписанию, производительности и другим частям плана проекта. Иногда сама по себе идентификация рисков помогает их избежать. Но если это невозможно, у вас есть план Б. Одно предупреждение: если вы имеете дело со слишком сильными в анализе людьми, помните, что они склонны к параличу решений. Так что не старайтесь предусмотреть все возможные риски, предупредите хотя бы наиболее вероятные.
• Начните с определения цели того, что должно быть сделано. Сформулируйте проблему. Все действия в организации должны быть направлены на достижение результата – это один из способов сказать «реши проблему». Будьте осторожны с тем, что действительно необходимо конечному потребителю для решения его проблем. В некоторых проектах, по мнению команды, решение осуществляется в интересах клиента. Однако в действительности оно никогда не используется, что приводит к серьезным потерям для организации.
Подумайте о маленькой мышке. Как дальновидно это животное, которое не доверяет свою жизнь только одной норке.
Плавт (254–184 гг. до н. э.)
• С помощью ИСР (подробнее это обсудим в главе 7) разделите работы по проекту на меньшие порции, по которым можно дать более точные оценки по срокам, стоимости и потребностям в ресурсах.
Пошаговое планирование проекта
Обратите внимание, что некоторые из этих тем рассматриваются в следующей главе.
• Сформулируйте проблему, которую необходимо решить с помощью проекта.
• Разработайте документ о миссии проекта наряду с документом о его главных целях.
• Разработайте стратегию проекта, которая позволит решить его цели.
• Создайте документ о содержании проекта, который очертит его границы (что будет и не будет сделано).
• Разработайте иерархическую структуру работ (ИСР).
• С помощью ИСР оцените сроки, потребности в ресурсах и стоимость различных этапов проекта (с учетом возможного воздействия на окружающую среду).
• Подготовьте генеральное расписание проекта и его бюджет.
• Решите, по какому принципу строить организационную структуру проекта: по матричному или иерархическому (если можете выбирать).
• Составьте план проекта.
• Побудите все заинтересованные стороны подписать план проекта.
Резюме
• Если у вас нет плана, то нет и контроля.
• Люди, которые должны исполнять план, должны участвовать и в его подготовке.
• План должен быть подписан на специальной встрече, а не путем рассылки писем.
• Вся информация по плану должна храниться в файлах в электронном виде.
• Используйте «критерии выхода», чтобы определить выполнение значимого этапа плана.
• Требуйте, чтобы изменения в плане были утверждены до того, как вы приступите к их осуществлению.
• Управление рисками должно быть составной частью работы по планированию проекта.
• Парадигма – это вера в то, как устроен мир.
• Планирование – это ответы на цепочку вопросов кто / что / когда / где / почему / сколько / как долго.
• Логистика связана с обеспечением людей материалами и ресурсами, необходимыми для выполнения работы.
Упражнение
Мы говорили о стратегии, тактике и логистике.
В отношении чего нужно принимать решение в первую очередь?
а) стратегии;
б) тактики;
в) логистики;
г) не имеет значения.
Какова функция тактики?
Когда нужно планировать логистику проекта?
Ответы на вопросы
Глава 4. Управление заинтересованными сторонами в планировании проекта
В главе 3 отмечается, что заинтересованная сторона проекта – это любое лицо или организация, имеющая в нем свой интерес, иными словами, свою долю в результатах проекта. Данная категория может включать в себя участников и исполнителей проекта, клиентов, менеджеров и лиц, финансирующих проект. Институт по управлению проектами определяет заинтересованные стороны как «лицо, группу или организацию, которая может влиять, на которую могут повлиять или которая может осознавать себя подвергнутой влиянию решения, операции или результата проекта». Независимо от роли, которую заинтересованные лица играют в проекте, они должны быть определены, или идентифицированы, и должны являться объектом управления на протяжении всего жизненного цикла проекта, потому что оказывают прямое влияние на его успех или неудачу.
На заре своей карьеры в авиастроительной корпорации Grumman Aerospace я входил в команду специалистов по закупкам, которым было дано указание создать и задействовать систему оценки эффективности работы поставщиков. Команда у нас была хорошая, и трудились мы напряженно, но никто из нас не имел никакой подготовки в области управления проектами. В результате одни мероприятия по планированию проекта были осуществлены, другие – нет. Особенно это касалось управления заинтересованными сторонами. В частности, мы забыли подключить к созданию новой системы важную группу – техасскую штаб-квартиру компании. Они были очень недовольны. Деловой этикет не позволил этому подразделению высказать то, что они думали, напрямую. Но для них было болезненно выполнять наши предложения. Они задержали проект и создали вокруг него крупный конфликт. Если бы мы с самого начала правильно определили все заинтересованные стороны проекта, то завершили бы его в срок и в пределах отведенного бюджета. Эта невынужденная ошибка не должна была произойти.
Определение приоритета заинтересованных сторон по их отношению к проекту
Управление заинтересованными сторонами не обязательно сложно, но все же требует определенных усилий. Оно начинается с определения индивидуальных представителей этой категории, для чего ставятся три основных вопроса.
1. Кто получает выгоду от проекта? Обратите внимание на ожидаемые конкретные результаты проекта и на то, кто получит от них выгоду. Результатом может быть практически все что угодно, включая новый процесс внутри организации, приложение к программному обеспечению или новый продукт, выпускаемый на рынок.
