Agile Project Management And Software Contracts

By on August 30, 2016

This is an era of Agile!!  More and More clients want vendors to pursue agility in the software projects, as the clients perceive that “software so developed using agile would be of higher quality, greater resilience, and lower cost and matches the speed of business changes. And in sharp contrast, the vendors perceive the same agile as “accepting changing requirements every day, every time and anytime with usually minimal documentation.

Off late,  the relationship bondage between the Client and Vendor on agility has become so watertight that they negate  ‘ Waterfall ‘  approach  even  for establishing  regulatory ‘Contracts’, Agile is followed there too – TRUE !! Sometimes the contracts are not even existent, sometimes they are partly existent in mails and even if the contracts are established , they have the word agile embedded a thousand times to make it feel an agile project contract without realizing that Agility  focusses on adaptability and response time to changing Business requirements and Agile adoption always comes with special challenges and fundamental organizational changes at the client side and vendor side are necessary to realize the fullest outcomes.

Can just talking about ‘Agile’ make a project, an agile project? Will a project with a contract using the word ‘Agile’ make an agile project?  Will using and embedding the word ‘Agile ‘in every document of the project a hundred times make a Project an Agile Project? OR will embracing ‘Agile’ in mindset, skillset and toolset by self-organizing, self-governing and highly collaborative distributed teams make a project an Agile Project? 

Focusing a bit on evolving Agile Contracts, in general there are there are 3 key goals for any software development contract:

1) To define the purpose of the project [i.e. what are the parties trying to do? in simple terms  the scope of the work;
2) To define how the project is to be established and run[ i.e. the Execution Methodology ] ;
3)  To define what happens if the project goes wrong.

In the waterfall contracts, the Execution Methodology is not given prime importance all prime time is available for defining scope and legal remedies for what if the project goes wrong] as the client puts the onus of project execution, without clients participation completely on the Vendor . So a general contractual template that is picked up from a cloud of contracts just sufficed for the purpose as the Client and the Vendor obligations that are set forth in the contract are just ornamental for contractual purposes only. In Agile contracts, a general contractual template can’t be picked up to kick start an agile project,  prime importance and sufficient effort / time  in contract formulation  needs to be given to “ execution methodology” to determine the  wherewithal, to establish a  well-designed and crafted methodology of Agile roles and practices by both Client and Vendor  inclusively, cohesively and collaboratively , to recognize the need that Client and Vendor are mutually exclusive and inclusive  and  are as important as each other and together are responsible for successful outcome of projects  which means that !! If an Agile Project is successful it is because of both Client and Vendor and If an Agile Project fails, it is also because of both Client and Vendor – mutually responsible always.

Debashish Ghosh

Debashish Ghosh, CSM, CSP, PMP is an agile consulting leader with a Big 4 background.