As discussed in my previous post (How to Define Measurable and Traceable Requirements for SharePoint Projects), focusing on the business requirements first, user requirements second and then system/technical requirements is necessary to effectively define measurable and traceable requirements for SharePoint projects.
In this post, I’ll show you and explain you the 4 key steps in developing requirements for SharePoint projects.
Requirements Development is Iterative
Whoever told you that requirements development in a SharePoint project is a one-time event is clearly a poser. Developing SharePoint solutions is an iterative process (especially during Business and User requirements development) where both the customer and the implementation team specify, prioritize, validate and document what the project requirements are.
In my experience, business, user and system/technical requirements development involves these 4 key steps:
- Requirements Elicitation
- Analyzing Requirements
- Validating Requirements
- Documenting Requirements
Editor's Note: You can read more articles by Dux on SharePoint, including 5 Tips on Effectively Planning for SharePoint 2010 Migration.
Step 1: Eliciting is Not the Same as Gathering
Requirements Elicitation is the process of gathering and understanding what stakeholders and users need. This is performed both at both an organizational (business) and a more detailed user-level. Elicitation is a human-based activity; it entails face time and interaction between the customer and a SharePoint analyst.
This individual is NOT just an order taker from the customer, the analyst would want to find out business pain points around operational collaboration (i.e. meeting management, sharing files), business processes (i.e. employee onboarding) and reporting (i.e. monthly sales report).
The goal is to find out not only what the customer wants/needs, but also to identify existing pain points that can be easily addressed with SharePoint which would help them do their jobs better.
During this process, the analyst is responsible for:
- Determining requirements sources -- specific people, focus groups, industry research
- Decide how to gather information -- surveys, interview, focus groups
- Understanding business-level context and framework
- Investigating how the end users do their jobs
Essentially, the analyst would have to address the following questions during requirements elicitation:
- What do I need to know?
- Where do I get this information?
- Does the information make sense?
- Do I have enough information?
Remember, the goal is to identify a business solution and not showcase SharePoint whiz-bang features. You also have to consider how to promote better adoption once the solution is in place. That’s why minimal disruption or change to their technical habit/routine is important.
You wouldn’t want to give your customer a Lamborghini Diablo if they’ve just learned how to ride a bike yesterday.
Step 2: Analysis Doesn’t Lead to Paralysis
Requirements analysis takes elicited information and makes sense of it. The goal is to identify the real requirements.
For example, we had a customer with the marketing department who is challenged with managing events they organize for their partners around the world. Traditionally, they’ve relied on emails, spreadsheets and web-based tools to organize, communicate and manage these events. Their pain point? It’s really hard to assess, track and report the value that these events brings back to the business. Analysis of data (i.e. how many people registered and attended the event? Did they attend multiple events? Did their company buy more products after the event? How many people from the same company attended these events in the last 4 years?) is manually put together.
After eliciting the requirements, the first step in analyzing their needs is to profile users; understand who they are, why they came up with the requirement and what will make them happy. Knowing that the marketing team, executive management and their customers will be the benefactor of the SharePoint solution, we initially identified the key needs around:
- Automation of key events management process
- Real-time reporting capabilities
- Self-service features for registration, support and historical data lookup
Next, it is critical to model stated requirements. This can be achieved various ways (ie Process mapping, Use Case Diagram). One of the most effective techniques is to create a process flow diagram:
With this, we engaged the customer step us through their events management process, who’s involved and what other dependencies exist. As a result of doing this, we identified gaps (i.e., Payment process during event registration) and had to go back and elicit more requirements (iterative process kicking in baby!)
At this point,hopefully, you’ve analyzed the requirements you’ve elicited. Review them with the customer and make sure the gaps have been addressed. This is the last step towards identifying the real requirements.
Step 3: Too Legit to Quit?
Remember MC Hammer’s chart topping single “Too Legit to Quit”? There’s a line in the song that comes to mind whenever I’m working with customers to develop requirements for SharePoint projects:
Learning Opportunities
Webinar
Mar
21
Ready to Level Up Your Learning? Discover Your Learning Maturity Score
Learn how to level up your learning program in this free, interactive workshop
Webinar
Mar
29
The CX Commute vs. the CX Joy Ride
Is your CX traffic holding up your customer's journey?
Webinar
Mar
29
Is Your Microsoft 365 Data Recoverable? How to Survive the IT Hotseat When Data is Lost
See why MIcrosoft recommends third party backup
Webinar
Mar
30
An Optimized Customer Contact Strategy Combines Transparency and Intelligence: The State of Outbound Communications
Learn from the Neustar-commissioned Forrester Consulting study on challenges and solutions for contact centers
Conference
May
10
CMSWire CONNECT Customer Experience Conference - Austin 2023
Don't miss the top customer experience and digital experience conference of the year — live in Austin, Texas May 10-12.
Conference
May
10
Reworked CONNECT Employee Experience & Digital Workplace Conference Austin 2023
North America's best employee experience and digital workplace conference of the year — live in Austin May 10-12, 2023.
“The dreams that I have in store in my mind and I know
That i'm making it, I gotta get mine and nobody's taking it away”
In most cases, don’t you find customers asking for more than what they need/want/afford?
Now that you’ve analyzed the requirements, most likely you’ll have a long list of requirements that doesn’t seem realistic to deliver all at the same time. This is the part where you go back to the customer and validate:
- If the real requirements derived after requirements analysis is/are still valid
- The relative priority of these real requirements
Requirements validation is essential to identify the resources needed to implement the SharePoint solution. This paves the way to identify a realistic, high-level budget, schedule and SharePoint skillsets.
Read this post “How to Prioritize Business Needs When Implementing SharePoint” to see an example of a practical process that you can use to prioritize requirements.
Step 4: Put it on Paper
Now that you have your priorities in place, it’s time to formalize your requirements by documenting it. A requirements document formally communicates:
- Overall quantitative and qualitative characteristics
- Functionality of the desired end result or outcome
It should include:
- Requirement Statements
- Process Diagrams
- Prioritization Matrix
- Traceability Matrix
Additional Resources
I hope you found this post beneficial. As a supplement, here’s a recording of the “How to Best Gather Requirements for SharePoint Projects” presentation in the recently concluded Best Practices Conference 2010 in Washington, DC:
How to Best Gather Requirements for SharePoint Projects from Dux Raymond Sy on Vimeo.
In addition, here are the templates/artifacts I referenced in the presentation.
Also, I’ll be presenting “How to Best Gather Requirements for SharePoint Projects” at SharePoint Saturday East Bay on September 11, 2010. I’d like to invite you to this FREE, 1-day event in San Ramon, CA, USA. For more details and registration, go here.
Lastly, feel free to check out the Innovative-e events calendar for upcoming presentations around Project Management for SharePoint & SharePoint for Project Management.
Up Next: Practical Techniques in Writing Requirements
Now that you know the 4 Key Steps in Developing Requirements for SharePoint projects, stay tuned for my next post as I decompose a requirements document and share practical techniques in generating them.