Be careful what you promise: structuring an engagement (Будьте осторожны, когда даете обещания. Структурирование проекта.)

Когда клиенты приходят в McKinsey то, они хотят, чтобы их проблемы решили уже вчера и бесплатно. К счастью, большинство из них понимает, что это желание немного нереалистично. Занимаясь структурированием проекта (обычно за это отвечает – директор по обслуживанию клиентов (DCS)[7]) или директор проектов), компания сталкивается с ситуацией, когда от нее хотят максимум результата за минимальное время. McKinsey практикует почасовую оплату, при том, что ее время стоит недешево.

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

Работая с клиентом по решению одной проблемы, McKinsey практически всегда находит дополнительные возможности для улучшения его бизнеса. Эти проблемы могут быть разрешены в другое время и во время других проектов. Вследствие этого, одни проекты ведут к возникновению других. Таким образом, до тех пор пока клиенту нравится результаты работы, компания имеет поток новых заказов (за которые она очень часто не должна конкурировать).

Компания чрезвычайно хорошо определяет, сколько команда консультантов может сделать на протяжении типичного проекта. Лучшие директора проектов могут сбалансировать две конкурирующие между собой потребности клиентов, с одной стороны и группы проекта, с другой. Они говорят клиенту так: «Мы собираемся сделать X и Y. Мы можем сделать еще и Z, но это убьет команду». Разговаривая с консультантами они заявляют: «Мы уже обещали клиенту, что поработаем над проблемой Z, поэтому мы должны сделать это». Затем они добиваются от команды работы на пределе и одновременно дают понять клиенту, что он получает больше за свои деньги, тем самым превышая его ожидания.

Конечно, не каждый директор проекта настолько хорош. В мое время один из них имел репутацию человека, который завышает обещания для клиентов, а затем проводит команду через ад. Консультанты старались избегать таких директоров, которые имели смутное понимание о том, что такое конечный продукт и and left the team to figure out just what it was supposed to do.

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

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

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

Структурирование проекта, еще не гарантирует его успех, но, это, как минимум, позволяет взять верный старт.

Assembling a team (Составление команды)

About teams at McKinsey

В McKinsey вы никогда не работаете в одиночку. Все, что происходит в компании, происходит в команде. Начиная с работы на проекте, и кончая разработкой и принятием решений о внутренней политики компании. Самая маленькая команда, в которой я когда-либо работал, занималась pro bono для театральной компании из Нью-Йорка. С другой стороны, на проектах для некоторых крупнейших клиентов могут работать несколько команд, состоящих из пяти или шести консультантов одновременно. Эта своего рода «метакоманда». В начале девяностых члены метакоманды, работавшей по проекту AT&T, решили собраться вместе для обсуждения своей работы. В штаб-квартире компании не нашлось достаточно вместительного помещения для всех, поэтому они были вынуждены заказать отель.

McKinsey полагается на команды, потому что это – лучший способ для решения проблем, стоящих перед клиентами. Сложность этих проблем не позволяет одному человеку справится с ними, по крайней мере в тех высоких стандартах, которые требует компания. Больше людей значит, что у вас есть больше рук, чтобы собрать вместе данные и, что еще более важно, что у вас есть больше голов, чтобы понять, что значат все эти данные. Столкнувшись со сложными проблемами в вашем бизнесе, вам, видимо, также следует собирать команды для их решения. Больше рук не значит только то, что работа будет легче, это также означает, что результат будет лучше.

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