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