10 Classic Website Blunders
0 likes•121 views
The NCTech4Good meetup discusses common website project blunders, emphasizing statistics on project failure and strategies for avoiding these pitfalls. Key issues include misaligned organizational goals, unrealistic expectations, insufficient scheduling, and lack of leadership involvement. The document advocates for a structured process that encompasses project definition, planning, production, and post-launch maintenance to ensure success.
10 Classic Website Blunders
- 1. NCTech4Good Meetup: Classic Website Blunders September 18, 2019 1
- 2. Overview ● Intro ● Blunders ● Avoiding blunders ● Process ● Conclusion 2
- 3. Intro 3
- 4. David Minton 4 ● DesignHammer founding partner ● Over twenty years experience ● Involved in over 200 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. Blunders: classic or otherwise 8
- 10. 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 10
- 12. Field of dreams ● 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 12
- 14. 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 14
- 16. 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 16
- 18. 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 18
- 20. 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. 20
- 22. 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 22
- 24. 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 24
- 26. 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 26
- 28. 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 28
- 29. Process 29
- 30. Process Overview ● Project Definition/Resourcing ● Discovery & Planning ● Production ● Post-Launch 30
- 31. 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 31
- 32. Discovery & Planning ● Document project goals, intended audiences, and metrics of success ● Determine content strategy and organization ● Identify specific technology implementations 32
- 33. Production ● Design process ● Development ● Content migration ● Testing 33
- 34. Post-Launch ● On-going maintenance ● Content updates ● New feature development 34
- 35. Conclusion 35
- 36. Conclusion ● Use a process ● Avoid blunders that doom a project from the start ● Mitigate the effects of blunders that kill potentially successful projects 36