This document summarizes common website project blunders and how to avoid them. It discusses classic blunders like lacking a business case, having unrealistic expectations, and an insufficient schedule. It also covers blunders like absent leadership, communication breakdowns, and ignoring risks. The document recommends following a defined process with stakeholder involvement, user research, and aligning the project with organizational goals and available resources. It provides an overview of a project process including definition, discovery and planning, production, and post-launch phases. The goal is to help people avoid blunders that can doom website projects from the start.

1. BADCamp 2020:
Classic Website Blunders
October 16, 2020
1

2. Overview
● Intro
● Blunders
● Avoiding blunders
● Process
● Conclusion
2

3. Intro
3

4. Stephen Pashby
4
● DesignHammer Account Manager
● Over nine years experience
● Involved in dozens of Web projects

5. “Impressive Project Management Statistics”
● Most organizations have a 70% project failure rate
● On average, projects go over budget by 27% of their intended cost
● 55% of project managers cited budget overrun as a reason for project failure
● Only 64% of projects meet their goals
● 78% reported that their business was not aligned with project goals
● 75% believe their projects are always or usually slated to fail from the beginning
Source: https://learn.g2.com/project-management-statistics
5

6. 6
Why not? How
hard could it be?
Should we build
a new website?

7. Our story includes…
● Fencing
● Fighting
● Torture
● Revenge
● Giants
● Monsters
● Chases
● Escapes
● True love
● Miracles
7

8. 8
Fezzik: Why do you wear a mask? Were you burned by
acid, or something like that?
Man in Black: Oh no, it’s just that they’re terribly
comfortable. I think everyone will be wearing them in the
future.

9. Blunders: classic or otherwise
9

10. 10
Classic blunders

11. Classic blunders
● The most famous is “Never get involved in a land war in Asia.”
● But only slightly less well known is this: “Never go in against a Sicilian when death is on the line.”
Source: Vizzini, The Sicilian
11

12. 12
Lack of business case

13. Lack of business case
● Blunder: Project lacks a use case or business need
● Risk: Project is a waste of time and money
● When: Project is typically doomed from the start
● Why: There needs to be a reason
● Fix: Identify organizational goals, and determine how the project aligns before investing time
13

14. 14
Unrealistic expectations

15. Unrealistic expectations
● Blunder: Resources (time and money) are always constrained, be reasonable in what can be done
● Risk: Project doesn’t start, project isn’t completed, feature creep
● When: Any time, but typically during Project Definition or Planning
● Why: Compromise and reasonable expectation increase likelihood of success
● Fix: Look at projects that have similar budgets and schedules. Don’t look at groups orders of
magnitude larger to set project requirements
15

16. 16
Insufficient schedule

17. Insufficient schedule
● Blunder: Not allowing enough calendar time to successfully complete the project
● Risk: Project will be late or fail (if a hard deadline)
● When: Project is typically doomed from the start
● Why: Complex systems with interdependent parts take time (see Man Month Myth)
● Fix: Involve leadership in setting project goals and metrics of success and at key approval stages
17

18. 18
Absent or
uninvolved leadership

19. Absent or uninvolved leadership
● Blunder: Inadequate access to stakeholders/leadership during project
● Risk: Lack of leadership involvement at critical stages can lead to rejection of the entire project
● When: Project Definition, Discovery and Planning or Production
● Why: Leadership input and critical for project to align with organizational goals
● Fix: Involve leadership in setting project goals and metrics of success and at key approval stages
19

20. 20
Junior project manager

21. Junior project manager
● Blunder: Junior staff member tasted with managing project
● Risk: Lacks authority to make decisions, or require staff to provide support
● When: Generally doomed from the start
● Why: Project manager needs either authority to make decisions/assign staff to tasks
● Fix: Senior staff need to be responsible to maximize efficiency. Senior support of junior project
manager can work, but usually takes longer, and more prone to error.
21

22. 22
Communication
breakdown

23. Communication breakdown
● Blunder: Irregular meetings, inadequate documentation
● Risk: Misunderstandings will cause work to need to be redone
● When: Any stage
● Why: Documentation will avoid errors, and provide reminders of why decisions were made
● Fix: Regular meetings with notes circulated, approved, and accessible afterwards, documented
approval steps
23

24. 24
Design by committee

25. Design by committee
● Blunder: Too many people involved in decision making
● Risk: Project will be late and over budget, not really satisfy anyone
● When: Production, but stage is set in Planning
● Why: “Too many cooks spoil the soup”
● Fix: Rely on a small group of decision makers, ideally with one who can make ultimate decisions
25

26. 26
Vanishing volunteers

27. Vanishing volunteers
● Blunder: Entrusting mission critical tasks to volunteers that may leave at anytime
● Risk: May not complete tasks, or may disappear when support is necessary
● When: Production or Support
● Why: You get what you pay for
● Fix: Avoid a single point of failure, particularly in mission critical systems
27

28. 28
Blinded by buzzwords

29. Blinded by buzzword
● Blunder: Becoming distracted from your core goals by the latest web fad or bleeding edge
technology
● Risk: May increase project cost or complexity without delivering a compelling ROI
● When: Discovery and Planning
● Why: Just because you can do something, doesn’t mean you should
● Fix: Focus on the project goals and allow these to guide design and technology choices
29

30. 30
Ignoring risks

31. Ignoring risks
● Blunder: Failing to identify project risks and discuss mitigation
● Risk: Project failure due to everything not going as planned
● When: Project Definition, Discovery and Planning or Production
● Why: The unexpected (or inconceivable) frequently happens
● Fix: Identify potential risks and determine appropriate mitigations should the risks manifest
31

32. Avoiding blunders
32

33. Avoiding blunders
● Enure project aligns with organizational goals
● Align expectations with available resources
● Involve appropriate stakeholders to provide input, feedback, and approval
● Get feedback from potential users through surveys or user testing
● Follow an appropriate process including communication, feedback, and approvals
33

34. 34
Align with
organizational goals
“I’ve hired you to help me start a war. It's a
prestigious line of work with a long and
glorious tradition.” — Vizzini

35. Align with organizational goals
● How does this project fit in with the organization’s mission and vision?
● Core organizational focus?
● Discrete tactical initiative?
● Vanity project/boondoggle?
● Understanding this can guide appropriate scope and resourcing
35

36. 36
Match expectations
with resources
Westley: I mean, if we only had a
wheelbarrow, that would be something.
Inigo Montoya: Where we did we put that
wheelbarrow the albino had?

37. Match expectations with resources
● A well-resourced project that delivers a core organizational focus can realistically have one type of
expectations
● A department project resourced with chewing gum and bailing wire should realistically have much
more modest expectations
● If you are not investing the resources of Apple, should you expect Apple levels of polish?
● “Get used to disappointment.”
37

38. 38
Stakeholder
involvement
Fezzik: EVERYBODY MOVE!
Inigo Montoya: Thank you.

39. Stakeholder involvement
● Line up the stakeholders you need to have involved, to make sure the right people weigh in
throughout the process, including:
● Technical requirements
● Information architecture
● Design
● User acceptance testing
● Final sign-off
● Involved the right people at the right time can help keep your project on schedule and minimize
costly re-work
39

40. 40
User surveys & user
testing
“What did this do to you? Tell me. And
remember, this is for posterity, so be
honest — how do you feel?”
— Count Rugen

41. User surveys & user testing
● Ultimately, whether users can find your website useful and compelling will determine your success
or failure
● Engaging with your users to learn how they will interact with your content and functionality can
help you avoid blunders
● Common user testing tools include:
● User Surveys
● Card Sorts
● Tree Testing
● Usability Testing
41

42. 42
Follow an appropriate
process
“I just figured why you give me so much trouble.”
“Well, I haven't fought one person for so long. I've
been specialized in groups, battling gangs for local
charities, that kind of thing.”
“You use different moves when you're fighting half a
dozen people, than when you only have to be
worried about one”
“ZZZZZZZZ”
— Fezzik

43. Follow an appropriate process
● Following an appropriate process will help you avoid many blunders
● Making sure you have the right sign-off from the right stakeholders can help with questions later
when busy stakeholders do not remember what they approved
● Documentation can help you remember not only what you and your team decided, but why it was
decided
● Best practices for development can simplify maintenance and reduce the cost of future
development
43

44. Process
44

45. Process overview
● Project Definition/Resourcing
● Discovery & Planning
● Production
● Post-Launch
45

46. 46
Project
definition/resourcing
“My brains, his steel, and your strength against
sixty men, and you think a little head jiggle is
supposed to make me happy? I mean, if we only
had a wheelbarrow, that would be something.”
— Westley

47. Project definition/resourcing
● Define what is the organization going to do and why
● Determine who will be involved (staff, stakeholders, & volunteers)
● Allocate appropriate resources (calendar, budget, and/or staff time)
● Select and hire outside resources, if appropriate
47

48. 48
Discovery & planning
“I always think that everything could
be a trap, which is why I’m still alive”
— Prince Humperdinck

49. Discovery & planning
● Document project goals, intended audiences, and metrics of success
● Determine content strategy and organization
● Identify specific technology implementations
49

50. 50
Production
“Don’t rush me, sonny. You rush a
miracle man, you get rotten miracles.”
— Miracle Max

51. Production
● Design process
● Development
● Content migration
● Testing
51

52. 52
Post-launch
“I have been in the revenge business so
long, now that it’s over, I don’t know
what to do with the rest of my life.”
— Inigo Montoya

53. Post-launch
● On-going maintenance
● Content updates
● New feature development
53

54. Conclusion
54

55. Conclusion
● Use a process
● Avoid blunders that doom a project from the start
● Mitigate the effects of blunders that kill potentially successful projects
55

56. 56
Thank you
BADCamp 2020!

57. BADCamp 2020
Coming up next
Friday 11 am
● Accessible SVGs: Inclusiveness Beyond Patterns with
Carie Fisher
● Decoupling Drupal: Gatsby Live Preview from the
same project with Chad Carlson
● Making a better community, better software, and a
better world with Tara King, Ruby Sinreich, and Elli
Lugwigson

58. BADCamp 2020
Coming up next
Friday 10:45 am ● Coffee Break with amazee.io in the Expo Hall