Via experience with federal government projects comes tips on troubleshooting projects that go bad. It happens more often than you think (at least at the federal level.)
Benjamin Knopf is a senior analyst Brian Gagnon a senior director at CEB, the member based advisory company formerly known as the Corporate Executive Board. They co-authored an opinion piece for FCW, which covers the business of federal technology.
They drive the message behind their opinion piece with this paragraph: “CEB research shows that as many as 30 percent of projects in an average portfolio are troubled at some point during their life cycles. Some 20 percent of projects eventually fail, wasting significant time and money without delivering expected benefits to the agency or the public. Even more disconcerting is the fact that 20 percent of organizations don’t know whether they have troubled projects. (It is fairly safe to assume that they do.)”
In effect, one-out-of-five federal projects fail while almost one-in-three hit troubled patches. That’s not a reassuring rate of success (unless you’re a baseball manager).
Here are what Knopf and Gagnon suggest are the three areas most needing attention:
- Inadequate metrics
- Cultural barriers
- Strained communications
The metrics of most projects are schedule and budget related but neither are good indicators to prevent problems before they happen. As the authors point out, “Consequently, nearly three-quarters of PMOs report that more than 20 percent of their healthy projects actually conceal problems.”
Writing at BusinessWorld.com, Rossana Fajardo, who writes the “Suits the C Suite” column, says, a common cause of program failure is execution. That covers (a) inadequate risk assessment, quantification and allocation of project risks, (b) incomplete or unrealistic cost information, (c) shifting budget, scope and timetables, (d) lack of accountability, (e) adversarial team and supplier relationships, and (f) lack of skills or resources in program and project management.
Her column approaches the topic from the IT perspective but it offers advice that works for any project manager. “IT programs do not fail or underperform due to only one reason; there is usually an amalgamation of reasons. It is therefore crucial that management be aware of the organization’s specific IT program risk universe and implement strategies up front to manage the most likely risks to program success,” she writes.
Cultural barriers, according to Knopf and Gagnon, aren’t ethnic in nature but rather a corporation’s commitment to not punishing for failure. “Many project managers and members of project teams hesitate to escalate identified problems for fear of career repercussions,” they say.
John Henes, writing for CNBC.com, seconds the notion that failure needs to be an option. “Risk is required for growth,” he writes. “[W]ithout it, we would not have our greatest businesses, products and technologies. In fact, without it, we would not have become the dominant economy in the world over the last century.”
At Marketers Brain Trust, Leslie Rhode builds on that sentiment. “Always plan to succeed, but also be prepared to fail and able to recover from it. This is a delicate balance. Don’t give up too early as success could be just one more sprint away, but don’t commit so much that you can’t recover.”
Knopf and Gangnon also say communications can be an issue, especially when working with contractors. “Differing objectives and management approaches generate significant challenges to effective collaboration across internal staff and contractor lines,” they say. In simpler terms that means hire contractors who understand your language, whether you’re a government agency or private entity. Consider creating a glossary of terms, if need be. That sounds simple but could help eliminate miscommunications.
