Думаю, многим читателям знакома следующая ситуация.
Вы завершили работу над проектом или ключевым этапом (например, разработали систему, написали техзадание, подготовили дизайн-концепцию и т. д.) По вашему мнению, всё круто! Результат превосходный, а у заказчика замечаний нет. Деньги на студию! Однако, если копнуть дальше, некоторые из одобряющих еще не посмотрели на результаты вашей работы.
Другие не будут координировать свои действия без одобрения результатов владельцем смежной системы, с которой можно интегрироваться.
И эта песня может тянуться очень долго.
Поэтому сегодня мы поговорим о согласовании результатов работы.
Многие думают, что главное хорошо делать свою работу, и деньги придут. Однако на самом деле важнее – договориться о результатах свою работу и получи готовность клиента платить твоя работа.
Конечно, самое главное — собрать деньги, но решением проблем с финансированием занимаются другие люди, не участвующие в проекте.
Долгое время мне приходилось работать на стороне подрядчиков.
На данный момент я нахожусь по другую сторону баррикад — на стороне заказчика в типичной российской корпорации.
Поэтому я хотел бы описать свой взгляд на эту проблему на примере координации результатов ИТ-проекта в аналогичной компании.
Я надеюсь, что эта статья будет полезна читателям, которые работают с небольшими клиентами, поскольку основные принципы координации справедливы для проектов и клиентов любого размера.
Обычно процесс одобрения выглядит следующим образом: 
Подробно процесс описывать не буду; Думаю, простая схема достаточно отражает ее суть.
Главное, что следует из этого извлечь, — это процесс утверждения.
многоитеративный .
Не питайте иллюзий, что вы сделаете работу, заказчик проверит результат, вы внесете мелкие исправления, потом он пару дней подумает и подпишет документы.
Отмечу, что под Результаты относится к разработанной информационной системе, приобретенным лицензиям, компонентам системы, проектной документации, проведенным мероприятиям (например, обучение, нагрузочное тестирование) и т. д. Момент сдача и прием результатов — это мегасрок, когда по плану результаты работы должны быть переданы поэтапно.
Эту дату знает каждый член команды проекта, а также большинство заказчиков.
Исполнители Это могут быть как сотрудники заказчика, так и подрядчики.
К координаторы включают руководителя проекта от заказчика (РПЗ), руководителя проекта от подрядчика (РПИ), функционального заказчика (ФК) и других представителей бизнеса, иногда называемых рабочей группой проекта, то есть тех людей, которые управляют проектом.
Одобрения от Заказчика — в их число входят как координаторы, которые также согласовывают результаты, так и другие лица компании (ИТ-специалисты, специалисты по безопасности и т. д.), без одобрения которых результаты не будут утверждены.
Хорошие результаты или управление ожиданиями клиентов
Чтобы творческие люди (дизайнеры, 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 тысяч.
Чувствуете разницу? В следующей части статьи подробно пойдет речь о процедуре одобрения, а также о других критериях успешности этого процесса.
Теги: #согласование результатов #Управление проектами
-
Нужна Ли Мне Ит-Поддержка?
19 Oct, 24 -
Удивительный Веб-Дизайн Впечатляет Клиентов
19 Oct, 24 -
Обновленная История Стива Джобса
19 Oct, 24 -
Обзор Планшета Ainol Novo 8
19 Oct, 24 -
Запугивающая Реклама
19 Oct, 24 -
Браузер Flock Стал Еще Более Социальным
19 Oct, 24
