Project Management – When Failure Is Not an Option

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.

The framework also identifies the IT groups working on a project as well as the time each will devote to it monthly, which can improve communication and resource issues. For example, an effort to implement new customer-facing technology in all of A.G. Edwards’ branch offices fell behind schedule because overburdened project managers didn’t have time to loop in functional managers. As a result, they often demanded at the eleventh hour that functional managers drop everything and devote team members to the technology upgrade. Using the framework, Pilewski was able to get the project under control. The framework raised the project’s visibility inside IT and made it clear when managers needed to install infrastructure or test hardware and software.

The standard plan framework establishes the high-level activities that need to take place across all projects. To drill down, Pilewski and the project planners, managers and developers use software from Primavera that provides dashboards and progress reports for project tracking. They can compare original estimates with actual costs, see if milestones are met, list activities required for completion, or view all the projects that a functional group in IT is working on. Primavera also provides the data to the project management office, which uses it to identify when different IT functions should be brought into a project or when activities such as building test plans need to take place. All the company’s 126 projects follow Pilewski’s framework, so they’re measured the same way; the same activities are monitored across all projects using the software; and the data that project planners feed into the software is consistent and yields apples-to-apples comparisons across projects.

Notably, the standard plan framework does not specify how project and functional managers should perform each of those 25 steps, which distinguishes it from a traditional project methodology. By outlining what they need to keep track of instead of how they need to keep track, says Pilewski, the framework gives project managers the flexibility to break down their own work. In addition, they can use the framework in conjunction with any application development methodology, he says. That’s important because project managers can find standard project management methodologies too rigid and constraining.

“Companies are too big and too complicated to standardize on everything,” says Patrick Boylan, CEO of Intellilink Solutions, a boutique consultancy specializing in project management. “They need to find a way to get some form of control over projects while also giving the IT department the flexibility it needs to respond to clients.” A.G. Edwards has done exactly what Boylan suggests using its standard plan framework.

The Art of Persuasion

Although the standard plan framework is flexible, it was a tough sell inside the IT department. To win over the staff, Parker and Pilewski used various tactics. First, Parker appealed to his team’s sense of professionalism. He knew they weren’t happy that projects took years to complete. In one-on-one conversations, meetings with individual teams and formal town hall sessions, he told his workers that the framework would help them meet their milestones.

Pilewski then identified the project managers receptive to new ideas and hungering to improve their effectiveness. He asked them to get involved in pilot projects—a small product acquisition project and a large infrastructure application upgrade—where they used the standard plan framework for the first time. Pilewski then used those project managers as evangelists to get the rest of the team on board.

Pilewski and his project management office also provided planning services to all project managers so they wouldn’t feel overwhelmed by learning a new tool with new requirements. Specifically, the PMO built a project manager’s individual plans into the standard plan framework. All a manager had to do was specify the way she wanted to break down her work and whether she wanted the plan in Microsoft Word, Excel or on a whiteboard. Pilewski says providing those services prevented a groundswell of negative energy from forming around the framework.

Finally, Parker cajoled IT into embracing this new and more disciplined project management mentality by measuring project success rates and publicizing those metrics in quarterly reports delivered to A.G. Edwards’ top brass. He figured that if his staff knew he was briefing senior management on these metrics, they would take project management more seriously.

Redefine Success

In addition to implementing the standard plan framework, Parker redefined project success. Instead of defining it as completing a project on time and within budget, A.G. Edwards also weighs its business value, a key criteria to the project sponsors. So if a project is not completed on time but delivers the expected business value, the company still considers it a success.

Parker didn’t change the definition of success to lower the bar; he redefined victory so internal customers had the final say on project success and so it more closely aligned with their needs. For example, when IT was asked to create an application to recruit financial consultants, the project looked like a quick, low-cost development effort, according to Pilewski. In working with the sponsors on the functional requirements, the project team realized the competitive advantage of using this software to recruit the best and brightest brokers. They realized they’d have to devote more time to getting the application just right. The project took three times longer than planned and cost more than double its original estimates, but it’s still considered a success because it has enhanced the recruiting process.

“Project managers focus so much on cost and schedules,” says Pilewski. “The real trick to project management, though, is making sure that project managers understand that their customers play a key role in the project, and that the customers define success.”

He also restructured the PMO to foster joint accountability between project managers and functional managers within IT, whose agendas are often at odds. “People in IT infrastructure have day jobs,” says GlassHouse’s Lawler. “They’re dealing with production outages and fighting fires, and those issues often take precedence over a project, so projects slip and slip.”

Pilewski says that scenario was the reality at A.G. Edwards when he arrived. To fix it, he moved the project managers out of the PMO and into the functional areas to give them skin in the game. When the managers reported into the PMO, they didn’t have to live with the changes made to IT systems as a result of their projects. The new arrangement increases a project manager’s stake in a function because he is working with those systems every day.

This new reporting structure also eases the burden on functional managers, who sometimes coordinated with multiple project managers for each initiative their group worked on. Now they meet with one project manager, who is assigned to their functional group. Additionally, functional managers now have access to reports from Primavera that identify the projects their groups are responsible for so that they can plan workloads and effectively allocate their teams across projects.

Credibility Gain

IT’s stock within the brokerage house is on the rise these days due to its newfound ability to manage projects and help the business meet its goals. Project write-offs are a thing of the past. “We’re getting more for our money because we’re running projects more efficiently,” says Parker.

And what of that $196 million mainframe migration that he was hired to steer? Parker says the first phase of the multiyear project, while taxing, went smoothly. The project team converted the old legacy system to the new one in May 2005 as originally planned. And although the budget grew 5.5 percent, Parker says it remained “well within established parameters.” Impressed, A.G. Edwards funded the final phase of the project, which should be complete by 2008.

“We’ve made huge strides,” says Parker. “If we had a 1,000 percent improvement we needed to make, we’ve probably made 700 percent of it. We still have 300 percent to go.”