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

Hello Dallas, meet Bangalore

One thing to raise up on "Project Gerald" is its global scope. Phase 1 has a dev team mainly in India and two business change teams in the US and UK. This gives us an entertaining timezone shift (West Coast US to India) and also some differing cultural challenges.

The most important thing on a global programme in the first month is hit the road later on you can do the conference calls and videos but there is nothing like the personal touch. Don't wait until there is an issue to fly, get out on the road right at the start and make sure everyone knows you are in charge, what you want to achieve and how you will promote their success within the project.

Lets be clear its horrible travelling, but there really is nothing that gets you out of this situation. Don't con yourself that everything will be fine and you can do it all remotely. If the team doesn't know you then they will feel less inspired by you and be more prone to take local orders over project directions. You need to smash those lines and make sure they report through the programme.

I see my job as the architect to be the owner of the programme. Its not a commodity area so a Project Manager wouldn't have a clue what to do, without the architect knowing the technologies and the approach there really is no project. The PM can almost be an administrator and tracker if the architect is able to organise the project effectively. If it goes tits up its my fault, the PM might get some flak but everyone knows its my programme so I make sure I'm in control of it.

So some basic hints if you are going to travel

• Schedule - Make sure there are defined deliverables out of the time you spend, don't just make it a glad handing shop. Make these joint deliverables and get your hands dirty
• Remember names and faces - a cheap way around this is to get a "team page" put up with everyone on there, so you can at least pretend you remember
• Make it a "we" - when speaking to people tell them what you want them to do and what "we" will therefore deliver together
• Regionalise efficiently
  

This last point is important. Using a Service Architecture you can make sure that you teams are geographically efficient by centring certain teams in certain locales, but don't do this blindly. For two of my services the requirements piece will be done hugely onshore with the development in India but for the third the requirements will be done globally and the development will be done globally. The boundaries between the services therefore need to be crystal clear to make sure you have an effective global programme.

This brings us to the next point.... estimation

Technorati Tags: SOA, Service Architecture

Setting the high level services.

Okay so now the team is getting established, as a hint for the future though remember that August is a really bad time to get a project going in Europe, and we are looking at structure. We have three high level business services

• Engagement
• Management
• Production

These are the real names but they describe the basic areas of the project I'm on.

Engagement is all about getting information, its about how we get the information from the users and from other systems that we need, it covers how that information gets filtered and the process around registering systems and users.

Management is about what we do with the information, how we prioritise certain elements and eliminate others and use it to decide what actions should be taken. It covers approving actions and business case creation.

Production is about what happens once we've decided to take an action. How do we track their implementation and their operation against the original costs and business case estimates.

This really means that when we do the process and technology work we are being very clear about these handover points between areas because they represent different operational ambitions. Engagement is all about quantity and then filtering. Management is about the quality and Production is about realising the benefits.

We've also mapped the stakeholders onto these areas to determine which bits are most important to them and so which bits will have them actively engaged.

This is now the structure that we will use to organise the project.

Technorati Tags: SOA, Service Architecture

The importance of being absent

For the first time in several years I only had a one week summer holiday, now admittedly this was because I also had one week in Paris about a month ago so it isn't too tough. During the week away I was completely off from work this means

• No work phone
• No checking email (didn't even take the security card so I couldn't do web access)
• No contact at all

It was a great break, although the weather was a bit crap. Coming back I have "quite" a lot of emails, only 250 as its August. These break down into broadly 4 groups

1. Circular & email lists - standards bodies, HR and that sort of thing. No issues here
2. Urgent requests for information - only one of these is now within time and they've managed to get the information from elsewhere while I was away
3. Urgent requests for my feedback - about 40 of these, 38 appear to be not as urgent as the original email said as they've then followed up the out-of-office with a "when you get back", 1 has expired and the other one I'm doing this morning
4. Problems that went away

Its the last group that are the ones that would have killed the holiday. There are only a few (about 6) but they all follow the same pattern

1. Urgent email asking for help
2. Email sent cc'ing in others asking for how to contact me
3. Alternative resolution suggested
4. End of thread

Now a few of these are now in my inbox and I'll deal with them. But its much better to deal with them after a week by the sea relaxing (if having two young kids can be described as relaxing) with me in a good frame of mind than doing it remotely, being annoyed and having an annoyed family. It also has the added benefit of having flagged up on high that I'm critical to some important things (if I'd done the work on my holiday it wouldn't have been so visible) and that I'm controlling my own time.

The reason I bring this up is that too often in IT people burn themselves up with a mistaken view that working on holiday somehow makes you more valuable. It doesn't, it makes you an idiot and sets the expectations of others that you will do exactly what they ask, no matter how unreasonable it is. Holidays are there to be taken, its your right to take them and a decent company should be more than happy for you to take them as it makes sure you are more productive. The same goes for weekends, evenings and nights. I work late quite a lot, but only when I'm project managing or powerpoint/word writing. Coding means being fresh which means getting in the sleep.

If you work through your holiday then you are basically just saying that your life is less important to you than what work wants you to do. Does this mean you are more likely to get a pay rise? No. Want to know why?

Well first off your working in the holiday won't be visibile, if you get the work done then you'll get a pat on the head but nothing more. If it goes wrong you'll still get it in the neck and be blamed back at base "We are still waiting on George to deliver" and you can bet that the rider of "because he is currently trekking in Peru and only has a pigeons for communication" won't be added. This means that you don't get visibile credit and you do get visibile issues.

Secondly you are covering up for someone elses problem. Unless you have buggered up, in which case it is your fault, then the odds are someone else has made an error of either planning or execution which means they need your help to dig them out of the hole. If this is the PM on a project then you can bet they will take the credit and won't like to be reminded of their error.

Thirdly you are valuing your time cheaply. Why give a big pay-rise to someone who works 365 days a year already? Its not like they can do more.

I was told something in pretty much my first job when I was put under-pressure to cancel a holiday. The PM raised the issue up to the director that I wasn't "co-operating" and he summoned me to his office and said

Take your holidays and make sure we can't contact you. If it screws while you are away up we might shout, but we'll remember that only you could fix it.

Its a message that has served me well. When I've been asked to work weekends I've asked for compensation, and got it. When I've been asked to cancel holidays I've told people to go hang, although on one occasion I did agree to do 3 days while on holiday, the company then paid for all two weeks and I did the work on the flight out there.

My point is this. Keeping in contact doesn't make you more important, it makes you more of a fool. It won't get you the rewards and it certainly won't get you the recognition.

When you take a break, plan for the break, make sure you have done everything that you should have done and everything that you are responsible for. Then get the hell out of there. Whenever a PM complained to me about people being on holiday being an issue I saw it as their problem and their fault for not planning and noted down the people who were the "issue" as being the people to reward.

Ditch the phone, ditch the email, ditch the contact. Kick back and relax. You'll feel better and others will feel better towards you now that they know they can't push you around so much.

Technorati Tags: SOA, Service Architecture

Getting the basics done

Now before the team starts ramping up you need to get it clear what the project is aiming for. You've done the vision and you know your stakeholders which is great. But you don't really know what the project is.

This is where your service architecture comes in. The purpose at this stage is normally just to do the Level 0 which will define the different groupings and areas for the project. For mine we've got 3 top level services which define the different areas of the project. They've got different purposes and focus which means the different groups will have different focuses and structure.

You want to get this done before your team starts forming into cliques as you want them to form into cliques that match the business structure of your project. Sketch out the services and then make sure you set up the teams along those lines. This makes sure that as you move forwards in the project you have the clarity required in the team to deliver in the way that you want.

Technorati Tags: SOA, Service Architecture