CXO

Scale it back: Controlling a project gone awry

Sometimes an IT manager will find that a project needs a major or minor scaling back to keep it alive. These five steps can help put the team, and the project, back on track.


By Lisa Gill

It’s a lesson often learned the hard way: even the most carefully planned projects can be derailed by the unexpected. Budget cuts, sponsorship changes, resource allocation problems, and new technologies are just a few of the variables that can threaten your projects. Though it’s tempting to just forge ahead, that strategy may not be such a good idea. Consider these tips from project managers who’ve been there. They may help get you—and your team—back on track.

1. Gather your courage
Recognizing, then admitting, it’s time to take a step back and reassess a project can be difficult, but it’s a critical step, according to Vince Sheehan, director of University Information systems for the Indiana University-Purdue University Indianapolis campus. He and a team of 30 IT pros have spent over three years overhauling one of the country's largest library systems. When phase three is complete, the overhaul will enable more than 93,000 students across eight campuses in Indiana to use the Web to renew and reserve books at 54 university libraries. Though the group delivered phase one on time and nearly 4 percent under budget, it wasn’t an easy road. On several occasions, they stopped the project so they could adjust to changes they couldn’t have seen coming.

"Making that call is never easy because in some respects it's an admission of failure, and we all take these things personally," says Sheehan. "But it’s kind of like 'check your ego at the door' and do what's best for the project and the organization."

Sheehan believes a solid practice is to never throw a surprise at the boss, unless it is unavoidable, and says constant communication about the potential for delays or the need to scale back is important.

"As the manager, you need to make a call and say, 'I think we need to make this decision. Either this due date slips, or we scale back to meet the date,’" says Sheehan, who says such lessons have been painfully learned.

2. Stop the presses, and the staff
When you discover a project is about to undergo a major shift, all work on it should cease.

"The first thing you should do is stop, because you're not going to be able to get the project back in control while you're moving forward," says Daniel Mahoney, senior vice president of research for Giga Information Group, a Massachusetts-based technology advisory firm. "Then you impose a moratorium. You pull together the key stakeholders, you review the current situation, and you make some decision as to what needs to happen to bring it under control."

A project Mahoney managed for a large U.S. automobile maker took a similar turn when a new project sponsor introduced a radically different idea about the type of technology the group was using.

"What he wanted was a very valid alternative; we were just driven in another direction. It totally threw a monkey wrench into this project, but what we did was stop the project," explains Mahoney. "You can't have those conversations in the back room while the programmers are out there programming and the purchasing people are buying hardware." It’s also important to retain credibility with team members who have already put time and energy into the original project.

3. Weed out scope-creep measures
Brian Ellison, a business IT project manager for Hewlett-Packard for nearly two years, says at least two projects he has worked on suffered so badly from scope creep that they were cancelled.

But on a current server-optimization project, Ellison is constantly on the lookout for any request or idea that may derail his team.

Ellison said team members may say “'Let’s do a Web page for this project!" But does this project necessarily need a Web page? It's so much of 'that would be cool to do,' and the team loses track of what it is they were ultimately there to do."

No project is immune to becoming larger and less focused than originally intended. This often hampers significantly the ability to meet deadlines with allocated resources. For a project about to be scaled back, one area to review is what unplanned additions to the original project contributed to its demise. From there, a decision should be made to either work the elements into the revised timeline, or chuck them altogether.

In many cases, even new technology released in the middle of the project can contribute to changing its scope and nature.

IUPUI's Sheehan explained that with the library project, as the university negotiated the vendor contract, the vendor released a new version of the software that offered some of the functions suggested by librarians, faculty, and students.

"So we had to make a decision. Did we want to go with the new version or did we want to go with the existing version and upgrade later?" explained Sheehan.

The group agreed that, due to its magnitude, the project already contained too many risk factors. As a result, they decided to stay with the original software package.

"We all agreed the best approach was to go with the current, established version first and then upgrade to the newer version and get that increased functionality later," says Sheehan. "The job was tough enough to accomplish without trying to deploy something brand new out of the box."

4. Identify multiple project phases
Sheehan and the IU team tried to avoid scope creep and were able to implement the new vendor technology by scheduling multiple phases of the project instead. Phase two of the library project included the new vendor software with some of the functionality, but not all of it.

"This past holiday season we employed the new version, which is now in a dot one release, not a dot zero release, and it's stable. We let other people work the bugs out of that. But again, we had to make some scale-back type of decisions," says Sheehan.

Sheehan said the team needed more time to install the upgrade, so the decision was made to go live but without all of the functionality they were hoping for. The final phase is now expected to be released in the fall of this year and will incorporate all of the originally scheduled elements.

5. Reestablish sponsorship, change control, parameters of project
Giga Information Group’s Mahoney also attributes scope creep to a poor change-control process and believes once a project gets scaled back, it’s time to reestablish all the critical elements that will keep it moving forward. Understanding who the sponsor is, what process decisions will be made, and what path a change follows, and identifying exactly when the project is considered finished will keep the team on track and establish a clear path to the finish line.

Sheehan's mantra also includes planning on a decision tree of people to move changes along. "I think the notion of 'how are we going to organize to make decisions about the project' is just as important as organizing the work load, and maybe even more important. And I think that's often a missing factor up front."

Have you ever had to scale back a project in order to control it?
If you have had to scale back a project, was the process problematic or a success? We’d like to hear from you. Post a comment or e-mail us.

 

Editor's Picks