Although I am not a legal expert, during all this time since I was involved in web development, I have seen quite a few issues or pitfalls in IT contracts that can significantly affect the project’s life cycle.
Furthermore, when they do affect the project, they do it in a very frustrating way because you usually develop specific expectations from the project or from the customer and eventually you see that some of them are not really aligned with the contract in place. That’s when things can get off track if the right decisions are not made right away.
The following list of issues were mostly identified from an implementation provider point of view but nevertheless, they can be very useful tips also for contractors since all parties can be affected by them.
- Do not use complex contract types. There are quite a few contract types that are well known in the industry, like: Fixed Price, Time and Material, Cost plus Incentive Fee, Cost plus Fixed Fee. It is highly recommended to stick with them! Once I have experienced a situation when the remuneration on the contract was quite complex. It was a combination of T&M and Fixed Scope with monthly payments that should not exceed 25% of the initial estimate provided during project initiation. By the time the project execution was around half, both us and the customer already had different calculations about the remunerations in that month. Eventually, after hard negotiations, we agreed to close the contract in that point, reassess the remaining project scope and sign a new Fixed Scope contract for what’s left.
- Specify in the contract when customer input is needed. By far, one of the most important issues that is causing general delays to any project is represented by delayed customer input. For example, the customer might constantly postpone project status meetings where various project related decisions have to happen or the customer sends the requested resources a few days later than estimated. All these small delays can sum up and create a significant delay for the project completion. If the implementation provider doesn’t specifically highlight when exactly it needs input from the customer and what happens if it’s not delivered on time, then the implementation provider might be held accountable for these delays.
- Decide upfront whether or not to commit for third party integrations. Quite often, when implementing IT projects, integrations with various third party systems are needed (Eg. CRM, CMS, DMS tools). Those systems might have APIs with limited functionality that might not be able to achieve the desired functionality within your application. For these particular scenarios, the customer can be reasonable and willing to work with you to find a workaround or simply can be quite inflexible and requesting you to implement what has been requested without caring too much about technical limitations. So, in my opinion, you have to decide upfront with the customer whether or not you are willing to be accountable for any integration limitations or risks.
- Specify in the contract what type of resources the customer needs to provide during the project. Usually the customer does acknowledge that a dedicated resource needs to be allocated to oversee the project but there are cases when the customer assumes that everything the implementation provider needs to know was already provided during project initiation. As a result, a weak cooperation will be kept during project life cycle. In order to overcome this, the implementation provider needs to specify in the contract what types of resources are needed from the customer and which will be their assignments.
Of course, there are other important issues with less impact like specifying which browsers or which devices will be supported by the application or how many languages the layout of the application might support, but I feel the above ones are mandatory to be mentioned in any IT contract nowadays.
As always, I encourage you to contribute if you like with similar experiences and lessons learned that can help others not to do similar mistakes.