How to Avoid Problem-Solving

One of the best ways to avoid problem solving is to treat the problem as fluff. Often, our users begin the conversation with this assumption, and we play along. Other times, we make this choice because we're just too lazy (or negligent) to make an effort.

Here's how it plays out.

User: "I need a workflow solution."

IT Person: "Great, I'll find one and install it. We use [X] brand infrastructure components, I'll locate something compatible." Fill in Sun, IBM, Oracle or Microsoft for [X].

Note the things that are missing from the previous -- and all-too-typical -- conversation:

• Who has a problem?
• What problem do they have?
• Where, when and why does this problem occur?
• What happens when we solve this problem?
• What happens if we don't solve this problem?
• What are the constraints on potential solutions?

Since we don't know any of the above, we can buy and install anything -- anything at all -- and the odds of success are just random chance.

Better yet, we can draft a random set of purely technical requirements that are little more than quality factors, and avoid the tedious process of understanding the actors and the use cases. I find that many requirements documents are essentially the SEI Quality Measures Taxonomy ; they barely mention users, business value, or business context.

The consequence is the following:

User: "I need a workflow solution."

IT Person: "We already installed one and you didn't use it. So we installed a different one and you didn't use that either. What does it take to make you happy?"

Another way to avoid problem solving is to assure that all solutions involve programming. Some management-types deny they are mandating programming solutions. No matter how much they deny it, no other choice is ever on the table. Lacking any alternative problem-solving strategy, we're left with writing expensive and ineffective programs.

Note that this can be the result of ignorance or malice. An IT manager can be simply ignorant of IT's role in organizational structure and operations; they could be under the manifestly false impression that end-users can put together a logical process better than IT people. An IT manager can be malicious in spreading their preference for programming (and the resulting empire of programmers and maintainers) over solving problems. The root cause doesn't matter. What matters is that software is the solution of choice.

What's wrong with that? Since we aren't allowed to talk about organizational change, and how an ineffective process can create errors, we are put into patch mode. We're accreting functionality that turns a problem into a feature.

First, system X has a bug, leading to process defects. Management dictates that we write new programs Y1 and Y2 to work around that bug.

"No one would ever do that," you say. Which is far from true. There are a million reasons why people do this every day. System X is a legacy, it's an investment that we must preserve, it's too expensive to fix, we don't know what the bug really is, it's a packaged product, it's someone else's problem, it's slated for replacement anyway, ... The list is long and sickening.

Second, we note that the results of Y1 and Y2 aren't quite right, so we institute manual procedures to check Y1 and Y2. These are complex and error-prone procedures. Our defect rate is reduced in one area, but increased in others. Note that adding process to correct another process, means we're losing ground here.

So we decide to add a workflow solution to make sure that the manual repairs for Y1 and Y2 is executed flawlessly.