Fog Creek Software
Discussion Board

Another Iceberg. Straight Ahead!

As all of you in this forum knows, implementing a new system is not only about giving users a new and shiny
web- , windows, or platform-of-choise application.

Before we can successfully implement a new technical solution, the underlying workflow within the organization will also have to change.

I believe this to be a two-fold problem,

1) Customers that want a software solution to simplify a
process will most of the time try to model the application
to implement the non-computer way of doing things. I mean
if we could give them binders out of the computer screen
most people would be overjoyed.

2) When asking business-people the simple and straight forward question "How do you do this task?,
What gets you from A to B?" most people tend not to tell me the steps to acomplish the actual task (in a workflow perspective). They rather tell mestuff like "Ah, yes. You know we have this screen and I put a number in this editbox and press this button and this checkbox means..."
-- The result will be they are telling me the TECHNICAL steps of doing things.

If some programmer comes up with a more rational way of doing whatever the customer is doing, say we can do stuff in 3 steps instead of the current 15, you can pretty much rest assured that the implementation of the new system will contain 18 steps to complete a task that needed 3,
and had 15.

This probably comes from the fact that the customers user-group that is working in conjuction with the programmers uses 20% of the current functionality, but all uses a different 20%, thus resulting in all the steps ending up as "must-have" stuff.

As long as we implement systems as the above 3,15,18 example we can be sure of missing the target. Do any of you have a way of communicating the need for the customer to change not only the system implementation, but also the way they work?

How do your companies handle this problem?

Please share your thoughts.

Patrik Öhman
Friday, February 22, 2002

Yawn . . .

Friday, February 22, 2002

Wow, A., what a helpful comment...

Patrik, I have had good experiences with trying to get the customer think about the basics of the task. Not how they go about doing it at the moment, but ask questions like "if you only had a pen and paper (or whatever would be absolute neccessary for the task in a non-technical world), how would you go about it?" Then ask them, what tools would make that task easier from that perspective. What I mean is: Do not ask them, how they would want to change the current procedure (because then everything is explained in terms of what is visible to the user from the current procedure, normally buttons, checkboxes and the like), but ask them to mentally built a complete new procedure together with you.

If it is possible, sit down and manually solve some of the tasks yourself. I normally get an itch in the fingers to sit down and code something to make the task easier to handle.

I am not saying: throw away everything they already have, I just say, for modeling new task oriented procedures, concentrate on the task first, then see, what you can reuse from the system that is already there.

Have fun,

Jutta Jordans
Friday, February 22, 2002

Another thing I've found helpful to ask is "what are you trying to accomplish?" Often it's not "Fill in form 3872B" but "Keep track of amortization rate changes" that's important. If you can get the customer to focus on the goal rather than the implementation, sometimes you can free up their minds to explore in search of a better (or at least more easily computerized) process.

Of course, sometimes this can be carried to extremes. I worked with one executive for a while who started his day with a three-inch thick stack of printouts that he now wanted to recreate as they moved from minicomputers to networked PCs. Turns out that when all was said and done, what he really wanted was to turn on his PC in the morning and have a big colored blob in the middle of the screen. If the blob was green, he could go play golf. If it was red, he had to go out on the shop floor and kick some butt.

Mike Gunderloy
Friday, February 22, 2002

It boils down to focusing not so much on WHAT a person does, or HOW they do it, but WHY. I suppose it's the difference between focusing on tasks and results, and allowing for multiple possiblities to get the desired results.

One of my favorite analogies about this topic is the "cat-in-the-cage" story. You can embellish this as much as you want, but it boils down to this:

The head of a group of monks in Tibet found a stray cat and made it his pet. During morning and evening prayers, said playful cat had a habit of disturbing the other monks. So the order had a fancy gilded cage made for the cat, so that he might not prove such a disturbance during prayers. After some years, the head monk passed away. The twice daily ritual of putting the cat in the cage continued as always. After more years, the cat also passed away. The order then went to the local village to find another cat that could be placed in the cage, marking the beginning of prayers.

A good book to read on this topic would be Jakob Nielsen's "Usability Engineering."

Robert K. Brown
Friday, February 22, 2002

Some customers are smart, others are dumb, just like software developers.

The smart ones will want smart solutions, the dumb ones will (maybe) prefer dumb ones, or if you are lucky smarter ones.

Just keep both happy.

That way, with the dumb ones you get to have a rest.

Saturday, February 23, 2002

*  Recent Topics

*  Fog Creek Home