Three Steps to Disaster

I have this theory about the life cycle of a lot ofcomputer systems. I call it Peter’s Three Step Life Cycle (originality isn’t mystrong suit).

In the first step (Acceptance and Delight), some group ofusers is given a computer system. They’re so excited to have this package (andso pleased that someone has finally spent some time and money on them) thatthey don’t notice that the system doesn’t actually match the way the businessworks.

Let me make a distinction here between “the way thebusiness works” and “the way we do business.” In the secondsituation, the client is talking about some mismatch between the companyprocedures and the way a computer system demands the work be done. The simplestsolution is to change the company procedure. Fortunately, most people don’trealize that the procedure can be changed and, instead, call in someone like meto build a new system for them. They’re wonderful people who keep me employed.

However, there are certain realities that are beyond companyprocedures. I describe them as “the way the business works.” Anyapplication must match those needs in order to succeed. Your immediate reactionmight be, “How could someone build a system that does meet the fundamentalneeds of the business?”

As an example, let me tell you about one of my clients. Theyhad this wonderful system that allowed them to forecast how much product wouldbe wanted by each customer in each month. The idea was that, at the start ofeach month, the production department could match inventory against forecastand determine how much product should be made. Unfortunately, this systemdidn’t allow you to specify what kind of packaging the product was in. So,while the company might have a forecast for 500 tons of product X and actuallyhave 500 tons of product X in stock, it didn’t help them plan production. Thecustomer would need the product in cardboard containers, and the stuff ininventory would be in metal containers, or on pallets, or in some inappropriateform. Effectively, the system forecasted products the company didn’t stock.

It gets better. The system would tell these users that thestock was needed by, for instance, Customer 12. However, Customer 12 isn’t onecustomer. Customer 12 has a plant on the East Coast and another on the WestCoast. The plant on the East Coast wanted its material on pallets, and theplant on the West Coast wanted the material in boxes. Since the system lumped allof the demand from these two plants under the heading “Company 12,”it effectively forecasted demand for a customer that didn’t actually exist. Since they were in Step 1 of Peter’s Life Cycle, the userswere so pleased to have any support at all that they actually started to usethe system. They then entered Step 2 of Peter’s Life Cycle: Workarounds andDisgruntlement. In this phase, the users start to develop manual systems tocompensate for the deficiencies of the computerized system. In my example, thismeant two people for two weeks at the start of each month, decoding theforecast system output. These two clerks would convert the demand fornon-existent products to fictitious customers into demand for real product foractual customers. Since the results of their work were on paper instead of thecomputer, they would then match the results against inventory by hand.

This leads to the third phase, which I call Termination andDisgust. By the end the third phase, the company will have two systems: theofficial, computerized system and the unofficial, manual system. The work is actually done in the manual system and only recorded in the official system. Infact, it now takes longer to do the work than if the computerized system didn’texist. The users recognize this, and the system that they once welcomed is nowdespised.

This is where I came in and, at the department’s request, puttogether a proposal for a simple Access application to handle forecasting ofreal product to real customers. The department’s proposal was turned down bythe information systems group.

After all, they said, we already have a forecasting system.

About Peter Vogel

After 10 years of editing Smart Access, Peter continues to develop with Access (though he also does a lot of .NET stuff). Peter is also still editing other people's article--he even self-published a book on writing user manuals ("rtfm*") with a blog here.
This entry was posted in Editorials. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.