Classic Website Blunders
0 likes247 views
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.
Classic Website Blunders
- 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
- 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
- 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
- 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
- 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