Script The Demo

This has evolved out of observing how demos can be sources of project instability, but a satisfactory pattern has yet to gel. Here's the raw material. Please comment or add on.

Problem: A act of giving a demo can introduce unexpected instabilities into a project.

Demos serve to show progress to existing stakeholders, to gain support from potential stakeholders, to provide an opportunity for feedback, and to get mid-project kudos for the development team.

During the course of a project, progress is often invisible to key stakeholders and decision makers. Lack of visibility raises anxiety, and makes it hard for managers to "do their thing" (i.e., to make decisions). A demo provides visibility, and can unleash a pent-up need to manage. However, demos really yield partial visibility, and often, by design, misleading visibility. Both can lead management to make, with the best of intentions, decisions that seem inconsistent with the goals of the project.

People who are out of touch with the project often come away from the demo with a misunderstanding of the true state of progress. "It runs, ship it!" is a common post-demo cliche. At best, the project leader has to expend CorrectiveAction time to reset expectations. At worst, the schedule gets shortened by edict.

Casual demos are often a source of feature-creep instability. A project member demos a mock-up of a "neat" idea to a skip-level manager or someone in marketing, and the neat idea now becomes a requirement, with either no adjustment to the schedule, or a hit on the project leader's time to negotiate a schedule change.

Therefore: At various times during the evolution of a project, script one or more "official" demos. Be clear on the purpose of each demo, and be wary of demos that seek to both demonstrate progress and gain feedback via mockups. Be deliberate as to what is and isn't shown, and train demo-givers to not deviate from a script.

Don't rely on demos as the sole indicator of progress. PERT charts do have value.

Comments:

• This doesn't apply to exploratory projects.
• This level of control risks missing opportunities by blocking new ideas.
• Too many words.

-- DaveSmith (7/24/96)