Search out the domain experts and listen.
Providing analysis is on occasion an extremely rewarding activity. When you see your advice making a substantial and beneficial difference to a business it is very thrilling, and better than any other form of reward. Why is this? Well it is difficult to not get involved with a business on an emotional level when that involvement is based on observation and collecting evidence. It is very hard not to become passionate about finding those apparently hidden, but what turn out to be self evident, truths.
It is nigh on impossible not to find the truth if you abandon opinions and views and empirically collect data and then use this as the base from which to build an assertion. Facts speaking for themselves as it were; let the data form new opinions.
Just like it is very easy to build great software by talking to the right people; finding a business case is trivial if the data gathering involves talking to the right people, the domain experts; the ones who live the problem on a day to day basis.
Find the problem owners.
Oh yes the problem word, well if there is no problem there is no solution, but reassuringly if there is no problem no one will have asked for those words of wisdom in the first place. As we are looking for domain experts we will come across those who own the problem, but how to recognise them? There may be those who see no problem, they will be the ones who are responsible for the problems and it will be they who are the custodians of the systems and processes that brought the problem about, these are the problem owners. It is best not to rely on them for evidence overmuch, it is in their interest (in the short term at least) not to look too deep or too far, this does not mean they are not valuable however.
The problem owners will not deliver the evidence but they will have a good grasp of the symptoms. The black art is to get beyond their defenses and persuaded them to share the symptoms. How many times have we all heard “It is not the software/process/system that is wrong, people just don’t use it properly.” The fact is that invariably the software/process/system is wrong and the symptom is the fact that the users are unable to use it properly. Convincing the problem owner that this is the case may be tricky however, and that is why collecting data is so crucial for without it you are just throwing another opinion into the table.
A walk in the park.
Where will we get the data we need to find a solution from? The day to day users of the system are who you need to spend some time with. The symptoms that the problem owner showed you will help you to make that time well spent. One very good way of spending time with them is to get them to give you a walk through of their day to day life and how they use the systems and software, and, what processes they use. Get them to expand on the symptoms, what makes their life difficult, what could make it easier.
Large organisations with thousands of employers will of course prevent you from looking in every corner but a series of workshops spread across all of the subject areas will allow you to look at the general landscape in detail.
The symptoms should have defined the subject areas and these will fall into areas such as; operations, finance, sales, marketing, production, technology and information, human resources, training, requisitioning, procurement, legal, quality control, compliance, support etc. Each of these areas may in turn break down into subsections, for instance finance may have; invoicing, credit control, purchasing, payroll etc. These groupings of subject areas may be repeated across divisions or regions. The head of each subject area should be able to nominate the people who can help by walking through how they work.
A plan of the walk will stop you getting lost but it will help. It could include; how do they collect information, how do they record information, how do they find information and how do they share information. The plan may look like a series of questions but it would not work at a questionnaire, just as a plan of a park will not give you the same information as walking the pathways within it. Having a guide, or better still a series of guides to show you all of the most interesting (good and bad) parts of the park will condense your knowledge of it and save years of wanderings, they are the experts in this arena after all; these guides are the domain experts, elicit their expert knowledge. The plan may contain ways to elicit; what the current system is doing well, what the current system doing badly, what does it need to start doing and what does in need to stop doing.
When running a workshop that takes the form of a walk-through a part of the plan will need to cover how to capture the information, your companions may take notes or better still make audio or video recordings. The workshop may be remote and the channel that you run it through (e.g. skype, webex, teamviewer) would capture the sessions but in the end the information gathered in these workshops needs to be analysed, condensed, sorted and stored, normally as a series of snapshots. A combination of these snapshots will provide (suprise, suprise) the bigger picture.
Making the pictures come to life
How do you convince a problem owner/s that, what may have been their creation now needs to be put out to pasture. You need the evidence to show that what may once have been a breakthrough and revolutionised their work processes has not been able to keep up with new demands and may even have evolved into a bit of a monster. That fantastic, well designed database has moved with the times in terms of data but in doing so contains so much and so many disparate and discrete pieces of information it gives itself a series of headaches. It may have served and enabled the business to achieve massive growth and allowed the business to expand into new territories but without having its own transport it can not get to or serve those in the new landscape. Find out from the problem owner what they would consider a successful outcome to this investigation (e.g. more efficiency, faster decision making, better customer relations etc.) the data that has been gathered should point out how these measures of success can be achieved.
The snapshots that were taken from the walk-throughs should form the arguments for the need for change (or not) and provide the solutions. Some of these snapshots may form a contra arguments against change. The bigger picture will probably show that a change in one area will allow another area to work well and remain unchanged. More often than not a simple solution will emerge, for example adding a way of making information available from one domain to another could make everyone lives much easier and their jobs becoming a walk in the park.
Words of wisdom.
If you have a business analyst or a consultant come to you with opinions and selling solutions remember that is what they are; someone with opinions who is selling solutions, it is probably a safe bet to ignore them, it will certainly be cheaper. If on the other hand they take the time to explore and out of this exploration discover solutions it would be wise to listen.