Tale of two projects

“Be careful with your ‘firemen’, they are probably your main arsonists.”

– Bryce’s Law

INTRODUCTION

The following is a true story; a classic “Dilbertism”. Because of this, the names have been changed to protect the innocent (as well as the guilty). Interestingly, I don’t think this story is unique and similar stories can be found in countless IT stores around the world.

Our story begins just a couple of years ago at a large manufacturing company in the American Midwest. At the time, the company was interested in replacing two old, but important systems; an Accounts Payable System (“AP”) and an Accounts Receivable System (“AR”). The IT director selected two of his most experienced veterans to manage the projects, we’ll call them “Steve” and “Bob.” Both project managers assumed their responsibilities on the same day: Steve to build the AP system and Bob to build the AR system. Both received roughly the same amount of human and mechanical resources to get the job done.

Steve was a very organized and disciplined manager. He found it essential to organize and train his staff in advance so that everyone understood the development process, the deliverables to be produced, and the responsibilities assigned. Recognizing the vast scope of his project, Steve felt it was important to methodically attack his system and meticulously drew up a plan and timeline to implement it. In Phase 1, you spent what appeared to be an inordinate amount of time studying the business problem, specifying the information requirements, and developing a rough design of the system solution. Steve’s people were actively involved in this initial phase and thought through the problem carefully before proceeding with the project. After Phase 1, Steve’s team finalized the details of the overall AP system architecture and divided his group into teams to address the various subsystems in parallel. To complement this effort, the database staff oversaw the logical design of the database to fit the needs of the entire system, not just a portion of it.

Steve also enlisted the support of the AP Department and key personnel from this area participated in the development of the system. The input of these users was vital not only in Phase 1, but also in the following phases in which the business processes were designed.

By concentrating on the overall system architecture and then gradually refining the design in subsequent phases, the software engineers received detailed specifications that were easy to follow and implement. As a result, the programming phases went smoothly, including testing.

Core subsystems serving AP’s operational needs were met and installed with strong support from the user community.

While Steve’s project was progressing smoothly, Bob was facing chaos with the AR system. Rather than studying the problem from scratch, Bob’s group began by building a central database. Soon after, he put his programmers to work building some basic input screens and some fairly simple outputs. Before long, Bob had something to prove to the user community (and his boss) to show that progress was really being made.

But Bob’s group hadn’t done their homework. The AR community

it was not consulted and the requirements were not defined. As a result, programmers were left wondering what users really needed, which started a long round of “cutting and tweaking” the code. Furthermore, the integrity of the database was questioned. False assumptions were made about the calculated data items that cascaded through the program code. Furthermore, no data validation rules were established. This forced programmers to invent their own rules and formulas for calculations in each of their programs, creating data redundancy problems and even greater headaches for development staff. As Bob gave users glimpses of the programs, data integrity issues became a problem and users did not trust the information the system produced (for example, different programs calculated calculations in a different way). different). Bob’s group touted the AR system as “next-generation,” but users weren’t convinced that it was reliable or intuitive to use.

All of this led to a redesign of the database and programs, not just once but several times. Consequently, the project schedule began to slide and costs were over budget. To overcome this problem, Bob and his staff worked overtime to catch up on the schedule (which he never realized). Regardless, the IT director began to notice the long hours Bob and his team put into the project and congratulated them on their dedication.

Bob eventually handed over a part of the project to the AR department, but when testing it, users found it riddled with bugs. To overcome this problem, Bob’s group was always ready to jump in and modify the code as needed. Even though users found the programs buggy, they praised Bob for how quickly his group could fix them.

NIGHT AND DAY

The difference between Steve and Bob’s groups was like night and day. While Bob was operating in a “run over” mode of operation, Steve’s group operated quietly and began to deliver the system on time and on budget, to the satisfaction of the user department.

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 had the tact to produce some management and the user community could “touch and feel”, thus demonstrating that something was happening in his department, right or wrong. Additionally, his SWAT team approach to fighting fires made him a favorite of corporate management. As a result, Bob enjoyed a high profile at the company, while Steve was relatively unknown.

Unfortunately, Bob’s project went haywire, unbearably. Recognizing that he had to do something radical to get Bob’s project back on track, the IT director made an unusual move; changed Steve and Bob as project managers. Steve was tasked with cleaning up Bob’s mess, and Bob was tasked with finishing Steve’s project. Suddenly, it sounded like a cunning move. Steve had shown the IT manager that he could get things done, regardless of the size of the application. And the IT director thought Bob could just shut down the AP project. The IT director was wrong. As Steve began 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 many people, especially Steve’s former project team, who felt they had caught defeat from the jaws of victory. Steve was also increasingly disenchanted, having almost completed a system and was now tasked with cleaning up his predecessor’s mess. To add insult to injury, due to Bob’s high profile, he was given a raise in salary and job promotion, and Steve did not get the same.

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

LESSON LEARNED

Is there a happy ending to this true story? Not for Steve. Although he cleaned up the mess and eventually brought both projects to a successful conclusion, he was disillusioned with the way the company had treated him. Subsequently, he went off and started his own consulting company that was eventually hired by his old company to develop new systems (at substantially higher rates). As for Bob, he enjoyed the benefits and pay that come with his new position for quite some time. Eventually, he got the hint and moved to another company where he did a similar one.

name by itself.

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

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