- There are four types of digital presence change: streamlined, routine work program, redesign, and one-off.
- All change (streamlined, routine work program, redesign, and one-off) can lengthen or hasten the next redesign.
- There is a natural flow between the types of digital presence change.
Although we may all have a knee jerk reaction that redesigns are overused, I would propose that we dig a bit deeper. In many ways other changes are even more damaging, and at a minimum one of the reasons that we wind up needing to do redesigns more frequently is that we don't undertake other types of change well. In other words, we need to consider the other changes since they can contribute to the very thing we want to put off as long as possible: redesigns.
There are four types of digital presence change (whether the digital presence is an intranet, web presence, or extranet), broken out along two dimensions:
- Breadth of change. In other words, how much of the digital presence is being affected?
- Disruption. How much of a change is this to the site visitor?
The types of changes are:
- Streamlined. These are changes that the system (writ large, to include both technical and non-technical issues) has optimized. This hopefully allows for strong and focused content publishing for example.
- Routine work program. The routine work program makes tweaks to these systems on a regular and planned basis.
- One-offs. These are the ones that break outside the normal process (for instance microsites).
- Redesigns. These are substantial and broad changes to the site(s) as it already exists.
Note that there is a cadence to each of these quadrants:
- The streamlined activities are happening daily.
- The routine work program occurs a few times a year.
- Redesigns happen every few years or less.
- One-offs should happen as infrequently as possible.
We aspire to be on the left side of this matrix, with high quality streamlined activities such as content publishing and also making routine tweaks to the system. But in many of the discussions on this topic there is less exploration about continuing to change the underlying machinery / system methodically on an ongoing basis.
That said, where we often live is actually in the dangerous zone of one-offs. This is because we don't differentiate between what is technically fast from what should be streamlined. Also, instead of optimizing the system we already have it is easier to create one-offs.
There are several reasons why creating a series of one-offs is dangerous:
- They create a fragmented digital presence.
- They hasten the need for a redesign.
- They may redesigns (when they must happen) more difficult.
- We are tempted to applaud them.
Your implementation partners (agencies, integrators, and development shops) are usually commissioned for the more disruptive change. One of the most important reasons for early digital strategy is since implementors are usually approached for the disruptive change: you need to be lined up before undertaking these. Also, you need to make sure you have the routine work program running (or a commitment to getting there) before approaching implementors.
One way to look at this is where problems are even inserted into our system, for example when we make moves toward fragmentation. Note that all of these are ways of accelerating our path to the next redesign, and this can even happen when we are in the middle of a redesign (in other words, a redesign can hasten the approach of the next redesign, or it can do a better job of getting the bones right to push the next redesign out).
The only way for us to be able to effectively navigate these types of change is to clearly differentiate possible change from actual change. In other words, we need to create the buffer to carefully consider possible changes. Of course if something is streamlined then it (assuming it meets standards and will keep the digital presence focused) should be done rapidly. But otherwise the requested changes should be held for consideration in the regular work program. This step is often skipped, where teams are reduced to in effect taking orders from the various site owners.
So the ideal flow goes something like this:
- A request for change comes in.
- If the change is routine and meets standards, then do it quickly (of course, if it's self-service then 1 & 2 are one step).
- If we can make meaningful change in the next regularly-scheduled work program (let's say the next quarter's work program) then do it. Of course one of the advantages of this approach is that it encourages creative thinking to try to come up with an approach that can make meaningful change (as oppossed to a grander, more disruptive change).
- Those that don't make it into the next work progam are put into a holding tank. Note that some items may never be implemented. Also, you may reach a point where the only way to really staisfy the requests / meet business needs is to redesign.
- If the only reasonable approach is a radical, pervasive, and broad change, then wait for a redesign.
- We mostly want to avoid one-offs. There may be cases where this is appropriate, but it should still follow through this flow regardless.