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.

1. 1

2. SharePoint functionality:
To Build or to Buy?
Let's ask Pareto!
André Krijnen
@AndreKrijnen
Femke Goedhart
@FemkeGoedhart

3. 3
Introductions…
@AndreKrijnen
@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

15. Build?
Buy?
or
Vanilla?
15

16. Only 18% of implementations are out-of-the-box
or plain vanilla, although 40% have only “limited
customization”
AIIM
16

17. Build versus bought
17

18. Build versus bought
18
CustomizationorAdd-on

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!

23. Three steps:
23
Objectify
Rationalize
Generalize

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

30. THE FOURTH STEP...
30

31. 31
Constraints!

32. 32
? Request

33. 33
? Request
Objectify

34. 34
? Request
Objectify
Rationalize

35. 35
? Request
Objectify
Rationalize
Generalize

36. 36
Generalize
3 years
3 Months 3 Months3 Months

37. REQUIREMENTS GATHERING
37

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

40. STARR Method
Situation
Task
Activities
Results
Reflection
40

41. 5 Why’s
Why?
Why?
Why?
Why?
Why?
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. MoSCoW
Must
Should
Could
Would
43

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

65. MANAGE EXPECTATIONS
67

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

69. 71
Project
the vision,
manage
the pieces

70. AFTERTHOUGHTS
Remember Hofstadter….?
72

71. 73
Questions?