Think Holistically, speak clearly

Recently I've had a couple of occasions where I've needed to work on some direct communications to some execs. In all of these (both internal and external) there have been a whole list of issues but a couple of actually core ones. People often like to hide in the detail of these conversations, particularly in change programmes, and you lose the big picture as they sink into arguing line 83 of the spreadsheet.

Most of the time the issues come down to something very specific from which other issues stem and I've found that by ignoring the detail when engaging with people it helps hugely in getting the result you want. So if the lack of a specific person means that you aren't engaging with the business, aren't getting the documentation and aren't getting the sort of clarity you need then completely ignore the later points just be specific that "lack of Bill = FAIL". If they want to get specific then just say "engagement, documentation, clarity, I can go into the specifics but it all comes back to having Bill". Let the senior people ask for the detail, let yourself just provide the clarity.

If you don't then its certain that the person you are talking with won't, after all you are the expert in this area so how are they meant to understand it better than you?

With some SOA efforts I've seen this where people start saying things like "We need to reorganise the teams, set up a new procurement process, buy an ESB, get a rules engine, get finance engaged, agree on the KPIs" and the list goes on. The reality is that the first two bits are the most important and the rest will either drop out or be materially effected by the first two.

The problem is that engineers, and especially architects, like to "think holistically" which means "telling everyone all the problems" in other words there is a lack of filtering between the brain and the mouth.

So take that list of 20 "big issues" on your project and look at it. If you could fix just 2 (or at most 3) which would they be? Do they now seem quite a lot bigger than the rest of the list? So go and be clear "these mean FAIL".

Technorati Tags: SOA, Service Architecture