The content management implementation failure rate is higher than it should be, and projects seem to fail for the same cluster of reasons: unrealistic requirements, expectations, human factors, etc. In this session, Deane will discuss the major reasons for project failure learned through almost two decades of implementation experience, and discuss strategies and policies to put in place at each stage of the project to prevent them.
8. How Projects Fail
• Abortive
Fails to launch
• Quantitative
Fails to make project numbers
• ROI / Goals
Doesn’t bring about desired change
• Expectations
“It just doesn’t feel like I thought it would.”
11. You know what you’re doing.
You have a very limited and
slanted view of what other people
are actually doing.
12. Case Study Syndrome
• “I read this in a case study, so clearly
everyone is doing it.”
• People don’t produce case studies about
things that didn’t happen.
• Form of Survivor Bias.
13. No one writes case studies about
the 99% of companies that aren’t
doing anything interesting.
14.
15. “The Law of Narrative Gravity posits that
the public and press are drawn to
narratives, and the more widely accepted a
narrative, the more it attracts and shapes
the perception of facts.”
− Aaron Zamost for
BackChannel
16.
17.
18. Case Study Syndrome is the sum
total of all the things you’re
convinced you should be doing.
19. Doesn’t fit your market.
Not enough staff.
Not the right skills.
You probably have bigger
problems.
20. Case Study Syndrome steals
attention away from more critical
problems that you can actually
solve.
23. Building a New Home
• Deciding to move
• Developing floor plans
• Buying a lot
• Budgeting for construction
• Apply for financing
• Preparing to move
• Actually moving
• Redecorating
• Buying new stuff
• Learning how to use new
stuff
• Planning new services
• Planning new commute
• Changing vehicles
• Changing schools
• Sending address changes
• Throwing a house-
warming party
Transitioning to a New Home
24. We tend to focus on what we think
is (1) novel or (2) risky.
25. Training / Re training
Migration
Internal Marketing / Reporting
Governance
Infrastructure
39. The Truth
• There’s a good chance significant parts of our problem
originated external to technology
• We tend not to look to people, governance, or process,
because these things exist now
• If problems could been fixed without new
technology…why weren’t they?
• It’s easy to say, “things will be better when we have
new technology because we’ll have something we
don’t have now.”
40.
41. Software is one aspect of a
content environment, and it’s
rarely the most important one.
46. Things that leave on Day 2…
• Your budget
• Your staff
• Your contractors
• The attention of the C-level
• Any sense of urgency
• Your enthusiasm
• Your job?
47. Many projects never make the leap
from project to product.
In reality, the only time a website
is “done” is when it’s permanently
removed from the Internet.
48. Launch day is not the finish line.
It’s the starting line.
49. 1. Case Study Syndrome
2. Development Myopia
3. Control Fixation
4. Deus Ex Machina
5. Big Bang Syndrome
54. Stop trying to solve Problem B
before you’ve solved Problem A.
55. Questions to Ask:
Content Strategy
• Do you know who your audiences are?
• Do you know what they want from your
organization?
• Not your website; your organization
• Do you know how they try to get it from your
website?
• Do you have content to fill those needs?
57. Questions to Ask:
Content Management
• Can your editors publish a page of content
according to their own standards of quality?
• Can your editors aggregate content according
to their own needs?
• Can they collaborate as a team to their level
of satisfaction?
• Can they do this without unreasonable
frustration?
58. Questions to Ask:
Governance and Stakeholders
• Who is your ultimate stakeholder?
• What is their model of success?
• Are they comparing this project to others?
• (Spoiler: yes)
• Which projects, and what about those
projects makes them a model of success?
59. “Six months after this project
launches, what needs to happen
for us to think that it was all worth
it?”
60. We’re so determined to be
amazing that we don’t stop to
check that we’re any good.
67. Pretend that the actual build is
guaranteed.
What else do you have to do?
68. Start: “Hey, maybe we should do
something about the website…”
(time passes…)
Start: Development Begins
End: Website Launches
(time passes…)
End: “Hey, aren’t you glad we did
something about the website?”
72. Perfect is the enemy of good
“Return on Management” is a
perfectly valid decision factor.
73. Factors to Determine ROM
• Frequency of the situation addressed
• How often does it occur?
• Lead time of the situation addressed
• How far will we be able to see it coming?
• Post-launch proximity to the people who can
address it
• Can we reasonably code-source something to
save budget?
83. The Sad Truth: Some things just
won’t work…
• It won’t fit your content/marketing model
• You won’t be able to staff it
• Existing staff will turnover
• A “feature champion” might leave
• Your plans will change over time
• It may have just been a bad idea
84. You need to indoctrinate your
organization to incrementalism.
If you don’t like something, just
wait a minute…
85. “We’re programmers. Programmers are, in
their hearts, architects, and the first thing
they want to do when they get to a site is
to bulldoze the place flat and build
something grand. We’re not excited by
incremental renovation: tinkering,
improving, planting flower beds.”
− Joel Spolsky
86.
87. “I was drawn to medicine by the aura of
heroism—by the chance to charge in and
solve a dangerous problem.”
− Atul Gawande
88. “Success is not about the episodic,
momentary victories. It is about the longer
view of incremental steps that produce
sustained progress.”
− Atul Gawande
91. 1. Put first things first
2. Plan from true beginning to true ending
3. Keep rough edges in context
4. Don’t confuse means and ends
5. Set the stage for incremental improvement