Project Management Software
Specialists in Project Infrastructure
In the first part of these two articles we looked at what information you need to collect. The second part looks at how you might analyse it and how to develop options from the analysis.
Analysis of Information
Having gathered and collated the information, we are now faced with making sense of it and drawing conclusions. There is no simple way that will suit all situations. Some general principles apply however.
What do we know?
The first step is to organize the information into a format based on our original six areas. Some information might not fit neatly, but put it into the most relevant box or even in two boxes. This gives us a context of information we have gathered relating to past, present and future for the organisation and also externally.
Challenge the problem
Taking the information we have gathered to date, does the business problem still stand? A couple of things may have happened.
Assuming the problem/opportunity is still valid, we can move to the next step.
Known and unknown
At this point we need to decide what we know, and what gaps still exist. Where there are gaps you need to ask:
Having reviewed the analysis, you can start to draw out requirements. What are the things in your analysis that will dictate the path forward? These fall into two groups.
You need to create a list of your requirements and classify them as one or the other. Typically these requirements are responses to problems or gaps in the existing world. For example if your analysis indicates that the current salary review process is too complex, one requirement may be to develop a simpler salary review process.
A numbering system is a good discipline for requirements. One useful approach is to number them 1, 1.1, 1.1.1, 1.1.2 etc. in a hierarchy. The benefit of numbering is that you can track changes to requirements over time.
Suppose 2.3.4 was a 'must have' requirement to provide training to all users. As the project progresses you find that not all people require training. You can change 2.3.4 to provide training to key users. As the project progresses, you have an audit trail of changes and you can also record details of why the change occurred.
There is usually more than one way to solve a problem or exploit an opportunity.
One favorite quote is
"For every problem there is a solution that is obvious, simple and wrong".
Exploring options is a critical part of coming up with the best solution. When you present a path forward to the organisation it is not helpful if you are asked"
"But have you considered this option?"
If you can answer yes, it gives management much more confidence that you are on the right path.
Sometimes, options are immediately clear. Other times there seems to be only one solution. It is best to have a group discussion as to what the options may be. This usually requires well briefed participants so you may need to provide a briefing on the analysis prior to brainstorming solutions.
Options within options
In cases where there is only one option, the variables may be within that option. For example there may be a business problem relating to remote location for minors at a new mine. As there is no town at the site, the only solution is to build accommodation. The options might be:
Number of options
There might be dozens of options but presenting too many options will only confuse the situation. A better solution is to come down to around three options for consideration. If there are options within those options, you can present them as separate decisions to either form part of the option selection process, or to be decided at a later date.
Suppose the business problem is to reduce IT overheads. Options are to outsource your IT, reduce development costs, or cut the number of software licenses. In the case of an option to outsource your IT operations, there may also be a decision to be made as to whether it is outsourced to a local company or an overseas company. Suppose the location has little impact on the outcome. You can raise the question of location as one to be decided later in the project if this option is selected.
Don't try to gather every little detail for every option. Look at the big questions and once a path is decided, you can flesh out the detail.
The last step is to check that you have actually addressed the problem/opportunity you started out to analyse. Often you can come up with a brilliant solution to the wrong problem. You need to ensure that you have solved the right problem before taking it to management. You may have discovered something useful along the way and it may well be worth pursuing but make sure the original problem or opportunity is addressed.
The two white papers take you on a journey from deciding what information you need to collect through to making recommendations from developed options. Analysis is not a process of probing in random directions to hopefully turn up something interesting. It is a planned exercise in understanding what you need to explore, how you are going to collate the information, how you can best collect the information, then doing something with it when you are finished.