When drafting the contracts be sure to define exactly what you will be using it for and the functional requirements needed from any particular software investment. A key component of your deal and contract is the definition of the structure that best suits your organisation. You will have to run several roll outs and implementation models beforehand to determine exactly what you will be asking from the vendor. Be sure to accommodate for growth and expansion in your calculations and models.
Developing a payment schedule will be essential for these contracts. Base these around milestones instead of specific dates. Do not pay anything more than 20 percent for a deposit, and reserve a large portion of payment for completion or final implementation.
An often overlook portion of these contracts is access to the source code of the software. Include in the contract, exactly when and under what conditions will the source code be made available to your team. This also includes source code escrowing (updates, right of use, etc.)
Finally, service level agreements (SLAs) and customer support should also be included into the contract in case support down the line is required.
Vendors will often suggest that hardware purchases can and should be done through them and sometimes included in their contracts. This is for most of the time the best decision as you enable yourself to not only have a one-stop shop and ease for ordering hardware, but most importantly installation. You know that if you order through your IT partner, you’ll be quoted the right hardware for the job and have it installed without any issues. Dependent on your driving factors however this might not always be the best course of action . Better pricing can usually be had by engaging alternative hardware vendors.
However, note that if there is a problem with the hardware at installation time be it a physical fault problem, delivery issue or the hardware might not actually be fit-for-purpose, you will need to sort all of that out yourself, not your IT company. This can largely be time sensitive and time consuming and cost you much more than what you originally saved in purchasing equipment elsewhere.
Regardless of how you want to purchase the hardware, the following should be outlined in your IT contract:
Typically representing the largest spend in any budget, Professional Services should be outlined and defined with a fine tooth comb lest it lead to spiraling costs. Roles, responsibilities, tasks and deliverables should be stated clearly in the contract as well as any completion schedules required. As with step 6, if there is monthly maintenance and support involved as part of professional services, a full list as to what will be included is essential and must be itemised in your IT contract.
It would also be wise to include into the contract the requirement for weekly/monthly progress reviews and periodic updates with penalties should any deviation from these reports and reviews occur. Ultimately you need to see what you’re getting for your money so reporting and regular updates are important.
Termination policies and periods should be stated and clearly defined, including how the contract can be terminated.
If you’re investing capital into a project that you will be maintaining, developing and using in-house (even basic user administration), a simple two-lines should not be overlooked.
Perhaps one of the most important parts of any IT project contract; the scope. This is a combination of the charter, timeline and high level requirement documentation. The contract should include all background information regarding the project, objectives, assumptions as well as a brief explanation of what is in scope and what is not part of the scope.
The project schedule should include all milestones and any billable points. The high level requirements are a mixture of various key technical elements so it’s extremely important these are all explained to you in a language that you understand. Do not get confused by tech-talk. If you feel that is happening then project documents and contracts will need to be re-worded before sign-off or financial commitment.
This part of the contract should also state governance processes as well as standardised documentation procedures. And finally, the definition of the various deliverables of the project so you are aware fully of what will be implemented, covering pre-planning project tasks, during-project tasks and post-completion tasks and support.