Dieser Artikel auf Deutsch

One recurring pattern in software development plays out during the initial phase of the project: The client describes their requirements. So far, so good – everything is clear, and this is also how things are supposed to go. However, it becomes apparent at this stage that the requirements are formulated in such a way that they stipulate a specific approach to arriving at a solution. This method is already familiar, normal, and well rehearsed for the client in this form, so it is more or less viewed as the only way to reach the goal. The thinking behind this is that if only the solution is formulated in sufficient detail, the schedule and costs can be determined directly, and nothing else can go wrong during realization.

Is that really the case?

Where’s the problem?

If only the path used to reach a solution is formulated, many aspects describing the context that has led to this solution remain hidden. The client is intimately familiar with just that context, but the contractor may not be. But why should the contractor be interested? After all, the contractor is only responsible for implementation, and it just takes much too long to explain the context on top of everything else. The contractor is just supposed to do exactly what they are told via the circuitous route of the client’s specifications.

There are examples in which this approach works well, even yielding advantages. But not always…

The pitfalls

The client’s overwhelming desire to receive software, burned onto a CD, on time and within budget after providing the specifications is understandable. The likelihood of the client’s receiving the optimum solution with this approach is lower, however:

• Lack of context leads to more misunderstandings in interpreting the requirements.
• User interactions that are prefabricated without including the actual end user reduce acceptance of the application.
• Unrealized synergies create avoidable ballast for the application.
• Lack of knowledge regarding the current architecture and implementation lead to inappropriate approaches to finding a solution.

The other process

Every approach to finding a solution describes how to solve a problem. All too often, the problem itself and the context in which it is situated are not stated explicitly, or are even unclear to the client, so that it is not even possible to list one reasonable, practical, and sustainable approach to take to arrive at a solution.

Ideally, the right solution is found almost automatically if the parties are aware of the following factors and then define them accordingly:

• In what situation do I encounter
• which problem, and
• what implications does this have for me if it is not solved,
• and what need is paid off if it is solved after all?

This method is called “SPIN” (situation, problem, implications, need payoff). It is often used in sales, but here as well, it leads almost automatically to the actual requirement – although not yet to the solution! This also lays the foundation for evaluating solutions, meaning carrying out a cost-benefit analysis.

“Tell me how your project starts and I’ll tell you how it ends.”

Where does a project start? Right, exactly: when the requirements are described. To do that, though, we need a good basis – the current situation and the problems arising from it. Here as well, the parties all too often make a serious error during stakeholder analysis in the project. In many cases, stakeholders are viewed not as important sources of information, but as a risk to the project, something that just has to be managed properly. One crucial stakeholder in any software development project is the end users – those who actually use the solution and are supposed to benefit from it.

When looking for the true end user, there are typically people relevant to the project who throw up roadblocks with the following statements:

• “Trust me, I’ve done this myself for years.”
• “Our processes have always worked this way.”
• “Are you crazy? I’m not about to ask the departments what they want. Then we’ll just end up with everyone weighing in with whatever they want!”

The crucial errors at the start of the project are made in analyzing requirements. This represents a missed opportunity to map out a solution that users will truly accept, rather than one they have to be ordered to use.

It is possible to determine the right requirements and guarantee implementation with limited resources. The possibilities during the initial phase of the project range from shadowing, eye tracking, and surveys to ongoing acceptance tests while the project is in progress. To accomplish this, we include the User Experience (UX) team in the projects right from the start, and they also follow the project through to the end. A UX architect’s role is just as important as that of a technical architect.

So what solution would you like to have?

If the context is clear and the requirements have been formulated neutrally with regard to the solution, various solution scenarios can be developed. Here as well, not a single line of code is written yet at this point. To visualize the potential solution, digital paper prototypes known as “wireframes” are used. These simulate not only the potential outward appearance, but also the workflow for the user interactions. This quickly conveys a sense of the application (the user experience), and initial user feedback can enable changes without major additional time, effort, and expense. Wireframes do, however, also have to avoid giving the impression that the solution has already been implemented and is complete.

Similarly, at least two solution scenarios should be formulated, and more is even better. If these scenarios even build on each other, it is also already possible to craft and coordinate a roadmap at this point. The solution scenarios can then be evaluated not only on a yes-or-no basis, but also based on solution A, B, or C. An initial estimate of time, effort, and expense additionally makes it possible to evaluate the requirements by way of a cost-benefit analysis and to tailor the optimum solution perfectly to fit the need.

Obstacles

Why isn’t this always done this way?

The client is often pressed for time, already having invested enough time to write down their solution. The value added by a requirements analysis based on user requirements and using UX methods might not be clear at first. Contractors should not underestimate the lengthy process it can take to convince the client that the investment this represents at the outset is justified and will pay off many times over.

An open, honest consideration of the results of projects, especially looking at acceptance by the users – the people for whom the solution has ultimately been prepared in the first place – leads to the realization that the damage done by processes that do not receive optimum support, and thus are not practiced efficiently, is much greater than the initial investment at the start of the project.

Communication based on partnership and expertise in subject-specific matters and requirements analysis make it possible to examine the other party’s ideas for reaching a solution on a targeted, capable basis and learn more about the context. If, in the end, the client’s original solution should be chosen from the large number of possible solutions, this is also an opportunity to have compared solutions and be sure that it is truly the best one. Experience has shown, however, that a different solution is very often chosen as being better suited to the task.

Every client who has taken this path with us in the past now values the advantages it brings them, and none of them wish to proceed in any other way anymore.

Summary

The path to the right solution starts with a clear description of the problem. One key question helps in this regard: What problem does this solution solve?

The client can reap a wealth of opportunities by having the ability to choose among many solutions:

• Cost-benefit analysis
• Use of synergies
• Definition of a roadmap for a function
• Solutions with targeted user acceptance
• Development of additional innovative improvements

This post is the start of a series of examples from day-to-day project management practice at akquinet tech@spree.

 

Tassilo Kubitz

akquinet tech@spree