John Parker had no illusions about the considerable challenges awaiting him as CTO of A.G. Edwards. The management team had painted a clear picture during his job interviews in fall 2001. IT costs were too high. Projects dragged on for years, if they were completed at all. Some had derailed so dramatically that the St. Louis–based retail brokerage firm had to write them off. Poor project management was taking a toll on the bottom line.
The executives told Parker they needed a CTO who could overhaul the IT department and ensure that a planned five-year, $196 million migration of a mission-critical mainframe system would proceed smoothly. They simply couldn’t afford to have a project of that magnitude follow IT’s usual MO, where systems developed in isolation—sometimes over the course of years—often failed to meet the company’s requirements once delivered. It just couldn’t happen.
What Parker found after he was hired matched what he had heard during his interviews: Almost half of all projects were late and over budget. Most cost 54 percent more and took 54 percent longer than original estimates. And he found evidence of the write-offs. "We were running hundreds of projects over the course of a year, and 1 to 2 percent of them would have been written off and the write-offs would have been significant," says Parker, now CIO. In 2002, A.G. Edwards wrote off $46 million worth of software investments, according to a company filing with the Securities and Exchange Commission.
Fast-forward to 2006. The company’s project success rate (defined by the number of projects that arrive on time, within budget and that deliver the expected business value) has soared from 54 percent in 2002 to 88 percent today. Improved project management has had a dramatic impact on the company’s financials: The SEC filing shows that IT and telecom costs declined from $295 million in 2002 to $241 million in 2005, even as investment in the mainframe migration continued. Meanwhile, net profits jumped from $71 million in 2002 to $186 million in 2005.
Parker achieved this project management turnaround by transforming how IT operated—from its interactions with the business to the structure of its project management office. Experience has taught him there’s more to running successful projects than methodologies and tracking software, which is where most IT organizations get hung up. Successful projects hinge on sound leadership and constructive relationships between IT managers and the business. So Parker set out to improve his department’s track record by working with the company’s top executives to identify the most important projects and by providing all IT managers with leadership training to improve their credibility with the business.
"If you try to fix project management without fixing the top first, you’re not going to have much success," says Parker. "Projects will always flame out if your leaders aren’t flying air-cover for projects when they get into trouble, regardless of how good your project management procedures and tools are."
Parker also brought in a project management expert to instill some discipline into the process. Ed Pilewski, now VP of IT productivity and quality, chose not to take the traditional route of forcing a rigid project management methodology on the technology staff—a tactic that can backfire and create resistance to change. Instead, he implemented a standard framework for measuring, monitoring and reporting on a project’s progress that fosters transparency and accountability. The framework also gives project managers some flexibility in how they approach their work.
The company also reinvented its project management office, or PMO. Project managers used to report into a centralized office; now they report into different functional groups within IT, such as application development, network engineering and quality assurance. The idea is to increase their stake in a project’s success and put them on an even playing field with the functional managers. The mission of the productivity services office, as the PMO is now called, is to help project managers with planning and to provide them with the reports they need to keep their projects on track—a departure from the old, bureaucratic model.
In fact, A.G. Edwards’ holistic approach to project management represents a departure from the standard operating procedure and is worth emulating, say field specialists. "Other companies are doing bits and pieces of what A.G. Edwards is doing," says Sam Lawler, director of GlassHouse Technologies’ project management practice. "What makes A.G. Edwards unique is that they’ve made a real commitment as a firm to address project management top to bottom."
A.G. Edwards’ top-to-bottom approach to project management has worked well for the company—and it can work for you too.
The Big Picture
The consequences of poor project management can be dire: Plenty of companies, from Nestl¿o Nike, have seen earnings negatively affected by botched IT implementations. In spite of the financial risk, many still haven’t mastered project management: Just 29 percent of IT projects conducted in 2004 were completed on time, on budget and with all features and functions originally specified, according to The Standish Group, a consultancy that publishes a biennial benchmark report on IT project success rates.
Good project management is crucial to prevent backlogs as the economy quickens and companies take on more IT initiatives in 2006. "There’s a strong need for project management today. With market conditions improving and profits starting to reappear in organizations, businesses have money to spend on technology, which increases demand for IT," says GlassHouse’s Lawler. Yet CIOs cited project backlogs as their primary barrier to effectiveness in CIO’s 2006 "State of the CIO" research (see "The Project Backlog," www.cio.com/state). "Project management is the number-one success factor for getting anything done in an organization," says Lawler. "A firm’s ability to execute its strategy lies within its ability to manage projects."
But project management isn’t easy. A PMO or a formal project management methodology (such as PMI or ITIL) doesn’t guarantee success, as A.G. Edwards, which had both, can testify. "I’ve gone into many organizations that use a project delivery methodology, yet their projects continue to fail," says Peter Graham, a vice president with consultancy Palladium Group. "If that’s the only thing that’s done, you may see some incremental uptick in quality or ability to meet deadlines, but you won’t get sustainable results."
Projects remain challenged for two reasons. First, implementing formal methodologies requires a change management effort not just in IT but across the business. Second, PMOs often become minibureaucracies that fail to address the problems that dog projects, such as a lack of shared accountability between functional and project managers. The need to address those intractable challenges explains why A.G. Edwards couldn’t simply rely on a new methodology or its existing PMO to improve project success rates.
Start from the Top
When Parker came on board in November 2001, he observed the classic case of the IT department as order-taker—never saying no to the business, and never explaining what it could and couldn’t do vis-¿is projects. He knew that to improve project success rates, he had to change this mentality and the business units’ perception that IT staffers were passive or incompetent. "A successful project is really a marriage of businesspeople and IT people," says Parker, who oversaw a variety of successful fast-track projects while serving as Northwest Airlines’ VP of information services from 1999 to 2001.
At A.G. Edwards, Parker’s first step was to make IT managers realize they were more than yes-men and yes-women and to build their credibility with the business. He began by providing ongoing leadership training to all 250 employees with management responsibility in his IT department. He wanted them to understand their role in achieving A.G. Edwards’ strategic goals. Parker also reasoned that if the IT managers were positioned as bona fide leaders, their business-unit counterparts would take their opinions more seriously, and the groups would be able to work more collaboratively on projects.
"Leaders set the tone for the relationship with the business community and for the level of efficiency, discipline and performance that you get out of your IT shop," he says. "If your leaders are taking orders, there’s no way they can effectively form the right kinds of relationships with the business to drive projects effectively."
The training was particularly important for frontline managers, who had always associated themselves with their teams and never with the IT leadership. Parker sought their participation because of the close influence these managers have on staff who execute the project work, from writing code to testing functionality. So he created a series of quarterly meetings during which line managers learn to work with budgets, provide vision and express opinions diplomatically.
Parker also worked with CEO Robert Bagby and the senior management team to align IT with the business strategy. The goal was to establish a plan to strengthen and streamline business operations and identify the technology to enable growth. To do that, he met regularly with a governance committee that comprised the top eight executives to facilitate alignment and consensus on the most important initiatives. Pinpointing priority projects meant that Parker could focus his troops on their execution. He says if you don’t zero in on the initiatives that support business strategy and generate revenue, you end up with your employees working on low-value projects, like changing screen colors.
Transforming how IT managers perceived themselves and did business was a dramatic shift for the department and for the company. Although Parker had support from senior management, he still met resistance from certain "bad actors" in the business community who refused to use the proper channels to request work or to follow the new processes for specifying requirements.
Parker initially opted for a subtle approach to this problem. "I didn’t march into anybody’s office and say, ‘These are the new rules of engagement with IT.’ That just wouldn’t work," he says. Instead, Parker positioned himself as the good cop with recalcitrant colleagues. He would mention to them the challenges he had with certain division heads or managers. He stopped just short of saying, "This is the problem I’m having with you. You need to stop second-guessing the platforms we’ve chosen and stop telling your direct reports not to give us the detail we need around requirements."
He also made positive examples of division heads and managers who engaged with IT and encouraged them to act as proponents for change. When he needed to be direct with those division heads who were telling their employees not to provide detailed requirements, he showed them charts explaining how that would increase the likelihood of project failure.
Parker often used consultants to play the bad cop. For example, he had them spell out in no uncertain terms that businesspeople had to develop their requirements with more detail. But Parker himself could also be tough in dealing with toxic "IT bashers" who deliberately worked against the technology department. If he couldn’t get them to "cease and desist" on his authority as the CIO, he asked their bosses or their bosses’ bosses for help.
Implement the Tactical Plan
With the IT strategy set, a governance committee for prioritizing projects in place and leadership development under IT managers’ belts, it was time for a fresh approach to project management. To get the ball rolling, A.G. Edwards hired Pilewski as an independent consultant in June 2003. Three months later, he was named VP of IT productivity and quality.
Pilewski knows a thing or two about project management. Prior to A.G. Edwards, he spent six years as an independent consultant turning around large IT projects in danger of failing. He also worked for Capgemini as director of project delivery for its Midwest division.
When Pilewski arrived, the brokerage firm already had a project management methodology in place. Pilewski kept that. Then, he made a pivotal change: He introduced what he calls the standard plan framework to monitor and report on the progress of projects. The framework is basically a set of repeatable steps designed to improve project delivery and accountability. Pilewski had used it before and knew it could benefit A.G. Edwards.
Here’s how it works: The framework lists 25 activities for managers to track during a project’s lifecycle, such as developing architecture specifications, performing requirements analysis and building test plans. Project managers are also responsible for tasks within each activity. In the requirements analysis phase for a corporate recruitment application, for example, the project manager was asked to document exactly what the business group wanted the application to do.
Another benefit of the framework is that it highlights existing systems that require, say, more memory or new interfaces as a result of a proposed software implementation or infrastructure upgrade. Doing so pinpoints interdependencies that a project and functional manager need to be aware of to keep things on track.