The following is a true story; a vintage “Dilbertism.” Because of this, the names have been changed to protect the innocent (as well as the guilty). Interestingly, I do not believe this story to be unique and similar stories can be found in countless IT shops around the world.

Our story begins just a couple of years ago in a large manufacturing company in the American Midwest. At the time, the company was interested in replacing two aging, yet important, systems; an Accounts Payable System (“AP”) and an Accounts Receivable System (“AR”). The IT Director selected two of his most seasoned veterans to manage the projects, we’ll call them “Steve” and “Bob.” Both project managers were charged with their responsibilities on the same day: Steve to build the AP system, and Bob to build the AR system. Both were given approximately the same amount of human and machine resources to accomplish the work.

Steve was a very organized and disciplined manager. He found it essential to organize and train his staff upfront so everyone understood the development process, the deliverables to be produced, and their assigned responsibilities. Recognizing the large scope of his project, Steve felt it important to methodically attack his system and meticulously worked out a plan and schedule to implement it. In Phase 1 he spent what appeared to be an inordinate amount of time studying the business problem, specifying information requirements, and developing a rough design of the system solution. Steve’s people actively participated in this early phase and thought the problem through carefully before proceeding with the project. Following the Phase 1, Steve’s team finalized details of the overall AP system architecture, and divided his group into teams to tackle the various sub-systems in parallel. To complement this effort, his data base people oversaw the logical data base design to accommodate the needs of the whole system, not just any one portion of it.

Steve also recruited the support of the AP Department and had key personnel from this area participate in the development of the system. The input from these users was vital not only in Phase 1, but also in succeeding phases where the business processes were designed.

By concentrating on the overall system architecture and then by gradually refining the design over succeeding phases, the Software Engineers were given detailed specifications which were easy to follow and implement. Consequently, the programming phases went smoothly, including testing.

The core sub-systems satisfying the operational needs of AP were on schedule and being installed with great support from the user community.

While Steve’s project was coming along smoothly, Bob was facing chaos with the AR system. Instead of studying the problem upfront, Bob’s group began by building a core data base. Shortly thereafter he set his programmers to work building some basic input screens and some rather simple outputs. In no time, Bob had something to demonstrate to the user community (and his boss) to prove progress was indeed being made.

But Bob’s group had not done their homework. The AR community was not consulted and requirements were not defined. As a result, programmers were left second-guessing what the users really needed which started a long round of “cut-and-fitting” the code. Further, the integrity of the data base came into question. False assumptions were made about calculated data elements which cascaded throughout the program code. In addition, data validation rules were not established. This forced the programmers to invent their own rules and formulas for calculations in each of their programs which led to data redundancy issues and even bigger headaches for the development staff. As users were given glimpses of the programs by Bob, data integrity issues became an issue and the users didn’t trust the information being produced by the system (e.g., calculations were computed differently by the various programs). Bob’s group touted the AR system as “state-of-the-art,” but the users were not convinced it was reliable or intuitive to use.

All of this lead to a redesign of the data base and programs, not just once but several times. Consequently, the project schedule started to slip and costs exceeded budget. To overcome this problem, Bob and his staff worked overtime to play catch-up with the schedule (which he never realized). Regardless, the IT Director began to take notice of the long hours Bob and his team were putting into the project and complimented them on their dedication.

Bob finally delivered a portion of the project to the AR department, but in testing it the users found it fraught with errors. To overcome this problem, Bob’s group was ever ready to jump in and modify the code as required. Even though the users found the programs buggy, they commended Bob for how quickly his group would be able to fix them.

The difference between Steve and Bob’s groups were like night and day. While Bob operated under a “helter-skelter” mode of operation, Steve’s group operated quietly and began to deliver the system on time and within budget, much to the user department’s satisfaction.

Steve understood the enormity of the system and its importance to the company, and, as such, took the time to organize and train his group accordingly. Bob also understood the importance of his application but took the tact of producing something management and the user community could “touch and feel” thereby demonstrating something was happening in his department, right or wrong. Further, his SWAT team approach to putting out fires made him a favorite with corporate management. As a result, Bob enjoyed a high profile in the company while Steve was a relative unknown.

Unfortunately, Bob’s project ran amok, unbearably so. Recognizing he had to do something radical in order to get Bob’s project back on track, the IT Director made an unusual move; he swapped Steve and Bob as project managers. Steve was charged with cleaning up Bob’s mess, and Bob was charged with finishing Steve’s project. Offhand it sounded like a shrewd move. Steve had proven to the IT Director he could get things done, regardless of the application size. And the IT Director figured Bob could simply close-out the AP project. The IT Director figured wrong. While Steve started the arduous task of bringing organization and discipline to the AR system, Bob quickly dismantled Steve’s organization and brought chaos to the AP system. This did not sit well with a lot of people, particularly Steve’s former project team who felt they had grasped defeat from the jaws of victory. Steve was also growing disenchanted as he had almost completed one system and was now charged with cleaning up his predecessor’s mess. To add insult to injury, because of Bob’s high profile status, he was given an increase in pay and job promotion, and Steve didn’t receive likewise.

Steve got the AR system back on track and finally implemented it much to the satisfaction of all concerned. Bob lost control of the AP system almost immediately and it spun out of control until Steve was finally called back in to finish it. Not knowing what to do with high-profile Bob, the IT Director made the classic move of promoting Bob and transferring him to another area where he could do no harm.

LESSONS LEARNED

Is there a happy ending to this true story? Not for Steve. Although he cleaned up the mess and ultimately managed both projects to a successful conclusion, he became disenchanted with how he had been treated by the company. Subsequently, he left and started his own consulting firm who was ultimately hired by his old company to develop new systems (at substantially higher rates). As for Bob, he enjoyed the perks and pay resulting from his new position for quite some time. Eventually, he got the hint and moved on to another company where he made a similar name for himself.

Although Bob was a fine example of the “Peter Principle” (rising above your level of competence) he recognized results were not necessary on the road to success but rather, image was everything. He learned early on that “the squeaky wheel gets the oil.”

As I mentioned at the outset, this is not a random incident, but one that could probably be told by a multitude of corporations who have “promoted the guilty, and prosecuted the innocent.”

Have you got a similar story? Please do not hesitate to send them to me.

“Beware of your firefighters; they are probably your chief arsonists.”
– Bryce’s Law

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:
http://www.phmainstreet.com/timbryce.htm

Copyright © 2010 by Tim Bryce. All rights reserved.