BRYCE ON MANAGEMENT
– Does this story of systems development sound familiar?
Click for AUDIO VERSION.
To use this segment in a Radio broadcast or Podcast, send TIM a request.
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!
P.S. – Also, I have a NEW book, “Before You Vote: Know How Your Government Works”, What American youth should know about government, available in Printed, PDF and eBook form. DON’T FORGET GRADUATION DAY. This is the perfect gift!
Note: All trademarks both marked and unmarked belong to their respective companies.
Tim Bryce is an author, freelance writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 40 years of experience in the management consulting field. He can be reached at timb1557@gmail.com
For Tim’s columns, see: timbryce.com
Like the article? TELL A FRIEND.
Copyright © 2020 by Tim Bryce. All rights reserved.
Listen to Tim on WZIG-FM (104.1) in Palm Harbor,FL; Or tune-in to Tim’s channel on YouTube. Click for TIM’S LIBRARY OF AUDIO CLIPS.
Whether you are in the Information Technology field or not, you have likely heard these excuses before. They particularly arise whenever quality work is required or when organization and management control is imposed. Of course, I’m talking about the ten common myths of I.T. Ten common rationalizations people in the Information Technology world turn to whenever their authority or professionalism is challenged. They are neither new or limited to a specific geographical location. They have been around as long as the modern computer and they transcend all cultural and industrial boundaries. What’s worse, they have proven to be effective.
Whenever I’m asked to discuss the subject of Information Systems in the corporate world, I am inevitably asked, “Where does the programmer fit in?” I think this is an odd question as I see programming as only a small part of the overall puzzle. People are startled when I mention this, particularly programmers, who tend to see themselves as the center of the systems universe. I counter by asking, “What exactly does a programmer do?” After much discussion, we end up with the same answer, “a programmer takes human understandable specifications and converts it to a machine executable program, either by writing and compiling source code or through some interpreter capable of generating the program.” This, in turn, leads to an interesting discussion as to what is meant by “requirements” (it seems everyone has their own spin on this). More importantly, it leads to a discussion as to what exactly a system is.
If you think the physical infrastructure of our country is bad, its bridges and highways, you should see its systems. Like it or not, we are a nation run by systems developed as far back as the 1960’s. No wonder COBOL programmers are still in demand. Over the years I have heard one horror story after another, be it in banking, insurance, manufacturing, or government. I have also written about such snafus, such as at the 
Let me preface my remarks by saying I’ve been involved in the I.T. industry for over 40 years and have seen a lot, particularly banking systems. In the United States I watched mainframe based systems evolve into today’s version where people access their accounts through smart phones and move money around accordingly. These systems are still based on legacy systems which are less than impressive if you study them. Legend has it they are all based on the same program source code from the 1960’s which was modified and patched together to suit local needs. I have found banking overseas has been more stable, innovative, and forward thinking, particularly in Europe and Asia. In fact, the Japanese used our “PRIDE” methodologies to design their latest generation of banking systems which are considered state of the art and ahead of their American counterparts.
There are several interpretations of Business Process Design, which is concerned with devising a cost-effective approach for the various tasks to be performed in a business. Here is mine which has worked effectively for me for several years. It’s not a matter of what tools I use, but rather understanding the principles behind the design process itself.
In a recent Information Technology discussion group I am involved with, someone posed the question, “What is complexity?” I was surprised by the question as I thought it was understood what complexity was all about. Evidently not. The person posing the question was primarily concerned with complexity in system design, but I think it goes beyond systems, to all facets of business, be it related to products or services.
Now and then, I am asked about our corporate slogan, “Software for the finest computer – the Mind” which we have used since our company’s inception in 1971. “What does it mean, where did it come from?” I am asked. At first, it was used in connection with our “PRIDE” methodology for system design. There was nothing remotely like it on the market at the time. Consequently, people asked my father, Milt Bryce, what it was, “Is it hardware or software?” Recognizing their confusion, he said, “It’s neither, actually it is software for the finest computer – the Mind,” meaning it provides instructions so people could build information systems. At first, “PRIDE” consisted of nothing more than some manuals and forms for people to follow during system design. When asked what language it was programmed in, we said “English,” which amusingly confused the techies. Later we added computer software to help expedite the methodology, but make no mistake, “PRIDE” is a thinking process, a way of looking at systems and how to build them. Since then, the expression has gone on to represent other aspects of management and life in general, which is why I use it in my writings.
Another major system snafu was recently reported by the press, 
THE BRYCE IS RIGHT! 