Talk at the 2015 Tekom Tcworld conference in Stuttgart, based on my experience and research on turning around failing information and content management projects.

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 con
fi
dence 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
fi
le 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 work
fl
ows
• 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
fi
rst 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
fi
rst 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:
fi
rst 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 con
fi
gurations
• Inconsistent naming
• Different structures (element sequences)
• Arbitrary reuse
• Cloning documents/topics for any reason

40. Everyone doing things differently:
• Different tool con
fi
gurations
• Inconsistent naming
• Different structures (element sequences)
• Arbitrary reuse
• Cloning documents/topics for any reason
Weakens all the bene
fi
ts 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

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 work
fl
ow. 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 work
fl
ow. 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 work
fl
ow. 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