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.
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.
- The business problem is not a problem. We discovered that what everyone thought was a problem is not a problem at all. The initial problem was the number of clients who were on 90 day payment terms. After investigation we find that compared with others in this industry, we have significantly lower numbers on 90 day terms.
- The business problem is not the real problem. We started out to address a business problem that our trucking fleet was not big enough. We find that there are plenty of trucks but not enough drivers. We now need to go back to the Sponsor and Project Steering Committee and advise them that the problem needs to be redefined.
- The problem is worse than we thought. The business problem, or in this case an opportunity, was to understand the viability of purchasing a competitor. We find the competitor is on the verge of bankruptcy. Before any further work is done, the findings need to go back to the Sponsor and Project Steering Committee.
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:
- Can I develop a solution without knowing this information? If not you need to fill in the gaps.
- What impact will this lack of knowledge have on a solution? It will probably depend on the solution, but you may have to dig deeper later in the cycle if you decide to go down a particular path. Say you are looking at time sheeting IT systems for the organisation, and do not know if they are multi-language, or even if you need the ability to handle timesheets in several languages. It will only become an issue if your preferred option is for a program that cannot handle multiple languages.
- Reviewing what you don’t know may result in further information gathering.
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:
- What type of accommodation
- How you build the accommodation.
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.
Copyright Project Perfect