In 1987, I was in the army and stationed at Camp Red Cloud in the Republic of Korea. One weekend morning, I had to track down a colleague whom I knew to be shacking up with one of the bar girls from our favorite hangout in Uijeongbu (의정부시). We’ll call him Sgt. Bob and we’ll call her Miss Kim. They were both really nice people and made a cute couple. Miss Kim answered the door and WHOOOAAA! Holy Cow! 아이고! I had only seen her at night, in a dimly lit dive bar wearing a kilo of makeup. The person who opened the apartment door that morning was much different in appearance.
I was reminded of that experience recently when I read the project charter for a troubled and failing software implementation. If bogus management mumbo jumbo actually got projects done, this undertaking would have been a fantastic success rather than drowning eight figures deep under water.
Beautiful planning documents
The project documentation was elaborate and beautiful. In 30 years of working on some pretty big projects, I have neither seen nor produced anything so impressive. It was all right out of PMBOK (the Project Management Body of Knowledge) and included all the pretentious, pseudo-business jargon one expects from graduates of third-rate business schools.
Discussing the project with management in the rarified environment of the C-suite, I could see all the butterflies, unicorns and balloons the executives were describing. They made it clear that any problems with the project were someone else’s fault. In the raw light of day, though, without the management makeover, the project started to look a lot more like Miss Kim did that Sunday morning.
Had this been a private-sector project, the PM and a couple of the executives would have been forced to change their LinkedIn headlines to “seeking new opportunities.” In the public sector, depending upon the organization, you can screw up big-time and generally still keep your six-figure job. You might even get promoted!
No one involved in the grossly overstaffed and overbudget project had a clear vision of what the final product was supposed to look like or how it should function. As things continued to go wrong, more money and more unqualified people were thrown at the problems. There were no quality control mechanisms in place, and no one was really accountable for anything. It was all overseen and managed by people with PMP certifications. Typical public-sector IT, really. Firing the entire team was certainly advisable and justified, and many organizations would have taken that approach.
One problem was that the people leading the project really believed they had the required skills and knowledge, in spite of all the evidence to the contrary. After all, they had official-looking pieces of paper that said they were certified to manage projects. They thought they were brilliant managers and no one had ever told them anything different.
Do you think the $2.14 billion Affordable Care Act website was an anomaly? Nope! In smaller county and municipal government organizations, six- and seven-figure IT disasters aren’t uncommon. In larger municipalities and counties, eight-figure FUBARs aren’t rare. Once you get the state and federal level, the disasters can easily hit nine figures and the losses frequently end up buried in unmarked graves. Taxpayers rarely hear about these massive failures. The culprits get to keep their jobs and end up with generous defined-benefit retirements.
Twenty years ago, one tech industry crisis was the “Paper MCSE” — someone with a Microsoft certification who had never touched a server. Project management seems to be in a similar crisis now. It seems that everyone is a PMP. One government project I have been following has received a few hundred million dollars in federal grant money, and they have been hiring lots of PMPs. All of them appear to be 12 or 13 years old, so I’m not clear on how they met the experience requirements for the certification.
Failure and the truth about management
One essential management skill not taught as part of the PMP or any other certification is recognizing and managing failure. The ability to identify failure, call it and transition to the success track is rare. In order to do that, one has to be able to say:
“I was wrong!
I managed that poorly!
I see where I went wrong and I will do it better next time.”
This almost never happens, especially in the public sector. Give it try. Practice saying it if it doesn’t come naturally. Familiarity with failure is a big part of success.
Unfortunately, ensuring the success of complex projects requires more than the creation of cool-looking documentation and checking off boxes as recommended in a handbook. Management of a complex project and a horde of stakeholders and vendors isn’t something you learn in a 35-hour class, and passing a multiple-choice test proves nothing about your ability to do it. If you have no idea what you’re doing, and no idea what you are trying to achieve, no methodology or framework will save you. One can’t just stick pins in a doll and expect something magical to happen.