SharePoint functionality: To Build or to Buy? Let's ask Pareto!
SharePoint functionality: To Build or to Buy? Let's ask Pareto!
SharePoint is the complete solution for collaboration, document management and sharing knowledge across our organisation, and even beyond. It will drive our business!" For the last ten years it was this that message IT-departments used to get budget-approval to implement the platform we all know and love (and yes, sometimes hate). The reality is though that lots of companies struggle to get beyond using it as an intranet or document file storage. What happened to our promise to cover not just the 'sharing' and 'storage' part but really enhance our business processes with specific functionality tailored to the collaborative working? Like HR who needs functionality to support annual reviews, quality control who wants to monitor key performance indicators or the support departments who want to gauge customer satisfaction? "No problem!", most IT departments standard Pavlov reaction to these request was: "we'll build it ...!" But that takes lots of time, money and can cause massive delays which often also begs the question: isn't there another way? Aren't we inventing the wheel when others surely have already done so? In this session Femke Goedhart and André Krijnen will discuss the intricacies and challenges of deciding when to make a standard solution fit (non-standard) business requirements and when to build your own. Taking you from how to handle the familiar "but that won't fit OUR organization!" arguments to figuring out the pragmatic factors that are really important in taking such a decision. To show you how, we will take several real-life customer scenarios through a decision matrix based on the 80/20 principle of Vilfredo Pareto that can help you determine whether to go 'Build' or 'Buy and Extend'. It will give you handles and tips on how to guide a decision process that is often difficult and can touch nerves but that, in the long run, can help you really fulfill that initial goal: creating a true collaboration platform.
Recommended
More Related Content
What's hot
What's hot(19)
Similar to SharePoint functionality: To Build or to Buy? Let's ask Pareto!
Similar to SharePoint functionality: To Build or to Buy? Let's ask Pareto!(20)
More from Femke Goedhart
More from Femke Goedhart(20)
Recently uploaded
Recently uploaded(20)
SharePoint functionality: To Build or to Buy? Let's ask Pareto!
- 1. 1
- 2. SharePoint functionality: To Build or to Buy? Let's ask Pareto! André Krijnen @AndreKrijnen Femke Goedhart @FemkeGoedhart
- 4. BUY OR BUILD...? Don’t reinvent the wheel... 4
- 5. OR BUY AND BUILD...? 5
- 6. 6
- 7. 7
- 8. 8
- 9. “Recent research report on 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 without a problem….”
- 12. 12
- 13. 13 “….CRM …… custom relations” “…..track leads and orders….” “….Quality process….” “….share project documents….”
- 14. GETTING TO THE NEXT LEVEL… 14
- 16. Only 18% of implementations are out-of-the-box or plain vanilla, although 40% have only “limited customization” AIIM 16
- 19. 19 20% customization is 80% of the work!
- 20. SO HOW DO YOU DECIDE? 20
- 21. Start with a problem 21 “….Quality process….”
- 22. 22 Constraints!
- 24. 1. OBJECTIFY Breaking it down… 24
- 25. 25 Document Mgt Workflow •Approval cycles •Rejection procedure •…. Governance •Versioning •Retention •Archiving •… Non conformity Registration •Logging •Assigning •Overdue reporting •…. …. Auditing Reporting •…. What do they mean with Quality Control?
- 26. 2. RATIONALIZE Is it really the best way?.... 26
- 27. Is automation always the answer…? 27 Photo credit
- 28. 3. GENERALIZE Do we need to reinvent the wheel…. 28
- 29. Are we really so unique? 29
- 31. 31 Constraints!
- 32. 32 ? Request
- 36. 36 Generalize 3 years 3 Months 3 Months3 Months
- 38. Techniques • Interviews • Focus groups • 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
- 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
- 44. Eisenhower decision matrix 44 URGENT NOT URGENT IMPORTANT NOT IMPORTANT
- 45. Eisenhower decision matrix 45 URGENT NOT URGENT IMPORTANT MUST! SHOULD NOT IMPORTANT COULD WOULD (Nice to Have)
- 46. 46 20% of your functionality Will cover 80% of what your users need!
- 47. THE REALITY… 47
- 48. The case • Production company • 300 users • Quality Online (IBM Domino) • Microsoft 49
- 49. • Building everything • Limited time frame • Limited budget 50 Personal story
- 50. Eisenhower decision matrix 51 URGENT NOT URGENT IMPORTANT DMS Workflows Usable UI Versioning Integration w/ Office Email Templates Logging NOT IMPORTANT Non-conformities Auditing Risk Management
- 51. Option: Buy or build • Interface • Extensibility • Quality • Cost • Information 52
- 52. The SharePoint market • $6.44 billion worth • Apps and applications (solutions) 53
- 54. 55 20% of your budget Will pay for 80% of your functionality!
- 55. 56
- 56. 57
- 57. 58
- 58. 59
- 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 your code contains 80% of the bugs!
- 62. Hofstadter’s law 63 “It always takes longer then you expect. Even when you take Hofstadter’s law into account.”
- 63. LETS GET BACK TO THE BEGINNING… 65
- 64. Pareto Principle 66 80% of the effects come from 20% of the causes
- 66. Expectation gap 68 Time —> Expectation gap Software Requirements third edition, Karl Wiegers & Joy Beatty
- 67. 69 Time —> Expectation gap contact pointcontact point 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
- 71. 73 Questions?