Content strategy versus scope creep
Content strategy implementations require substantial planning, coordination, and hard work. The effort involved in keeping planned work moving along can be difficult. Scope creep–discovering new requirements along the way–can potentially derail your entire effort if you’re not careful.
This characterization of scope creep not only injected humor into an otherwise stressful situation, but it allowed the project team to personify and target the problem and not the people who unwittingly created it.
Scope creep can manifest in a content strategy implementation in many ways. Examples include:
- new outputs: You may have planned for PDF and HTML5, but product teams are now requiring native Android or iOS output.
- new inputs or changing technology: The data center has been quietly working on a server update, and the information delivery to your team now uses a new format or schema.
- additional stakeholders: Sales and marketing suddenly have a strong interest in (and a compelling argument for) managing content in your intended system.
- team changes: Your XSLT expert has been reassigned to a critical web project, and you have inherited another developer to fill the gap.
- changes in deadlines: Another project that some team members are also involved in now has an earlier release date. Or worse–delivery of technology that you require has been delayed, and pushing your schedule out means that your team members’ other responsibilities are now in jeopardy.
Resolving these types of issues within the scope of your implementation project is simply not possible. Addressing one problem will likely create another. For example, adding support for additional content types will likely require additional output formats and push out your deadline.
Rather than combat scope creep head on, build a strong defense against it. Fewer logistical gaps in your project limit the chances of scope creep making an appearance. You must have clear requirements and firm commitments from all involved parties up front. Detail all dependencies, and plan out alternative approaches should any of those dependencies change.
Perhaps the best defense against scope creep is the ability to say “no”. It is perfectly acceptable to push back on new requirements and to deny other changes once your project is underway. However… you must have a strong business case and must plan your project accordingly from the beginning and obtain full agreement on the planned project scope first. Leave no stone unturned as you engage others in your organization during the discovery phase of your content strategy.
Fewer unknowns create fewer logistical gaps in your content strategy, and thus fewer opportunities for scope creep infiltration.
I like the “say no” method, but you are right, Bill, we need a strong understanding of the requirements before the begin. Maybe we could have the customer sign a scope document or something similar. This will make them less likely to object to our “no.” Have you ever done that yourself?
Hi Pawel. Yes, scoping is essential. Whether you are a consultant or an internal employee, any project needs boundaries. Before kicking off any project, you need to identify what is in and out of scope and get agreement on that scope. This makes it much easier to say “no” to requests that are out of scope.