My blogs have so far tended to address SCL issues or IT in legal practices as opposed to IT law itself. I want to redress this by focusing on a conundrum that IT lawyers have never in my humble opinion satisfactorily resolved.
Ever since I can remember, capturing the development phase of a project in appropriate contract provisions has challenged and sometimes eluded the art of the best practitioners in the field. Development itself may have moved on more from the creation of new source code and entire new systems to configuring an established software platform, with some new code around the fringes. However the complexity of the transformation activity remains. It is hard to predict the timescale for completion of the project with reasonable accuracy, and meeting the (often evolving) requirements of a customer is difficult.
Fortunately software and system builders and developers have found ways round this. Using iterative development and processes such as Agile methodologies they have built up much better ways of ensuring that the customer’s requirements are met within a controlled and disciplined development environment. Wikipedia describes Agile as “a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.”
It interestingly also comments that Agile is sometimes confused with “Cowboy Coding” which is “a (usually derogatory) term for software development without a defined or structured method: team members do whatever they feel is right”! We’ve all come across that approach I suspect.
However IT contracting practice has simply not caught up with iterative development methodologies. These may be applied in practice but the contract will normally assume a traditional approach with fixed requirements and designs and deliverables. In other words the contract does not reflect what is actually happening on the ground, which is not good news, particularly if things should go wrong. The fundamental problem is that customers, whilst acknowledging the benefits of Agile type methodologies, want fixed price contracts. Iterative development contracts lend themselves to time and materials contracts, perhaps with some fixed monthly budget. This essential dilemma makes contracting for these processes hard, short perhaps of having a separate T&M design and development contract before a fixed price build and operate agreement is entered into.
Everybody in the IT community seems to acknowledge that Agile or something similar is a better approach to development projects beacause it is far more likely to deliver the customer’s needs. The Obama administration has endorsed Agile. So there must be something right about iterative development.
It therefore seems a great pity then that nobody has to my mind come up with a satisfactory way of reflecting this commendable development approach in IT contracts.
So I would like to issue an Xmas challenge readers. This is to come up with an effective way of contracting for Agile or similar iterative development methods and to find an enduring solution to this puzzle.
Clive
