(InfoWorld in Print)

| Navigational map -- for text only please go to the bottom of the page |

May 20, 1996 (Vol. 18, Issue 21)

IS SURVIVAL GUIDE

BY BOB LEWIS
Shepherding complex projects is hard work, but the payoff is success

MANAGEMENT SPEAK: We want to deliver a quality product.

TRANSLATION: The product will be late and over budget.

Thanks to reader Michael Heinich

Why are so many client/server projects late, over budget, and underfeatured?

It must be the technology. After all, IS mainframe development projects never come in late, over budget, and underfeatured, do they? I wrote a piece on empowerment a few months back. (See "You can be both ethical and empowering: Help your employees succeed," April 8, page 56.) Several managers responded with stories of employees who chronically make excuses and duck responsibility.

When IS managers blame their inability to deliver on technology, it's time to look at who's really unwilling to shoulder responsibility.

IS gained a reputation for late system delivery long before client/server technology. One reason client/server technology created excitement was its potential for reducing development time. Why has it failed to do so? Last week we looked at methodologies. This week, the issue is project management -- probably the key difference between successful and failed projects.

Because I'm at best an adequate project manager, I called in an expert, Terry Westropp, for a second opinion. (Full disclosure: Terry is a fellow employee and senior project manager at Perot Systems.) Qualifications? Terry manages real projects of significant size and scope, on both mainframes and client/server technology, and brings them in on time and within budget.

What differentiates successful projects from the others? Here are some guidelines:

Scope control. Everyone hates it, but at some point everyone has to agree to freeze the design. Last week we talked about using staged releases to take the sting out of this. "Scope creep" is a big reason for late system delivery. Resist it; or rebuild the project schedule each time you add a new feature and get every stakeholder to buy in to the new schedule.

Regular, concrete, measurable results. Your project plan must call for every member of the project team to deliver something tangible every week. Tangible means you can point to it, touch it, use it, and verify its existence. You can't define the milestone for a week as "70 percent completion" of some function or other, because nobody can verify "70 percent complete." With weekly tangible results, you'll never be more than a week late without knowing about it.

Weekly status meetings. Every team member presents this week's results compared with the plan. The team discusses both expected unexpected problems and unexpected unexpected problems. (Example of the former: learning how to use a new middleware technology to access a remote database -- you expect to do some mucking around in this situation. Example of the latter: The development tool blows up when you try to join more than 15 tables in one report.)

A key success factor: Ask, and insist on an answer to, the magic question, "What are you going to do about it?" for every late delivery. This isn't a rude question -- it's a matter of one professional asking others how they're going to get their part of the project back on track. The answer may be long hours; it may involve weekend work; or it may involve rescheduling, if a task really was misestimated. Whatever the solution, though, it has to be explicit. "I'll keep working on it" isn't an explicit solution.

Team buy-in to the plan. Anyone can load some project management software and create a Gantt chart. If the project team doesn't believe a schedule is realistic, the whole project can turn into an emotional pressure-cooker. One solution: Parcel out project responsibilities to the team. Everyone plans his or her own delivery schedules. The project manager integrates them so all dependencies are accounted for.

Walking around. Updating Gantt and Pert charts with this week's actual numbers constitutes project administration. Walking around, looking over programmers' shoulders, asking questions, and offering help -- that's project management. When you're interacting with project management software you're just counting beans.

There's no magic to good project management. It's hard, detailed, demanding work. If you expect shortcuts (and take them) you'll end up with a late, disappointing system.

Bob Lewis is a Minneapolis-based consultant with Perot Systems Corp. Send him e-mail at Robert.Lewis@ps.net. Visit his forum on InfoWorld Electric at http://www.infoworld.com.

Please direct your comments to InfoWorld Electric.