In the race to meet the demand for something cheaper, faster and better – many organizations find it challenging that their agile practices are in major conflict with existing project management standards. While consultants, service providers and software developers from various countries utilize the agile framework, you just wonder how things will work out, especially when adopting this lean concept to your outsourced project. The fact is that there isn’t really a one-size-fits-all-solution where this agile practice is concerned. The issue is not really about the nature of an agile project but rather, how everyone will transition to make the contract effective as they work for a common goal. How do you really do it.. or, can you really do it?
Finding the Right Answer with the Right Question
Keep in mind that the concept of agile is an ever-evolving one and there’s no common definition for it. You may read a manifesto about the topic, but it’s more of how you will all work as a team to deliver business value that matters. In this case, it is important for you to have the same idea of what agile will be before you even sign that contract with your client. The last thing you want is a mismatch in perceptions that will lead to frustrations and distrust. You also have to be upfront on how you will get paid by agreeing on the scope of work or the ‘iteration’, and the price for that. You will have to calculate compensation for extra work as well and make sure that the fee schedule is fair for both parties. You also have to include project review in the process, like how will you get paid when bugs happen? What’s the feedback timeframe? Therefore, in order to achieve quality deliverable, you have to work on constant and consistent communication using technology accessible to everyone.. and make sure that transparency rules from start to finish.
Resistance to Change vs. Responding to Change
While contracts are legal reflections of people’s wants and fears, keep in mind that they don’t give birth to successful projects. It is collaboration and trust that build the bond between a client and a service provider. The trouble is, once a contract is signed and the development phase rolls, everyone is mixed up on what the real scope is and what constitutes a revision in the contract. Is it the request for changes that leads to arguments where Agile is concerned? Perhaps, it’s more likely about a lack of change. Not everyone can follow these changes too and when new requirements emerge, old ones are overlooked and misinterpretations may arise. Think of it as a beautiful piece of architecture – aesthetically pleasing from the outside, but dysfunctional on the inside. Is it much safer to draft a contract the traditional way then?
Agile Development and the Unconventional Contract
When we speak of contracts, we often think about fixed price models which may not necessarily apply to work done by cross-functional teams. Other than disputes, changing the contract structure can have legal implications and this approach is definitely not for everyone. Sometimes, the simplest way to make sure that the process is least disruptive is to keep the plan from your customers, unless they ask. Or, if your customers don’t like what you came up with, then, they don’t have to pay for it. It can work if you have deep pockets though. You may also have a rolling contract where your clients pay regularly in response to project delivery… the options are plenty and so are the risks. The real question is how ready are you to make your clients sign that contract without having to define the project’s scope.. and still, giving them the assurance that they’ll get what they pay for?