You are here
Getting the Bones Right
There are several times when you need to try to structure things correctly:
- When changing the underlying technology
- When generally trying to make big changes, including trying to rein in previous changes that were not done in an ideal manner
- When confronted with what, on the face of it, appears to be a smattering of disjointed issues that represents a deeper pattern.
Let’s consider the case of a CMS replatforming project. In that case, ideally we follow this process:
In this model, we first clearly define what business goals our website is serving. Next, we set up the “bones” of the overall system. Here, I don’t just mean the right CMS, but things like: a) the right templating approach, b) the staffing commitment to maintain high quality, and the technology to match, and c) the resolve to keep improving, and to anchor our changes on the vision (and not the squeaky wheels). Only after the flexible structure of a growing skeleton do we move on to the improvement phase.
You see, there’s a murky space between the idea of content, and the hard reality of a content management system. — Deane Barker
But that’s not the way most organizations approach replatforming their site, which goes more like this:
In this model, we might not even really understand the problem before sending the RFP, in the hopes that the implementation vendors will also help in defining the needs (or worse, we may not have any desire to understand the business needs). The implementation is focused on the launch, and we forget after launch. In addition, we might even focus on creating a new website entirely that looks slick but creates yet another silo. Perhaps the biggest problem: we thought more about what the site needs to look like upon launch and not how it needs to respond over time.
What are the bones?
One way to look at it is that the vision first needs to be set, then this ripples out to defining and implementing the bones of your web presence, and from there you can keep improving in phases (either as a part of a phased rollout on a new platform or on an ongoing basis). In the diagram below, each wedge represents an area that is needed for a website to function. The point here is less that this is exactly how you would break down the areas, but that at least these areas need to be covered. Each successive “wave” radiating out from the vision means more depth in both planning and implementing each of these areas. But organizations usually have pretty strong biases on what is important, and so planning and implementation often goes quite deep into one area at the expense of others. For example, since the technology is often the scapegoat, the entire focus of a replatforming may be on the technology. But without considering the people for example, you could implement technology that satisfies the technologists but not the individuals actually using the system (and so even with the shiny new CMS you wind up in the same mess again a few years later).
The vision should define just enough of all disciplines to convince the team that it is possible, then the vision ripples out into waves of implementation.
