As an engineer in training I attended many short courses during the first few years in my new job. One of the most valuable courses was a two day problem solving workshop. It remains one of the few courses that to this day that I remember clearly; and that has over many years helped me analyse complex problems and find the optimum solution.
Our technical training as engineers and the nature of the work results in us becoming automatic problem solvers. It is difficult for engineers to not attempt to tackle any complex problem. We tend to see a nail and then look for a handy hammer close by to hit it with.
Perhaps a better solution in some situations is to simply remove the nail?
Our technical training enables us to see our own “obvious” solution clearly, but in many situations, particularly in business this is not the best solution.
Solving business problems
In the world of business, problems are amplified by the realities of an unpredictable environment and the complexities of business processes that are a blend of technology based automation and fallible human decisions.
Most engineers find themselves eventually in a business environment, so with their skills they feel they have a powerful “hammer” at hand and they then spend their time looking for nails. When that hammer includes skills to write software, the temptation is often to dive in and write a solution in code.
In business there is of course a valid place for solutions based on software applications. The underlying assumption is that by automating business processes using software, many of the limitations of human behaviour can be designed out of the processes and the system as a whole can be made more predictable and manageable.
However, mangers can conveniently “abdicate” some of their responsibilities to software based systems. After all is it not easier to tweak awkward business rules in a system rather than change employee behaviours in other ways? The end result of enforcing software on unwilling users is the proliferation of workarounds in the form of black books and spreadsheets hidden away from management.
Don’t rush to a software solution
In the world of software solution development, tried and tested problem solving principles should apply as in solving any other problem.
Yet we find software teams making the one fatal mistake of rushing in to develop applications before defining and framing the original problem properly.
A process to define the problem upfront before writing software will go a long way to ensure success of the solution.
Problem solving techniques
Accepted formal techniques to solve problems include
- root cause analysis,
- restating the problem,
- trial and error,
- problem decomposition and so on.
A number of robust methodologies have evolved to approach complex problems in a systematic and disciplined way.
Some of these are proprietary, others are common sense; and there are many resources on the web that will assist you in this regard. A problem solving workshop with a good facilitator can be a very productive forum in which to get to the best solution.
Don’t rush prematurely into a “requirements analysis”
When a team sits down to solve a business problem through a software application, they often jump the gun and start with a “requirements analysis”. The output of a requirements analysis is some specification that is sufficient to estimate the development effort required (and costs), as well as some high level system definition.
The ease with which a requirements analysis process is initiated in a company can become so entrenched that everyone can easily overlook the underlying assumption: “that building another software application can solve this problem for us”. If you have good business analysts and a responsive IT department, it can be tempting to do a requirements analysis without first analysing the problem. Once you set up a requirements analysis workshop you are already communicating to the team that software is the only solution; and you could be putting the cart before the horse.
In many cases more software is simply not helpful. The system fails. With much hand wringing and determination to adopt a more “agile” approach to developing requirements; people then focus on the wrong problem. They look to enhancing the software development process itself while still ignoring the underlying business problem. Again, the underlying assumption is that software can solve anything. I have seen this behaviour many times in recent years and this has certainly cost the affected business heavily.
Ahead of initiating any software requirements analysis process, you should be asking whether you fully understand the business problem you are trying to solve.
Start with a problem solving workshop that looks at alternative ways to solve the problem other than rushing to building an application.
An application that does not solve the underlying problem merely provides an automated solution that will simply amplify the symptoms.
Precede every solution with a proper understanding of the problem
A recommended approach is to challenge every and all assumptions made about the problem before you start a formal requirements analysis process. This is of course common sense, yet I have seen so many projects skip this step.
In many cases by simply stating the problem properly you will significantly improve the prospects of a successful solution. Stating the correct problem implies that you have challenged all underlying assumptions, tried to reframe the problem, evaluated alternative solutions (other than a system development) and challenged any assumptions or artificial constraints.
Only once you have done this, you will know that you are on the right path should you decide to develop an application, or add a new feature / report to your existing application.
The techniques of problem solving can be easily learned so why not invest some time in a problem solving course?
Often a software application is the right solution…
Having understood the problem well, assessed alternative solutions and challenged all assumptions; if you still believe that you need to develop a software application by all means go ahead.
In all probability your solution will then work well and be successful because it actually solves the right problem.