Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1 of 72

SharePoint functionality: To Build or to Buy? Let's ask Pareto!

3

Share

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.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

SharePoint functionality: To Build or to Buy? Let's ask Pareto!

  1. 1. 1
  2. 2. SharePoint functionality: To Build or to Buy? Let's ask Pareto! André Krijnen @AndreKrijnen Femke Goedhart @FemkeGoedhart
  3. 3. 3 Introductions… @AndreKrijnen @FemkeGoedhart
  4. 4. BUY OR BUILD...? Don’t reinvent the wheel... 4
  5. 5. OR BUY AND BUILD...? 5
  6. 6. 6
  7. 7. 7
  8. 8. 8
  9. 9. “Recent research report on SharePoint found that 60% of SharePoint projects are stalled, struggling or failing” AIIM 9
  10. 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. 11 “A solution without a problem….”
  12. 12. 12
  13. 13. 13 “….CRM …… custom relations” “…..track leads and orders….” “….Quality process….” “….share project documents….”
  14. 14. GETTING TO THE NEXT LEVEL… 14
  15. 15. Build? Buy? or Vanilla? 15
  16. 16. Only 18% of implementations are out-of-the-box or plain vanilla, although 40% have only “limited customization” AIIM 16
  17. 17. Build versus bought 17
  18. 18. Build versus bought 18 CustomizationorAdd-on
  19. 19. 19 20% customization is 80% of the work!
  20. 20. SO HOW DO YOU DECIDE? 20
  21. 21. Start with a problem 21 “….Quality process….”
  22. 22. 22 Constraints!
  23. 23. Three steps: 23 Objectify Rationalize Generalize
  24. 24. 1. OBJECTIFY Breaking it down… 24
  25. 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. 26. 2. RATIONALIZE Is it really the best way?.... 26
  27. 27. Is automation always the answer…? 27 Photo credit
  28. 28. 3. GENERALIZE Do we need to reinvent the wheel…. 28
  29. 29. Are we really so unique? 29
  30. 30. THE FOURTH STEP... 30
  31. 31. 31 Constraints!
  32. 32. 32 ? Request
  33. 33. 33 ? Request Objectify
  34. 34. 34 ? Request Objectify Rationalize
  35. 35. 35 ? Request Objectify Rationalize Generalize
  36. 36. 36 Generalize 3 years 3 Months 3 Months3 Months
  37. 37. REQUIREMENTS GATHERING 37
  38. 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. 39. Methods for specification & prioritization • STARR • 5* Why - Iterative question asking • SMART • MoSCoW • Eisenhower decision matrix 39
  40. 40. STARR Method Situation Task Activities Results Reflection 40
  41. 41. 5 Why’s Why? Why? Why? Why? Why? 41
  42. 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. 43. MoSCoW Must Should Could Would 43
  44. 44. Eisenhower decision matrix 44 URGENT NOT URGENT IMPORTANT NOT IMPORTANT
  45. 45. Eisenhower decision matrix 45 URGENT NOT URGENT IMPORTANT MUST! SHOULD NOT IMPORTANT COULD WOULD (Nice to Have)
  46. 46. 46 20% of your functionality Will cover 80% of what your users need!
  47. 47. THE REALITY… 47
  48. 48. The case • Production company • 300 users • Quality Online (IBM Domino) • Microsoft 49
  49. 49. • Building everything • Limited time frame • Limited budget 50 Personal story
  50. 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. 51. Option: Buy or build • Interface • Extensibility • Quality • Cost • Information 52
  52. 52. The SharePoint market • $6.44 billion worth • Apps and applications (solutions) 53
  53. 53. 55 20% of your budget Will pay for 80% of your functionality!
  54. 54. 56
  55. 55. 57
  56. 56. 58
  57. 57. 59
  58. 58. Don’t worry developers 60 80% of features are standard available 20% of the time development is needed
  59. 59. What to build • Workflows 61
  60. 60. 62 20% of your code contains 80% of the bugs!
  61. 61. Hofstadter’s law 63 “It always takes longer then you expect. Even when you take Hofstadter’s law into account.”
  62. 62. LETS GET BACK TO THE BEGINNING… 65
  63. 63. Pareto Principle 66 80% of the effects come from 20% of the causes
  64. 64. MANAGE EXPECTATIONS 67
  65. 65. Expectation gap 68 Time —> Expectation gap Software Requirements third edition, Karl Wiegers & Joy Beatty
  66. 66. 69 Time —> Expectation gap contact pointcontact point Software Requirements third edition, Karl Wiegers & Joy Beatty
  67. 67. 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
  68. 68. 71 Project the vision, manage the pieces
  69. 69. AFTERTHOUGHTS Remember Hofstadter….? 72
  70. 70. 73 Questions?

×