All Posts in Policies and Procedures

|In: Organizational Effectiveness|Last Updated:

Why are so many client/server projects late, over budget, and under-featured?

It must be the technology. After all, IS mainframe development projects never come in late, over budget and under-featured, do they?

I wrote a piece on empowerment a few months back. Several managers responded with stories of employees who chronically make excuses and duck responsibility.

When IS management blames its 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.

Since 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 reasons for late system delivery. Resist it, or rebuild the project schedule each time you add a new feature and get every stakeholder to buy into the new schedule.
  • Regular, Concrete, Measurable Results: Your project plan must call for every member of the project team, every week to deliver something tangible. 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% completion of some function or other, because nobody can verify “70% 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 as compared to 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 putzing 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.)
  • (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 another 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 mis-estimated. 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 their 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 programmer 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.
    • Comments

    |In: Organizational Design|Last Updated:

    Ambrose Bierce, the 19th century cynic, told of the inventor who built a flying machine. When the inventor started the machine, it immediately and quickly bored a hole straight to the center of the earth. Leaping free, the inventor was heard to remark: “My invention was perfect in every detail. The problems were merely basic and fundamental.”

    Big projects are like that – they dig us all into deep holes, rarely fly, and even when they’re perfect every detail, they often turn out to be flawed in basic and fundamental ways – the usual consequence of having implementation scheduled years after conception.

    For some reason, everyone expresses surprise when IS projects come in late, over budget and with fewer features than promised, even though that’s by far the most common outcome. Since most new IS projects are based on client/server technology, we of course blame the technology, even though, as we saw last week, client/server projects fail neither more nor less often than traditional mainframe systems.

    The complexity of project management increases exponentially with the size of the project. This means big projects need exceptional project managers. Unfortunately, exceptional project managers are hard to come by, and they deservedly command salaries that can make IS executives uncomfortable.

    Next week, we’ll look at the basic principles of managing big projects. This week we’ll talk about how to avoid them in the first place, because most can be prevented. Here’s what to strive for:

  • Small Teams: Don’t put more than five people on a project team. Small teams mean low overhead.
  • Quick Delivery: Define projects no more than six months long. When a product is due in 180 days, the team feels a sense of urgency in the first team meeting. The project deliverable, by the way, should provide tangible value, not just something tangible.
  • Restricted User Involvement: End-users should define business processes and system functionality, not system design details. Get agreement on this point up front, and then have frequent, informal contacts rather than formal interviews. Be highly interactive, and learn their business from them.
  • Staged Releases: Make your first release as small as you can. Set up two teams working on staggered schedules. Team One freezes its design three months after starting. Team Two starts designing the next release while Team One codes. Team Two freezes its design three months later, while Team One installs its release. The benefit? You can successfully freeze the design, because it’s easy to add new features to the next release. This gets you out of the trap of “scope creep” that kills so many projects.
  • High-Productivity Tools: Delphi, Powerbuilder, Visual Basic and their competitors all increase programmer productivity by a huge multiplier compared to Cobol or C++. Only use procedural languages when you have no other choice.
  • Simple User Interfaces: GUIs tempt programmers into showing off by building in lots of overlapping pop-up windows with cool interface widgets and heavy mouse action. Make your programmers experts in clean interface design.

    • Usually, when you’re faced with a big, intimidating project you can break it up into a series of overlapping, independent, small, manageable projects that match the above characteristics. When you do, you’ll experience several key benefits. Your projects will come in on time. You’ll be able to track changing business requirements

    You’ll also find yourself able to respond to changing company priorities, because you won’t have committed all of your development resources to a single project for a long period of time.

    Think small.

    Comments