Как выбрать тип контракта для проекта

Всем привет! Я Наталья Ренская, организационный консультант-коуч, а также автор курса Delivery Master для мидл и сеньор менеджмента ІТ-проектов, в котором собран весь мой опыт за последние 15 лет работы в индустрии.

И на курсе, и в сообществе для РМ’ов нередко поднимаются вопросы, касающиеся правильно оформленной документации.

Один из документов — контракт на выполнение работы. Вопросы, которые могут быть актуальны для РМ’а:

  • как выбрать тип контракта для проекта и как аргументировать выбор перед заказчиком?
  • что должно быть прописано в контракте (какие детали должны быть указаны)?
  • как происходит калькуляция бюджета проекта или выполненных работ за определенный период, как это отображается в контракте?

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

Цель контракта

Основная задача контракта — зафиксировать договоренности между заказчиком (компания-клиент, покупатель) и исполнителем (компания-вендор, продавец).

Цель клиента (покупателя) — возложить максимум рисков выполнения на вендора (продавца), оставляя за собой возможность дополнительных поощрений в виде зафиксированных бонусов.

Цель вендора — минимизировать свои риски и при этом получить максимальную прибыль.

Также целью составления контракта может быть:

  • предварительная калькуляция стоимости проекта;
  • оценка необходимых ресурсов для выполнения работ;
  • оценка возможностей реализации требований заказчика;
  • оценка длительности работ;
  • обсуждение возможных конфликтов и стратегий выхода;
  • обсуждение рисков и возможностей, а также допущений и зависимостей.

На основании подготовленного предложения заказчик может принимать решение Build or Buy.

Четыре типа контракта

Каждый из них отличается соотношением рисков и возможностей клиента и вендора:

  1. Время и материалы (Time and Material — T&M).
  2. С фиксированной ценой (Fixed Price — FP):
    • Firm Fixed Price (FFP);
    • Fixed Price Incentive Fee (FPIF);
    • Fixed Price Award Fee (FPAF).
    • Fixed Price Economic Price Adjustment (FPEPA)
  3. С возмещением затрат (Cost Reimbursable — CR):
    • Cost Contract;
    • Cost Plus Award Fee (CPAF);
    • Cost Plus Percentage of Cost (CPPC);
    • Cost Plus Fixed Fee (CPFF);
    • Cost Plus Incentive Fee (CPIF).
  4. Dedicated Development Center (DDC) — если заказчик хочет на долгосрочной основе расширить свой штат за счет офшорной команды.

На выбор контракта могут влиять различные факторы, например, наличие или отсутствие информации, уровень взаимоотношений между заказчиком и вендором.

Рассмотрим варианты:

  • Наличие или отсутствие детальных требований к продукту/проекту → тип FP не подходит.
  • Ограничения по золотому треугольнику: бюджет, скоуп, время → жесткие ограничения по всем трем вершинам обычно прописываются в FP-контрактах.
  • Наличие доверия между заказчиком и исполнителем (сотрудничали раньше или пришли по рекомендации) и длительность отношений → возможность заключить T&M-контракт, а в случае старта нового проекта — DDC. При отсутствии доверия чаще всего клиент просит FP или CR тип контракта.
  • На чьей стороне будет находиться контроль и управление проектом → FP дает много свободы исполнителю в управлении и распределении бюджета. При этом FP подразумевает жесткое ограничение по бюджету. И от степени проработки (детализации) контракта зависит маржинальность проекта. Другие типы контрактов подразумевают ежемесячный отчет по часам работы каждого специалиста на проекте. При этом ограничение вводится на ежемесячную сумму расходов, что помогает сохранить маржинальность проекта при непредвиденных изменениях или отклонениях от плана.
  • Степень прозрачности финансовых расчетов → отсутствие прозрачности вызывает недоверие в отношениях, и чем больше недоверия — тем жестче условия для исполнителя. CPIF позволяет задать максимально прозрачные финансовые расчеты и при этом фиксированная ставка прибыли исполнителя закладывается в сам контракт.

Первый контракт с новым клиентом часто заключается с типом Fixed Price, потому что клиент хочет минимизировать свои риски. Последующие договоры с ним же можно переводить на T&M.

В моей практике были случаи, когда первый контракт на FP заключали только на часть работы. Например, 3-месячный договор для написания MVP. Последующая работа над этим же проектом оформлялась через T&M.

Были и такие ситуации, когда один и тот же клиент, с которым сотрудничали больше 5 лет, сначала просил перейти на T&M, желая сократить косты, потом снова переводил контракт в FP (чтобы уж точно сократить), чтобы через год снова попросить перейти на T&M, потому что так проще было контролировать расходы. Такое поведение чаще всего свидетельствует о недоверии со стороны клиента.

Каждый контракт имеет свои преимущества и недостатки. Давайте рассмотрим их детальнее.

Time and Material (T&M). Время и материалы

Этот тип характерен для проектов, в которых понятны только верхнеуровневые требования, полный объем пока не определен. При этом можно точно сказать, какие конкретно специалисты нужны, сколько человек должно быть задействовано на проекте. Несмотря на то, что итоговая стоимость выполнения всех работ не ясна, стороны соглашаются, что оплата будет производиться по результатам выполненных работ и что стоимость будет зависеть от затраченных ресурсов (времени и/или материалов).

В самом контракте фиксируется максимальная сумма за период действия контракта.

Например, договор на один месяц на пять команд:

Role# of Resources# of Days# of HoursRate per HourCost
Technical Lead52217650$44,000
Senior Developer102217640$70,400
Middle Developer352217630$184,800
Junior Developer52217620$17,600
TOTAL$316,800

Total Estimated Price per month: $316,800.00. То есть максимальная сумма затрат в месяц не будет превышать эту сумму.

Или возьмем тот же контракт, но в условиях есть договоренность, что заказчик оплачивает все расходы, связанные с командировками. Тогда это будет выглядеть так:

Total estimated travel price including tickets: $3,200.00

Total Estimated Price per month: $320,000.00

То есть максимальная сумма затрат в месяц не будет превышать $320 тысяч.

Чем хорош этот тип контракта?

  • Зафиксированы максимальные косты за период действия контракта.
  • При необходимости прописано требуемое качество системы (SLA).
  • Зафиксированы рейты специалистов.
  • Оплачивается все время, которое специалисты на стороне исполнителя были заняты на проектах заказчика. Оплата происходит раз в месяц.
  • Основные риски берет на себя заказчик.
  • Хорошо подходит под agile-проекты.

Его стоит выбирать, если вы работаете в условиях неопределенности по скоупу, а соответственно и по длительности работ; необходимо будет увеличивать/уменьшать количество сотрудников на проекте в течение определенного времени (T&M подходит, поскольку подразумевает только верхнее ограничение по сумме за период времени); планируется долгосрочное сотрудничество «заказчик — исполнитель»; есть запрос на staff augmentation.

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

На встрече клиент спросил: «Как измениться цена, если поменять тип контракта c T&M на FP?». Мы предполагали такой вопрос, поэтому сроки и задачи пресейл-команда прописывала тщательно. Наш ответ был: «Цена контракта останется той же. Изменения в работе, которые описаны в виде допущений при взаимодействии с 3rd party, должны будут оформляться как дополнительные соглашения к договору, что повлияет на стоимость всего проекта».

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

В итоге мы успели по срокам, немного просели в маржинальности проекта, получили лояльного клиента, с которым продолжили сотрудничество.

Fixed Price (FP). Контракт с фиксированной ценой

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

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

Про что важно помнить при заключении этого типа контракта? Исполнитель гарантирует срок и бюджет — и это прописано в договоре. Также нужно зафиксировать скоуп проекта, чтобы не просесть по маржинальности. Для этого мы прописываем не только In Scope, но и Out of Scope.

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

Как-то мы заключили с клиентом договор, в котором прописана работа дизайнера на 1 месяц. Дизайн сдали вовремя и в том объеме, который был оговорен. Клиент после демо обратился с просьбой, чтобы дизайнер доделал все фреймы, а это дополнительно еще две недели работы. Поскольку в контракте было четко прописано, что мы делаем и какие фреймы и задачи дизайнер не делает, то дополнительная работа была проведена как change request с заключением отдельного соглашения.

При этом возможны различные бонусы и поощрения за выполнение определенных условий, например, за досрочное выполнение работ.

Варианты FP-проектов

Firm Fixed Price (FFP). Это контракт с твердой суммой, которая остается неизменной вне зависимости от фактических затрат исполнителя. Это наиболее общий тип контракта для тех случаев, когда объем проекта и расходы достаточно прогнозируемы.

Fixed Price Incentive Fee (FPIF). Фиксированная цена + вознаграждение = фиксированная оплата плюс бонус за оговоренные показатели производительности (быстрее и лучше).

Fixed Price Award Fee (FPAF). Фиксированная цена включает в себя вознаграждение + премия (бонус). Возможная премия определяется заранее и распределяется на основании Execution.

Fixed Price Economic Price Adjustment (FPEPA). Контракт с фиксированной ценой и оговоркой о возможной корректировке цены, например, из-за изменения курса НБУ на момент выплаты.

Важно помнить, что цена, оговоренная контрактом Fixed Price, является ограничивающим фактором для исполнителя. В какой-то момент выполнения работ по проекту РМ может дойти до точки принятия полной ответственности (Point of Total Assumption), когда сумма на затраты уже израсходована и дальше идет «съедение прибыли». С этого момента РМ должен еще тщательнее контролировать все дальнейшие расходы.

Что характерно для FP-проекта:

  • Зафиксированы все три точки золотого треугольника: срок, деньги и объем работы. Еще раз хочу обратить внимание на отдельный пункт с Out Of Scope задачами и допущениями (зависимостями).
  • Качество продукта может быть зафиксировано в контракте. Если критерии качества продукта не зафиксированы, качество становится разменной монетой в случае непредвиденных ситуаций. Изменения возможны, если их проводить в виде отдельных дополнительных соглашений к контракту.
  • Основные риски берет на себя исполнитель, и эти риски должны отражаться на оценке длительности и стоимости работ, а также в допущениях (зависимостях).
  • Оплата происходит в конце проекта с возможной предоплатой в начале и в середине проекта.
  • FP-контракт позволяет нанимать сотрудников без согласования с заказчиком, развивать интернов внутри проекта. Правда, тут могут быть нюансы с предоставлением доступа к системам клиента.
  • FP сложно завершить прибыльно, если у исполнителя раньше не было опыта работы с такими контрактами.
  • После завершения проектных работ дальнейшее взаимоотношение заказчик — вендор может фиксироваться в других типах контракта.

Парадоксально, что РМ Middle-уровня с опытом работы с FP-проектами в среднем завершает проект с контрактом FP успешнее, чем РМ Senior-уровня без опыта работы с FP-проектами (только T&M или CR).

Итак, этот тип контракта хорош, если:

  • это небольшой или регуляторный проект;
  • заказчик предоставил хорошо проработанные требования;
  • у вас есть опыт работы с подобными проектами;
  • в вашей компании есть РМ’ы, у которых был опыт ведения проектов по FP-модели.

Cost-Reimbursable (CR). Контракт с возмещением затрат

«А мы делаем проект T&M, но у нас расчет идет исходя из зарплаты и админ костов» ©.

Cost-Reimbursable — контракт, при котором заказчик покрывает расходы и в некоторых модификациях дополнительно выплачивает бонус (процент прибыли от суммы себестоимости работ).

Варианты модификации этого типа контракта:

Cost Contract. Покрытие расходов исполнителя, подходит для некоммерческих организаций.

Cost Plus Award Fee (CPAF). Возмещение затрат + премия (бонус). Стимул тут — потенциальная премия, которая определяется и распределяется заранее, в зависимости от исполнения. Часто бывает субъективной, в суде невозможно оспорить.

Cost Plus Percentage of Cost (CPPC). Такой тип контракта предусматривает возмещение затрат + процент от них в качестве прибыли. Средства заказчика, как правило, оказываются перерасходованными, потому что исполнителю нет необходимости контролировать расходы. В некоторых странах этот тип контракта запрещен.

Cost Plus Fixed Fee (CPFF). Дополнительное поощрение входит в фактическую стоимость контракта, что стимулирует дополнительный контроль и микроменеджмент на стороне исполнителя. Риски лежат на стороне заказчика. Можно использовать для R&D, когда необходимые затраты еще не вполне ясны.

Cost Plus Incentive Fee (CPIF). Такой тип контракта включает покрытие затрат исполнителя и дополнительно гонорар, который будет зависеть от производительности и экономии затраченных средств. Часто применяют в длительных и сложных проектах, в которых есть возможность детально контролировать расходы.

Пример расчета по этому контракту:

Actual Cost + Target Fee + ((Target Cost — Actual Cost) * Share Ratio)

Возьмем в качестве примера такие значения:

Target Cost — $100,000 — договорные затраты

Target Fee — $10,000 — договорная прибыль

Share Ratio — 80/20 — процент распределения

Actual Cost — $80,000 — фактические затраты

Подставим эти значения в формулу:
$80,000 + $10,000 + ((100,000 — 80,000) * 20%) = $94,000

То есть исполнитель получит $94 тыс. при выполнении условий вознаграждения.

Себестоимость проекта рассчитывается на основании прямых и непрямых затрат:

  • Прямые затраты — это зарплата команде, стоимость оборудования, необходимого для выполнения работы, и прочие расходы, без которых выполнение условий контракта невозможно.
  • Непрямые затраты — административные расходы: аренда офисных помещений, оплата коммунальных услуг и прочие накладные расходы.

Бывают случаи, когда с клиентом заключается основной договор по T&M типу, при этом указывается, что дополнительная разработка частей по интеграции с другими системами будет оформляться в виде FP, а оплата операционных расходов (командировки, закупка оборудования, закупка лицензий) — в виде СС (подтип CR).

CR-контракт хорош, если реализация проекта необходима для некоммерческих организаций с ограниченным бюджетом и в условиях неопределенности скоупа работ. Для таких случаев выбирают СС — расходы по выполняемым работам и админ костам будут покрыты, при этом маржинальность проекта для исполнителя — нулевая.

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

Хорошая альтернатива FP-проекту, если нет сильного ограничения по бюджету.

Dedicated Development Center (DDC). Выделенный центр разработки

Выделенный центр разработки — это отдельная команда на стороне клиента, расположена в другой стране/городе/офисе. Отличие от staff augmentation — управление проектом и командой происходит не напрямую, а через менеджера проекта.

Когда клиенты готовы рассматривать такой тип контракта?

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

Среди преимуществ DDC могут быть:

  • в условиях экономического кризиса такой тип контракта гарантирует медленный процесс сокращения, потому что команда обладает большим количеством уникальной экспертизы;
  • РМ и команда работают как самостоятельная единица, принимают решения внутри команды и реализовывают продукт на основании требований РО заказчика.

Контрактные риски

Основные риски для исполнителя в проекте FP:

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

Основные риски для исполнителя в проекте T&M:

  • часто найм сотрудников (особенно сеньоров) проходит через клиентское интервью, потому что клиенты хотят убедиться в уровне профессионализма специалистов, которые будут работать на проекте по рейту, указанному в контракте. Это удлиняет процесс найма и длительность работ;
  • сost saving на стороне клиента может приводить к требованию сократить количество сотрудников по данному контракту;
  • повышение сотрудников внутри проектной команды может быть возможным только по согласованию с заказчиком (см п. выше);
  • клиент может потребовать заменить конкретного сотрудника.

Основные риски для исполнителя в проекте CR:

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

Основные риски для исполнителя в проекте DDC:

  • переход на staff augmentation модель;
  • сильно смещенный график работ из-за необходимости участвовать во встречах заказчика и при условии большой разницы во времени между таймзонами заказчика и исполнителя.

Соотношение рисков заказчика и исполнителя для каждого типа контракта можно представить так:

Ответственность за управление проектом:

Полнота требований по отношению к типу контракта:

О чем стоит помнить?

Продать контракт проще, чем реализовать все обещания сейлза заказчику.

Поэтому деливери- и сейлз-команде важно работать вместе. И подключать РМ’а нужно на ранних стадиях пресейла для более корректных расчетов стоимости и сроков.

Реальный пример. Проблема, с которой обратились на консультацию — постоянный конфликт между Sales и Delivery, который казался неразрешимым: сейлзам надо продавать — это их работа, а деливери необходимо реализовывать проект — это их работа. И если сейлзы продают, а деливери реализовывают, то зачем что-то менять и ломать рабочую схему?

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

Для того чтобы выйти из конфликтной ситуации, мы проанализировали вместе с СхО существующие процессы внутри компании и организовали встречи между представителями Sales и Delivery команд:

  • воркшопы для обсуждения и проработки RACI matrix, в которой прописан процесс пресейла и правила взаимодействия между подразделениями;
  • таунхолы, которые подготовили деливери для сейлз-команды, где было представлено, что они делают, какие задачи решают, какие потребности клиента закрывают, в чем есть экспертиза, что можно предлагать клиентам.

Также создали Case Study Library внутри компании, которую наполняет деливери-команда для того, чтобы у сейлзов нужная информация была под рукой.

Это не избавило нас на 100% от конфликтов между командами, но сотрудничество двух направлений позволило убрать конфликт с уровня взаимоотношений заказчик — исполнитель и перенести его на уровень взаимоотношений внутри компании, а также создать атмосферу в коллективе, при которой стало возможным конструктивное обсуждение конфликтов.

Содержание контракта

Описание работ контракта

Некоторые работы могут начинаться без конкретного понимания скоупа задач, например, для доработки существующих систем. В этом случае подписывается сначала Master Service Agreement (MSA), а потом для каждого проекта прописывается Statement of Work (SOW), который будет дополнять и конкретизировать рамочное соглашение MSA.

SOW, как и MSA, приобретает юридическую силу после подписания его обеими сторонами. При необходимости дополнительных работ оформляются Change Requests (CR) и вводится как дополнительное соглашение к контракту.

Да, процесс внесения изменений — это тоже часть контракта.

Описание календарного плана работ

Также в SOW может прописываться детальный календарный план выполнения работ по проекту с датами демонстрации функционала.

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

Дополнительно

Также в контракте может указываться, кому принадлежат права интеллектуальной собственности и результаты выполненной работы. Иногда это прописывается и в контракте, и в NDA.

В некоторых проектах прописывают критерии качества и критерии приемки, которые ложатся в DoD и Acceptance Criteria в требованиях.

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

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

— Мы хотим повысить прибыльность проектов на 15%.
— Давайте рассмотрим причины низкой маржинальности и подберем варианты решений. Например, продумаем более детально план работ, выделим время на риски или подтянем рейты специалистов до рыночного уровня. Либо используем CR-контракт.
— Тогда мы не продадим контракт клиенту, давайте лучше посмотрим, как срезать косты внутри компании.
— Овертаймы на постоянной основе, чтобы успеть вовремя, и урезание костов — риск «не продать» контракт сотрудникам, что может повысить ретеншен. Это еще больше снижает маржинальность из-за недополученной прибыли за время поиска и замены специалиста.
— Задача менеджера выполнить контракт в срок и при этом сохранить сотрудников.
— Ваш РМ участвует в пресейле? Если он берет на себя этот комитмент, тогда это действительно его задача.
— Нет, он сильно загружен текущей работой над проектами.
— Давайте вернемся в начало разговора: нам стоит выяснить причины низкой маржинальности и высокой загрузки сотрудников компании, прежде чем мы начнем обсуждать варианты решений.

Радует, что на украинском рынке все чаще СхО готовы замедлиться на какой-то период, чтобы проработать стратегию продаж и взаимодействия заинтересованных лиц внутри компании во время подготовки предложений потенциальным клиентам.

Итог

С одним и тем же клиентом могут быть контракты разных типов. Дополнительные соглашения к контракту могут отличаться по типу от основного контракта.

Ни один тип контракта не гарантирует на 100% качественной реализации продукта в срок. Любой из них имеет светлую и темную сторону, и во многом процесс работы зависит от взаимоотношений между представителями заказчика и исполнителя.

Похожие статьи:
В выпуске: 10 заповедей iOS-разработки, книга по SwiftUI, план на Swift 6, памятка по работе с форматтерами, много библиотек и немного про...
НАУ змінить організаційно-правову форму, а також розширить повноваження й автономію своєї наглядової ради. Також від жовтня виш...
Ще далекого 2015 року в СКБД MySQL, починаючи з версії 5.7.8, додали підтримання нового типу даних JSON. Насамперед це створило нові...
В ІТ-компанії ELEKS повідомили про трагічну загибель колеги-розробника Руслана Івахненка. Він був родом із Харкова, певний...
[Об авторе: Алексей Воронков — управляющий директор e-Residency в Украине. Ветеран ИТ-индустрии с обширным опытом работы...
Яндекс.Метрика