Робота проєктного менеджера — це не лише спілкування з командою та клієнтом, а й ведення документації. Кожен документ, що використовують для проведенні тендерів і підписання контрактів, має свої особливості і потребує великої уваги. Віталій Шквира, Delivery Director в SoftServe, розповів про основну тендерну і контрактну документацію, з якою працює проєктний менеджер. У статті розкажемо про те, які нюанси слід врахувати, щоб контракт був однаково вигідний для обох сторін.

Зміст:

• Який вигляд має процес закупівель
• Основні типи тендерної і контрактної документації
• Структура контракту
• Типи контрактів
• На що звертати увагу проджект-менеджеру: важливі моменти та рекомендації

Який вигляд має процес закупівель

Часто у великих організацій є окремі підрозділи, які займаються закупівлями та контрактами. Не зважаючи на те, що формування і підписання контракту, як правило, не є прямим обов’язком проєктного менеджера, є великий сенс включатися в цей процес. Саме менеджер в кінцевому результаті буде відповідальний за виконання основних пунктів договору. Отже, є великий ризик того, що весь проєкт може піти хибним шляхом з самого початку.

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

1. Компанія-замовник визначає проблематику або бізнес-потреби, вирішення яких лежить в основі рішення або продукту. Його випуск, у свою чергу, буде закладено у скоуп проєкту, базуючись на вимогах.

2. Коли основні вимоги визначені, замовник готує специфікації. Так звані Terms of reference (TOR) і Statement of work (SOW). Так підрядники краще розуміють, у чому суть проєкту і що саме потрібно зробити.

3. Відбувається пошук підрядників і вибір методу закупівель.

4. Підготовка тендерної документації. У багатьох організаціях, особливо це стосується компаній «enterprise» рівня, є заборона на так званий «Single Sourcing» — отримання послуг або товарів від єдиного підрядника або постачальника. Тобто проведення тендеру між певною мінімальною кількістю учасників є обов’язковим етапом, коли, наприклад, плановий бюджет контракту перевищує певну суму. Але бувають і винятки. Наприклад, коли підрядник є єдиною організацією на ринку, що надає потрібні продукти або послуги, або ж з цим підрядником вже є тривала і успішна історія співпраці — так званий «vendor of choice».

5. Тендер. Складність тендерного процесу визначається специфікою конкретного замовника або проєкту і може варіюватися від простого RFQ (Request for Quotation/Запит на Котирування) до максимально складного повноцінного тендеру — з кількома раундами відкритих загальних сесій з підрядниками, з уточнювальними питаннями і торгом.

Менеджеру зі сторони підрядника буде корисно (я б навіть сказав, необхідно) дізнатися максимум інформації у замовника: потреби, обмеження, бюджет, очікування за технологіями, рівнем і локацією ресурсів, що буде після того, як випустять рішення, чи потрібна документація для користувачів, тренінги для них тощо. Все це прямо впливає на формування цінової пропозиції.

Наприклад, є досить поширена ситуація, коли компанія-підрядник бюджетує саме розробку і поставку рішення, а замовник, зі свого боку, очікує на певний період супроводу після релізу. Він сподівається, що якийсь час підрядник підтримуватиме рішення і користувачів. Такі моменти необхідно уточнювати одразу і чітко фіксувати в контракті. Менеджеру зі сторони замовника важливо розуміти, що будь-яка інформація, яку надає замовник, має надаватись однаково всім учасникам тендеру.

6. Оцінка пропозицій. Великі організації у більшості випадків мають чіткий фіксований процес відбору підрядників за конкретними критеріями. Ідеально, коли цей процес прописано у тендерній документації.

7. Вибір підрядника.

8. Переговори за контрактом та підписання. На цьому етапі початкова ціна, перелік товарів або строки можуть дещо змінюватись.

9. Виконання контракту.

Основні типи тендерної і контрактної документації, з якими працюють менеджери проєктів:

• NDA (Non-Disclosure Agreement). Документ, підписання якого передує розповсюдженню будь-якої непублічної інформації обома сторонами. Підписується обов’язково. Варто зауважити, що кожна сторона може мати свій шаблон NDA. В такому разі підписуються обидва кожною стороною (замовником і підрядником).
• Request for Proposal (RFP) — запит на комерційну пропозицію. Найпоширеніший документ. Найчастіше готуємо RFP в рамках тендерної документації, яку дає замовник, тобто насамперед чітко витримуємо прописані критерії оформлення комерційної пропозиції. Проте не зайвим буде вказати додаткову інформацію про компанію, а саме: загальний досвід на ринку, потужності, експертизу, досвід виконання подібних проєктів з наданням конкретних Case Study, рекомендації від інших клієнтів.
• Invitation for bid (IFB) — запит на ціну. Це варіація RFP: отримавши такий документ, замовник очікує побачити фіксовану ціну. Його надають тільки в тих випадках, коли вимоги досить опрацьовані й можна достатньо точно порахувати бюджет майбутнього проєкту.
• Request for quotation (RFQ) — запит на котирування, в межах якого дають рейт: одна година фахівця коштує певну суму. Не зовсім правильно з точки зору налагодження відносин з клієнтом та іміджу компанії давати саму лише ціну. Тут так само, як і у випадку з RFP, варто додати інформацію, яка дає ширше уявлення про компанію-підрядника.
• Request for Information (RFI) — запит на інформацію. Тут намагаємося максимально розповісти про компанію, досвід, чому саме ми повинні виконувати цей проєкт. Інколи запит на інформацію надходить окремо, коли клієнт шукає потенційних вендорів для майбутніх проєктів.

Якщо говорити про класичний проджект-менеджмент, є відкриті засідання й торги, на які приїжджають представники вендорів. Вони проводять відкриті сесії, де ставлять питання, а представники замовника відповідають на них. Але в IT такий підхід практично не зустрічається.

Найближчий курс за напрямом: IT Project Management

Структура контракту

1. Спочатку підписують NDA.

2. Далі — Master service agreement (MSA). Це рамковий контракт, який не покриває специфіку конкретного проєкту. Він загально описує, що необхідно зробити, що виконавець зобов’язується якісно і вчасно виконувати свої завдання, а замовник — вчасно приймати й оплачувати результати роботи. Детальне описання конкретного проєкту, фази чи сервісу описують у SOW. В межах одного MSA може бути кілька SOW. Тобто не потрібно щоразу підписувати MSA знову: достатньо підписати його один раз між двома компаніями, і в межах цього MSA реалізовувати різні проєкти. До речі, кожна окрема SOW може регламентувати окрему цінову модель (T&M, Fixed Price, Deticated Team, Outcome-Based чи Transaction-Based).

3. Підписання SOW.

4. Підписання Amendments (доповнень) або Change Order-у (СО). Коли в рамках одного SOW потрібно розширити список робіт, внести будь-які доповнення, не потрібно цей SOW перепідписувати — достатньо підписати Amendments. В рамках одного SOW їх може бути кілька.

Важливо знати, що Amendments має силу над SOW, а SOW доповнює MSA. Якщо у SOW зафіксована умова, а потім в Amendments вона змінюється, більшу силу має Amendments.

Типи контрактів

Fixed-Price Contract

Згідно з контрактом, конкретний скоуп робіт виконується за конкретну ціну і, як правило, в конкретному таймлайні. Цей тип контракту є найбільш ризикованим для підрядника. Це пов’язано з фіксованим бюджетом. Звісно, бюджет фіксований умовно, оскільки зміни є невід’ємною частиною будь-якого проєкту. І як тільки виникає потреба в цих змінах, Change Management процеси починають працювати. Зміни погоджуються клієнтом в рамках прописаної в контракті процедури і беруться в роботу.

Fixed-price contract менш ризикований для замовника. Цей тип контракту рекомендовано використовувати тільки при достатній деталізації вимог. Зрозуміло, що кожен замовник хоче мати чітке розуміння бюджету. В таких випадках можна використовувати так званий «Rolling Wave Planning» — детально пропрацьовувати скоуп на найближчу фазу проєкту, фіксувати бюджет. Для наступних фаз пропрацьовувати високорівневий (орієнтовний) прогноз.

Контракти, які передбачають заохочувальні виплати для підрядника

Є Fixed Price with Incentive Fee (FPIF). В такому випадку, припустимо, ціна робіт — 100 тисяч, а винагорода — 2 тисячі. Якщо підрядник виконує проєкт раніше запланованої дати, отримує винагороду.

У випадку контракту Fixed-Price with Award Fee (FPFA) підряднику виплачується фіксована ставка та періодично додаються премії за успішне виконання завдань. Наприклад, бюджет проєкту — 100 тисяч. Підрядник кожного місяця випереджає графік виконання на 15%. За кожен такий місяць він отримує від замовника 1 тисячу додатково, але загальна сума таких винагород не перевищує 10 тисяч.

Fixed-Price contracts with Economic Price Adjustments

У таких контрактах зазначено, що бюджет може змінитися за деякий час відповідно до змін на ринку. Наприклад — прив’язка до курсу валют.

Time and Materials (T&M)

Це один з найрозповсюдженіших контрактів, в якому фіксується вартість часу фахівців або матеріали. До матеріалів, наприклад, можна віднести вартість ліцензій програмного забезпечення. У цьому випадку замовник сплачує за фактом витраченого часу і матеріалів, маючи фіксовані у контракті рейти. Time and Materials є достатньо прийнятним для обох сторін. Особливо у випадках, коли чіткі межі проєкту визначити важко або неможливо.

Cost Reimbursable Contract

Згідно з цим контрактом замовник відшкодовує лише собівартість виконання робіт. Такі контракти часто використовуються в державних установах або в дослідницьких лабораторіях. Cost Reimbursable contract найменш ризикований для підрядника. В будь-кому випадку підрядник повинен бути зацікавлений у досягненні результатів проєкту й допомагати замовнику.

Cost plus % of Cost Contract

Тут підрядник отримує відсоток від бюджету проєкту. Чим більший бюджет, тим більша сума по відсотку. Такі контракти майже не зустрічаються на практиці, а в деяких країнах (наприклад, в США) взагалі заборонені на законодавчому рівні.

Гібридні моделі контрактів

Останнім часом вони набули великого поширення. Як це працює? Ми можемо підписати Fixed-price contract на одну фазу, наступна ж фаза може виконуватися в T&M ціновій моделі. Тобто один контракт може мати різні прайсинг моделі. Багато залежить від «рівня невизначеності» на проєкті.

Важливі моменти

• У більшості випадків Time and Materials регламентує лише вартість годинної/денної ставки та/або вартість матеріалів. Відповідальність за виконання цілей проєкту здебільшого лежить на замовнику. Але навіть у таких ситуаціях виконавцю варто брати неформальне володіння і відповідальність на себе. Адже якщо в певний момент проєкт «зверне не туди» і стане зрозуміло, що це точка неповернення, програють обидві сторони. Клієнт розірве контракт, дарма витративши кошти, адже цілі проєкту не виконані. Виконавець втратить лояльність клієнта (або ж взагалі клієнта) і зіпсує свою репутацію на ринку, що в подальшій перспективі негативно вплине на бізнес.
• Обов’язково потрібно погодити визначення ролей, відповідальність, вимоги та структуру команди. Все це визначає підрядник і погоджує з клієнтом. Також потрібно затвердити термінологію (будь-який неймінг і визначення).
• Важливо переконатися, що клієнт працював з підрядниками раніше. Якщо ж клієнт ніколи не працював з IT-аутсорсинговими компаніями, він в 99 випадках зі 100 не має чіткого розуміння, як надати необхідні доступи, зробити «онбордінг», в які процеси включати людей з організації підрядника, як комунікувати тощо. Всі ці моменти суттєво затягують старт робіт.
• В жодному разі не занижуйте бюджет у Fixed-price контрактах. Нерідко саме занизька ціна може бути причиною відхилення пропозиції. Для клієнта це може означати, що ви недостатньо оцінили проєкт. Відповідно, не розібралися в тому, що саме потрібно клієнту. Нещодавно ми підписали контракт, попри те, що наша пропозиція була найдорожчою. Клієнти вибрали нас, оскільки побачили: ми чітко розуміємо, що саме має бути виконано. Вартість повинна бути відповідною.
• Чітко визначити роботи, які не входять в скоуп проєкту — зафіксувати out of scope у контракті. Це не значить, що потрібно остаточно відмовитися від виконання цих робіт. Якщо це в компетенції підрядника, роботи можуть бути виконані в рамках окремих Change Orders або SOW.
• Не забувайте про нефункціональні вимоги (NFRs), які іноді може пропустити й сам клієнт. Один із яскравих прикладів — вимоги від внутрішнього ІТ клієнта, служби інформаційної безпеки або маркетингу. Важливо з самого початку розуміти розуміти, як IT-департамент підтримуватиме рішення, чи є обмеження по використанню конкретних технологій, вимоги до швидкості роботи (performance), візуального оформлення програмного рішення тощо. На одному з проєктів ми виявили, що одна з ключових технологій, на якій базувалося рішення, не підтримується ІТ-службою клієнта. На той момент значна частина коду вже була реалізована, тож довелося переписувати його. Таким чином графік і бюджет проєкту зазнав негативного впливу.
• Фаза стабілізації — майже must have. Часто після релізу в продакшен, з моменту старту використання системи кінцевими користувачами, з’являються проблеми, які було важко передбачити під час тестування. Ясна річ, що насамперед це має покриватися правильними Quality Assurance і Quality Control процесами. Проте практика показує, що все спрогнозувати неможливо. Отже, потрібно запланувати певний період часу на так званий post implementation support. Важливо також правильно пояснити клієнту суть цієї фази.
• Багато проєктів провалюються тільки тому, що клієнт включається на етапі прийняття і випуску продукту. Необхідно ж робити це з першого дня. Як з цим боротися? Чітко фіксувати в контракті рівень залучення клієнта, а також швидкість реакції і прийняття рішень.
• Детально прописати Change Management процес і ролі в рамках цього процесу.

Загальні рекомендації

• Своєчасна оплата — must have. Якщо клієнт затримує оплату, це червоний прапорець для РМа, який може сигналізувати, що щось йде не так.
• Одна з характеристик хорошої співпраці — жодна зі сторін не дивиться у контракт. Зворотна ж ситуація може означати, що якась із сторін починає обмірковувати розрив контракту і шукає формальні на це причини. Варто зауважити, що, навіть в разі розбіжностей, до суду справа доходить рідко, адже судові процеси рідко несуть вигоду якійсь із сторін. Як правило, це великі фінансові і репутаційні втрати для обох. Сторони повинні завжди намагатися знайти вихід із ситуації
• Маркетингові права і права на інтелектуальну власність. Майже завжди ці права повністю залишаються у замовника. В поодиноких кейсах інше регламентується контрактом.
• Так званий «договір про ненапад». Цей пункт контракту регламентує можливість (частіше виключає її) як найму фахівців підрядника стороною замовника, так і навпаки.
• «Безкоштовні» зміни. Деякі зміни практично не вимагають ресурсів з боку підрядника. В таких випадках підрядник може зробити це безкоштовно для замовника. Це буде правилом хорошого тону і основа для подальшої успішної співпраці.
• Групові зміни. Якщо клієнт достатньо повільно реагує на Change Requests, є сенс опрацьовувати їх періодично, зібравши в один список, і вже тоді надсилати замовнику.

Робота з контрактами є невід’ємною частиною професійної діяльності проєктного менеджера. Тож хороше розуміння процесів, специфіки й використання описаних вище підходів — must have для будь-кого, хто називає себе РМ-ом і хоче бути успішним у своїй кар’єрі.