Projects Don't Fail, People DoBy John McCormick | Posted 2005-01-13 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce
The government -- believe it or not -- may have hit upon a way to cure basic illness.
The rule known in scientific and philosophical circles as Occam's razor stipulates that when multiple theories are available to explain a problem, the simplest one is preferred.
Organizations have struggled with information-technology projects for decades. Businesses have applied various management theories and implemented assorted software tools to straighten out the mess. Yet these projects continue to falter.
The Standish Group, an information-technology consultancy that tracked about 10,000 projects across all organizations in 2004, classified 53% of them as "challenged"—meaning they were delayed or over budget. And, it says, 18% failed outright.
The Office of Management and Budget (OMB) put half of the 1,200 federal-government technology projects in the fiscal 2005 budget—621 in all—on a "watch list" because it felt those efforts were falling short in areas such as performance measures and project management.
But the government may have hit upon an uncomplicated way to slow, if not reverse, the failure rate of technology projects. And commercial enterprises that follow the feds' lead may find themselves at a competitive advantage.
Indeed, an interesting picture emerges when one looks more closely at the numbers. The Standish Group reports the number of challenged projects increased 3% from 2003 to 2004. However, according to OMB, the number of troubled projects in government, while still high, was down 20% from the 771 at-risk projects reported in fiscal 2004.
One reason the government appears to be steadying shaky projects, according to both federal-agency chief information officers and project management experts, is that it simply realizes that projects don't fail—people do.
Technology projects are complex, and everything from a lack of funds, to a lack of staffing, to a lack of time and focus can be blamed for failures. But someone sets and approves the budget, someone picks the people, someone sets the schedule and someone executes the parts of the project that have to get done.
"You look at any major report that's ever been done in this area; it says that major projects fail, generally, because of people," says Ira Hobbs, the Treasury Department's CIO. "Not because of the lack of dollars or the lack of clarity in the vision. But in terms of people managing what they're doing."
Over the last couple of years, OMB, the Office of Personnel Management (OPM) and the CIO Council—which includes information chiefs from almost 30 federal agencies—started pushing the government to require managers to have a certain level of expertise before taking over projects.
In 2003, OPM created an official "project management" job title for federal agencies. And, this past summer, OMB went another step further, issuing "guidance" for agencies deploying technology project managers. The budget agency said that these managers should have the education and skills to plan, organize and implement projects and have two years' project experience before being charged with larger efforts.
"Project management is evolving and becoming the centerpiece of everything we're doing," Hobbs says.
That hasn't been the case in business. Deborah Bigelow, executive vice president of management consultancy PM Solutions, and others say many corporations don't qualify technology managers. Bigelow notes that less than 20% of corporate project leaders are certified by the Project Management Institute, the recognized authority.
Some companies are now getting serious about project management. Cigna, for instance, last month became a advisory board member of the Computing Technology Industry Association's Project+, a respected certification. The insurance giant says it's looking to gain greater insight into project management best practices.
People who make their people better managers of projects will gain an advantage over rivals who don't.
Will training and certification solve all project ills?
No. But when you have a problem, who are you going to call?