Content Strategy – Frequency of Change
Your content strategy is affected greatly by your frequency of change. Static policies that only get updated once a year are pretty simple to maintain. But when you have a manual of, say, 100 procedures, and 3 of them change in any given week, and another 20 change monthly, and half of them need to be reviewed quarterly, keeping up with them can be a challenge.
Some Factors That Cause Change
Knowing why things change can give you insight into the ways you can mitigate or plan for change.
- State or local laws. Usually they’re infrequent, but the changes are material. These are the kinds of changes that are easy to miss, but with large implications.
- Immature processes. An early stage franchise system with 15 units probably changes more frequently than a mature system with 1,000 units because they have not yet perfected their processes.
- Multiple audiences. The more you personalize your content (one set for students, one for parents, one for administrators, for example), the more chance there is that something will need to change.
- Use. The more users you have, the more they use your documents, the more chance there is to notice areas of improvement. Ambiguity can be clarified. Loopholes to policies closed. Enhancements to procedures communicated.
- Multiple authors. In a distributed author environment, turnover means new people take on responsibility for their sections. New people mean new eyes, more change.
- Market forces. Especially on web sites, competitors’ price changes can lead to product responses on your side. Weather affects operations, which needs to be communicated.
- Growth. Your business plan expects your company to grow, add new users, create new products, upgrade equipment, etc. Every operational change has a commensurate document change.
Tips for Managing Change
- Schedule it. Every time you make a change, you have to communicate that change. If this happens too often, your users may tune you out so that no future changes get through to them. Make a schedule so users know what to expect.
- Challenge it. Change for the sake of change isn’t always a good thing.
- Batch it. Not all changes are mission-critical and don’t need to be real-time. Note the changes, put them into a change log, then make them all at once (according to your schedule).
- Mitigate it. The more thorough you are up front, the more precise and accurate your drafts, the less likely you’ll need to correct errors.
Change is neither good nor bad. Fixing a typo is an unforced error, but adding a process for a new product means revenue opportunities. Change happens, it just…is. Rather than fight it, plan for it and accept it.