Project Management Gone Bad - A Waterfall Story
Project management has been a staple of business for decades. It has undergone significant changes, particularly when it was formally adopted for Agile development. It wasn’t always that way, though. Let me take you back three decades, to a time when Waterfall was still the king of software development processes.
Back in the mid-nineties, while I was in the US Navy, I was asked to test some software. Some of my testing was for the Y2K bug. Another was for a program we were creating for another branch. It was new! It was awesome! It was using cutting-edge technology (ADA, COBOL, and DB4). It was going to revolutionize their services.
Government contractors and US Navy personnel conducted development, testing, business analysis, and documentation. We had a project manager who was a high-level government employee. The project was relatively new when I joined, having been in development for only a few months. The planning document had been around for several years, though. It was a cumbersome affair, printed out on huge bursted, line-printer paper.
Those were the heady days of i286 and i386 computers, with recycled gunmetal cases and monochrome monitors. We testers weren’t allowed to bug the programmers, as we were beneath them. If we found a bug, we had to formally document it in WordPerfect format, print it out, and place it in an “In tray” on our Chief’s desk. Code and Bug Fixes would require multiple days of downtime to the mainframe, and often had to be restarted multiple times. We never knew what was coming, though. It was truly a “black-box.” If we had questions about the software, we had to bug the software documentation specialists, who would consult the manual, which they were constantly updating and reprinting. Yes, the entire thing would get reprinted for even the most simple of grammatical errors. Essentially, we had numerous communication silos. We had a huge requirements document we had to follow for our development, with little insight into what it required.
Still, we worked on this software for several years. Back then, we could enter a series of commands into a .bat (Batch) file to configure the computer’s memory. While experimenting on this, I discovered the optimal configuration to make the system perform quickly. I shared it with my cohorts, and they all agreed it was a better configuration. It even got the attention of some of the programmers, who had me provide them with a 3.5” floppy disk so that their computers would run as quickly when they booted it up.
You know what didn’t end up in that requirements document? That memory configuration trick. No one bothered to record it.
Finally, the day came when we were ready to gold-stamp the floppies for delivery. For you young-uns, we had to physically put the code on a series of installation floppies and hand deliver them to the client. Often, a gold seal was placed on the final disks, hence the term “Gold Stamping.” CD-ROMS weren’t a thing yet, so we had to use 3.5” floppies. The project manager had installation disks for the software and the database. She had the completed user manual, which was larger than the requirement document. It was in a standard, printable format, though it filled multiple binders.
As she was leaving with her entourage of officers and NCOs, I handed her the configuration floppy disk with clear instructions. “Once you have installed the code, boot the computer up with this disk inserted. It will configure the system properly.”
Needless to say, this was the first she had heard of it. No one else had said a word to her, and the other high-ranking officials were just as much in the dark. Who was this lowly enlisted person to tell them what to do? Especially since he was merely an E-3. Not even a Petty Officer. And a tester? Anywho, they smiled and said, “Ok.” Off to the client they went.
When they got on site, they installed the software and database on the provided computers. They verified that both computers could talk to each other over the coaxial ring network. They fired up the database and received positive confirmation that it was working. Then they fired up the complicated program that had taken multiple years of planning, documentation, development, and testing.
Nothing. Zilch. Zero. Damn thing didn’t work at all.
We lost the contract. We lost a significant amount of influence in our industry. Some contract personnel were fired due to the cut, while others were reassigned to assist with Y2K work.
What happened? Surely our extensive documentation prepared us for all of the requirements needed. We were also using cutting-edge technology. You’d think it would mean we were destined for greatness!
The problem with waterfall was evident to me. Despite all the planning, the lines of communication disappeared as soon as the work began. There was little collaboration across the teams. It was frowned upon and actively discouraged. Everyone was so hung up on the requirements and planning documentation that they were unable to handle a simple change.
That stupid configuration disk I had created.
It sounds like a joke, but one of the programmers checked it out after the failed demo, and yes, if the PM had booted up the program using the configuration disk, the demo could have proceeded.
By that time, though, it was already too late. The program was over budget and overdue, and our PM had just offered the perfect excuse to cancel the entire program.
Now, I’ve seen a few debacles in my career. It is painful to witness, and even more painful to be in the midst of it all. This is why I could never go back to a classic waterfall program again. Is Agile perfect? Nope. It depends on folks collaborating and working together. It requires stakeholders to be involved in the planning process and provide feedback. It requires architecting based on what you have available, whether it be the hardware or the skills of the people involved. Sadly, many organizations overlook some of these areas.
Was the project manager at fault here? It’s hard to say. She went on to run several very successful endeavors before retiring. I don’t know what politics she was dealing with, nor do I know if she was the single point of failure.
My memory of the event is being focused through a lens of decades of hindsight. It certainly was a learning experience for me, though.
