Creating Requirements for SharePoint Projects

SharePoint SaturdayVirginia Beach January, 2015

Matthew J. Bailey

1. Phasers set to stun, mobile devices set to silent…

2. You must be present to win at the wrap-up at the end of the day…

A Few Friendly Reminders…

Gold

Platinum

Silver

K2

Raffle

SPSVB Sponsors

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

• 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

Today We Will…

• 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.

How You Perform Requirements is Dependent On Who, When, Where & Why

• 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!

Why Do Requirements Get Overlooked?

• 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

Why Are Requirements So Important – “Pay Now or Pay Later”

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

How the project ended up going…

• 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…

Types of Requirements Documents

• 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

Common Pitfalls With SharePoint Requirements

• Visio• Mind Map• Microsoft Project• Excel• Word• Balsamiq• Camtasia / SnagIt• OneNote• Team Foundation Server• PowerPoint – I just noticed the “Storyboarding” tab today!

Tools for Creating Requirements

• Agile • Test Driven• SCRUM

• Waterfall• Lean• SDLC (Systems Development Life Cycle)• RAD (Rapid Application Development)• “Whatever” or “We don’t have one” – eek!

Types of Methodologies

Requirements Categorization

Most projects should include the following…

• Audience / Stakeholders (Roles & Responsibilities)• Scope & User Objectives• Scope Creep - Scope Issues• Dependencies • Assumptions• Risks / Unknowns

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

Dependencies

Ability to perform our job function / do what we need to Ensure other items we need

function properly nowEnsure we have access to what we needBudgetSkilled 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

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

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

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

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?

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".

1. What we know2. What we know we don't know3. How can we learn what we know we don't know4. What we don't know we don't know You know what I'm saying? I knew you would! ;)

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.

!

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?

?

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

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

And now for some exciting real-world SharePoint project examples…

Let’s Review Some Projects

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)

Examples of SharePoint Specific Requirements

Example Governance Planhttp://office.microsoft.com/download/afile.aspx?AssetID=AM102310201033 All types of SharePoint requirements examples:http://www.rharbridge.com/?page_id=726

E-book of steps to gather SharePoint requirements:http://www.sharepointgeoff.com/welcome-to-sharepointgeoff-home-of-stationcomputing/user-requirements/

Requirements for a SharePoint Migration (bottom of post)http://sharepoint-community.net/profiles/blogs/select-sharepoint-migration-tool

Feel free to connect:

@matthewjbailey1

http://www.matthewjbailey.com

http://www.linkedin.com/in/

matthewjbailey1

sharepointmatthew@gmail.com

Download today’s slides at:http://www.matthewjbailey.com/speaking