Зачем менеджеру знать миссию проекта?

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