Contracts have two parts. The first ‘practical’ part documents what’s going to happen - essentially it records what one party is going to provide, what the other party will get, and how this will all happen. The second part is the ‘legal’ part – involving liabilities, warranties, consequence of terminations, etc. It is this second part which many people assume is the important part of the agreement, and the part they need legal advice on.
However, if businesses pay enough attention to the practical part they are likely to have more successful IT projects – they will be more profitable and the resulting solution will be more likely to meet the required business needs. So it is important for business managers to ask themselves the question “Are all your IT projects successful?” For suppliers - are your projects profitable? For customers – are your projects cost-efficient and on-budget? Or are misaligned expectations and lack of agreed details costing money and time?
The answer of course is no, not every project is successful. And for plenty of projects, where they lose money, they lose a lot of money. Here are a couple of places where a good contract can help save money.
A good agreement saves money by limiting miscommunications between the parties. Often with a software project the client has a wish list of things that they want the software to do – one which may not be realistically within the bounds of what the supplier can offer. Without a sufficiently robust contract the customer wish list can remain just that – wishes. And then when the software doesn’t fulfil that wish list this can cause disagreements, delays, or even require the whole project to be scrapped.
A good contract will lay out just what features the customer can expect from the solution and how those features can be tested to ensure they are performing. The customer understands what they’re getting, the supplier understands what they’re providing, and money is saved by limiting problems down the track.
Change versus Defect
During many projects there will be testing to determine if what the solution provides meets the requirements of the client. With a good process this can be pretty straightforward – client checks the product against what they need it for, defects are raised with the supplier and the supplier remedies those defects, and on re-testing the product should work as desired.
However, there can be some problems when the user testing raises requirements that the product was never supposed to meet in the first place. These can’t (or shouldn’t) be raised as defects which need to be fixed under the original contract, and instead are changes that can be achieved at additional cost.
A good contract will save money by including a process for determining what is a defect (which needs to be fixed at no cost as part of the testing and development process) and what is an add-on change which needs to be paid for by the customer.
IT Contract Templates enables customers to put contracts in place that are easy to set up while still including all the provisions that specialist IT projects need. They’re agreements that keep living throughout the life of the project, so both parties can refer back to them to make sure the lines of communication remain open and structured.
I T ’ S E A S Y T O