Any website needs focus to achieve ongoing quality, and keeping this focus is a way of avoiding the redesign-forget-redesign cycle. Once you have a sizable website, you have many voices (for example the owners of different subsites or sections) competing for changes to the website and underlying CMS. You need a way of product managing the implementation, so that you have a productive way of getting feedback. Without this, you could wind up with an unsustainable website, catering to the whims of the loudest stakeholders.
Organizations are tempted to take one of two approaches that get them trapped in a maze:
1. Don't engage (otherwise known as "they first have to give us their requirements") — NOT recommended
The CYA method of the central web team saying "first they have to give us their requirements" is an almost sure sign that there isn't engagement or focus. More sophisticated stakeholders may "win" in this environment, but this will also mean that items without an organization-wide priority will probably be implemented. On the face of it, this does seem like a reasonable approach because after all the central team needs to know the requirements, and who better to provide them than the team needing the requirement? But this overlooks the fact that individual teams probably have many non-web responsibilities, different groups don't know what other groups are up to, and also they do not understand the technical impacts of different requirements (see Developers, Don't Miss The Opportunity). Note that this is related to the approach of doing what stakeholders can pay for, which probably is not good for the organization overall (see You're Willing to Pay for the Feature? So What?).
2. Aimless engagement — NOT recommended
So if we're going to have a more active relationship between teams, then of course you want to go out and talk to stakeholders. But one thing to avoid is having this become aimless engagement, without specific goals and context. This problem can be made even worse if this is a big-bang, one-time engagement rather than setting things up for ongoing engagement. Some problems with aimless engagement are:
- Wasted energy on details that will longer be a problem in the future. Stakeholders naturally talk about the thorns they bump against in their day-to-day use of their systems. But assuming you are trying to fundamentally change the way the system works, many of these issues may be irrelevant in the new system.
- Poor expectations-setting about the future. Unless the context is specifically set, stakeholders will expect that the issues they raise will be resolved. And, as mentioned in the above bullet point, some issues may not even be relevant in the new system. Beyond that, you may wind up with the anchor of a long laundry list of issues, rather than a focused exploration of underlying required capabilities.
- Lost educational opportunity. Engagement should always be a two-way street, and one area in particular that we should focus on is educating the stakeholders (after all, they are educating the core team about their needs). For instance, if you are talking about moving away from Dreamweaver to a CMS, then the current site owners will need to be educated about a CMS.
Instead, I would propose the following approach:
3. Focused engagement — do this!
For focused engagement to work, the following must be in place:
- Overall objectives set and understood by all.
- Iterative / responsive / ongoing.
- Process understood (this does not mean heavyweight).
- Everyone has input, and can see the status of their requests.
