SharePoint Search Center Configuration by Matthew McDermott - SPTechCon
Creating Requirements for SharePoint Projects SharePoint Saturday Virginia Beach January, 2015...
-
Upload
rahul-biggerstaff -
Category
Documents
-
view
213 -
download
0
Transcript of Creating Requirements for SharePoint Projects SharePoint Saturday Virginia Beach January, 2015...
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
Download today’s slides at:http://www.matthewjbailey.com/speaking