Way before requirements to avoid train wrecks

We have all seen train wreck projects, and the problems are usually acknowledged quite late in the process.

Although teams are usually surprised by them, the underlying problems are usually quite clear early in the process. But instead of just identifying the problems, how do we avoid them in the first place?

One of the key ways is to make sure that the stage is set for success, and this needs to happen way before requirements are defined.

We’ll look at how you can:

• Define how much of the organization’s web presence should even be in the scope of a project (organizations usually fall in the trap of asking for work on a narrow slice of their web presence when big benefits would only come from a broader approach)
• Define the vision for a project in a way that the organization’s management is truly behind the effort (this includes ensuring that everyone understands the tradeoffs of decisions, so that teams don’t violently agree to something they don’t really understand)
• Frame web change as ongoing change, so even when developing a project for a specific scope and duration it is within the context of treating the web presence as a coherent product for the long term

All of these should be defined *before* any implementation RFPs are even sent, and certainly before requirements are developed.