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 ManagerMatthew 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 SharePointCore topics of requirements documentsChallenges and pitfalls specific to SharePointReview "real world" scenarios and see how requirements documents can lead you on the path to successUnderstand 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 themThe project is already past due and we need to make up timeThere isn’t any moneyThere isn't anyone in the role available that knows how to create themSharePoint is sometimes sold as self-service and stakeholders may not think they need any requirementsThe 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 requirementsWill cost more later to redoIt will be much harder to get them on board / have the project adopted the second time aroundThe 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…Performance3rd Party Tool Integration / Dependency on Other ItemsHardware / Infrastructure IssuesChoosing poor development methods / lack of experience
11 Types of Requirements Documents Business Requirements - Business requirements are high level requirements that management and a board of directors would typically understand, as followsFunctional 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 topicsData Type Diagrams - clearly defines the data types of each fieldFlow Diagrams* – when your project requirements become more complex (Visio)Prototypes / Mockups / Wireframes - screenshots, hierarchical site structure mappingTesting Requirements - should always come back to verify the deliverablesAnd 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 technologyPeople 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 thingsMost companies are using SharePoint in different waysIts success is dependent on both IT management, end users and many others understanding how it worksIt can be used for both business critical and non-business critical implementations, people's attitudes toward it may be differentPeople think they know what they want until you ask them more detailed questions or show them a mockup / demo
13 Tools for Creating Requirements VisioMind MapMicrosoft ProjectExcelWordBalsamiqCamtasia / SnagItOneNoteTeam Foundation ServerPowerPoint – I just noticed the “Storyboarding” tab today!
14 Types of Methodologies AgileTest DrivenSCRUMWaterfallLeanSDLC (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 ObjectivesScope Creep - Scope IssuesDependenciesAssumptionsRisks / 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 SupportEnd users / Other developers/project teams (not directly on this project)Past parties involved with project (if needed)Change ManagementManagers (related or ones whose actions could put a stop to everything)Project ManagersTrainer / 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 nowEnsure we have access to what we needBudgetSkilled SharePoint resourcesAbility to perform our job function / do what we need toEnsure other items we need function properly nowEnsure we have access to what we needBudgetSkilled SharePoint resources
18 AssumptionsGovernance stating what is allowed to be done/used in this environmentBugs – Known and they will not be consideredProperly configured well performing infrastructureA specific version or features of software that will be in place for our use
19 Risks & Unknowns What, me worry? Company initiatives Project participant turnoverProject historyActs of GodYou 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 processWhat 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 beBudget & time
21 Dealing With Scope Creep You might not put this on a requirements document but these tips can help you in the long runWhy 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 knowWhat we know we don't knowHow can we learn what we know we don't knowWhat we don't know we don't knowYou know what I'm saying? I knew you would! ;)
23 What we knowWhat 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 toolboxRefer back to the types of requirements documents and see which type will force answers to your questionsLook 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 surfaceCompany initiatives changingParticipant / people turnoverPeople’s agendaCan’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 notDo your best, keep notes from each lesson you learn for future projectsTake the time, even though it may not be enjoyable, to do more work upfrontGet commitment and sign off from othersDon’t give up! (unless you just got a way better job offer of course)
29 Examples of SharePoint Specific Requirements Example Governance PlanAll types of SharePoint requirements examples:E-book of steps to gather SharePoint requirements:Requirements for a SharePoint Migration (bottom of post)
Your consent to our cookies if you continue to use this website.