The Business Sensei

Effective problem solving

This is an excerpt from my new book, Organizational Psychology for Managers.

One of the things that world class successful organizations, the organizations that keep innovating and growing and reinventing themselves, have in common is a remarkably effective ability to solve problems. What is interesting, however, is that they don’t necessarily get it right the first the time; often, perhaps, but not always. What they are extremely good at is knowing how to solve problems in ways that constantly reinforce their cultural beliefs of optimism and success.

To begin with, problem solving is really a question of goal setting. In this case, it is a goal where the outcome is to make the problem go away. Unfortunately, that’s not really enough information to create a specific goal, although plenty of businesses try. There are, however, many ways to make a problem go away at least temporarily. Hence, if that’s all you focus on, you end up with a problem that feels like a boomerang in a Saturday morning cartoon: it keeps coming back and whacking you upside the head. Thus, we need to do a bit more work in order to formulate effective goals around solving our problem.

Before we can solve a problem there is one thing we absolutely have to know. What might that be? Whether I ask this of college students or managers, I always get the same response: puzzled looks and then people start yelling out answers such as, “the solution,” or “the cost of the problem,” or “what resources we need,” or a host of other answers. Eventually somebody says, “Don’t we have to know what the problem is?”

Exactly. Before you can find a solution, you have to identify the problem. As obvious as this may sound, if you don’t know the actual problem, then your solution isn’t likely to fix it. There are a great many solutions out there looking for problems.

A problem can be broken down into three major pieces: there is the actual problem, whatever that may be. We don’t know what the problem is because we can’t actually see it; what we can see are the effects of the problem. That may mean deadlines being missed or angry customers calling to complain or a lack of motivation or difficulty hiring or retaining talent, or countless other things. Those are the symptoms of the problem. Finally, there are the things that occur around the problem, things which attract our attention but which are basically irrelevant to the situation. They look important but they’re not. That’s known as chrome: the shiny stuff that draws our eye and distracts us from what really matters.

Balzac preaches real engagement with one’s own company and a mindful state of operation, especially by executives – who must remember that culture “just happens” unless and until they learn to recognize that their behaviors play a huge part in creating and cementing it. It covers the full spectrum of corporate life, from challenging bad decisions to hiring, training, motivating teams – and the secrets of keeping people engaged and learning – and/or avoiding actions which do the opposite. I highly recommend this book for anyone who wants to participate in creating and steering company culture.”

 

Sid Probstein

Chief Technology Officer

Attivio – Active Intelligence

For the Deadline Was a Boojum, You See

“There was one who was famed for the number of things
He forgot when he entered the ship:
His umbrella, his watch, all his jewels and rings,
And the clothes he had bought for the trip.”

— Lewis Carroll, Hunting of the Snark

Lewis Carroll billed the Hunting of the Snark as an “agony in eight fits.” While it’s not entirely clear what Carroll meant by this, the sentiment well describes the process of scheduling and hitting deadlines in many organizations. Certainly it’s clear that the Bellman didn’t have a schedule, or he wouldn’t have left his crew’s belongings on the beach.

Some years ago, I worked for a software company where the CEO decided that missing a deadline was a personal failing on his part. No matter what, the software would ship on the day he had announced. Even if the product had bugs, even if it did not work, it shipped on the day the CEO had promised. “Not a single day of delay,” said he.

He preferred to ship a product that did not work and then release a bug-fix rather than delay the software even a day. He never understood why customers grew increasingly irate and would call the company to complain. He was keeping his promise to ship by a certain date, and certainly adherence to the schedule was important.

There are several problems with this belief. The most obvious, of course, is the stubborn belief that the software must go out on a specific date no matter what. Shipping any product that doesn’t work is going to upset your clients. Doing it repeatedly just makes the company look incompetent or indifferent to its customers. It is not meeting their needs to give them something that they cannot use.

Stepping back, though, from that minor problem, we have to ask what the point of the schedule was. There seemed to be little rhyme or reason to why the CEO picked the dates that he did. When pushed, his reaction was that scheduling was important, otherwise things didn’t get done. True, but not necessarily relevant. Fundamentally, a schedule is a tool; like all tools, it must be used properly or there is risk of serious injury. In this case, financial injury.

A schedule is not an arbitrary set of dates put down on paper to make sure that everyone works hard and doesn’t goof off. The goal of a schedule is also not to precisely calculate how long each task will take and account for every minute. It is not a holy writ to be held to beyond the bounds of common sense or product quality, nor is it put in place in order to have something to ignore. Sadly, I can’t count the number of times I’ve seen schedules designed with exactly those somewhat dubious objectives in mind. However, a well-designed schedule needs to satisfy some fairly significant constraints:

1. A schedule helps make sure you don’t forget anything. It is both a to-do list and calendar. It helps people know what to work on when so that they don’t have to waste time constantly figuring that out.
2. A schedule is a tool for marshalling resources. Building a product requires different resources, be those resources time, people, or equipment. The schedule helps make sure that the right resources are available at the right times so that the project can move steadily forward.
3. A schedule is a tool for managing dependencies. In any large project, different pieces will depend on other pieces or on obtaining external resources. Some dependencies are obvious from the beginning, others do not emerge until the project is under way. The schedule helps organize tasks and manage dependencies so that they don’t derail the project.
4. The schedule helps you determine what you can do in the time available with the resources you have; alternately, it helps you understand how long it will take to accomplish your goals with the resources you have available.
5. The schedule enables you to define reasonable checkpoints, or milestones, that will let you know if you are moving successfully toward your planned target date or if problems are emerging. Missing a milestone is feedback that something is not working as expected!
6. A schedule needs to have enough slush in it to handle unexpected problems. You can’t always determine all possible dependencies at the start; some parts of the project may turn out to be significantly more difficult than expected; you may discover that a piece that appeared to make perfect sense just won’t work and needs to be redone. When I speak about this to technology companies, someone always claims that they’ve done a few simple calculations and developed the perfect project schedule. Based on the reactions from the rest of that person’s department, I have my doubts.
7. The schedule also needs enough slush to handle external delays. If your schedule is so tight that a severe winter storm closing the roads or having someone come down with the flu or having a vendor be late on a delivery will cause real problems, then you need to rethink the schedule. As that great sage Murphy so wisely said, “If something can go wrong, it will go wrong.” Plan for it.

You’ll also notice that if you design a schedule this way, you’ll tend to be running ahead of schedule, not behind. Falling behind schedule is demoralizing, particularly when the schedule feels arbitrary. Running ahead of schedule energizes the team to work harder. A team that falls behind tends to stay behind, while a team that runs ahead tends to get further ahead. In other words, nothing succeeds like success.

When you view a schedule in this way, it has the potential to be a powerful, flexible tool for getting things done as opposed to causing quality, effort, and enthusiasm to softly and silently vanish away. Isn’t that the whole point?