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