Many of my projects have started with the following brief from the sponsor: “find where the problems are, make it better, I have a team of 25, (50 or even 100 +) people but we still have all these issues!”
This is great news for a business analyst, I have got a chance to start with a truly blank sheet of paper!
A team of 25 -100 or more people is a lot of analysis. This number of people will be split into many smaller teams, apparently working completely differently from each other, often across multiple locations. So where do I start?
This definitely needs planning, I am always trying to keep it simple but projects of this size means I really have to use all the various business analysis tools.
The first stage is to identify the key stakeholders both inside and outside the area under analysis, the sponsor will give you a starting point for doing this. Something else that really helps is getting an organisation chart. From there I plan who I need to have my initial conversations with. Also in parallel I’ll try and get my hands on as much documentation and reporting as I can. (see document analysis)
From the key stakeholders I get a feel for the symptoms, then I’ll start talking to the next level of management down. Nothing too formal but I will use some the questioning and note taking techniques I talked about in this other post. By now I should have a really good idea of who most of people or teams are and I will be able then put together a detailed analysis plan. (see here for analysis plans)
From the raw data I have collected the real analysis starts.
- I start by looking at some obvious high level organisational and system trends. I’ll take all the different people and teams and try and fit them into 5 to10 categories, I am looking for duplication, teams performing similar tasks to each other. On a system front I do the same thing, are we using different applications for similar functions, (see my post on system and people taxonomy)
- The next thing I look at is the flow of work through teams and look where there may be business risks or quality issues or lots of manual steps. I start to analyse the points in the flows where there are lots of manuals steps and issues to get to the root causes. (see my post on looking for the root cause)
- Once I have got the issues together into a list I will look to add the following things (1) the quantifiable business benefit of fixing the issue (2) an educated guess on what it would take to fix the issue (time, money, other) From this I can give relative priority to each issue, so I can roughly order the list.
Now once I have got the first list together I will create two or three bold ideas that will cover the bulk of the items in the list (e.g a new system, a major team restructure, outsource, change the business focus etc) and then I will circle back with the sponsor and relevant key stakeholders and collect their views. In any big organisation there will many other initiatives or strategies that I will not be aware of and this will have a bearing on the ideas. It’s not a always a straightforward cost/benefit analysis.
At this point I now have everything I need to start developing actual proposals, I have a good idea where the problems lie, what it would take to fix them and how that fits with current strategy, other initiatives and the support from the sponsor and the key stakeholders. (look out for my future posts on proposals and business case)
In summary I think the key things are; understand the scope as quickly as you can then create a detailed plan and follow it. Big analysis projects need breaking down and need to be worked through methodically. Keep in mind though that the business analysis tools are not the output. It’s very easy to spend too much time creating pretty pictures and fancy looking plans but it’s the investigation, the ideas, and the solutions that count……