It's about time to sum up everything you know about a project and how it should be planned and executed. Or, as the case may be, should not...
I was once with a company that had an old mainframe process—one that included tons and tons of code, had been in operation for 30 years, and was on its last legs. Hardly anyone was left who thoroughly knew or understood the system. It had labyrinths of COBOL, Natural/Adabas, and even some Assembler code all mixed in. No individual person had a clear grasp as to how the thing had been put together or how it ran.
To save the company, big time, a honcho wanted to move the whole thing to a client/server environment. He took people out of their current company roles and put them on a project team. He hired dozens of contractors. And he appointed two of the contractors as project managers (even though they had no PM experience and knew almost nothing about mainframe systems). The finalized team consisted of about a hundred people.
They had one thing in their hand—a hard deadline of Christmas, eleven months away.
The group knew they didn' t know anything about client/server relational databases. The consensus was that Informix should be the database of choice. Off to training went the contractors and employees to learn about Informix and about PowerBuilder—the front-end development component that would allow them to create the screens that ran against the Informix back end.
It was quite a production. The best way I can describe it is for you to imagine Yul Brynner in The Ten Commandments, standing before the construction plans of the pyramids, papyrus scrolls rolled out on a huge granite stone. "Moses! Come here!" Yul cries. "See what I am going to build!" Our little mainframe project had that kind of ostentation. Sturdy foam placards were posted in the hallways, showing pictures of racehorses hurtling toward a finish line—each horse representing a project element. We had a really great project title and T-shirts with the project ' s logo.
There were several problems, though. Cost and material overruns were horrific. Tens of thousands of dollars went into overtime as the unqualified
PMs fought with each other and disagreed with management, and as they struggled to make sense of the mainframe code and of the project.
We drastically overestimated the ability of the servers to handle the voluminous quantities of code and database activity required. New machines were brought in—several at a time.
Project team members were completely in the dark about what they were doing and about how they were doing it. How could we possibly have expected people who were freshly back from training to create quality deliverables? On top of it all, a few PC-oriented programmers could have cared less about mainframe operations, had giant egos, and were really involved in trying to single-handedly create the project without benefit of the mainframe SMEs. And morale didn' t exist, because corporate employee team members were required to work overtime, but contractors were released at their regular time.
Am I describing a disaster yet? It gets worse.
It became apparent that team members were going nowhere fast. Deliverables were way behind; time and cost overruns were astronomical. Through a series of highly strategic blamestorming efforts, the PMs and sponsor determined it was the database' s fault that things weren't moving along. So, to get the project back on track, the PMs decided to switch from Informix to Oracle and sent everyone back out for training again!
Finally, around Thanksgiving, the sponsor had a meeting with the team members. He wanted to know why they deliverables weren't proceeding as expected, and he wasn't satisfied with the answers the PMs were giving him. So he brought the employees and contractors together and actually said to them, "Can 't you code faster?"
You have the picture, right? We ' re ten months into this project. There are no deliverables. The contractors have pillaged the project' s budget. Servers are sitting on the floor doing nothing. Some of the boxes scattered around say Informix, others say Oracle. And the sponsor is asking if people can code faster. Oh, the stupidity that went on with this project is breathtaking!
Finally, on Christmas Eve, the sponsor dismissed the contractors for good. He put the employees back onto their respective teams and called the project a failure. He had to go before some bigwigs and confess that he ' d just burned through several million dollars and had nothing to show for it.
What went wrong here? There is a litany of mistakes, all of them classic, all of them avoidable, and any one of them potentially fatal:
■ The project ' s deliverables were not clearly stated.
■ People with no project management training were put in charge of the project.
■ There were no SMEs who knew how to write the code needed to get the process off of the mainframe and onto client/server.
■ Cost and time overruns were not managed (they were actually good for contractors).
■ The deliverable deadline was way too short.
■ Contractors were allowed to control how things got done, with no input allowed from business experts.
■ The size of the project was drastically underestimated—good estimation techniques were not used.
■ And—probably the straw that broke the camel' s back—the switch from
Informix to Oracle came way too late in the project. Once you ' ve decided on a platform, unless there ' s an incredibly good reason for doing so, you should never switch horses in midstream. I think this single decision killed the project at that point, even though it wasn't officially killed until much later.
Was this article helpful?