It is a common misperception that a tech development project is similar to a construction project and relatively predictable. In reality, all development projects are highly uncertain with variable research and development.
An agile approach contemplates that requirements will be articulated in an iterative and evolutionary manner so that time and money is not wasted in developing software for requirements that are not ultimately needed. It also recognizes that money may be better spent for requirements that were not recognized at the beginning. Compare this to a sequential-development (‘waterfall’) project where all requirements are identified upfront and when developed may never be used, because they were ill-conceived or lacked effective engagement with real users. In addition, after delivery of a ‘waterfall’ project many requirements still need to be added to meet the true needs. This means that a contract based on a ‘waterfall’ approach will actually increase the risk that the client pays more and gets less than they expect, and that the reverse will occur when the agile approach is understood and addressed in a contract.
How do you measure success with respect to an agile contract negotiation? There is a saying regarding contract hardball that, “you know you have a good contract when both parties are unhappy” because neither party got what it wanted. An agile mindset argues the opposite for both parties, and that a “win-win” approach is really what is mutually optimal. But of course the real test of a contract is in the execution stage of the project, when the people on the ground are working together. During this stage, any need to refer to the contract is arguably a sign of failure—not only of collaboration but also of the contract’s ability to foster a framework for collaboration and success.
The good news is that an agile and iterative approach can, by design, decrease risk and save time and money. The early feedback and delivery of a working system every two weeks (for example) fundamentally changes the dynamics behind contractual terms, as opposed to the excruciating negotiation and effort put into a traditional ‘waterfall’ project which is driven by the assumption (and fear) of a long delay before delivery.The good news is that an agile and iterative approach can, by design, decrease risk and save time and money. Share on XYour team and our development-team must be closely involved and collaborating throughout the life of the project. This ongoing collaboration does not mean that Chromedia has vast opportunity for further billables, rather it means that contractual constructs must be created to allow for continual customer participation, assessment, and evolution.
The contract is meant to include the broader notion of agreements or specifications between our companies for product development. With less emphasis on nailing down these agreements and more emphasis on ongoing collaboration, learning, and evolution. Performance and collaboration between our companies will get better and better as we share all the gain or pain. Protecting yourself is easy, if you are extremely dissatisfied with performance, simply terminate the engagement at the end of iteration. You will have been delivered functional working deliverables that provide value every step of the way.
