The problem with problem descriptions
“If I have an hour to solve a problem, I spend 55 minutes on the problem and 5 minutes on the solution,” Albert Einstein is reputed to have said. In itself a very clever statement, and yet there are enough project managers who like to get started immediately when problems become known. They roll up their sleeves, spit in their hands and rush to work. They perceive problems as bad that need to be solved immediately. I have had other experiences and this irritates one or the other project manager, especially when I don’t want to get started immediately and don’t want to hear about his solutions at first.
Problems or descriptions of problems
There are project managers who have a quick solution for every problem. But whether the solution is also a good solution is not always clear. Often solutions are carried out on the back of developers who have to work overtime or even additional shifts on weekends. Often such a solution does not deserve the name. Of course, the word “problem” is biased. A better name is probably “problem description”. Because that’s what it’s all about: To be able to measure a solution at all, it has to be measured against something. Only if a question is clear and known, it is possible to judge whether an answer to it is right or wrong. This can be confirmed by anyone who has ever copied in mathematics lessons, only to find out later that the teacher had given two versions of the exam with different tasks. In everyday life, there are numerous examples of solutions that work in themselves, but could certainly be better designed, such as ticket machines, automatic revolving doors or the remote control for the television.
The context of the problem
A good problem definition describes the task to be solved as generally as possible. However, at some point you will follow to the limits of what is reasonable and feasible. There is a small anecdote of a hand gun manufacturer who was to develop a new rifle for the British Army. After he had to reformulate his requirements several times, because they were allegedly too solution-specific, he finally wrote down the following requirement: “Defend the Queen and the United Kingdom”. This requirement was certainly correct, but in such a wording an essential part of the context is of course disregarded, because after all a rifle should be developed as a handgun. Such information must be taken into account. The context, i.e. the framework conditions, can be very different for many developments: For an electrical device, for example, these can be the permissible operating temperatures, for a car the statutory exhaust emission standards, for a bridge the permissible total weight or for a company’s accounting department a ten-year obligation to provide evidence.
Step by step to the solution
Only the smallest problems can be solved in one step. You can hang a picture on the wall relatively easily with a nail, a hammer and, if necessary, an adhesive strip. Such problems are usually not seen as a problem, but as a task. In the case of actual problems, however, a solution is found in two steps:
- The problem is analysed in order to find a solution.
- This solution approach provides the framework for the next problem.
Here is an example from the automotive industry: A manufacturer decides to develop an anti-theft device. One part of the solution is to detect movements in the interior. From this point on, the interior becomes the context and a solution for the problem “surveillance” can be sought. Possible solutions are then surveillance with camera, radar, ultrasound, infrared or a watchdog. If a garage door manufacturer wants to offer anti-theft protection for cars, he will not, however, understand the car interior as a context.
Problems and perspectives
Remember the example of the arms manufacturer who wanted to defend the Queen and the United Kingdom? Even if the rough solution seems to be given, it can’t be wrong to take a closer look at the basic problem. For many manufacturers, the sad truth is that most customers are not interested in the specific products or what they can do with them. Perhaps you are familiar with the striking statement that “DIY stores do not sell drills, but the possibility of making holes in a wall”. For a manufacturer this means a close examination of his customers and their needs. To paraphrase Henry Ford, “If I asked people what they wanted, they would have said faster horses.” In other words, problems must be viewed differently at different levels and from different perspectives. One of these levels is the customer level. It is one of the most important, because after all, customers should pay for your products.
On the way to the right solution!
If you agree with me that a good problem definition or problem description is very important, the next question is: How do you come to the solution? There are different, often complementary approaches. In my opinion, these are the most important ones, but without claiming to be complete:
- Stakeholder involvement: Even if users are often perceived as the most important stakeholders, they are not the only stakeholders. Often the user is not the same as the buyer – but the buyer must be convinced to pay for the product. Stakeholders for commissioning and operation, maintenance and disposal must not be forgotten. And the legal situation must also always be taken into account.
- The implementation of workshops: For me, workshops are the ideal means of describing problems or collecting requirements. Of course workshops also include related forms such as interviews or focus groups. The question often arises as to what happens after the workshop. Here I can recommend the book “Workshops in Requirements Engineering”¹ as a very practical reference book. It describes an easy and yet robust process to get from the workshop to resilient requirements.
- Existing documentation, reverse engineering and observations: For systems that are still in use, it is advisable to use the requirements described and the existing documentation as a starting point. If these do not or no longer exist, you should carry out reverse engineering. In addition, observations of the users when using the system are also a helpful tool. However, we must be careful here, as you will already be confronted with a solution. It is important to recognise the problem underlying the solution.
At this point I would like to point out a danger once again: Often people try to find the “best” solution. Unfortunately, the “highest quality” solution is often equated with the “best” solution. And this is rarely the case, because the highest quality solution is often also the most expensive one. Most customers expect very good value for money and have to stick to budgets. The right solution is therefore the one that best meets requirements, taking into account the general conditions. And this may well be a low quality solution. In a fast-food restaurant, you probably also don’t expect silver cutlery to be included in the scope of delivery. And if you had to pay extra for it, you might just pass by this fast food restaurant next time.
Conclusion
Describing a problem clearly is the first step towards finding the right solution for the problem in a given situation. Invest some time to clearly formulate a problem in cooperation with your stakeholders, because this will make it easier to develop a solution. And not only that: you will find that an “obvious” problem is suddenly not so obvious if you try to describe it clearly. This also helps you to find the way to the right solution – or may even prevent you from solving a problem that does not even exist.
Notes:
Dr. Michael Jastram can be found in his weekly German language blog System Engineering Trends and the English language Formal Mind blog. He shares his knowledge about requirements exchange and the open standard ReqIF in his online library ReqIF.academy.
[1] Workshops im Requirements Engineering
The Ishikawa diagram is a great way to visualise a problem and its causes.
Dr. Michael Jastram has published another article in the t2informatik Blog:
Exchanging requirements without loss
Dr. Michael Jastram
Dr. Michael Jastram is a systems engineer with a focus on requirements modeling. He is founder and project lead of the Eclipse Requirements Modeling Framework, an open source project for requirements modeling that implements the open ReqIF standard as a reference implementation. As an advocate for openness, he shares his knowledge through books, professional articles, lectures and as an organiser. Mr. Jastram has twenty years of professional experience, ten of them in the USA, where he earned a degree at M.I.T. and worked as a software engineer and architect in several start-ups. He is founder of the Düsseldorf-based Java User Group rheinjug e.V. and managing director of Formal Mind GmbH.