Time: it’s the bane of project managers. Despite all the advances in project management process and professionalism, too many IT projects still come in late. Project managers waste time by charging ahead too fast, communicating poorly or allowing their teams to get bogged down in stakeholder indecision, technical minutiae or business politics.
But by planning, setting standards and making sure project team members are on the same page, you can avoid wasting time. Here are nine notorious project time-wasters and how to avoid them.
Rushing in. If you “save time” by skimping on analysis and design, you probably won’t correctly define business requirements upfront, says Lois Zells, a project management consultant in Redondo Beach, Calif. This will come back to haunt you during testing, she says, when developers discover that they missed some important business need, or response time is seriously degraded because of a poor design. Then testing will take “10 times longer than it should,” she says.
The solution: Resist the temptation to shortchange analysis and rush into development. A rule of thumb for project managers is that for every hour of planning, you save three hours of work.
The life-cycle rut. Some project managers still use a “waterfall” or “phase-gate” life cycle, which is designed to yield fewer defects but draws out project time, says Johanna Rothman, president of Rothman Consulting Group Inc. in Arlington, Mass. Other project life cycles provide alternatives that reduce defects without affecting speed, she adds. Don’t choose a life-cycle model just because it’s the one you’ve always used. Look into alternatives that address the project at hand.
Poor communication. When projects get bogged down, it’s often because of a lack of communication, says Mark Brooks, a project team leader at a large financial services firm that he declines to name. Team members may waste time on a problem if they don’t know that another team member has the solution.
To avoid this, Brooks set up a telephone bridge that remains open all day. The bridge saved the day recently when a hard drive controller failure on a backup production server threatened to halt a project. “But when everybody jumped on the audio bridge, we found out there was another server chassis in another part of the data centre,” Brooks says. The team transferred the backup hard drives into the new chassis and had a new backup server running in 45 minutes. The project continued on schedule.
Excessive research. Project teams can waste weeks sifting through industry white papers on products and architectures, says Kevin Gungiah, director of systems administration at The Weather Channel Interactive Inc. in Atlanta. Moreover, it’s often hard to tell hype from reality. “I found there was a lot of marketing for what I wanted to do, but the solutions just weren’t there yet,” he says. All that research can be nearly useless anyway, since vendor labs can’t replicate conditions in your data centre, he says.
It’s quicker and more useful to call as many customer references as possible to see what their experiences with a product have been. Gungiah also recommends testing technologies on-site prior to purchasing them.
Untamed e-mail. Important e-mail messages exchanged among project team members can get lost amid the spam, wasting precious time. At the beginning of a project, Brooks establishes a standards team that creates a six-letter acronym to be used in the subject line of every e-mail that deals with the project. “That enables people to use the Outlook rules bar to look for that acronym and move it to a project folder,” says Brooks.
He also recommends including an action item in an e-mail title or in the first three lines of a message so it will show up in the preview page of Outlook. “That way, without opening their e-mail, they can see you want them to do work,” he says.
Indecision. Business stakeholders waste project time when they can’t decide on issues such as technical standards to which worldwide offices must comply with an upgrade. “You’re in the middle of a project, a business issue needs to be resolved, and everything stops,” says Larry Sisemore, an international manager of systems development at FedEx Corp. in Colorado Springs.
Although business decisions can be highly political and sensitive, “project managers need to be assertive” and push for closure, he says. When assertiveness isn’t enough, contact the business manager who owns the project and tell him the delay could cost him the deadline, says William Telkowski, chief technology officer at J.P. Morgan Chase & Co.’s I-Solutions group. If the business manager cares, he’ll make sure the problem is addressed, Telkowski says.
Obsessing. IT workers often get so focused on a problem that they lose track of time. “What was ‘just a minute’ drags on for a week or two,” says Catherine Tomczyk, a project manager at First Data Corp. in Greenwood Village, Colo. The solution: “We put in our rules that if someone is stuck on a problem for more than eight hours, we escalate it and assign a buddy to help them,” she says.
Between-meeting paralysis. When problems pop up the day after the weekly meeting, a week can go by before they’re addressed, says Tomczyk. As the deadline approaches, she schedules 10- or 15-minute daily meetings with her project team to ensure that problems are addressed as soon as they’re discovered.
Embellishment. Many developers just don’t know when to quit, says Rothman. “(They) have a passion for excellence and will embellish or add more features than were originally planned for a project if they think they have more time,” she explains. Rothman uses release criteria to define what “done” means so the team knows when to stop. For example, if a project’s design calls for certain functions to be done manually, she clarifies exactly where the automation ends.
