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

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

1,926 views

Published on

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.

Published in: Software
  • Be the first to comment

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?

×