When I was a kid, I worked on a small golf course my family owned (we no longer do). One of my tasks was to mow the ditch out in front of the parking lot. The parking lot was about 20 ft above the highway and therefore the ditch had a fairly step slope to it. Mowing it was a challenge. The only mower we had that was up to the task was one called Yazoo. They don’t make this model anymore, but it was a rear-steer three wheeled mower with wide wheelbase, a large mowing deck out front and a fairly low center of gravity. It was the only machine we had that could do the job.
However, doing the job was a bit of an art. The mower’s transmission was a bit old, and unless you kept your hand on the lever, forcing it into gear, it liked to slip into neutral. On top of that, the slope of the hill forced you to sit on the very edge of the uphill side of the seat or you risked sliding off. Finally, the real trick was managing the weight of the mower deck. At the steepest part, enough of the weight came off the high-side wheel. It would slip, lose traction, and cause the mower to turn uphill until you were stuck with no other option but to back down the hill and start over. The only way around this was to carefully transfer the weight off the mower-deck by lifting it slightly with the lever used to raise the deck for transport. Then, and only then, could you successfully mow the steepest part of the hill. Also, keep in mind that any wheel spinout left a nasty scar in very public view of all that drove by the golf course (and the ensuing “discussions” about my lack of mowing talents with my father).
To recap, the trick was – sit on the very edge of the seat leaning heavily to the hillside, with one hand hold the mower in gear, with the other hand hold the steering wheel, with the right foot, push carefully down on the “deck lift lever” and with the left foot balance yourself (100% OSHA approved! ).
So what does all this have to do with software?
The other day I was working through some issues with the system we’re building. The system is a replacement for a semi-manual data entry process.
In it, there’s a lot of “if use sets flag X and Y then set flag Z to true” and a lot of “the users are trained to know that they need to add B when they see A”, etc. All of these rules the users need to remember make getting the system to work sound a lot like describing mowing the ditch with the Yazoo.
The system feels like someone observed me mowing and build a new mower to make my life easier, but missed the point. They put a button the steering wheel that as long as I push it, will hold the mower in gear – “Now you can keep both hands on the wheel”, they made the seat twice as wide – “Now you can just slide over instead of leaning on the edge”, they made the “deck lift lever” foot operated instead of hand – “Now you’ve got a pedal to push”.
If only someone had asked “why?” and kept asking “why?” instead of just observing and asking “what do you do?”. If they had, the designers would have built a mower that stayed in gear, had much better weight over the powered wheels, and… maybe an iPod holder (every project needs a little gold plating!!)
Far too often analysis seems to end at asking “What do you do?” with out asking enough about “why?” is it done. I recommend following the “5 whys” to get the root cause. This is really important! Only with that kind of questioning do business systems really deliver the productivity gains and competitive advantages that justify their costs.
There is a danger in all of this though. Its easy to copy the existing process – broken as it may be at least its known to work. As you start to build the system that strives to solve the root cause, there is the real chance that you may deviate too far from their old process and miss the mark – creating clever software that doesn’t solve the real problem. Mistakes during the analysis at this level can be disastrous.
The key to avoiding it? Agile Methods.
Get the software with the new process in front of the users ASAP – short, focused iterations. Have the users use it to do their jobs (not just “play” with it) and get their feedback… and continue to ask why.