Key Points
- Concentrate on getting the bones right rather than rushing to implement the first site.
- Don't postpone key business decisions by building first
In a rollout we want to change multiple sites or site sections
Many organizations have complex digital presences. Whether we are talking about an external web presence, an intranet, or an extranet, there are often:
Multiple sites, or multiple site sections
Mutliple groups that are managing content
Multiple systems
In a rollout, we are attempting to make changes to many or all of these different slices of the digital presence. For instance, in a global rollout of a redesigned external web presence we may want all the country sites to use the new system (for instance, to better share information or to have better brand consistency). Even if not specifically planned in detail, usually the teams rolling out complex digital presences are thinking that some substantial portion of the digital presence will be changes. An incomplete rollout is when some of the sites, site sections, or groups do not actually end up using the new system, or using it in a way that is conducive to business goals.
Although this post is mostly talking about big rollouts involving a lot of sites, the general principles are the same for single sites. If people don’t buy into the structure you create, then they will find ways around it, which will reduce the impact of your implementation significantly.
"Build it and they will come" is not effective
One of the most common mistakes I see is organizations taking a “build it and they will come” attitude to complex digital presence rollouts. This may have worked in the movie Field of Dreams, but it's not the best way to do things for complex digital presences. Often the approach is to build the main corporate site and then expect other sites to magically follow suit.
In this model, the various stakeholders are not meaningfully involved in discussions about what the new digital presence will do, and only receive an announcement that the tool is ready and some vague description of the end state. Two things happen that feed on each other: 1) people don't come into the new system while at the same time 2) the presence ends up being something of Frankenstein's monster, with the various slices of the digital presence not being well connected or effective.
Fundamentally, just building a platform does not mean people will use it. And digital presences—whether it’s an intranet, extranet, or external web suite of sites—require internal participation to make it work.
An example: a global rollout
Let’s say you are rolling out a new global web presence, with dozens of country sites and a main corporate site. You could concentrate on the main corporate site for the initial launch, and then expect the countries to use the same templates as the corporate. This does not work well for a variety of reasons including:
Aside from at the most trivial level, the corporate site probably has entirely different requirements than country sites.
The mere fact that the country site owners were not consulted is an issue on its own — this can lead to resentment.
Related to the above two items, the most sophisticated country groups (perhaps those with the most business for your organization) will have probably already developed sophisticated functionality. You need to decide what to do with those early; otherwise, those groups that you most want in the new platform may have the most ammunition to stay out of it.
When the rollout is not planned, and for example when some sophisticated country groups do not move in, the resulting global site is perhaps worse (for example, setting the false expectation that the "news from around the world" includes the most prominent country operating units for your business) than if every country had just done their own thing.
Often the flow of information is key, and in particular the information to/from country sites and the corporate site. Implementing things in the wrong order, or without considering the overall structure well, can mean that you have to rework content and/or the system.
By building first, it overlooks the opportunity to face political and broad issues head-on, and instead probably just kicks that can down further down the road.
Key problems with the "build it and they will come" approach
Global web rollouts are just an example of where the “build it and they will come” approach is a problem. In general, some problems with building (especially with an example site rather than concentrating on core functionality) and then expecting blanket participation are:
They oversimplify the solution (make it simpler to implement the first site, more difficult to initially implement the following sites, and then more difficult to maintain over time)
They do not respect the need to get buy-in.
They are inefficient.
They overlook opportunities to reframe the problem for higher impact.
It postpones real, needed business decisions
They overlook the opportunity for stronger ongoing improvements.
A better approach
So what is the alternative to the “build it and they will come” model? Set the vision, build the core functionality, and snowball rollout:
Set the vision (including getting buy-in) and strategy early. Note that here we aren't just talking about open-ended discussions, but framing the vision that everyone understands and most stakeholders find compelling. In particular, the pros and cons of the approach are clearly understood, and the key desired outcomes are prioritized (and some things will not be implemented).
Build the core features, that flow out of the vision. The core features might be flexible yet regulated templating that all sites will use, content modeling, a core taxonomy, standing up new authoritative systems or better integrating with existing systems for different types of content, or setting up better ways of teams working together. For instance, if content sharing across the globe is important than that should be architected from the start. I often refer to this as getting the bones right (rather than just concentrating on the skin of the site).
Define the rollout (including sequencing), and only then implement. This ideally snowballs so that stakeholders become more and more interested in participating as time goes on.
