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

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…

SPSVB Sponsors K2 Platinum Gold Silver Raffle

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

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

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.

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!

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

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…

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…

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

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!

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!

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

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". 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! ;)

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

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

 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 Plan http://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