Он обязательно воскликнет: «Почему так дорого?» У него в голове была своя цифра, а ваша ее явно превосходит. Он может сказать: «Если это столько стоит, мы не оправдаем свои расходы». Вот именно! Это именно то решение, которое заказчик должен принять. Однако он уверен, что ему удастся склонить руководителя проекта на снижение стоимости. И если вы согласитесь, то только ввяжете и заказчика, и себя в гораздо более серьезные проблемы, которые возникнут позднее.
Назвать спонсору настоящую цену – ваша обязанность. Это нужно, чтобы он принял правильное решение относительно данного проекта. Если поддаться давлению и подписаться на более низкую сумму, позже случится катастрофа. Поэтому для вас гораздо лучше понести возможное наказание сейчас, чем быть повешенным позднее.
Разумеется, есть и другая возможность. Если визави говорит, что может позволить себе заплатить только такую-то ограниченную сумму за проект, вы можете предложить ограничить его содержание или объем. Если проект годится и с таким объемом, он может быть осуществлен. Иначе разумнее и экономнее вообще забыть о нем и взяться за что-то другое, более прибыльное. Кто-то сказал, что скорее в проекте случайно что-то пойдет не так, чем все пройдет идеально. Что касается стоимости проекта, бюджет наверняка будет превышен. Это просто другой вариант изложения закона Мёрфи: «Если какая-нибудь неприятность может случиться, то она обязательно произойдет».
Фазы проекта
Существует множество моделей деления проекта на фазы его жизненного цикла. Одна из таких моделей, которая отражает весьма распространенный тип проблемных проектов, представлена на рис. 1.2.
Рис. 1.2. Жизненный цикл проблемного проекта
Я показывал этот рисунок разным людям по всему миру, и все они улыбались и говорили: «Да, именно так все и происходит». Меня в этой ситуации успокаивает лишь то, что не только американцы сталкиваются с подобными проблемами. Плохо то, что если все признают эту модель, то многие проекты обречены на неудачу.
На простейшем уровне проект имеет свое начало, середину и конец. Я предпочитаю модель жизненного цикла проекта, изображенную на рис. 1.3, но и другие варианты имеют право на существование. В моей модели вы увидите, что любой проект начинается с расплывчатой концепции и команда должна сформулировать содержание работ до того, как к ним приступать. Однако нередко мы начинаем работать над проектом исходя из того, что имеем его правильное определение или что участники разделяют его цели и понимание необходимой работы. Это неизменно создает трудности по мере продвижения проекта (рис. 1.3).
Рис. 1.3. Правильный жизненный цикл проекта
Несколько лет назад управляющий проектом одной компании, которая тогда была моим клиентом, пригласил меня к себе и сказал: «Я только что провел онлайн-конференцию с ключевыми сотрудниками моей команды и понял, что мы не можем прийти к единому мнению о том, чего должен достичь наш проект».
Я ответил, что такая ситуация складывается довольно часто.
«И что же мне делать?» – спросил он.
Я ответил, что ему придется заставить членов своей команды двигаться в одном направлении, объяснив им, какая высокая цель или миссия стоят перед проектом. Он попросил меня помочь провести такую встречу.
На встрече я подошел к доске и сказал: «Давайте запишем, какая проблема стоит перед нами». Кто-то сразу же возразил: «Не нужно, мы и так знаем, в чем проблема».
Я, не смутившись, ответил: «Ну что ж, если так, то записать ее – пустая формальность, на это потребуется всего несколько минут. Мне удобнее, если она будет изложена письменно. Поэтому прошу вас помочь нам начать».
Далее можно было позабавиться. Кто-то сказал: «Но…» Я записал это на доске. Кто-то воскликнул: «Я с этим не согласен!»
Через три часа мы, наконец, завершили письменное формулирование проблемы.
Руководитель проекта оказался прав. В его команде не было единого мнения ни о том, в чем состояла проблема, ни о способах ее решения. Я с этим сталкиваюсь настолько часто, что начинаю думать, что у всех нас есть некий дефектный ген, который мешает правильно сформулировать проблему, прежде чем приступать к работе над ней. Помните: руководитель проекта решает проблему в большом масштабе. И от того, как вы ее сформулируете, зависит, как вы будете ее решать. Если проблема определена неправильно, то вы можете найти правильное решение, но не для данной конкретной проблемы!