Workflow. Everyone in the tech world has heard the word. If you’re an analyst your trained and told to “figure out the client’s workflow.” You talking, sketch arrows on white boards, ask the question “then what?” like 50 times, and eventually produce a series of massive visios. The client lavishes you with praise, saying that you’ve managed to really capture their businesses. Everyone’s happy, and the team goes off an builds the application.
Then testing starts. It’s innocent at first, with little discrepancies where the users find a few little exceptions they forgot to mention during the analysis process. Soon though it’s a full blown disaster, where everyone is growing tired of the phrase, “Well that’s how it works most of the time, but sometimes….” Now there’s a growing realization that the software based on the vaunted workflows you discovered miss out on about 30%-40% of what users actually do on a regular basis.
It’s a familiar story to anyone involved with a software project. There’s this disconnect between the fantasy workflow that people thinks makes up their jobs, and the day to day activities that actually do. It’s tempting to blame the users for not understanding their own jobs, but I think the problem is more fundamental, and it’s with the whole concept of workflow as applied to the modern job.
To understand why, let’s take a look at what work is. Basically, all work can really broken down into two categories. There’s doing things and then there’s solving problems. Doing things is the easy concrete stuff. Write up minutes of the meeting for your boss, take that check from your grandmother to the bank, go running for five miles, all these fit in the doing things category. Getting them done is just a matter of setting aside time, and making sure you have the right tools for the task at hand. When you start the task, you know about how long it will take and can basically envision, in detail, what you will actually be doing.
Solving problems, on the other hand is a very different matter. Solving problems is a matter of breaking complex goals down into a list of things that fit in the “doing things” category. When you start to solve a problem, you really don’t have a good idea of how long it will take. You don’t know who you’ll have to talk to, what you’ll have to read, what tools you’ll need, anything. You’re starting at a big black ? trying to figure out what comes next. It involves a lot of staring out the window, mulling over problems, talking to people, rewriting or redrawing things, in general tasks that often feel somewhat frustrating or unproductive.
So what happens when you ask someone who’s job is to solve problems to “describe their workflow” or more common “so what do you do during the day”? Their mind immediately goes to the concrete, easily visualized and remembered activities of their job, all the doing things stuff. They don’t describe the problem solving stuff because they may not remember it, or they may not have the language to describe what is often an intuitive, somewhat haphazard process. Even if they do talk about problem solving, it usually doesn’t make it to the analysts workflow diagrams because workflow is about doing things. There’s no space on the diagram for problem solving.
What really makes this an issue, is that more and more modern work is a matter of problem solving and less and less about doing things. So when we ask clients to describe their workflow, what we’re doing is getting them to describe the boring, pointless, and most often unimportant, parts of their job.
What’s a better strategy? Don’t ask people what they do, ask them what problems they solve. A question as direct as “what problems do you solve on a daily basis,” will reveal alot more about what their real work day does than asking them for a blow by blow of the day. You’ll hear in great detail about the exceptions to the rule, the tricky important issues, and you’ll have a much richer understanding of how to make software that gives them a leg up on those problems.