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

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

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

Изменения следует вносить в следующих случаях:

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

• при проведении согласованных изменений. Если заказчик принимает изменение, которое сказывается на продолжительности или бюджете проекта, оно должно быть отражено в плане или бюджете;

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

Когда возникает такая ситуация, перечитайте соответствующие разделы второй главы.

• Помните пословицу «За день нельзя опоздать больше чем на день» и контролируйте выполнение работ. Отставание от плана на две недели не возникает внезапно, это результат опозданий, накопившихся за десять рабочих дней.

• Чтобы оценить, как выполняется проект, определите, насколько далеко вы продвинулись по плану, и проанализируйте тенденцию.

• Расходуйте резерв пропорционально ходу выполнения.

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

• Не допускайте неконтролируемых изменений в проекте.

• Управление проектом построено на преодолении всех обстоятельств, мешающих его выполнению.

• Постоянно информируйте заказчика о ходе работ.

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

Формы отчета, реестры рисков, проблем и изменений в форматах MS-Word и MS Excel доступны на сайте: http://www.pearson-books.com.

Рассмотренная тема очень важна для управления проектами и поэтому раскрывается практически во всех работах, хоть и не всегда одинаково хорошо. Отдельным проблемам, скажем управлению рисками, посвящены тома объемом в несколько сот страниц, при желании, конечно, вы с ними можете ознакомиться, хотя эти знания, скорее всего, вам понадобятся лишь в особых случаях. Я рекомендую ознакомиться со следующими материалами: The Project Workout (Financial Times Prentice Hall) by Robert Buttrick, 2nd edn, 1999, Chapters 21–25. The Project Manager: Mastering the Art of Delivery (Financial Times Prentice Hall) by Richard Newton, 2005, Charters 5, 7 and 10. The Definitive Guide to Project Management (Financial Times Prentice Hall) by S. Nokes et al., 2003, Chapters 4–7. Practical Project Management: Tips, Tactics and Tools (Wiley) by Harvey A. Levine, 2002, Chapters 4–8.

Приготовьтесь начать проект. Готовы ли вы провести стартовую встречу? Ее следует тщательно спланировать. Если вы проведете ее как надо, у вас будет мотивированная и энергичная команда; если провалите – доверие к вам как к менеджеру проекта может быть подорвано.

Управление проектом должно быть прозрачным. Убедитесь, что у вас есть все необходимые формы и документы, что вы знаете, как их использовать, и понимаете, кто из членов команды имеет право доступа к ним. Определите, будете ли вы рассылать их по электронной почте, выкладывать на сайт или станете использовать варианты, распечатанные на бумаге?

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

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

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

ТЕМА ГЛАВЫ

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

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

ОСНОВНАЯ МЫСЛЬ

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

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

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