Several years ago I found myself working at a manufacturing company where, after years of neglect, the apps that ran the Accounts Payable and Accounts Receivable departments were in desperate need of replacement. The IT director selected two managers, Steve and Bob, to head twin redesign projects. I won't tell you which of them was me.
Recognizing the complexity of the Accounts Payable project, Steve studied the business issues and recruited key personnel from the AP department to help identify information requirements and develop a rough design of the solution.
Still, as days passed with no code being written, management grew nervous. The IT director even scolded Steve for his slow progress. Nonetheless, when Steve's software engineers finally received specifications, they were clear, specific, and easy to implement. The core sub-systems needed to satisfy the operational needs of AP were completed on schedule, and users thought they were great.
Bob took a different approach. Focused on fast results, he set part of his group to building a core AR database, while a second set of programmers created basic input screens and sample outputs. In no time, Bob had something to show the boss, who was suitably impressed.
But Bob's group never defined AR requirements, and programmers were left second-guessing what users really needed. When AR staffers got their hands on the first iteration, several rounds of code cutting and fitting were required, and the integrity of the database came into question. False assumptions about calculated data elements cascaded throughout the program code, and contradictory validation rules led to data redundancy issues.
All of this required a desperate last-minute redesign, and Bob and his staff found themselves putting in long hours of overtime. Initially the IT director complimented them on their dedication. But as he heard more and more complaints from the user community, he realized just how deep the problems ran.
So he made a radical move: He swapped Steve and Bob as project managers. Steve was charged with cleaning up Bob's AR disaster; Bob was directed to tie a bow around Steve's near-complete AP project.
Steve succeeded in getting AR back on track. Meanwhile, Bob brought chaos to Steve's AP team, who watched, horrified, as Bob snatched defeat from the jaws of victory. In the end, Steve was put in charge of both projects, but by now Bob enjoyed such a high profile for his initial successes that the IT director would have looked stupid if he just fired him. Bob was "promoted" to a department where he could do no harm -- with a bonus, of course.
Is there a happy ending to this true story? Well, sort of. Steve was so angry that he quit and started a consulting firm, which was ultimately hired to develop new systems for his old company at a substantially higher pay rate for Steve. As for Bob, he enjoyed the perks of his new position for some months before moving on to another company.
I wish I could draw an uplifting moral from this tale, but the more I think about it the more discouraged I get. It seems to suggest that looking busy counts for more than actual accomplishment. But maybe I'm the last guy in the world who didn't know that already.
The person that wrote this article wishes to remain anonymous