Legions of dot-coms have collapsed, companies are laying off workers, and the economy remains in a sinkhole. It’s against that backdrop that some sanity appears to be returning to IT project management.
Gone are the days of bottomless-pit project funding and caffeine-pumped software developers sequestered off-site and working around the clock to be first to market with a glitzy Web site.
Instead, experts say, economic pressures have prompted IT departments to return to traditional, hands-on “block-and-tackle” project management, with a heavy emphasis on things like strict budgeting, daily progress reports, continual user feedback and codified processes and methodologies.
“There’s been a fundamental shift,” says Bob Wourms, director of the IT practice at PM Solutions, a project management consulting firm in Havertown, Pa. “A couple of years ago, time to market and market share were very critical. The focus now is on what is profitable.”
Experienced project leaders who have recently produced profitable projects on time and on budget attribute a good part of their success to dusting off and putting in place certain project management chestnuts, such as securing visible and active executive support for an endeavor early on. Along the way, they’ve also developed a few best-practice rules to keep their projects not only on track but in the black as well. Here’s how they’ve done it.
Stick to the goal, but know when you’re done
Profitability requires you to keep projects not only on time and on budget, but also on target to deliver no less or more than what they were designed to accomplish.
This was a key challenge for Jann Davis, manager of Project Discovery, a US$10 million customer service and call center initiative at PacifiCorp, a Portland, Ore.-based electric utility with 1.5 million customers.
One of the goals of the 18-month project, which involved implementing a new Web-based billing system and automating many call centre activities, was for PacifiCorp’s 325 call center agents to handle 80 per cent of incoming calls in less than 20 seconds. This entailed scripting different responses that would pop up on an operator’s computer screen, depending on the type of call request that came into the company’s two call centers.
“The problem was keeping the team to the 80/20 rule,” Davis says, noting that certain team members wanted to script responses for the rarest types of customer issues. “I had to keep pointing out the goals of the project. We didn’t need a Ferrari.”
Knowing when you’re done is critical to keeping a project on time, on budget and on track, Davis says. How do you do it? “I had to throw people together in a room constantly and have businesspeople and developers sit together to come up with, agree on and then stick to the requirements,” she explains.
Sweat the small stuff
“I wouldn’t characterize it as brute force, but rather as paying relentless attention to detail,” says project leader Pat Freeman, describing his style of managing a $55 million, 15-month project to develop a next-generation software system for car dealerships at Dayton, Ohio-based automotive software developer The Reynolds and Reynolds Co.
Initially, Freeman’s role was that of project rescuer, because the development effort was off schedule and over budget. There were also no clearly defined project management processes and procedures.
Freeman tackled the problem by instituting what he describes as “very intense” weekly reviews, during which each and every detail of any slipping task, deliverable, schedule or cost was scrutinized.
“The meetings lasted two to four hours, and we had a structured agenda every week, looking at the same series of things,” he says. “We always approached issues in terms of risk and what effect they’d have on the schedule and business case” before developing solutions.
This enabled the team to focus first on higher-risk tasks that could set the project back, Freeman says. It also helped keep the project on time and on budget for its first 10 months, though a quality control issue that surfaced toward the end of that time added another four weeks to the original testing schedule.
Insist on a full-time project team
One of the first things Gina King did when she was tapped last year to lead a four-month software development project was to insist that any member assigned to her team be there on a full-time, dedicated basis. Otherwise, it would be impossible for members to stay committed and focused, she says.
King, an IT manager at Valassis Communications Inc., an $800 million marketing services company in Livonia, Mich., had just 16 weeks to produce a new Web-based estimating tool for a large customer that was being heavily courted by a Valassis competitor that claimed to have a similar tool near completion.
“We were in danger of losing our client, so we had to get them something quick,” King recalls. With a full-time project team, the effort was completed on time and is credited with adding $1 million in annual revenue to Valassis’ books.
Do your own testing
Chuck Linebaugh, director of information systems at O’Hagan, Smith & Amundsen LLC, proved the effectiveness and financial benefit of a new, specialized software training course by requiring that all users at the Chicago-based law firm take and pass certification tests based on the training.
“When we started the project, we had an analogy that this [training] course is going to be like karate, and that every one of the tests a user passed is like earning another belt,” Linebaugh explains. “And we wanted everyone to earn a black belt.”
The content of the training course was developed based on information Linebaugh and his support staff gleaned from reviewing a year’s worth of calls placed to the help desk by the firm’s 100 attorneys and 150 support staffers. From users’ questions, “we defined 90 things people had to know and broke these things into four core subjects,” Linebaugh says.
The four subjects Windows 2000, file management, Microsoft Word and Microsoft Outlook then became the areas in which users were certified. Testing began in June 2000, and the law firm’s managing partner was the first employee to become fully certified. By June 2001, all 250 employees had taken and passed the certification tests, which are now part of the firm’s hiring process.
The training course and user certifications have yielded a return on investment of about $400,000, thanks to a drop in secretarial and other support costs. That’s because more knowledgeable workers, including attorneys who now handle their own e-mail and word processing, require fewer secretaries to support them.
Secure a payment commitment upfront
Dave Patterson is a big believer in what he describes as full transparency.
“Every project we’re working on and its status is reported through the intranet,” says Patterson, vice president of IT at Zurich North America, the Baltimore-based insurance arm of Zurich Financial Services. “The status of projects is all very fact-based. You’re either making your dates or you’re not; you’re on budget or you’re not; you either have an issue or you don’t.”
Patterson says Zurich applies the same black-and-white, fact-based thinking when it comes to paying salaries and bonuses to members of an IT project team. The bulk of each project team member’s salary is based on market pay rates and the worker’s competency. “But about 10 percent to 20 percent of compensation is based on whether the company makes money and whether we deliver a project as promised,” Patterson says.
His other financial rule of thumb is to always get the budget and funding arrangements of a project in writing.
“At the start of every project, there is a project agreement,” Patterson says. “It needs to contain the full scope of the project plans, risk analysis, costs and benefits, and it has to be signed by the business partners willing to pay for the project. From a block-and-tackle perspective, I will not allow a project to initiate if I don’t have a customer who is willing to pay for it.”
