January 19, 2012
Even if our resumes and LinkedIn profiles portray us as superhuman, we all fail. And nowhere are those failures more apparent than on some of the big IT projects we lead and manage.
The important question is: How quickly can we fail at something before we make a big investment in it? Failing fast, one of the themes of InformationWeek's upcoming report on IT project management, is a practice that can save an organization millions of dollars. I've worked at both companies and government enterprises, and most of them have something in common: lots of rules, gatekeepers, and controls--longhand for bureaucracy. The checks are all well intentioned, but the combined effect is the same: slow, lumbering projects. At the same time, enterprise IT projects start to acquire a certain credibility the longer they're allowed to survive. Projects start to attach themselves to the careers of certain managers, and there's a reciprocating effect: The projects take on a heightened importance among line-level staff ("Oh, what will Ms. X think if I don't do well on this project?"). The project's sponsors damn the torpedoes and plow ahead, because the project simply must work. "My name's on it!" Projects also acquire a life of their own. You know how data center technicians will insist that, this time, one more reboot, one more fix, will make the upgrade work rather than concede that the project is turning into a nightmare? That's how some project managers get. Instead of raising a flag to warn that a project (a) doesn't have enough resources, (b) was ill conceived, or (c) is subject to new information that makes it a bad idea, project managers have been trained to push the puck forward, forward, forward. The wheels of bureaucracy will eventually grind to the realization that the project is indeed a bad one--but not until the big investments have been made. Alex Adamopoulos, CEO of Emergn, a project portfolio management consultancy whose customers include British Airways and BT, says he has seen millions of dollars spent on projects before organizations muster the will to declare them a failure. Organizations are wasting more than money. Hundreds, sometimes thousands of employees disrupt their work processes at a certain point in a big project's lifecycle. Global CIOs: A Site Just For You Visit InformationWeek's Global CIO -- our online community and information resource for CIOs operating in the global economy. So if a project is doomed, organizations usually treat as a hero the person who pulled the kill switch early on, right? Well, it's complicated. Greasing The Wheels Of Bureaucracy As we researched our report, we discovered five key strategies that will help your organization fail fast. 1. Make Your Project Management Offices Business-Focused. "Don't be afraid to call out the business," says Matt Anderson, director of Cerner's PMO. But PMOs must first build up some business cred. Those project managers who start with the premise of "Let's do what we need to do to make the business successful" instead of taking on the typical enforcement and gatekeeper role are far more likely to get management's ear and access to the kill switch. 2. Define Criteria For Failure. These criteria start with a project's sponsoring executive. Execs don't need to tell their PMs up front that it's OK to fail, because often, especially early on, it's not OK to fail. But they do need to let their PMs know that at some point they may need to flag the project for termination, and the sponsoring execs must lay out the criteria. We spend so much time defining project success, but we spend little to no time defining project failure. 3. Assign Programs, Not Projects If a project fails, that doesn't mean the program is failing, so there's not that same "Oh, Lord, my job has just gone away" feeling. Most of us run many, many projects at once. Don't let PMs create allegiance to projects, just to the program. 4. Adopt Small-Organization Startup Processes Identify processes suited to quick execution. Eric Ries's book The Lean Startup is an excellent starting point. 5. Don't Declare "Done"Your organization will need to make some changes to create a fail fast environment. A frequent problem is to declare a failed project "done," stop the meetings, yank the funding, and move on. Don't. Keep the conversation going. Declaring "done" means that everyone can go back to doing things the way they used to. And that means continuing to let misguided projects linger and run up costs. Learn from your mistakes and continuously share that knowledge. Jonathan Feldman is a contributing editor for InformationWeek and director of IT services for a rapidly growing city in North Carolina. Write to him at [email protected] or at @_jfeldman. Nominate your company for the 2012 InformationWeek 500--our 24rd annual ranking of the nation's very best business technology innovators. Deadline is April 27. Organizations with $250 million or more in revenue may apply for the 2012 InformationWeek 500 now.
About the Author(s)
You May Also Like