Welcome!

.NET Authors: Tad Anderson, Ivan Antsipau, Liz McMillan, Pat Romanski, Matt Hester

Related Topics: .NET, Java, SOA & WOA, Web 2.0

.NET: Blog Feed Post

So, You Want to Outsource an Agile Project?

Any contract for agile project outsourcing also needs to answer these points

Irrespective of what the Agile Manifesto says (“Customer Collaboration over Contract Negotiation”) we do require a signed contract for ANY medium to large software outsourcing engagements – and that includes agile projects.

Why? Because when there is a commercial arrangement between two parties for delivery of any service where a significant amount of financial transaction is involved, there needs to be a clear agreement on:

  1. What is the service that is going to be delivered and what will be the charges for those services?
  2. What happens when things go wrong?
  3. Do's and Don’ts of how the interaction will happen

So, any contract for agile project outsourcing also needs to answer these points. But, how will an agile contract be different from a traditional software outsourcing contract?

This post is based on…
Major part of what follows comes from the whitepaper Agile Contract Premier by Tom Arbogast, Craig Larman, and Bas Vodde. I recommend that you read it.

I have also used some ideas from the following posts:

Let us see what these practitioners have recommended.

Is it possible to have Fixed-Price, Fixed-Scope (FPFS) agile contract?

Yes, it is possible but it should be avoided.

  • Requirement specification that is signed off is almost never what is actually needed
  • In an effort to deliver something within the constraints of price and scope, suppliers will often degrade the quality of their work – reduced code quality, do less testing etc.
  • Price include large risk contingency – this premium is usually hidden in the effort estimate

As a result, the customer may not get what they want and supplier may lose out because of changing requirement.

How can the supplier make such project work?

  • Use people with experience of the domain and the technology to estimate the effort
  • Clearly lay out the acceptance definition or the definition of “done”
  • Ensure that new requirements only displace existing requirements if they are of equal effort
  • Decide how additional requirement will be charged

FPFS contracts are common where there is low level of trust between both parties. This may be a starting point in the engagement and it the project is successful more flexible contracts can follow.

What are the options available for Variable-Price, Variable-Scope contracts?

Such contract normally starts with a Master Services Agreement (MSA) which is more like a rate card. The rate may be for people deployed, cost of each iteration, function point or story point delivered etc.

Since we are talking about variable-scope, there will not be any detailed definition of scope. However, there may be an overall cap to the total price of the contract.

Some form of an order may be released for executing the next iteration or next couple of iterations which will have a clearer definition of scope or backlog.

To cover the risk the contract may be terminated after completion of any iteration – agreed termination charges may have to be paid.

Can you have a completely transparent payment model?

Yes, if you follow Toyota. It is called the target cost contract. They follow this five step process:

  1. In collaboration between customer and supplier, identify, analyze, and estimate all possible project requirements.
  2. In collaboration, estimate the cost of change or scope increase during the project.
  3. From these two elements, establish the target cost.
  4. Calculate target profit, based on target cost (for example, 15% of target cost).
  5. Share all details and results with customer.

The idea is to have a trusting relationship where pain and gain can be shared by having a mechanism to adjust the actual cost based on the changing scope.

How do you protect against things going bad?

This is clearly the domain of the contract lawyers. They are supposed to ensure that contracts are drafted in such a way that suitable clauses are in place favoring their clients.

It is essential that non-lawyers involved in negotiating the contract understand the lawyers point of view.

However, one of the key premises of agile methodology is that the project risk is reduced through iterations and early delivery. So, it is strongly recommended that lawyers working on such contracts study and understand how agile method reduces risk.

This can help in significantly simplifying the contract.

Successful projects happen not because of the contract but because of many other things including collaboration, transparency, and trust. There are many natural roadblocks in the path of a successful project delivery – the contract should take care not to add any more roadblocks.

After all under normal circumstances everyone’s number one priority is to deliver a successful project. (There are situations where some people may want the project to fail.)

More Stories By Udayan Banerjee

Udayan Banerjee is CTO at NIIT Technologies Ltd, an IT industry veteran with more than 30 years' experience. He blogs at http://setandbma.wordpress.com.
The blog focuses on emerging technologies like cloud computing, mobile computing, social media aka web 2.0 etc. It also contains stuff about agile methodology and trends in architecture. It is a world view seen through the lens of a software service provider based out of Bangalore and serving clients across the world. The focus is mostly on...

  • Keep the hype out and project a realistic picture
  • Uncover trends not very apparent
  • Draw conclusion from real life experience
  • Point out fallacy & discrepancy when I see them
  • Talk about trends which I find interesting
Google

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.