Uploaded byFemke Goedhart
SharePoint functionality: To Build or to Buy? Let's ask Pareto!
The document discusses whether to build or buy SharePoint functionalities, highlighting that 60% of SharePoint projects fail due to complexities and unrealistic expectations. It emphasizes the importance of starting with a problem and following a structured approach to decision-making, including evaluating requirements and customizing solutions. The analysis also reveals that 20% of the functionality typically meets 80% of user needs, suggesting a focus on core features to manage expectations and project outcomes.
More Related Content
Similar to SharePoint functionality: To Build or to Buy? Let's ask Pareto!
SharePoint functionality: To Build or to Buy? Let's ask Pareto!
- 1.
- 2. SharePoint functionality: To Buildor to Buy? Let's ask Pareto! André Krijnen @AndreKrijnen Femke Goedhart @FemkeGoedhart
- 3.
- 4. BUY OR BUILD...? Don’treinvent the wheel... 4
- 5. OR BUY ANDBUILD...? 5
- 6.
- 7.
- 8.
- 9. “Recent research reporton SharePoint found that 60% of SharePoint projects are stalled, struggling or failing” AIIM 9
- 10. Reasons for failure… •Complex • Development isn’t easy • Not a clear positioning against other software • Unfamiliarity / Lack in knowledge • Unrealistic expectations • No long-term governance • And… 10
- 11. 11 “A solution withouta problem….”
- 12.
- 13. 13 “….CRM …… custom relations” “…..trackleads and orders….” “….Quality process….” “….share project documents….”
- 14. GETTING TO THENEXT LEVEL… 14
- 15.
- 16. Only 18% ofimplementations are out-of-the-box or plain vanilla, although 40% have only “limited customization” AIIM 16
- 17.
- 18.
- 19. 19 20% customization is 80% ofthe work!
- 20. SO HOW DOYOU DECIDE? 20
- 21. Start with aproblem 21 “….Quality process….”
- 22.
- 23.
- 24. 1. OBJECTIFY Breaking itdown… 24
- 25. 25 Document Mgt Workflow •Approval cycles •Rejection procedure •…. Governance •Versioning •Retention •Archiving •… Non conformity Registration •Logging •Assigning •Overduereporting •…. …. Auditing Reporting •…. What do they mean with Quality Control?
- 26. 2. RATIONALIZE Is itreally the best way?.... 26
- 27. Is automation alwaysthe answer…? 27 Photo credit
- 28. 3. GENERALIZE Do weneed to reinvent the wheel…. 28
- 29. Are we reallyso unique? 29
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36. 36 Generalize 3 years 3 Months3 Months3 Months
- 37.
- 38. Techniques • Interviews • Focusgroups • Observation • Document studies • RFP Documents • Workshops • Questionnaires • Incident & compliance systems • Subject Matter Experts • Market research • Review of current systems • …. 38 Ask, Listen, Watch!
- 39. Methods for specification& prioritization • STARR • 5* Why - Iterative question asking • SMART • MoSCoW • Eisenhower decision matrix 39
- 40.
- 41.
- 42. SMART • Specific • What?Why? Who? Where? Which? • Measurable • How much? How many? Is it quantifiable? • Attainable • Can it be achieved with the resources & facilities available? • Relevant • Does it relate to the project vision & scope? • Timely • Can I set a date to it? 42
- 43.
- 44. Eisenhower decision matrix 44 URGENTNOT URGENT IMPORTANT NOT IMPORTANT
- 45. Eisenhower decision matrix 45 URGENTNOT URGENT IMPORTANT MUST! SHOULD NOT IMPORTANT COULD WOULD (Nice to Have)
- 46. 46 20% of yourfunctionality Will cover 80% of what your users need!
- 47.
- 48. The case • Productioncompany • 300 users • Quality Online (IBM Domino) • Microsoft 49
- 49. • Building everything •Limited time frame • Limited budget 50 Personal story
- 50. Eisenhower decision matrix 51 URGENTNOT URGENT IMPORTANT DMS Workflows Usable UI Versioning Integration w/ Office Email Templates Logging NOT IMPORTANT Non-conformities Auditing Risk Management
- 51. Option: Buy orbuild • Interface • Extensibility • Quality • Cost • Information 52
- 52. The SharePoint market •$6.44 billion worth • Apps and applications (solutions) 53
- 54. 55 20% of yourbudget Will pay for 80% of your functionality!
- 55.
- 56.
- 57.
- 58.
- 59. Don’t worry developers 60 80%of features are standard available 20% of the time development is needed
- 60. What to build •Workflows 61
- 61. 62 20% of yourcode contains 80% of the bugs!
- 62. Hofstadter’s law 63 “It alwaystakes longer then you expect. Even when you take Hofstadter’s law into account.”
- 63. LETS GET BACKTO THE BEGINNING… 65
- 64. Pareto Principle 66 80% ofthe effects come from 20% of the causes
- 65.
- 66. Expectation gap 68 Time —> Expectation gap SoftwareRequirements third edition, Karl Wiegers & Joy Beatty
- 67. 69 Time —> Expectation gap contact pointcontactpoint Software Requirements third edition, Karl Wiegers & Joy Beatty
- 68. Cost of rework •In requirements phase = *1 • In development phase = *2-3 • In production = *100 70 1x 2-3x 100x Boehm 1981; Grady 1999; Haskins 2004
- 69.
- 70.
- 71.