Document Analysis

A great way to get a piece of business analysis off to a flying start is look at what has already been recorded on the area in scope. The following is a list of the typical documents I look for when I start :

Project documentation: The analysis I am looking at may form part of larger programme of work, reading through this documentation will put my own project in context, there will be information on the programmes objectives, stakeholders, timeframes, etc.

Previous business analysis: Quite a few times I have assigned projects that have been previously mothballed, there no point reinventing the wheel maybe you just need to validate it instead !! I will look for gaps, I’ll start to form my own questions based on the documentation, I’ll get a good idea who the stakeholders are etc and then I’ll use this to build my own analysis plan.

Business procedures: This will give me an idea of the current state, the types of things the area does, how they do it, including the steps they take, the systems or processes they use, any quality checks and so on..

Organisation charts: These are normally easy to get your hands on. I find it really helpful to see how many teams there are, the number of people in each, the team structures. If I am planning interviews I can work out which people I need to talk to get a good representation of the  area, and even get some names.

System Diagrams: Depending on the type of project I will ask the IT teams for any system documents. Architecture diagrams and high level data flows are handy for getting to grips with the number of systems an area may use, and for driving out stakeholders that exist outside of the area under analysis.

Query systems: Strictly speaking may this is not a document to analyse but if the area I am looking at uses any kind of query, logging or management tool then looking at the type and volumes of queries can give me a good idea where problems may lie, and areas I may want to look into a bit more.

Management Reporting:  Anything that is measured is of interest, it may be the number items that the team handle or process, or it may the number things they have failed to fix, or the timeliness or processing. All information is useful. It may also be interesting to think of the things they are not measuring. Why is that? Maybe its not possible.

Error logs: Normally an area will maintain some kind of error log. Problems that they have spotted themselves or problems raised against them by someone else. If it was a business issue there is normally a record of it,  reviewing this gives me an idea of the problems that can occur and what their immediate causes are, however I have found this difficult to get hold of sometimes as it can be very sensitive to a company.

Internal Audit: In bigger companies there is normally some kind of area that looks at internal processes. They are normally looking for risks to the company and less about opportunities to improve or be more efficient. These risks may be financial or reputation, or in contradiction to regulations or laws. Any reviews or recommendations they have made will be a great input to the analysis process.

Wish lists: And finally to the area themselves, they know what does not work !!! The management of an area normally have a list of things they want to fix, or things they want to improve, however care should be taken as items on the wish list may solve immediate symptoms but not actually address the root cause. Having said that I still find it very helpful to get this information.

 

 

 

 

Posted in Investigating, Tools & Techniques Tagged with: , ,