Mike-O-Matic

I was attending a business analysis training session the other day, learning to flowchart my way to self-actualization and inner peace, when the trainer brought up that little gem. I am not usually one to fall prey to generic business analogies, but this one jumped out at me. He explained it like this:

When flying into Dallas-Fort Worth, the cities seem to shoot up out of nowhere from a giant prairie. Looking closely at the ground you will see many of the roads leading into the cities curve and bend, following no discernable logic at all. Why are they like this? Because back when Dallas was primarily a ranching town those were the paths the cattle would follow as they were driven into town. They would walk the long way around hills, cross rivers only at the low points, and follow a path of least resistance the whole way there. Over time people started following the same paths, and eventually they paved them and made them permanent. So now the town has a bunch of inefficient roads just because that was the way they had always been.

When applied to the world of information technology, this analogy can be taken to mean that you shouldn’t write new applications that codify bad practices already in place in a business or organization. New programs are a chance to get things right and should be used as an opportunity to ask the challenging questions about why things are the way they are and what can be done better.

Like many people in this industry, I have been in many situations where this advice has not been followed.

Once, while working for a contractor for a large government agency, I had the opportunity to head up a team creating an inventory management system to track the movement of IT assets throughout the agency’s campus. One of the requirements for my application was that it needed to be able to read the output of the government’s handheld units, used by the move technicians to track their activities as they moved the equipment around the offices. These handhelds had some serious drawbacks. For one, it didn’t accurately connect the equipment to a physical location. Instead, it tied it to a configuration number, which was theoretically tied to a location. Except when it wasn’t. A configuration number could be on an office, computer monitor, shelf, person, or an entire storeroom. Or the warehouse. Additionally, the configuration barcodes often ripped off or became unreadable and needed to be abandoned, leading to all of the equipment tied to them becoming stray until it was rescanned to another barcode. Oftentimes equipment was missed.

Another substantial issue was that the new system was entirely unofficial and received no formal assistance from the government office we worked with. They had built their own inventory management system at a significant cost (hence the handheld units) and were not inclined to start utilizing something made by our company, despite the fact that our database existed solely to make up for shortcomings of the incumbant system.

Consequently, we needed to spend a lot of time glossing over the gaps in the data we were able to receive from the handheld units, and needed to do a lot of manual data entry apart from what we were able to do electronically. The technicians disliked the extra work but got used to it. The development team also spent a lot of time digitally recreating forms that we had been using in our older processes and creating an ODBC datasource to SQL Server views which mimicked an old Access database used to generate certain reports that we kept for our records. This work was probably redundant, but was instrumental in securing the buy-in of people on both the government and contractor side who were wary of change.

Over time we were able to win converts on the government side, who liked the accurate reports we could generate and the relative ease with which they could get data out of our system. Eventually they started using our database’s internal ID numbers when communicating with us about pending work orders and completed moves and deployments. While the government’s database was still the official system, ours was instrumental in moving the government’s office equipment when they opened a new campus a few years ago. We were able to quickly add a new module just to accomodate the move, something that was just impossible on the official database.

Our story had a happy ending, but we were lucky. I fear that most Cowpath projects won’t be.

I am not so sure that most organizations understand the need for strong management when trying to implement IT projects. They obviously see the problem and understand vaguely that an IT system could help resolve it, but don’t want to do the often unpopular work needed to make the new system a success.

IT is not a solution in itself, but a tool to reinforce a solution.

Management’s job needs to be to redefine the process ahead of time so that a good information system can codify the best practices. This is not a job that can be done by technicians. Right or wrong, most workers who use such systems are wary of being told how to do their jobs, particularly when the person doing the telling is either a programmer or a machine that won’t accept input in the old way.

Prior to undertaking such a project, management needs to bring together the affected workers and try to figure out the real business problems that underpin the bad process. Consult with them. Apply thought. Then figure out how things should be. Oftentimes the solution will not be very endearing because it will involve people doing different jobs or fewer workers altogether, so it needs to be handled delicately. But it needs to be done.

If you find yourself placed on a Cowpath project, make sure you ask lots of questions. How are things currently done? How should they be done? Do the people doing things the bad way know it yet? What is your policy on violence in the workplace? If management doesn’t seem committed to making the project a success, you can be in for a real headache.

At the end of the cowpath, someone becomes a steak dinner. Don’t let it be you.

Til next time.

Subscribe to this Blog!