Contract of an Agile Integration Project

Agile Contract

Agile Contract

More than often I hear CIOs requesting fixed price and fixed scope agile IT-projects. As more and more set of heterogeneous Line-of-Business systems are utilized in companies, need for integrating these systems increases in these projects. Quite often system integration is thought as a sub-project for example for ERP-project. This is the first common mistake to make: slave system integration for projects without separate integration governance and the end result will be called “integration spaghetti“. If you are familiar with concept of spaghetti code, you shall understand why spaghetti integration should be avoided. It will be a topic for own post later on.

Whether the integration project is a part of some master project or not, certain common risks face the agile integration project part:

  1. Process level requirements are understood only after few iterative sprints of implementation.
  2. Interfaces of third parties are unclear or do not meet their own specifications
  3. Pace and quantum of changes

Typically first steps to wrong direction are taken already at contract negotiations. Peter Stevens has published “10 Contract Forms For Your Next Agile Project” which nicely puts together ready-made concepts for contracts with different risk levels for supplier and customer. When looked from high above, its all about whose taking the project risk and for what price. When integration project has fixed scope and fixed price the obvious risks are at the supplier side – was the original estimation precise? If not, supplier ends with project gone bad on financial level. Still, I think the bigger risk taker in fixed price and fixed scope project is the customer. When there are several other suppliers whose system or software is integrated, all interface, process logic and requirement changes – even minor adjustments – that come after or during integration implementation are considered as changes.  Additionally, all adjustment to processes, new exceptions handling etc. from Customer’s business people – all changes again. The risk for Customer is to end up with endless Change Game with integration supplier and costs of that cannot be estimated. Customer’s original goal of keeping costs fixed and well-known beforehand are ruined. Well, some CIOs do try to include also changes to these contracts, but that is something which raises the fixed price too high as integrator puts all imaginable and non-imaginable risks to price. Using fixed price and scope in integration projects requires tremendously accurate requirements and details typically familiar in waterfall project model. It is still possible though. One way to avoid these risks is to do heavy prestudies for processes, requirements and systems that are going to be put to work together. I’m hearing the heavy thunder of waterfall project model in that as well.

In his presentation Stevens also provides better models of integration project contract. One of them is called Phased Development. In this model Customer funds e.g. quarterly releases and approve additional funds after each successful release. Customer’s risk is always limited to single release and suppliers target is to have successful release to get funds for next phase. To share risk more for Supplier fixed profit model can be used in each phase. This means that if release is partially unsuccessful, Suppliers shall finalize it without profit covering only suppliers own costs. This reduces customer’s risk on investment made in earlier releases and not having cancelled project with several releases but not yet the business requirements met.

Common risk for integration projects is also 3rd parties whose systems are going to be integrated – this is also something that should be taken care at contract level. But not with the integrator. Quality of interfaces and interoperability capabilities for system should be written in the contract for system vendor – in a sanctioned manner.

In addition to contracting there are of course lots of other aspects that will increase the probability of successful release. For example using Acceptance Test Driven Development (ATDD) as development method for integration with mutually agreed automated acceptance test cases reduce the risk for ending up in costly Change Game from both sides.

In integration projects I suggest to go for the phased development model. To reduce risks for customer, use fixed profit model with phased development and ensure, that best development models and practices are in use.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s