Slides from my tcworld 2015 talk about avoiding content management failures‚ or turning things around if your project's in danger of failing. Video of the presentation at: https://www.youtube.com/watch?v=nWtDcptwY7I The abstract for the talk: Many content management implementations encounter obstacles at some point. Some end as disasters. Others limp along, never quite realizing the promised benefits. However, failure is not inevitable. With teamwork and the right approach, existing projects can be turned around, and new projects can be launched in the right direction. Using real-life examples, experience, and research, this presentation provides five activities that, combined, give content management initiatives the impetus and guidance to reach their destinations safely.

1. Steering content
management projects
away from the rocks
Joe Pairman

2. Implemented DITA:
bus. case, info model, CCMS,
training, platform design…
Consulting & coaching:
structured content & IA
About me

3. A CM disaster

4. KPMG: IT project
management survey
In 12 months, 49% had
suffered a recent project
failure
Geneca: interviews
with 600 people in
software dev.
75% of project participants
lacked confidence that their
projects would succeed.
IT failures: typical stats

5. Content management
implementation failures
Industry statistics suggest that the odds of a successful project
are dismal at best.
– Lane Severson, Doculabs
50% or more CMS projects “fail” in some way:
botched implementations, soaring project costs, launch delays,
ruined SEO, and more…
– “The CMS Myth” blog

6. Kappelman’s 12 early
warnings of project failure
PEOPLE
Lack of top management support
Weak project manager
No stakeholder involvement
Weak commitment of project team
Team members lack knowledge
Subject matter experts are overscheduled

7. Kappelman’s 12 early
warnings of project failure
PEOPLE
Lack of top management support
Weak project manager
No stakeholder involvement
Weak commitment of project team
Team members lack knowledge
Subject matter experts are overscheduled
PROCESS
Lack of documented reqs
No change control process (change management)
Ineffective schedule management
Communication breakdown among stakeholders
Resources assigned to a higher priority project
No business case for the project

8. Kappelman’s 12 early
warnings of project failure
PEOPLE
Lack of top management support
Weak project manager
No stakeholder involvement
Weak commitment of project team
Team members lack knowledge
Subject matter experts are overscheduled
PROCESS
Lack of documented reqs
No change control process (change management)
Ineffective schedule management
Communication breakdown among stakeholders
Resources assigned to a higher priority project
No business case for the project
Even the
process-
related EWs
are mostly
about people

9. Five critical factors
People
Ownership
Building support
Process
Observation
Exploration
Standards

10. Ownership

11. Can you just do all our content management for us?
v.s.
Ownership

12. CM turnaround due to
solid ownership

13. The CM ship needs
several crew to steer it

14. Building support

15. Risk: unrealistic goals due
to lack of knowledge
“It has ‘CMS’ in the name, so it can replace
Sharepoint or deliver web content”
“It’s built on a database, so it can manage our
parts list and BOM”

16. • Waning enthusiasm
• Other projects take priority
• New people come on board, wanting a
clean sweep
Risk: lack of support when
things get tough

17. Effective training/orientation
at outset
Chief&exec&/&
VP&
Director&
Key&
stakeholder/
par8cipant&
Key&
stakeholder/
par8cipant&
Director&
Project&
captain&

18. Chief&exec&/&
VP&
Director&
Key&
stakeholder/
par8cipant&
Key&
stakeholder/
par8cipant&
Director&
Project&
captain&
• Keep all training contextually relevant
• Focus on enabling decisions
Effective training/
orientation at outset

19. Gathering feedback, and
listening to it
Chief exec /
VP
Director
Key
stakeholder/
par8cipant
Key
stakeholder/
par8cipant
Director
Project
captain

20. Don’t stop communicating!
Chief exec /
VP
Director
Key
stakeholder/
par8cipant
Key
stakeholder/
par8cipant
Director
Project
captain

21. Observation

22. The trouble with
(many) requirements
Mixing domains Authors must be able to add tables with
set templates in a responsive design
Utterly vague The solution must have built-in reporting
features
Assuming
implementation
details
The source document has to be
authored in one file to ensure
consistency

23. Consequences of bad
requirements
• Over-specced system (reducing budget for other important
work)
OR
• Co-opting a tool that’s designed for a different purpose
• Onerous workflows
• Attribute values and arbitrary markup details to remember
and enter manually
• Barely presentable outputs

24. Towards a better way:
from use cases…

25. …to user stories

26. More trouble with
requirements: assumptions
“…a [complex] new content management
system will simplify and speed up our content
production”

27. Can you do more with the
tools you’ve got?

28. Can you do more with the
tools you’ve got?
If considering a large revamp, consider first improving what you
have:
• Topic structures in Word/FM/ID templates?
• Use basic tools for authoring, version control, publishing
• Static site builder tech? (Jekyll / Pelican, etc.)

29. Can you do more with the
tools you’ve got?
If considering a large revamp, consider first improving what you
have:
• Topic structures in Word/FM/ID templates?
• Use basic tools for authoring, version control, publishing
• Static site builder tech? (Jekyll / Pelican, etc.)
If a big solution has been implemented, don’t chuck it out
(straightaway)
• What knowledge and skills have been gained?
• What can the tool usefully do (even if not up to original goals)?

30. Mekon process:
first stage
overcomes
assumptions

31. Exploration

32. Modern PM styles:
Chances to try things out
0% 20% 40% 60% 80% 100%
Traditional
Ad-Hoc
Agile
Iterative
Lean
Successful Challenged Failed

33. How to apply to big
CM implementations?
0% 20% 40% 60% 80% 100%
Traditional
Ad-Hoc
Agile
Iterative
Lean
Successful Challenged Failed
€$£

34. Test system with user stories

35. Do small proofs of concept
(even for process changes)

36. Do a pilot project

37. Do an big pilot project,
if you can

38. Standards

39. Risks of no standards
Everyone doing things differently:
• Different tool configurations
• Inconsistent naming
• Different structures (element sequences)
• Arbitrary reuse
• Cloning documents/topics for any reason

40. Everyone doing things differently:
• Different tool configurations
• Inconsistent naming
• Different structures (element sequences)
• Arbitrary reuse
• Cloning documents/topics for any reason
Weakens all the benefits of content management: it’s expensive
and quality suffers
Risks of no standards

41. Setting standards
Centralized tool deployment
Naming conventions
Clear document structures/
topic types
Agreement on what can be
reused and how

42. Setting standards
Centralized tool deployment
Naming conventions
Clear document structures/
topic types
Agreement on what can be
reused and how
Flow chart / decision tree for
reuse decisions

43. Supporting standards
Support consistency with:
• Cleanup of existing content
(automated where possible)
• Name placeholders to type over?
• Pick lists for metadata

44. Supporting standards
Support consistency with:
• Cleanup of existing content
(automated where possible)
• Name placeholders to type over?
• Pick lists for metadata
• Just enough workflow. But make it visible!

45. Supporting standards
Support consistency with:
• Cleanup of existing content
(automated where possible)
• Name placeholders to type over?
• Pick lists for metadata
• Just enough workflow. But make it visible!
• Structure constraints and templates

46. Supporting standards
Support consistency with:
• Cleanup of existing content
(automated where possible)
• Name placeholders to type over?
• Pick lists for metadata
• Just enough workflow. But make it visible!
• Structure constraints and templates
• Visual indicators on reusable content

47. Monitoring standards
Foster small-group leaders
Reward suggestions for improvements to standards
• Visual recognition for a start
• Perhaps small material rewards such as vouchers
Meet regularly
Deliver quick actions on suggestions, or clear reasons not to
implement them

48. Harmonious cycle

49. Observa(on
Explora(on
Standards
Ownership.
Support.
Harmonious cycle