Large Programmes / Innovative Projects and Mobilisation

One of the challenges that I have faced on numerous occasions is project / programme mobilisation (by which I mean getting the piece of work started with people on board). First there is a need, something that is going to drive a stakeholder to spend money. In my experience something does not happen without a reasons, someone somehow needs to identify a need and then convince someone else to pay for it to be fixed. Once this has been done there will be a limited number of people who understand the nature of the initial problem and in a lot of cases have an idea as to how to fix it. This understanding often comes from the "don't come to me with problems, come to me with solutions!".

Once funding situation is in hand the next thing to do is shape up an understanding of the need or problem space is in more depth. There are a number of means of doing this, however a word of warning would be to keep this fairly simple as you are still in the problem domain at this stage and your audience is predominantly a business one. As you are doing this your next steps will be from project management for dummies. Namely get a Project Initiation Document as this will shape up what needs to be done and add some good discipline to it as well. As part of the process that PID generation requires you will need to pull together an organisational chart and a start for ten plan.

Once you have the org chart and a plan the next steps are going to be pulling the right people into the right spaces, without loosing the initial aim of the project, which is not easy. My personal experience has been mobilising from a handful of people to several hundred. Do not underestimate the length of time it can take to find hundreds of people work on a specific piece of work. Aside from the main challenge of actually finding the people it becomes increasingly difficult to get someone started and actually working. Unfortunately there are a lot of people out there who will more than happily do nothing and get paid for it! My personal experience is that recruiters are not technical or familiar with the business and as such they can never really understand your requirements (which might change anyway). As a result get the recruiter to whittle the numbers down and then spend 20 - 30 minutes tops doing a telephone interview. Trust me it will save you hours in the recruiting process. Outline the role as you see it and ask the question 'Is this something that you think would fit your skills / experience profile'. You will always get a yes by the way, but then ask 'how?'...

Personally I like to get every person onto the org chart so that they have an understanding of how they fit into the organisation, however resist the temptation to release a new org chart every day. Look for stability, in the EA space we are naturally adept at handling ambiguity and change as this is what we do, however many people in the delivery space are less well equipt to deal with significant rates of change. When people hit the ground make sure that they have things to do (and reading documentation is not one of them!)... Becoming involved in things as they are happening is the most efficient way of getting up to speed with what is going on. People learn by doing and interacting (and some by then researching what they have done and the conversations that they have had!)..

One last thing, get the message out, people like to understand what they are doing and why.. Forget the knowledge is power thing, it is old hat! Explain to people the purpose of what they are doing, keep the vision..

SOA Meets Business Processes

After my previous post around what SOA is, I thought that I would spend a little outlining my thinking on the major areas associated with SOA. I must admit that I am borrowing from a number of sources here SE Radio, The favourite, wikipedia, My links, (at this point I have decided the list is much to long to put anything other than..) etc.

In the current climate the corporate agenda is mostly filled with 'how do I cut costs?' opposed to how do I implement my new IT strategy which means that in order to even get close enough to get stakeholders excited, money needs to come into the equation (which is MV = PT by the way).

So you have targeted identified a collection of stakeholder(s) and sold them (Yes believe it or not we in the EA space are actually sales people, we just might not get the commission!) the concept that the road map needs to incorporate Services.. Probably the concept you have sold is that for the next project we can work in a quicker, leaner, more agile way, 'if' we consume from a number of services and these might as well be Business services as they are what the stakeholders will see. Great, from the aspect of a business user I can see a business process that consumes from a number of autonomous business services drop them all together and I get a working solution, easy! I also think that this idea needs to be sold communicated using business language opposed to technobabble. Gone are the days when I can talk about components, classes, methods, parametric polymorphism and the like (not that I ever did). What you need to do is articulate realisation of business challenges using Information Technology in an intuitive way.

All the time considering where in the quarterly life cycle you are, because this new initiative will be expected to return results by the next quarter!

Now the clock it ticking.. So what next.

SOA, A Perspective (namely mine!)

One of the great things about SOA (or Service Oriented Architecture) is that it means many things to many people. I am sure that if you ask a room full of architects what SOA is you will give one of two things (or potentially both) a room full of different answers and / or an argument about what it is. If you consult the many many resources on the Web (Amazon, Wikipedia, Google etc) you will find one hundred and one resources all focused on the same thing. After voyaging through a number of these I thought that I would articulate my thoughts..

First and for most I am of the opinion that SOA is more of a belief than a collection of technologies (although the vendors would say 'buy my product and you have a SOA!'). Having seen SOA implementations from the inside and also been on the outside witnessing the hardships I can say that this opinion has been re-enforced. So what do I mean by this, well, over the next few blogs I will outline my thinking in the SOA space. I have jotted down a few thoughts as to what I am going to articulate.

So what is SOA anyway (you could read the wiki!)

• Business Processes
  
• Component based development
  
• EAI
  

Challenges

• Making it last, how SOA becomes a strategic aim
  
• It's all about the money
  
• Skills, Skills and more skills
  

So much to blog.... So little time..

TOGAF 9

I am sure that anyone in the architecture space has seen the arrival of the new iteration of The Open Groups Architecture Framework, which landed recently. The much awaited new appearance of the widely used framework as been worked on for quite a period! The new iteration has had a considerable amount of contribution from Capgemini who have introduced an enhance Content Framework, there has been a degree of debate about what this means as a response to a blog from Ron Tolido. I was at the BCS Enterprise Architecture (EA) Speciality Group (SG) at which I am not sure you will be surprise TOGAF 9 was a major topic of conversation (outside of the usual conversation of what is Enterprise Architecture anyway debate). During one of the coffee breaks I had an opportunity to catch up with Wayne Horkan CTO (UK & Ireland) of Sun Microsystems a BCS peer of mine and also an old work colleague. Which sparked some interesting conversation on what needs to happen in the EA Framework space, especially as we were at the BCS talking about the subject!

Wayne has a great blog which points you at a number of interesting evaluation of TOGAF 9 and also talks about a point (which was the topic of our conversation) about the introduction of more 'architecture' into the TOGAF Framework (In which I also get a mention, thanks Wayne!).

My personal perspective which I am sure will cover more than one post is that architecture frameworks need to get simpler not more complex. When Judith Jones showed me the new TOGAF 9 book and said that it was twice as thick as the old one, I must admit I thought it would propagate to an even greater degree the 'ivory tower' complex that engulfs many EA practices. One of the things we talked about at length during the BCS EA SG was that EA practitioners need to become more intricately involved in the Business and what it wants to do. One of the main ways of doing this is to talk their language, which means investing time effort and energy to understand what their aims and objectives are. I for one am all about a common language for architects. However we need one that is simple enough that when we speak with our business colleagues we do not blind them with pseudo science because whenever we do this we loose needed credibility.

Agile vs waterfall

Could it be true? The long term battle of agile vs waterfall is finally over.... It would seem that SOA and web 2.0 have finally put the final nail in waterfall?

Personally I feel that this war has a long way to go. There are a number of outstanding questions that have to be answered before we can finally draw a line in the sand. Such as what about critical systems, what about the role of off-shore (or as my blackberry would rather say odd-shore), what about existing developments, what about contracts that require certain types of testing... That is to name but a few...

I think that either method is suitable in the right environment and the silver bullet? Well like so many others it is more marketting hype that a reality....

Many thanks

Matt

Sent using BlackBerry®