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, AG 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 AG 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 AG 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 AG Edwards's 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 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. The software 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." AG 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.