Lessons Learned of Drafting Silver Book FIDIC 2017
Lessons Learned по результатам разработки ЕРС Контракта по проформе Серебряной книги FIDIC 2017 года.
Часть книги про Контрактный менеджмент.
1. Прозрачность и эффективная коммуникация: важно поддерживать открытую и эффективную коммуникацию между:
· между разработчиками Контракта и персоналом Заказчика Контракта.
Регулярные встречи, отчеты и обновления помогут улучшить понимание и снизить вероятность недоразумений.
Очевидно, что встречи нужно планировать, писать повестку дня и, самое важное, фиксировать результаты встречи, ставить сроки и назначать ответственных лиц.
Очевидно, что нужно проводить встречи на регулярной основе (каждые 3 дня или еженедельно), в зависимости от сложности и плотности контента.
Перед началом взаимодействия необходимо указать контактные данные конкретных лиц (поименно, с указанием номеров телефонов, email и т.д.) и механизмы коммуникации между сторонами, чтобы обеспечить своевременную обратную связь и установить эффективное взаимодействие в процессе разработки Контракта.
Важно добавиться от Заказчика Контракта правильной, полной, своевременной обратной связи.
Важно Заказчику, точнее его представителям, объяснить, насколько важна качественная обратная связь, прежде всего для самого Заказчика. Если «не доходит» – эскалировать вопрос, проблему выше по иерархии. Для этого важно знать иерархию на 2-3 уровня выше тех, лиц с которыми непосредственно контактируем.
2. Конфиденциальность и защита данных: важно чтобы между разработчиками Контракта и персоналом Заказчика Контракта складывались доверительные отношения. Разработчик ЕРС Контракта – это правая рука Заказчика Контракта. Они находятся на одной стороне баррикад по отношению к будущему Подрядчику-Исполнителю.
Очевидно, что перед началом совместной работы, несмотря и независимо на наличие договора на оказание услуг по разработке Контракта, необходимо подписание отдельного соглашения о конфиденциальности, что, в некоторой степени, расширит границы взаимного доверия по сохранению конфиденциальности и защите данных, особенно в случаях, когда речь идет о передаче конфиденциальной коммерческой, еще никому неизвестной, закрытой информации и персональных данных лиц, задействованных в разработке Контракта.
3. Определение целей и требований проекта: важно ясно определить цели и требования Заказчика, понять, для чего ему EPC Контракту. Есть ли миссия у проекта? Есть ли принципы реализации проекта? Это может включать описание проекта, бюджет, сроки, качество и другие важные параметры.
4. Документальное оформление задания на разработку Контракта. Очень важно, чтобы Заказчик дал четкое, понятное, детальное задание на разработку Контракта. При его отсутствии – разработчиком Контракта составляется опросный лист, который заполняется Заказчиком. Необходимо обязательно уделить достаточное внимание документальному оформлению требований Заказчика, чтобы избежать возможных ошибок и неясностей при рассмотрении спорных ситуаций.
Важно добавиться от Заказчика Контракта правильной, полной, своевременной обратной связи по требованиям Заказчика, иначе Контракт будет разрабатываться на базе предыдущего опыта разработчика. Заказчику нужно это объяснить.
Важно иметь четкое разделение условий Контракта, которые определяет Заказчик только по своему усмотрению. Например, размер аванса, размер ежедневной неустойки и т.д., однако, если, например, размер аванс, по мнению разработчика, слишком завышен, например, превышает 30%, то следует заказчику несколько раз обратить внимание и рекомендовать пересмотреть размер аванса.
На основании задания на разработку Контракта необходимо обязательно декомпозировать все положения Контракта по времени разработки и, что тоже важно, по стоимости. Это позволит контролировать ресурсы разработчика.
Разработчику необходимо тщательное изучение и анализ полученной информации и документации, так как Заказчику свойственно путаться и выдавать «одно за другое», мечтать и выдавать «желаемое за действительное», думать и представлять одно, а на бумаге писать и говорить другое. И это не проблема Заказчика. Это нормально.
Разработчику нужно тщательно изучить все полученные документы и информацию, соотнести их между собой, при необходимости, сразу же, в том числе и по всякой мелочи (не думая, что это мелочь) обращаться к Заказчику Контракта за уточнением.
Разработчику нужно тщательно изучить все полученные документы и информацию, включая положения разрабатываемого Контракта и сопутствующие спецификации, чтобы полностью понять их требования, ограничения и противоречия. Это поможет избежать недоразумений и ошибок во время реализации проекта.
5. Заложить сроки разработки контракта с запасом. Декомпозировать положения Контракта в разрезе отведенного времени, при этом все дэд-лайны ставить не в те дэд-лайны, которые определяются Заказчиком, а на некоторое время раньше. Потому что, во-первых, у Заказчика «всегда что-то изменяется в процессе разработки», во-вторых, «всегда не будет хватать 1-2 дня для наведения красоты Контракту», в-третьих, если раньше закончил – это досрочное завершение работы в целом.
Декомпозиция положений Контракта в разрезе отведенного времени позволяет контролировать сроки разработки контракта и уделять больше внимания разработке той части Контракта, которая отстает по времени (независимо от каких-либо причин).
6. Разработчик контракта может не всё. Необходимо изначально определить и обозначить для Заказчика, что разработчик Контракта в большей степени работает с юридическим уклоном. В этой связи отдельные положения Контракта, связанные с технико-экономическим обоснованием, строительно-техническими требованиями, финансовым прогнозированием и т.п. выходят за пределы компетенции юриста.
В этой связи полезно составить матрицу-список документов, которые вообще должны быть в Контракте, среди которых выделить те, которые разработчик Контракта составит и те, которые Заказчик должен выполнить силами других специалистов.
7. Разработчику контракта не завершает работу передачей проекта документа, сопровождает разработку до момента подписания. Необходимо изначально определить и обозначить для Заказчика, что разработчик Контракта «ведёт» Контракт до дня подписания, несмотря на истекший срок оказания услуги по разработке. Но важно Заказчику акцентировать внимание, что такое «ведение» не должно быть длительным, нагруженным по объему дополнительных вопросов и задействованных ресурсов, не быть финансово затратным для разработчика.
8. Подумать о разработке KPI процесса разработки Контракта. Необходимо определить четкие процедуры оценки и контроля качества и эффективности процесса разработки и полученного/получаемого результата. Регулярные проверки и тестирования помогут выявить проблемы и недостатки на ранних этапах их возникновения, что позволит принять меры по их исправлению.
9. Подумать о составлении реестра часто возникающих рисков. Вести анализ рисков и разработать планы по их управлению. Это может включать оценку технических рисков, рисков, связанных с бюджетом и сроками, а также разработку мер по снижению и управлению этими рисками.
10. Управление изменениями в задании на разработку Контракта: при разработке очень крупных EPC Контрактов всегда возникают изменения в требованиях или условиях проекта. Разработчики Контракта должны разработать для себя удобные процедуры управления изменениями, которые позволят эффективно реагировать на такие изменения и обеспечивать их правильное внедрение в условия разрабатываемого Контракта.