Conclusion 04By Anne Field
Project Management 2001
Facing the twin challenges of time-to-market compression and ever-tightening IT budgets, CIOs find themselves more than ever under the gun to get their projects done on time and on budget. But while no one would debate the importance of expert project management for key IT initiativesand CIOs' job securitythe results of this month's survey of 1,077 CIOs and senior IT strategists indicate that most of their organizations still have a long way to go before they master project management. At the same time, however, our respondents believe that they themselves have done a better-than-average job of getting their projects done on time and within budget.Edward H. Baker
Only 10 percent of the respondents indicated that their organizations' most important IT initiative of the past two years had been completed both on time and on budget, although they were either on time or on budget about 50 percent of the time. Meanwhile, respondents gave themselves a success rating of 3.7 (on a scale of 1 to 5, where 5 is the most successful) in their ability to bring projects in both on time and on budget.
The discrepancy suggests either that CIOS do not hold themselves to particularly high standards when it comes to project management or that they do not have particularly high expectations for the efficient completion of their projects.
Delays. Cost overruns. Fickle priorities. IT projects are too often plagued by such problems. That's the consensus of both management experts and the more than 1,000 CIOs who responded to our recent survey on the trials and tribulations of project management. "Rarely does a project in an organization come in on time and budget," says Jayson Hahn, CIO of Merrimac Industries Inc., a maker of microwave components in West Caldwell, N.J.
Case in point: A year-long materials requirements planning installation recently went live at his company, about six months behind schedule. Hahn attributes the delay to inadequate planning: No one with sophisticated project management expertise was put in charge of the effort. As a result, "nobody knew which module needed to be set up first," he says. "One day, they'd start on the manufacturing component, then they'd realize they first had to do accounting, so they'd backtrack."
Hahn, who became CIO last year, hopes to put an end to such snafus with a more disciplined approach. But the experience underscores perhaps the central issue underlying project disappointments everywhere. Says Mark Keil, an associate professor in the computer information systems department at Georgia State University in Atlanta: "If you scratch beneath the surface, most of the problems lie with management."
Lack of commitment from key business units is foremost among the problems. "When there's little functional involvement, that's a sure recipe for disaster," says Andre Mendes, CIO of Pluvita Corp., a biotechnology company based in Bethesda, Md., and formerly the CIO for the Public Broadcasting Service in Alexandria, Va. When representatives from the business areas affected by a project don't fully participate in shaping it from the beginning, IT developers wind up flying blind, forced to produce a design for the project without the information they need. The result: a series of costly stops and starts as potential users belatedly provide the necessary specifications.
For John Wade, CIO of St. Luke'sShawnee Mission Health System, an eight-hospital system in Kansas City, Mo., the big culprit is "when the user doesn't direct the process. It's almost natural that a project doesn't get done on time in those cases." He points to one project, an upgrade to a billing and receivables system, launched a year ago. "We laid out the schedule for the departments, asked if they could make the dates, and they told us they could," he says. Trouble was, the managers involved hadn't really taken the time to think through the schedule they'd been handed. The project was completed two months late.
Pressure from the top can also affect the planning process. That's what happened to David Hanighen when he was vice president for software development at a mortgage loan originator and Internet bank. (He's now the vice president of information services of the Orange County Teachers Federal Credit Union in Santa Ana, Calif.). Feeling under the gun when the firm's senior management decided to install a new treasury system, the treasury group rushed through designing the specifications for the system's three components. "It was about 40 percent under what they really needed," he says. So partway through the project, they had to go back to the drawing boardand ask for more money as well. When Hanighen left the company, the project was already seven months behind schedule.
No matter what the level of business involvement, however, size matters. The bigger the project, the more complex it becomesand the more opportunity there is for delay. "Once you get over the 12-month time frame, the chances of being on time start to diminish," says Wade. A study done in 1999 of 500 companies by Deloitte Consulting bears that unfortunate truth out. It found that 90 percent of 90-day projects were completed on schedule, while only 50 percent of one- to two-year efforts made their deadlines.
Complexity isn't the only reason longer projects get delayed. There's also the frustrating matter of priority creep. The longer the time frame, the more likely it is that other needs will crop up, forcing IT to divert resources to another project. It may be that a new government regulation requires an immediate reconfiguring of another system. Or it's time for a system upgrade. Whatever the reason, "[In long projects,] needs change. Requirements change," says Wade. "And you find you're never able to deliver the original project." Or as Bill Foulds, director of IS for Providence Healthcare Network, an acute-care hospital, psychiatric facility and long-term care hospital in Waco, Texas, puts it, "If the CEO decides something is more important, that jumps to the top-priority list."
Consider a master-patient index project Providence started four years ago, one year before Foulds came to the company. A major undertaking, it was intended as a centralized way to identify patients across the Providence network, regardless of which facility they used. But thanks to a series of interruptionsother projects that required taking some of the 13-person IT staff away from the effortit has yet to be implemented. Recently, however, Foulds has renewed hope for completion. A new clinical information system, started two months ago, requires that the master patient index be in operation by the end of the calendar year. "Now people are buying back into the effort," he says.
That ebb and flow of management buy-in is a major contributor to priority creep. A year and a half ago, for example, Foulds began a reinstallation of a patient accounting and patient management system. But not long after, a daunting new federal regulation was passed, mandating that hospitals be reimbursed for outpatient care based on diagnostic-related groups, much like inpatient services. Meeting the government requirements meant putting in a new IT system, and it was a deadline that couldn't be missed. "Even though we had already bought the software, we had to put the other project on hold," say Foulds. Trouble was, roughly six months later, when the department was able to breathe again, many of the original managers involved in the project, including the psychiatric director of medical records and the director of nursing for long-term care, had moved to other areas of the company or left altogether. Over a three-month period, "we had to resell the new people on the project and convince them to commit resources," says Foulds. The system was eventually completed, but it took six to nine months longer than Foulds had hoped.
The moral of the story: When you're talking priorities, it's all about politicsbehind-the-scenes maneuvering for resources, for making sure your needs are number one on the list, even if that means pushing aside someone else's.
The way the maneuvering is played out differs from company to company and department to department, depending on how budgets are set and how big the issue is. In some companies, if the matter is small enough, it may mean little more than sweet-talking the right developer, says David Pinkus, who was the founder and CIO of a now-defunct Scottsdale, Ariz.-based software company called Rulebase Inc., and is now an external CIO for Construction Monitoring Systems LLC in Phoenix, which sells software for construction loan disbursement monitoring. "Salespeople know how to sell. So if they want something done, they'll find the right developer and try to sell that person on the features they want," he says. "Then the developer will sneak it in."
At Providence Healthcare, on the other hand, all projects are paid for through the IT budget, which is set every year by a management steering committee composed of the CFO, COO, CIO and directors of such departments as the lab and pharmacy. All changes to that plan must be approved by the COO. "If someone wants to replace, say, a system for submitting bills and he convinces the COO, then it may get adopted," says Foulds. Such changes in a project's priorities may happen out in the open; others occur without Foulds' knowledge. About 15 months ago, for example, "senior management decided we needed to replace our accounting and reporting package, because they felt it would save a great deal of money in the long run," he says. "They didn't discuss the effect on IT at all."
One solution to the relentless retooling of priorities, suggest a number of management experts, is to revamp the way projects are funded. At some companies, for example, every project needs to be paid for by the business unit involved. At others, there's a 50-50 ownership between IT and the functional unit. "That way the business has to come up with its own justification for a project. They're the ones who have to think about its value," says Haim Mendelson, co-director of Stanford University's Center for the Study of Electronic Business and Commerce.
Another approach is to think small. Mendelson calls it "the six-month rule"breaking projects into pieces, each with clear objectives, and each requiring no more than six months to complete. David Lago, director of development for ReturnBuy Inc., a reseller of excess inventory in Ashburn, Va., recommends going even furtherbreaking IT efforts into four- to eight-week chunks. "You take small steps toward a goal," he says. "Then, if priorities shift, you can still be pretty agile and it's easy to make adjustments." Recently embarking on developing a new interface for eBay Inc., ReturnBuy chose a phased-in approach. The first step, which involved implementing such basics as listing items for sale, took six weeks. The second phase, which included more advanced features such as highlighting particular items for sale and setting a minimum price, took just four weeks. Later phases, which will include such elements as listing prices simultaneously on the company Web site, have been designed to take a similar amount of time.
At Fenwick & West LLP, a Palo Alto, Calif., law firm, CTO Matt Kesner has actually declined to take on projects that will go on for more than six months. Says Kesner: "If something lasts longer than a year, I really think there is somebody who doesn't want the process to be completed."
Anne Field is a Pelham, N.Y.-based writer who covers management and business trends. Her work has appeared in a variety of business magazines and Web publications, including Business Week, Fast Company, Fsb.com and iSource. Comments on this story can be sent to firstname.lastname@example.org.
What gets in the way of successful project management? While respondents rated their satisfaction level on managing their most important projects in the past two years at an above-average 3.8 on a 5-point scale, they also identified numerous roadblocks to successmany of which involved setting and maintaining proper priorities throughout the process.
More than three fourths of the respondents agreed with the statement that their most important project was late or over budget because their companies' needs and priorities changed during the project. Additionally, 62 percent of the respondents said they encountered changes in personnel during the project-management phase, and another 61 percent said they ran into technical problems with one or more key product vendors.
A large percentage of respondents also agreed with a variety of statements posed to them about internal prioritization challenges they faced in managing their projects:
Priorities set at the beginning of projects were later shifted73 percent agreed.
The prioritization process for our most important project needs improvement64 percent agreed.
It is difficult to get different departments to agree on priorities61 percent agreed.
The prioritization process is politically driven 49 percent agreed.
Company size had a fairly predictable effect on the prioritization results; for instance, 44 percent of CIOs at companies with fewer than 1,000 employees believed the process is politically driven, but that number rose to 62 percent among CIOs at larger companies.
The most difficult aspects of ensuring on-time/on-budget project management: meeting top executives' expectations (3.3 on a 5-point scale of difficulty), changing deadlines (3.2) and dealing with unproven technologies (3.0).
The most popular IT applications that have been deployed and managed during the past two years are customer-facing applications, and some types of projects are significantly more difficult to complete successfully than others. One anomaly: As notorious as some installations have become, ERP projects did surprisingly well.
E-commerce, corporate portals and customer-relationship management were the three most-often-deployed IT initiatives by CIOs during the past two years, at 65 percent, 59 percent and 53 percent of respondents, respectively. The least-often-deployed applications? Supply-chain management, cited by a mere 23 percent of respondents, and then wireless, with 38 percent.
Sales force automation projects were the most likely to be completed over budgetjust one third of such projects avoided cost overruns. Distance learning was the project that was most likely to come in on budget, at 71 percent, and also the most likely to be done on time, at 64 percent. Meanwhile, just 40 percent of decision-support systems were completed on time.
A relatively strong inverse correlation between company size and project-management success suggests the increased difficulty of satisfactorily completing projects in larger corporate settings.
Smaller companies achieve better results in project management than larger companies. Fifty-four percent of companies with fewer than 1,000 employees said their most important IT projects of the past two years were completed on time, and 55 percent said they were completed on budget; among larger companies, those numbers dropped to 44 percent and 45 percent, respectively.
Shouldn't bigger companies, with bigger internal IT staff, larger budgets and the tendency to use outside consultants to supplement their internal resources, just "brute-force" their way through projects? Apparently not. Successful project management has little to do with the scale, scope or breadth of resources. Instead, it's all about experience and intellectual property, which can be found in companies of different sizes, shapes and cultures. And, in fact, a case can probably be made that larger companies might do well to "act small" when it comes to project management, perhaps deploying smaller teams or, wherever possible, biting off smaller pieces of a big project to manage rather than attacking the entire project at once.
The one vertical industry where on-time/on-budget project management is somewhat more likely to occur is the computer services industry. Systems integrators, software developers and value-added resellers (VARs) are the groups more likely than those in any other industry sector to have successfully navigated internal IT project management. However, no industry has a stellar record for being both on time and on budget.
Fifteen percent of CIOs in the computer services sector said they'd successfully managed their company's most important IT project in the past yearmeaning on time and on budgetcompared with 10 percent of all respondents. Other industries where CIOs said they'd done better than the average respondent include government, at 14 percent, and wholesale/retail at 11 percent.
Goverment industry CIOs' better-than-average success rate can likely be attributed to several factors, including the fact that government has been doing complex systems integration and IT initiatives longer than any other industry. Furthermore, government IT contractstypically given to third-party systems integrators and consultantstend to spell out more clearly the conditions of their projects, such as time frames and cost overruns. While this hardly ensures a successful project-management scenario, it at least makes clear the parameters for defining achievement.
Conversely, sectors where CIOs said their companies had significantly underperformed on successful project management included banking and finance, with a meager sub-1 percent success rate; transportation, at 4 percent; hospitality and healthcare, each with a 5 percent success rate, and education, at 6 percent.
For different aspects of project management, there are clear distinctions among the responsibilities and ownership mandates of various groups within the organization. CIOs tend to delegate the task of leading projects down in their organizationor at least "out" toward the business units. Presidents and CEOs, followed by CIOs and chief financial officers, tend to take the lead on setting priorities. Meanwhile, the board of directors is more often taking an active role when it comes to setting business priorities to be fulfilled by those IT initiatives.
Which group tends to own project management and implementation most often? Respondents cited business-unit and departmental business executives 53 percent of the time, making them the number-one group owning project-management responsibilities. Next comes IT/IS staff, cited by 46 percent of the respondents, then IT/IS management at 41 percent. Interestingly, respondents saw CIOs as only the fourth most likely group to lead project management, coming in at 37 percent.
But when it comes to setting business priorities to be fulfilled by those IT initiatives, presidents and CEOs overwhelmingly lead the way, cited by 81 percent of the respondents, far outdistancing the number-two group, chief financial officers, at 44 percent, followed by CIOs at 41 percent.
As for managing those priorities, IT/IS management usually takes the lead, cited by 62 percent of the respondents, followed by IS/IT staff at 56 percent and business-unit executives with 51 percent.
With so few CIOs indicating they were able to achieve both timetable and budget goals for their most important projects, it is understandable that business executives have been forced to lower their expectations. But is that what CIOs should establish as a benchmark for success? If not, then they must start working on framing reasonable expectations with the CEO and business-unit managers. The classic pitfall of overpromising must be avoided at all costs. Consider breaking those projects up into smaller modules, and look for outside help, if it's available and your budget allows. Most important, enlist your business groups as stakeholders in the project all along the way, especially when setting priorities at the outset.
How the survey was done:
CIO Insight designed the project management survey in partnership with Survey.com, a San Jose, Calif.-based supplier of online research services. The study was e-mailed to CIOs, CTOs and vice presidents of information technology and services whose names were gathered from a number of sources, including third-party lists and other Ziff Davis Media publications. The survey was posted on a password-protected Web site, and 1,077 people responded from July 9 to July 11.