steering content management projects away from the rocks

49
Steering content management projects away from the rocks Joe Pairman

Upload: joe-pairman

Post on 16-Apr-2017

90 views

Category:

Technology


1 download

TRANSCRIPT

Steering content management projects away from the rocks

Joe Pairman

Implemented DITA: bus. case, info model, CCMS, training, platform design…

Consulting & coaching: structured content & IA

About me

A CM disaster

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

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

Kappelman’s 12 early warnings of project failure

PEOPLELack of top management supportWeak project managerNo stakeholder involvementWeak commitment of project team Team members lack knowledge Subject matter experts are overscheduled

Kappelman’s 12 early warnings of project failure

PEOPLELack of top management supportWeak project managerNo stakeholder involvementWeak commitment of project team Team members lack knowledge Subject matter experts are overscheduledPROCESS Lack of documented reqsNo change control process (change management)Ineffective schedule management Communication breakdown among stakeholders Resources assigned to a higher priority projectNo business case for the project

Kappelman’s 12 early warnings of project failure

PEOPLELack of top management supportWeak project managerNo stakeholder involvementWeak commitment of project team Team members lack knowledge Subject matter experts are overscheduledPROCESS Lack of documented reqsNo change control process (change management) Ineffective schedule management Communication breakdown among stakeholders Resources assigned to a higher priority projectNo business case for the project

Even the process-

related EWs are mostly

about people

Five critical factors

People

Ownership

Building support

Process

Observation

Exploration

Standards

Ownership

Can you just do all our content management for us?

v.s.

Ownership

CM turnaround due to solid ownership

The CM ship needs several crew to steer it

Building support

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”

• Waning enthusiasm

• Other projects take priority

• New people come on board, wanting a clean sweep

Risk: lack of support when things get tough

Effective training/orientation at outset

Chief&exec&/&VP&

Director&

Key&stakeholder/par8cipant&

Key&stakeholder/par8cipant&

Director&

Project&captain&

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

Gathering feedback, and listening to it

Chiefexec/VP

Director

Keystakeholder/par8cipant

Keystakeholder/par8cipant

Director

Projectcaptain

Don’t stop communicating!

Chiefexec/VP

Director

Keystakeholder/par8cipant

Keystakeholder/par8cipant

Director

Projectcaptain

Observation

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

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

Towards a better way: from use cases…

…to user stories

More trouble with requirements: assumptions

“…a [complex] new content management system will simplify and speed up our content

production”

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

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.)

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)?

Mekon process: first stage overcomes assumptions

Exploration

Modern PM styles: Chances to try things out

0% 20% 40% 60% 80% 100%

Traditional

Ad-Hoc

Agile

Iterative

Lean

Successful Challenged Failed

How to apply to big CM implementations?

0% 20% 40% 60% 80% 100%

Traditional

Ad-Hoc

Agile

Iterative

Lean

Successful Challenged Failed

€$£

Test system with user stories

Do small proofs of concept (even for process changes)

Do a pilot project

Do an big pilot project, if you can

Standards

Risks of no standardsEveryone doing things differently:

• Different tool configurations

• Inconsistent naming

• Different structures (element sequences)

• Arbitrary reuse

• Cloning documents/topics for any reason

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

Setting standards

Centralized tool deployment

Naming conventions

Clear document structures/topic types

Agreement on what can be reused and how

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

Supporting standards

Support consistency with:

• Cleanup of existing content (automated where possible)

• Name placeholders to type over?

• Pick lists for metadata

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!

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

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

Monitoring standardsFoster 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

Harmonious cycle

Observa(on

Explora(on

Standards

Ownership.Support.

Harmonious cycle