Думаю многим читателям знакома следующая ситуация. Вы завершили работы по проекту или ключевому этапу (например, разработали систему, написали технический проект, подготовили дизайн-концепцию и т.д.) На ваш взгляд, все круто! Результат — супер, да и замечаний у заказчика нет. Деньги в студию!
Однако если копнуть дальше, то ряд согласующих еще не смотрели результаты вашего труда. Другие не будут согласовывать без одобрения результатов владельцем смежной системы, с которой нужно интегрироваться. И эта песня может тянуться очень долго. Поэтому сегодня будем говорить о согласовании результатов работ.
Многие люди думают, что главное хорошо выполнить свою работу, а деньги придут сами. Однако на деле важнее — согласовать результаты вашего труда и получить готовность заказчика оплатить вашу работу. Конечно же главнее — это забрать деньги, но решением проблем с финансированием занимаются другие люди, не участвующие в проекте.
Долгое время мне приходилось работать на стороне подрядчиков. На текущий момент я нахожусь по ту сторону баррикад — на стороне заказчика в типичной российской корпоации. Поэтому мне хочется описать мой взгляд на эту проблему на примере согласования результатов ИТ-проекта в подобной компании. Надеюсь, что читатели, работающие с клиентами поменьше, найдут для себя полезное в этой статье, ведь базовые принципы согласования справедливы для проектов и заказчиков любого масштаба.
Обычно процесс согласования выглядит так:
Не буду подробно описывать процесс, думаю, и так несложная схема достаточно отображает его суть. Главное, что отсюда следует вынести, процесс согласования — многоитеративный. Не тешьте себя иллюзиями, что вы сделаете работу, заказчик просмотрит результаты, вы внесете легкие исправления, потом он подумает пару дней и подпишет акты.
Замечу, что под результатами понимаются разработанная информационная система, купленные лицензии, компонент системы, проектная документация, проведенные мероприятия (например, обучение, проведение нагрузочного тестирования) и т.д.
Момент сдачи-приемки результатов — это мегадедлайн, когда по плану должны передаваться результаты работ по этапу. Эту дату знает каждый участник проектной команды, а также большинство заказчиков.
Исполнителями могут быть как сотрудники заказчика, так подрядчики.
К координаторам относятся руководитель проекта от заказчика (РПЗ), руководитель проекта от исполнителя (РПИ), функциональный заказчик (ФЗ) и другие представители бизнеса, иногда называемые рабочей группой по проекту, то есть те люди, которые управляют проектом.
Согласующие от Заказчика — в их число входят, как координаторы, которые также согласуют результаты, так и другие лица компании (ИТ-шники, безопасники и т.д.), без одобрения которых результаты не утвердят.
Дабы творческие люди (дизайнеры, UI-специалисты и иже с ними), которые стремятся сделать мир прекраснее посредством того, что результатами их труда будут пользоваться многие люди и получать от этого удовольствие, не обвинили меня в том, что я пытаюсь угодить бюрократам, убив элемент созидания и совершенства, публикую этот раздел.
Однажды, один известный дизайнер делал интерьер в квартире экс-патриарха криминального мира России Деда Хасана, пару лет назад убитого в центре Москвы. Так как заказчик долгое время провел в тюрьмах, то автор решил сделать оформление в темных тонах, в качестве напоминания о тех местах, где его клиент получил уважение и авторитет. Однако, увидев результат, заказчик был очень огорчен и приказал вернуть $70 тыс., которые были предоплачены за работу. Наверное интерьер был оформлен очень красиво, имел необычную концепцию, но исполнитель не угадал ожидания заказчика, и провалил проект.
Прицел на хороший результат и умение управлять ожиданиями заказчика — разные вещи. В рамках одного проекта одна группа ожидает получение бонусов за успешный проект, другая не замотивирована на этом проекте и хочет, чтобы их не трогали, а третьи понимают, что в случае успеха проекта в их филиале сократят штат сотрудников, поэтому они ожидают провала проекта. Чтобы придти к успеху, координаторам необходимо решать две эти задачи: разработать хороший продукт, а также управлять ожиданиями.
Сколько времени закладывать на приемку?
На согласование и доработку результатов нужно отводить минимум 30-50%, которое было потрачено на разработку первой версии. Бывает, что согласование и доработка занимает больше времени, чем разработка. Глупо надеяться, что вы разрабатывали проектные документы, например по этапу «Анализ и проектирование» три месяца(60+ рабочих дней), а согласуете его за 5-10 рабочих дней.
Факторы успеха процесса согласования
Чтобы успешно согласовывать результаты на каждом из этапов проекта, я выделяю несколько факторов, которые на мой взгляд обеспечивают успех или провал этого процесса.
Вы можете быть частью мега крутой команды, которая умеет разрабатывать самые сложные системы для самых крупных клиентов, но если на стороне очередного заказчика преобладает темная сила, которая имеет сильные позиции внутри компании и которая негативно настроена на ваш проект, то завершение любого этапа будет даваться вам с большим трудом. Не говоря уже о том, что ваш проект вообще никогда не завершиться или заглохнет еще на старте.
Поэтому в крупных проектах политические отношения с различными «кланами» заказчика, представителями извне (госорганы, подрядчики предыдущих систем), которые заинтересованы/крайне не заинтересованы в успехе проекта, зачастую имеют гораздо большее значение, чем умение проектной команды делать свое дело — разрабатывать продукт (оказывать услугу).
Еще раз напомню формулировку:
Рассмотрим типичную структуру согласующих по проекту.
Для того, чтобы результаты были приняты, они должны быть одобрены ключевыми согласующими. Ключевые согласующие как правило делегируют работы по согласования своим подчиненным.
Итак, ваш проект может быть включен в KPI для ряда Департаментов (то есть представители этого департамента замотивированы). Для функционального заказчика — это практически всегда априори. Для других лиц, которые должны согласовывать результаты, он не несет никакой выгоды, а для третьей группы лиц он вызывает большие проблемы. Например, внедряемая система требует усиление ИТ-инфраструктуры и более того при внедрении она сможет вызывать проблемы в работе других сервисов, а ИТ-блок, отвечающий за инфраструктуру, не готов сейчас улучшать, поэтому он будет всячески тормозить этот проект.
Исходя из влияния и вовлеченности вашей «группы поддержки» на стороне заказчика может быть сценария развития.
1. Ваша «группа поддержки» (на стороне заказчика) сильно заинтересована и активно участвует в проекта, но имеет маленький вес. В итоге вы будете сталкиваться с бездействие равнодушных и сопротивлением темных сил. Возможно придется эскалировать проблемы на «мега босса», которые поможет сдвинуть с мертвой точки вяло текущий процесс.
2. Ваша «группа поддержки», например, функциональный заказчик имеет большой вес в компании, у него есть хорошая мотивация, большой KPI за этот проект, но у него мало времени, его обычная операционная деятельность отнимает все рабочее время. Поэтому ему некогда проводить даже предварительную приемку результатов, не говоря уже об его участии в политических процессах. Соответственно ваша основная ваша задача — это вовлекать его в тонкости проекта.
3. Ваша «группа поддержки» не имеет сильного влияния, и не сильно заинтересована в проекте. Это самый худший вариант, думаю не стоит описывать плачевные последствия.
4. Самый благоприятный вариант. Ваша группа поддержки и влиятельна, и заинтересована, и активна. Значит несмотря на всевозможные трудности все у вас будет хорошо! Это и есть самый главный критерий успешного согласования, на мой взгляд.
На недавнем проекте мы работали с крупной международной консалтинговой компанией, испытавшая сложности с одним из Департаментов, который также должен был согласовывать результаты, но не желал участвовать в проекте. Оказалось, что этот проект не был включен в их KPI. В процессе общения консультанты этой компании мне рассказали, что вообще-то у них существует правило не входить в проект, если одному из ключевых менеджеров, который должен участвовать в проекте, не выделен KPI.
Прежде чем входить входить в какой-то проект, лишний раз стоит задуматься, а какова расстановка сил в компании, и какое отношение у каждой из них к предстоящему проекту.
И напоследок. Как известно, за свои ошибки нужно платить.
Давайте посчитаем, что будет, если вы ошиблись в прогнозах по согласованию и дорабатываете результаты за свой счет? Во сколько вам это обойдется? Ставки приведены для Москвы, они даже немного занижены.
Я считал результаты для проектных команд размером от 3 до 10 человек для различных периодов просрочки (2 недели, месяц, 1,5 месяца).
Например, по вине заказчика проектная команда из 5 человек вынуждена отрабатывать замечания еще месяц.
Если бы вы заранее заложили резервы на согласование и включили их в смету, то вы бы получили от Заказчика 2,2 млн. рублей.
В противном случае вы потеряли 660 тыс. рублей. Либо +2,2 млн, либо — 660 тыс. Чувствуете разницу?
В следующей части статьи будет подробно рассказано о процедуре согласования, а также о других критериях успешности этого процесса.
Однако если копнуть дальше, то ряд согласующих еще не смотрели результаты вашего труда. Другие не будут согласовывать без одобрения результатов владельцем смежной системы, с которой нужно интегрироваться. И эта песня может тянуться очень долго. Поэтому сегодня будем говорить о согласовании результатов работ.
Многие люди думают, что главное хорошо выполнить свою работу, а деньги придут сами. Однако на деле важнее — согласовать результаты вашего труда и получить готовность заказчика оплатить вашу работу. Конечно же главнее — это забрать деньги, но решением проблем с финансированием занимаются другие люди, не участвующие в проекте.
Долгое время мне приходилось работать на стороне подрядчиков. На текущий момент я нахожусь по ту сторону баррикад — на стороне заказчика в типичной российской корпоации. Поэтому мне хочется описать мой взгляд на эту проблему на примере согласования результатов ИТ-проекта в подобной компании. Надеюсь, что читатели, работающие с клиентами поменьше, найдут для себя полезное в этой статье, ведь базовые принципы согласования справедливы для проектов и заказчиков любого масштаба.
Обычно процесс согласования выглядит так:
Не буду подробно описывать процесс, думаю, и так несложная схема достаточно отображает его суть. Главное, что отсюда следует вынести, процесс согласования — многоитеративный. Не тешьте себя иллюзиями, что вы сделаете работу, заказчик просмотрит результаты, вы внесете легкие исправления, потом он подумает пару дней и подпишет акты.
Замечу, что под результатами понимаются разработанная информационная система, купленные лицензии, компонент системы, проектная документация, проведенные мероприятия (например, обучение, проведение нагрузочного тестирования) и т.д.
Момент сдачи-приемки результатов — это мегадедлайн, когда по плану должны передаваться результаты работ по этапу. Эту дату знает каждый участник проектной команды, а также большинство заказчиков.
Исполнителями могут быть как сотрудники заказчика, так подрядчики.
К координаторам относятся руководитель проекта от заказчика (РПЗ), руководитель проекта от исполнителя (РПИ), функциональный заказчик (ФЗ) и другие представители бизнеса, иногда называемые рабочей группой по проекту, то есть те люди, которые управляют проектом.
Согласующие от Заказчика — в их число входят, как координаторы, которые также согласуют результаты, так и другие лица компании (ИТ-шники, безопасники и т.д.), без одобрения которых результаты не утвердят.
Хороший результат или управление ожиданиями заказчика
Дабы творческие люди (дизайнеры, UI-специалисты и иже с ними), которые стремятся сделать мир прекраснее посредством того, что результатами их труда будут пользоваться многие люди и получать от этого удовольствие, не обвинили меня в том, что я пытаюсь угодить бюрократам, убив элемент созидания и совершенства, публикую этот раздел.
Однажды, один известный дизайнер делал интерьер в квартире экс-патриарха криминального мира России Деда Хасана, пару лет назад убитого в центре Москвы. Так как заказчик долгое время провел в тюрьмах, то автор решил сделать оформление в темных тонах, в качестве напоминания о тех местах, где его клиент получил уважение и авторитет. Однако, увидев результат, заказчик был очень огорчен и приказал вернуть $70 тыс., которые были предоплачены за работу. Наверное интерьер был оформлен очень красиво, имел необычную концепцию, но исполнитель не угадал ожидания заказчика, и провалил проект.
Прицел на хороший результат и умение управлять ожиданиями заказчика — разные вещи. В рамках одного проекта одна группа ожидает получение бонусов за успешный проект, другая не замотивирована на этом проекте и хочет, чтобы их не трогали, а третьи понимают, что в случае успеха проекта в их филиале сократят штат сотрудников, поэтому они ожидают провала проекта. Чтобы придти к успеху, координаторам необходимо решать две эти задачи: разработать хороший продукт, а также управлять ожиданиями.
Когда начинать приемку?
- С одной стороны, не нужно доводить работу до совершенства перед тем, как ее показывать заказчику (замечу, перфекционизм присущ очень многим ИТ-специалистам). Все равно придется исправлять и дорабатывать, только зря потратишь время и энергию. Когда выкладываешься по максимуму, но не достигаешь результата, то теряется мотивация.
- С другой стороны, нельзя показывать заказчику сырую версию. Это вызовет негатив, клиент скажет, что за фигню вы мне подсунули. А в следующий раз, когда ему будет продемонстрирована нормальная доработанная версия, то он уже не захочет вникать в суть результата.
- Когда результаты будут иметь нормальное качество, то можно отправлять их на согласование.
- Чем раньше и чем больше представителей заказчика будет вовлечено в проект, тем быстрее закончится приемка.
Сколько времени закладывать на приемку?
На согласование и доработку результатов нужно отводить минимум 30-50%, которое было потрачено на разработку первой версии. Бывает, что согласование и доработка занимает больше времени, чем разработка. Глупо надеяться, что вы разрабатывали проектные документы, например по этапу «Анализ и проектирование» три месяца(60+ рабочих дней), а согласуете его за 5-10 рабочих дней. 
Факторы успеха процесса согласования
Чтобы успешно согласовывать результаты на каждом из этапов проекта, я выделяю несколько факторов, которые на мой взгляд обеспечивают успех или провал этого процесса.
- На стороне заказчика существует как минимум один человек (группа лиц), который достаточно сильно вовлечен в проект и имеет большое влияние на всех согласующих.
- Для каждого этапа должен быть определен перечень результатов. Для каждого результат должен быть определен список согласующих лиц
Для решения этого вопроса я предлагаю использовать матрицу согласования. - Определен, а лучше зарегламентирован, процесс согласования результатов. Согласующие проинформированы о порядке согласования.
- Налажен быстрый процесс сбора и отработки замечаний.
- Вы умеете отделять зерна от плевел: вы быстро распознаете то, что выходит за рамки проекта и умеете управлять изменениями
- Наличие сильного куратора (если вы на стороне подрядчика), который поможет в общении с заказчиком, если согласование никак не двигается вперед.
- Вы открестились от работ заказчика (опять же, если вы на стороне подрядчика).
Главный фактор
Вы можете быть частью мега крутой команды, которая умеет разрабатывать самые сложные системы для самых крупных клиентов, но если на стороне очередного заказчика преобладает темная сила, которая имеет сильные позиции внутри компании и которая негативно настроена на ваш проект, то завершение любого этапа будет даваться вам с большим трудом. Не говоря уже о том, что ваш проект вообще никогда не завершиться или заглохнет еще на старте.
Поэтому в крупных проектах политические отношения с различными «кланами» заказчика, представителями извне (госорганы, подрядчики предыдущих систем), которые заинтересованы/крайне не заинтересованы в успехе проекта, зачастую имеют гораздо большее значение, чем умение проектной команды делать свое дело — разрабатывать продукт (оказывать услугу).
Еще раз напомню формулировку:
На стороне заказчика существует как минимум один человек (группа лиц), который достаточно сильно вовлечен в проект и имеет большое влияние на всех согласующих.
Рассмотрим типичную структуру согласующих по проекту.
Для того, чтобы результаты были приняты, они должны быть одобрены ключевыми согласующими. Ключевые согласующие как правило делегируют работы по согласования своим подчиненным.
Итак, ваш проект может быть включен в KPI для ряда Департаментов (то есть представители этого департамента замотивированы). Для функционального заказчика — это практически всегда априори. Для других лиц, которые должны согласовывать результаты, он не несет никакой выгоды, а для третьей группы лиц он вызывает большие проблемы. Например, внедряемая система требует усиление ИТ-инфраструктуры и более того при внедрении она сможет вызывать проблемы в работе других сервисов, а ИТ-блок, отвечающий за инфраструктуру, не готов сейчас улучшать, поэтому он будет всячески тормозить этот проект.
Исходя из влияния и вовлеченности вашей «группы поддержки» на стороне заказчика может быть сценария развития.
1. Ваша «группа поддержки» (на стороне заказчика) сильно заинтересована и активно участвует в проекта, но имеет маленький вес. В итоге вы будете сталкиваться с бездействие равнодушных и сопротивлением темных сил. Возможно придется эскалировать проблемы на «мега босса», которые поможет сдвинуть с мертвой точки вяло текущий процесс.
2. Ваша «группа поддержки», например, функциональный заказчик имеет большой вес в компании, у него есть хорошая мотивация, большой KPI за этот проект, но у него мало времени, его обычная операционная деятельность отнимает все рабочее время. Поэтому ему некогда проводить даже предварительную приемку результатов, не говоря уже об его участии в политических процессах. Соответственно ваша основная ваша задача — это вовлекать его в тонкости проекта.
3. Ваша «группа поддержки» не имеет сильного влияния, и не сильно заинтересована в проекте. Это самый худший вариант, думаю не стоит описывать плачевные последствия.
4. Самый благоприятный вариант. Ваша группа поддержки и влиятельна, и заинтересована, и активна. Значит несмотря на всевозможные трудности все у вас будет хорошо! Это и есть самый главный критерий успешного согласования, на мой взгляд.
Выход — там где вход
На недавнем проекте мы работали с крупной международной консалтинговой компанией, испытавшая сложности с одним из Департаментов, который также должен был согласовывать результаты, но не желал участвовать в проекте. Оказалось, что этот проект не был включен в их KPI. В процессе общения консультанты этой компании мне рассказали, что вообще-то у них существует правило не входить в проект, если одному из ключевых менеджеров, который должен участвовать в проекте, не выделен KPI.
Прежде чем входить входить в какой-то проект, лишний раз стоит задуматься, а какова расстановка сил в компании, и какое отношение у каждой из них к предстоящему проекту.
Финансовая сторона вопроса
И напоследок. Как известно, за свои ошибки нужно платить.
Давайте посчитаем, что будет, если вы ошиблись в прогнозах по согласованию и дорабатываете результаты за свой счет? Во сколько вам это обойдется? Ставки приведены для Москвы, они даже немного занижены.
Я считал результаты для проектных команд размером от 3 до 10 человек для различных периодов просрочки (2 недели, месяц, 1,5 месяца).
Например, по вине заказчика проектная команда из 5 человек вынуждена отрабатывать замечания еще месяц.
Если бы вы заранее заложили резервы на согласование и включили их в смету, то вы бы получили от Заказчика 2,2 млн. рублей.
В противном случае вы потеряли 660 тыс. рублей. Либо +2,2 млн, либо — 660 тыс. Чувствуете разницу?
В следующей части статьи будет подробно рассказано о процедуре согласования, а также о других критериях успешности этого процесса.
