Estimating global delivery - Don't toe the line

First off the basic rule on estimating

Cut your cloth to the available time and resources

What I mean by this is don't create an estimate for the fully gold-plated, uber techy dream system. Make a smart guess based on the business value of the project what you should be spending. As a hint the project should be costing less than its x2 benefits. So if it takes 6 months then you can spend a year of the ROI, etc, etc. What that starts saying is that if you are taking 4 years and spending 8 years of the ROI... is there really a business case? The point of this is to be clear up front on the constraints in your estimates and get them down. Be as clear in what you won't do as in what you will do.

What this post is really about though is doing global estimation and in particular the practice of "line shifting" that people seem to go through.

The practice goes as follows. Someone creates an estimate which assumes

1. All on shore delivery
2. Everyone knows the technology
3. Communication won't be an issue

I'm ignoring here the missing out the business change side (which is also scarily normal) but the point is that the estimate is created and produces an FTE count for the project



Then along comes someone and goes "great, now we need to deliver this offshore" and a line is drawn on the graph indicating the "onshore" and "offshore" resources. Now people think "Ohh its offshore so we better add in some more people for communication" as if adding people to a project makes it better and the offshore resource numbers are scaled up due to perceived quality issues.


Then the challenge comes "more offshore" so the line gets shifted again with more people added onto the offshore team as it crosses the line


So all that has really happened is that people shift numbers around in a spreadsheet so they get the graphs and answer they want (i.e. make it cheaper) but the actual estimation process is based on the original "onshore" case with numbers being randomly multiplied and shifted around without thinking about what this does to the project. The graphs look great though




The project then starts and people start splitting the work and they find that

1. The onshore team tries to "own" everything
2. The comms between the onshore and offshore teams is rubbish
3. The duplication of roles either side of the project creates a split which causes challenges
4. The project descends into a "project management" led exercise of reporting and tracking
5. The project delivers late and over budget

And the blame goes to "using offshore" resources. The reality is that the problem is the insane estimating process that marks lines in the sand and says "we must do 80% offshore" so people shift the line to 80%. The point is that if you are doing offshore then estimate based on distributed delivery.

Think about the services. Which ones can be done fully offshore (vanilla package delivery for instance), which can have requirements onshore but everything else offshore, which need to be right next to the customer because they will change the requirements frequently and its a critical business value service? Split the estimate up based on the services, then estimate them based on the right delivery model for that service this might mean you don't hit your 80% target, but it does mean you can explain why you didn't, and point out that some things (testing, load testing, integration testing, systems integration for instance) are being done 100% offshore.

The other point here is that it enables you to construct your service teams around the right delivery model for that team. Having an 80% line often means people leave business analysts onshore, sometimes that isn't the right thing, it might be better for them to fly over and spend a few weeks with the customer then go back and just do any changes via the phone. If its a low change area then this is a better model. It also helps you to understand the right way to train up your teams and the different type of training they will require, rather than having a blanket statement on training.

Toeing the line is a mental way of estimating a distributed delivery. It assumes that

1. All people have the same skills
2. Working offshore is like working in the same room, you just have to shout louder
3. All parts of the project are equally well suited to offshore delivery
   

It is however probably the most common way of estimating distributed delivery that I see today. The point of SOA is that different services have different business values and require different delivery models. Toeing the line assumes that everything is the same.

Estimate sensibly, estimate within the business case, but for pitys sake don't estimate based on a moving line of the percentage of resources you have offshore. Globally delivery works, most times when it screws up its because people are toeing the line onshore.

Technorati Tags: SOA, Service Architecture