Юноше, обдумывающему житье: путеводитель по желто-серому миру, часть 10
Попробую подступиться к описанию проектного процесса глазами менеджера.
Любой лид (lead, зачаток проекта) начинается с технического задания (ТЗ, RFP) от клиента или, в более простых случаях, обычного емейла, который спускает партнер. Собственно, уже на этой стадии лид должен быть занесен в систему ради великой цели Пайплайна/Финансового Планирования, но никто этого не делает, потому что степень неопределенности еще очень высока, а отчитываться надо, хотя бы по причинам проигрыша, ну его на фиг. ТЗ все вовлеченные лица внимательно читают, а потом делятся ощущениями, чаще всего нехорошими. Опытный партнер здесь играет ключевую роль, потому что чует риски, кроющиеся за обтекаемыми формулировками. Потом готовится пропозал (предложение). Опять же, в теории, да и во многих компаниях на практике, пропозал уже обязан быть зарегистрирован в системе и отслеживаться, но в моем конкретном случае все не сильно следовали данному правилу. То есть время на подготовку (с ведения партнера, вестимо) записывать себе было можно, а в непересекающейся параллельной вселенной - системе учета проектов - пропозал нигде мог и не засветиться.
Подготовка пропозала - отдельная тема. В четверке он делается в пауэр пойнте и чаще всего становится площадкой для самовыражения партнеров и желающих стать оными. Основная цель, как ее понимают многие старшие внутри компании - впечатлить клиента. Мол, раз мы ТАКОЕ можем еще на бесплатной стадии, представьте, что мы сможем за деньги? Ради нескольких слайдов презентации лопатятся горы информации. В моем благословенном Advisory креативный компонент пропозала также ставился во главу угла. Помнится один тендер для метрополитена, когда партнеру за несколько дней до подачи в голову пришла великолепная идея планируемые направления деятельности графически представить цветами линий метро, да и навигацию по презентации оформить соответственно. Этот труд с содроганием вспоминали все задействованные. (Когда полгода спустя на корпоративе аниматор, желая повеселить публику, рассказывал про первые профессии наших начальников и упомянул, что пресловутый партнер начинал художником-оформителем, участники зондер-команды по подготовке метро-тендера обменялись очень нехорошими взглядами.) По подготовке пропозалов регулярно проводятся тренинги, на которых можно почерпнуть интересные фишечки (особенно если тренинг ведет какой-нибудь бывший маккинзоид), где везде говорят о корпоративном стиле и принципах построения правильного пропозала, но все равно в итоге стиль и оформления, и выражения мыслей скачет от партнера к партнеру. Один партнер мне как-то снизил оценку за то, что я не следовала его принципу "одна мысль - один слайд", хотя до этого эсэм того же отдела полгода дрючила меня "содержательностью" слайда, где каждый миллиметр заполнялся анализом.
На стадии пропозала заводится проектная папка, которая выкладывается в сети в соответствующем каталоге. (Диск такой-то/Дивизион/Пропозалы/Финансовый год такой-то/...) Каталог пропозалов своего дивизиона - полезнейшая штука. Оттуда можно потырить массу полезных слайдов и умных выражений, уж не говоря о подборках материалов, сэкономив себе кучу времени. Однако многие манагеры ревностно относятся к своим детищам и паролят даже папки с пропозалами, выделяя доступ лишь проверенным избранным. В папке пропозала классическое наполнение - подкаталоги Admin (бюджет, стаффинг, прочие бумажки), RFC (Received from Client и все вариации на эту тему), SUBMIT (то, что получил клиент), в том или ином виде валяются десятки версий пропозала (в зависимости от педантичности манагера, они могут гордо сортироваться от v.1.1 до какой-нибудь v.8.17, а могут и быть такие чудные названия, как ,,,,proposal_27_fin_fin_fin_FIN_DO_NOT_CHANGE ) и папочка Zzz (ненужное старье, но пусть валяется тут). В случае успеха материалы потом перекочевывают в проектную папку, где уже порядка больше, и подпапочки уже имеют порядковые номера.
Осилив классические слайды "Наше понимание ваших потребностей" и "Наш подход", посадив стафят рисовать аналитическую часть, а интерна искать самые красивые иллюстрации в маркетинговом банке изображений, манагер запускает процедуру проверки клиента и рисков (заполнив формочку всего навсего в 48 вопросов и отфутболив ее партнеру и в Quality & Risk Management) и начинает подбивать бюджет. Расчет бюджета производится несколькими способами. Самый простой и любимый - это когда сначала его на бухгалтерском калькуляторе считает партнер и показывает цифру манагеру. Манагер, ориентируясь на партнерскую цифру, делает расчет старым добрым дедовским методом - в Excel. До недавних времен все было мило и просто - по дивизионам гуляли толково сделанные шаблоны бюджетов, оставалось только поставить имена и грейды сотрудников, и вбить расход времени, бинго. Ну и раз в год ставки обновить. Ставки, billing rates и cost rates, также рассылались в Excel. Но путь прогресса неисповедим, и примерно за год до моего ухода компанию стали постепенно переводить на глобальную онлайн платформу, которая должна была интегрироваться с кучей прочих. В этой платформе, чтобы найти, скажем, ставку синиора 2 года в Advisory, надо было долго и муторно искать ее в громадном разветвляющемся списке (Global-EMEA-Eastern Europe-Russia and CIS-Russia-Currency-FY20XX-Advisory-Moscow-Staff-Senior-Senior2), потом формировать онлайн-формочку, потом сабмиттить ее куда-то в космос, а вот в Excel как раз она выгружалась плохо, поэтому все по возможности старались избегать этой платформы - думаю, все же в итоге всех заставили на нее перейти.
Второй способ, разумеется, противоположный, топ-даун. Применяется, когда речь идет о тендере с уже заявленной максимальной суммой, о клиенте, границы финансовых возможностей которого хорошо понятны, или о случае, когда мы только что посчитали бюджет первым способом, партнер доволен, загрузка людей по времени нормальная, сроки соблюдаются, а сумма в результате получается сопоставимая с бюджетом Российской Федерации такая, что в принципе уже можно пропозал не подавать. Тогда начинаем резать сроки и загрузку команды до сколь угодно нереальных, ни в коем случае не трогая святую святых - маржинальность.
В тучные времена маржинальность проекта в 40% была проходной (стандартной), по маржинальности 10-39% надо было писать объяснение, с чего такая благотворительность. Затем гайки подкрутили, и все ниже 50% стали отбраковывать - вплоть до того, что если партнер видел в пайплайне проект с маржинальностью 49%, он звонил и нехорошим голосом просил бюджет переделать. Уже после моего ухода даже сформировали Финансовый Комитет, который должен был рассматривать пропозалы с маржой ниже 50% и принимать по ним решения. Правда, инициатива была мертворожденной, поскольку появление Финансового Комитета совпало с кризисом в стране и полным отсутствием проектов, и поэтому когда одна очень правильная и блюдущая процедуры молодая манагерша потребовала официального одобрения Финансового Комитета на ее проект с 37% маржинальностью, но зато со стратегически важным клиентом, это вызвало небольшой переполох, который кончился тем, что после недели переписки один из членов комитета написал ей, что за полгода существования не было ни одного заседания, и мол пусть она не парится и спокойно запускает проект, хорошо что он вообще есть.
С начальной стадией вроде разобрались. Проект заматчен с матрицей оказания услуг (тот еще квест, особенно в российских условиях), получил свой уровень "среднего" риска (минимального практически не бывает), клиент проверен, удалось уломать второго партнера на quality review, формочки заполнены, стаффинг зарезервирован, пусть даже пришлось поругаться с парой других манагеров. Делаем огромный прыжок через протоколы разногласий, изменения ТЗ, бодание по контракту, подписание контракта, установочные встречи, первичные информационные запросы и (в случае крупного проекта) разделение команды на стримы. Дальше манагер убивает гору времени на план-график (в двух вариантах - для внутреннего пользования и для клиента) и отчетность по план-графику (клиенту, эсему и партнеру), и практически сразу же начинает готовить презентацию с промежуточным отчетом, параллельно туша пожары в стримах и оказывая регулярную психологическую поддержку клиенту. Если проектная группа выезжает в офис клиента, манагер еще и обязан решать вопросы с помещениями, ключами, интернетом для команды, бэкапами информации, поездками, расходами, чаем и печеньками, и прочая.
Каждый раз, когда манагер заходит в интранет, ему автоматом на главную страницу подгружается статистика по его текущему проекту - несколько графиков, драматически лезущие вверх (всякие там расходы времени в процентах от запланированного) или зловеще пикирующие (фактическая маржинальность), плюс выдается число дней неоплаты последнего счета и т.п. Вполне себе ничего, если все время напоминать себе, что план никогда реалистичным не был, да и де факто затраты еще больше, чем нарисовано. Тем временем проект катится себе куда-то, рано или поздно прибывая к точке сдачи. Проходят закрывающие презентации, клиент получает финальные драфты и пропадает с горизонта, а манагеру остается тема Закрытия Проекта.
Одно время все проектные документы и материалы должны были быть запротоколированы и заархивированы в каком-то информационном хранилище на вечные времена. Интерфейс у этого хранилища предполагал зашкаливающее IQ. Во всем Advisory до конца этой процедуры доходила только одна сотрудница. Я честно как-то выслушала ее инструкции, потратила неделю на попытки хотя бы сформировать опись по требованиям, а потом откладывала и откладывала продолжение этой мороки, пока не ушла в декрет. Когда я вышла из декрета, хранилище поросло быльем, но отчетность по каждому проекту надо было а) перевести на английский, б) санитизировать (т.е. убрать все конфиденциальные моменты), в) сделать резюме, г) заполнить формочку и д) выложить в глобальный банк обмена информации по проектам. Разумеется, большинство сотрудников, особенно не из англоязычных стран, начинали с пункта в), поэтому глобальный банк обмена информацией содержал 1-2 фразы о проекте самого общего характера ("консультационные услуги по формированию стратегии крупной компании такого-то сектора в Латинской Америке"), и самыми ценными там являлись имена участников.
Без оплаты финальных счетов, впрочем, никакого закрытия быть не может. А это растягивается на годы. Бывает, что недоволен клиент, часто очень сильно тормозят процесс иностранные офисы четверки. Бывает, что увольняются манагеры или даже уходят партнеры, следы документации проекта теряются в дебрях, проходят годы, а финансовый контролер отдела и наименее утилизированный манагер все пытаются выбить какие-то деньги по просроченной дебеторке, иногда подключая нового партнера, что делает предприятие еще более убыточным.
Любой лид (lead, зачаток проекта) начинается с технического задания (ТЗ, RFP) от клиента или, в более простых случаях, обычного емейла, который спускает партнер. Собственно, уже на этой стадии лид должен быть занесен в систему ради великой цели Пайплайна/Финансового Планирования, но никто этого не делает, потому что степень неопределенности еще очень высока, а отчитываться надо, хотя бы по причинам проигрыша, ну его на фиг. ТЗ все вовлеченные лица внимательно читают, а потом делятся ощущениями, чаще всего нехорошими. Опытный партнер здесь играет ключевую роль, потому что чует риски, кроющиеся за обтекаемыми формулировками. Потом готовится пропозал (предложение). Опять же, в теории, да и во многих компаниях на практике, пропозал уже обязан быть зарегистрирован в системе и отслеживаться, но в моем конкретном случае все не сильно следовали данному правилу. То есть время на подготовку (с ведения партнера, вестимо) записывать себе было можно, а в непересекающейся параллельной вселенной - системе учета проектов - пропозал нигде мог и не засветиться.
Подготовка пропозала - отдельная тема. В четверке он делается в пауэр пойнте и чаще всего становится площадкой для самовыражения партнеров и желающих стать оными. Основная цель, как ее понимают многие старшие внутри компании - впечатлить клиента. Мол, раз мы ТАКОЕ можем еще на бесплатной стадии, представьте, что мы сможем за деньги? Ради нескольких слайдов презентации лопатятся горы информации. В моем благословенном Advisory креативный компонент пропозала также ставился во главу угла. Помнится один тендер для метрополитена, когда партнеру за несколько дней до подачи в голову пришла великолепная идея планируемые направления деятельности графически представить цветами линий метро, да и навигацию по презентации оформить соответственно. Этот труд с содроганием вспоминали все задействованные. (Когда полгода спустя на корпоративе аниматор, желая повеселить публику, рассказывал про первые профессии наших начальников и упомянул, что пресловутый партнер начинал художником-оформителем, участники зондер-команды по подготовке метро-тендера обменялись очень нехорошими взглядами.) По подготовке пропозалов регулярно проводятся тренинги, на которых можно почерпнуть интересные фишечки (особенно если тренинг ведет какой-нибудь бывший маккинзоид), где везде говорят о корпоративном стиле и принципах построения правильного пропозала, но все равно в итоге стиль и оформления, и выражения мыслей скачет от партнера к партнеру. Один партнер мне как-то снизил оценку за то, что я не следовала его принципу "одна мысль - один слайд", хотя до этого эсэм того же отдела полгода дрючила меня "содержательностью" слайда, где каждый миллиметр заполнялся анализом.
На стадии пропозала заводится проектная папка, которая выкладывается в сети в соответствующем каталоге. (Диск такой-то/Дивизион/Пропозалы/Финансовый год такой-то/...) Каталог пропозалов своего дивизиона - полезнейшая штука. Оттуда можно потырить массу полезных слайдов и умных выражений, уж не говоря о подборках материалов, сэкономив себе кучу времени. Однако многие манагеры ревностно относятся к своим детищам и паролят даже папки с пропозалами, выделяя доступ лишь проверенным избранным. В папке пропозала классическое наполнение - подкаталоги Admin (бюджет, стаффинг, прочие бумажки), RFC (Received from Client и все вариации на эту тему), SUBMIT (то, что получил клиент), в том или ином виде валяются десятки версий пропозала (в зависимости от педантичности манагера, они могут гордо сортироваться от v.1.1 до какой-нибудь v.8.17, а могут и быть такие чудные названия, как ,,,,proposal_27_fin_fin_fin_FIN_DO_NOT_CHANGE ) и папочка Zzz (ненужное старье, но пусть валяется тут). В случае успеха материалы потом перекочевывают в проектную папку, где уже порядка больше, и подпапочки уже имеют порядковые номера.
Осилив классические слайды "Наше понимание ваших потребностей" и "Наш подход", посадив стафят рисовать аналитическую часть, а интерна искать самые красивые иллюстрации в маркетинговом банке изображений, манагер запускает процедуру проверки клиента и рисков (заполнив формочку всего навсего в 48 вопросов и отфутболив ее партнеру и в Quality & Risk Management) и начинает подбивать бюджет. Расчет бюджета производится несколькими способами. Самый простой и любимый - это когда сначала его на бухгалтерском калькуляторе считает партнер и показывает цифру манагеру. Манагер, ориентируясь на партнерскую цифру, делает расчет старым добрым дедовским методом - в Excel. До недавних времен все было мило и просто - по дивизионам гуляли толково сделанные шаблоны бюджетов, оставалось только поставить имена и грейды сотрудников, и вбить расход времени, бинго. Ну и раз в год ставки обновить. Ставки, billing rates и cost rates, также рассылались в Excel. Но путь прогресса неисповедим, и примерно за год до моего ухода компанию стали постепенно переводить на глобальную онлайн платформу, которая должна была интегрироваться с кучей прочих. В этой платформе, чтобы найти, скажем, ставку синиора 2 года в Advisory, надо было долго и муторно искать ее в громадном разветвляющемся списке (Global-EMEA-Eastern Europe-Russia and CIS-Russia-Currency-FY20XX-Advisory-Moscow-Staff-Senior-Senior2), потом формировать онлайн-формочку, потом сабмиттить ее куда-то в космос, а вот в Excel как раз она выгружалась плохо, поэтому все по возможности старались избегать этой платформы - думаю, все же в итоге всех заставили на нее перейти.
Второй способ, разумеется, противоположный, топ-даун. Применяется, когда речь идет о тендере с уже заявленной максимальной суммой, о клиенте, границы финансовых возможностей которого хорошо понятны, или о случае, когда мы только что посчитали бюджет первым способом, партнер доволен, загрузка людей по времени нормальная, сроки соблюдаются, а сумма в результате получается сопоставимая с бюджетом Российской Федерации такая, что в принципе уже можно пропозал не подавать. Тогда начинаем резать сроки и загрузку команды до сколь угодно нереальных, ни в коем случае не трогая святую святых - маржинальность.
В тучные времена маржинальность проекта в 40% была проходной (стандартной), по маржинальности 10-39% надо было писать объяснение, с чего такая благотворительность. Затем гайки подкрутили, и все ниже 50% стали отбраковывать - вплоть до того, что если партнер видел в пайплайне проект с маржинальностью 49%, он звонил и нехорошим голосом просил бюджет переделать. Уже после моего ухода даже сформировали Финансовый Комитет, который должен был рассматривать пропозалы с маржой ниже 50% и принимать по ним решения. Правда, инициатива была мертворожденной, поскольку появление Финансового Комитета совпало с кризисом в стране и полным отсутствием проектов, и поэтому когда одна очень правильная и блюдущая процедуры молодая манагерша потребовала официального одобрения Финансового Комитета на ее проект с 37% маржинальностью, но зато со стратегически важным клиентом, это вызвало небольшой переполох, который кончился тем, что после недели переписки один из членов комитета написал ей, что за полгода существования не было ни одного заседания, и мол пусть она не парится и спокойно запускает проект, хорошо что он вообще есть.
С начальной стадией вроде разобрались. Проект заматчен с матрицей оказания услуг (тот еще квест, особенно в российских условиях), получил свой уровень "среднего" риска (минимального практически не бывает), клиент проверен, удалось уломать второго партнера на quality review, формочки заполнены, стаффинг зарезервирован, пусть даже пришлось поругаться с парой других манагеров. Делаем огромный прыжок через протоколы разногласий, изменения ТЗ, бодание по контракту, подписание контракта, установочные встречи, первичные информационные запросы и (в случае крупного проекта) разделение команды на стримы. Дальше манагер убивает гору времени на план-график (в двух вариантах - для внутреннего пользования и для клиента) и отчетность по план-графику (клиенту, эсему и партнеру), и практически сразу же начинает готовить презентацию с промежуточным отчетом, параллельно туша пожары в стримах и оказывая регулярную психологическую поддержку клиенту. Если проектная группа выезжает в офис клиента, манагер еще и обязан решать вопросы с помещениями, ключами, интернетом для команды, бэкапами информации, поездками, расходами, чаем и печеньками, и прочая.
Каждый раз, когда манагер заходит в интранет, ему автоматом на главную страницу подгружается статистика по его текущему проекту - несколько графиков, драматически лезущие вверх (всякие там расходы времени в процентах от запланированного) или зловеще пикирующие (фактическая маржинальность), плюс выдается число дней неоплаты последнего счета и т.п. Вполне себе ничего, если все время напоминать себе, что план никогда реалистичным не был, да и де факто затраты еще больше, чем нарисовано. Тем временем проект катится себе куда-то, рано или поздно прибывая к точке сдачи. Проходят закрывающие презентации, клиент получает финальные драфты и пропадает с горизонта, а манагеру остается тема Закрытия Проекта.
Одно время все проектные документы и материалы должны были быть запротоколированы и заархивированы в каком-то информационном хранилище на вечные времена. Интерфейс у этого хранилища предполагал зашкаливающее IQ. Во всем Advisory до конца этой процедуры доходила только одна сотрудница. Я честно как-то выслушала ее инструкции, потратила неделю на попытки хотя бы сформировать опись по требованиям, а потом откладывала и откладывала продолжение этой мороки, пока не ушла в декрет. Когда я вышла из декрета, хранилище поросло быльем, но отчетность по каждому проекту надо было а) перевести на английский, б) санитизировать (т.е. убрать все конфиденциальные моменты), в) сделать резюме, г) заполнить формочку и д) выложить в глобальный банк обмена информации по проектам. Разумеется, большинство сотрудников, особенно не из англоязычных стран, начинали с пункта в), поэтому глобальный банк обмена информацией содержал 1-2 фразы о проекте самого общего характера ("консультационные услуги по формированию стратегии крупной компании такого-то сектора в Латинской Америке"), и самыми ценными там являлись имена участников.
Без оплаты финальных счетов, впрочем, никакого закрытия быть не может. А это растягивается на годы. Бывает, что недоволен клиент, часто очень сильно тормозят процесс иностранные офисы четверки. Бывает, что увольняются манагеры или даже уходят партнеры, следы документации проекта теряются в дебрях, проходят годы, а финансовый контролер отдела и наименее утилизированный манагер все пытаются выбить какие-то деньги по просроченной дебеторке, иногда подключая нового партнера, что делает предприятие еще более убыточным.