1. Creating Requirements for SharePoint Projects
SharePoint Saturday
Virginia Beach
January, 2015
Matthew J. Bailey

2. A Few Friendly Reminders…
Phasers set to stun, mobile devices set to silent…
You must be present to win at the wrap-up at the end of the day…

3. SPSVB Sponsors K2
Platinum
Gold
Silver
Raffle

4. I consider myself a “SharePoint All-Rounder”
I consider myself a “SharePoint All-Rounder”. My positions with SharePoint have varied around Administration, Development, Training, Analyst, UAT and Project Management. My job functions have changed at each position based on the crazy life of an IT fellow in corporate America, but it keeps things interesting! If I don’t know an answer to one of your questions, I will try to find out or point you in the right direction!
SharePoint Business Analyst & Administrator & IT Project Manager
Matthew J. Bailey

5. Today We Will…
Assume that these projects will be created with SharePoint (since this a SharePoint event). In some situations you may have the option to choose which software would best suit the needs of the stakeholder during the requirements process, however for today we will assume SharePoint is the software of choice.
Review the different types of requirements and methodologies commonly used in the world of SharePoint
Core topics of requirements documents
Challenges and pitfalls specific to SharePoint
Review "real world" scenarios and see how requirements documents can lead you on the path to success
Understand there are no right or wrong answers today, this is a learning opportunity based on past experience and shared knowledge

6. How You Perform Requirements is Dependent On Who, When, Where & Why
In most environments, it is common to meet with your stakeholders to gather their ideas and go through several cycles before going back to them and compacting the project to a smaller, less featured and more realistic deliverable.
My personal method, however, is to gather as much information about your stakeholders environment and plans before getting too far in the process of finalizing requirements. I have seen many, many hours wasted on talking about project features that will never see the light of day and time could have been spent focusing on other items due to lack of ability or money. Doing this also helps in avoiding having to let your client or stakeholder down by going back to them and removing so much of what they may have been excited in the first place. Also, depending on the environment you work at, different situations will alter how you create requirements.
In the end, however, you should choose the method that works best for you.

7. Why Do Requirements Get Overlooked?
There isn’t time to create them
The project is already past due and we need to make up time
There isn’t any money
There isn't anyone in the role available that knows how to create them
SharePoint is sometimes sold as self-service and stakeholders may not think they need any requirements
The person telling you to not have any isn’t the person who will end up doing the work when everything falls apart!

8. Why Are Requirements So Important – “Pay Now or Pay Later”
One the main reasons projects fail is due to lack of requirements
Will cost more later to redo
It will be much harder to get them on board / have the project adopted the second time around
The failure of one project on SharePoint could affect any other project using SharePoint in the future due to people associating it with the software

9. How we thought the project should go
We haven’t realized it yet, but it is going show up later…
Performance
3rd Party Tool Integration / Dependency on Other Items
Hardware / Infrastructure Issues
Choosing poor development methods / lack of experience

10. How the project ended up going…

11. Types of Requirements Documents
Business Requirements - Business requirements are high level requirements that management and a board of directors would typically understand, as follows
Functional Requirements -Functional requirements on the other hand are very detailed and outline exactly what needs to be delivered and would typically be read by business analysts, developers, project manager and testers:
Technical Requirements - A technical requirement pertains to the technical aspects that your system must fulfill, such as performance-related issues, reliability issues, and availability issues.
Use Cases or User Stories - examples might be something like step-by-step instructions, 1. Go to website 2. Click on login 3. Enter username and password 4. You are redirected to the start page.
Mind Maps / Maps* - A mind map or concept map is a visual representation of hierarchical information that includes a central idea surrounded by connected branches of associated topics
Data Type Diagrams - clearly defines the data types of each field
Flow Diagrams* – when your project requirements become more complex (Visio)
Prototypes / Mockups / Wireframes - screenshots, hierarchical site structure mapping
Testing Requirements - should always come back to verify the deliverables
And many more…

12. Common Pitfalls With SharePoint Requirements
People don’t fully understand how SharePoint works and will base their requests on what they have seen somewhere else based on a different technology
People may have incorrect preconceived notions based on how SharePoint was sold (as a self-service type of software)
SharePoint is like Swiss Army Knife and can be so many different things
Most companies are using SharePoint in different ways
Its success is dependent on both IT management, end users and many others understanding how it works
It can be used for both business critical and non-business critical implementations, people's attitudes toward it may be different
People think they know what they want until you ask them more detailed questions or show them a mockup / demo

13. Tools for Creating Requirements
Visio
Mind Map
Microsoft Project
Excel
Word
Balsamiq
Camtasia / SnagIt
OneNote
Team Foundation Server
PowerPoint – I just noticed the “Storyboarding” tab today!

14. Types of Methodologies
Agile
Test Driven
SCRUM
Waterfall
Lean
SDLC (Systems Development Life Cycle)
RAD (Rapid Application Development)
“Whatever” or “We don’t have one” – eek!

15. Requirements Categorization
Most projects should include the following…
Audience / Stakeholders (Roles & Responsibilities)
Scope & User Objectives
Scope Creep - Scope Issues
Dependencies
Assumptions
Risks / Unknowns

16. Audience (stakeholders)
Who Will Be Doing What (role)? How Much Will They Do? Who Could Affect What?
Do we have the right stakeholders involved?
IT / Administrators (Windows, AD, InfoSec, SQL, SharePoint, etc.) / Infrastructure / Architecture / Developers / Help Desk or Support
End users / Other developers/project teams (not directly on this project)
Past parties involved with project (if needed)
Change Management
Managers (related or ones whose actions could put a stop to everything)
Project Managers
Trainer / end user adoption

17. Dependencies Ensure we have access to what we need Budget
Ability to perform our job function / do what we need to Ensure other items we need function properly now
Ensure we have access to what we need
Budget
Skilled SharePoint resources
Ability to perform our job function / do what we need to
Ensure other items we need function properly now
Ensure we have access to what we need
Budget
Skilled SharePoint resources

18. Assumptions
Governance stating what is allowed to be done/used in this environment
Bugs – Known and they will not be considered
Properly configured well performing infrastructure
A specific version or features of software that will be in place for our use

19. Risks & Unknowns What, me worry? Company initiatives
Project participant turnover
Project history
Acts of God
You can’t necessarily control these but it is good to have backup plans if they occur

20. Scope & User Objectives
What Are We Doing? What Are We Not Doing? How Will We Know When We Are Done?
How the user will interact to complete this process
What must be delivered and/or occur for the project to be considered completed? How will we test it?
What the expected level of effort will be
Budget & time

21. Dealing With Scope Creep
You might not put this on a requirements document but these tips can help you in the long run
Why Are We Doing This? Reality check of what is realistic with the time and budget vs. what the stakeholders want (want something that would take 100 hours to build but would only be used twice a year for example)
Prioritization (assign point values to requirements)
What is the ROI of this requested item, hours of time saved, money saved by eliminating another system, both? Could you do a cost benefit analysis?
Will any of this project (code, workflow, etc.) be reusable in the future giving it extra value?
Will the support (server, man hours, upgrades, database size increases, new features being built into it, IT, external data systems, etc.) exist to implement this?

22. Process to Create Requirements
How can we get onto the path of a successful SharePoint project? 
Sorting through projects can sometimes be difficult, start by separating items into "buckets".
What we know
What we know we don't know
How can we learn what we know we don't know
What we don't know we don't know
You know what I'm saying? I knew you would! ;)

23. What we know
What are we sure of and is ready for a final confirmation? !
What do we know from the notes we have gathered, left over remains, talking with stakeholders, past documentation, holding requirements gathering sessions, etc.

24. What we know we don’t know
What are we not sure of but know it? ?
What items do we see that we can’t answer without help or input from others?

25. How can we find out what we know we don’t know?
Going back to our toolbox
Refer back to the types of requirements documents and see which type will force answers to your questions
Look at your software toolbox
“Phone a friend” – utilize other SME and resources when you need assistance in knowledge

26. What we don’t know we don’t know
We haven’t realized it yet, but it might show up later…
Bugs that will surface
Company initiatives changing
Participant / people turnover
People’s agenda
Can’t always control it, but good to be aware of it and have backup plans

27. Let’s Review Some Projects
And now for some exciting real-world SharePoint project examples…

28.  Final Thoughts… What can assist us with project success even more?
Letting Go: What can you control, what can you not
Do your best, keep notes from each lesson you learn for future projects
Take the time, even though it may not be enjoyable, to do more work upfront
Get commitment and sign off from others
Don’t give up! (unless you just got a way better job offer of course)

29. Examples of SharePoint Specific Requirements
Example Governance Plan
All types of SharePoint requirements examples:
E-book of steps to gather SharePoint requirements:
Requirements for a SharePoint Migration (bottom of post)

30. Feel free to connect: @matthewjbailey1 http://www.matthewjbailey.com
Download today’s slides at: