A key contributor in successful SharePoint projects is having requirements properly developed and well-defined. In this 3-part series, Dux Raymond Sy will discuss how you effectively develop requirements for SharePoint Projects:
- Part 1: How to Define Measurable and Traceable Requirements
- Part 2: 4 Key Steps in Developing Requirements
- Part 3: Practical Techniques in Writing Requirements
Being On The Same Page
What Does This Mean?
8549176320
Bank account number? Random numbers? Telephone number?
Ok, what does this mean?
SharePoint
Collaboration? Document Management? Reporting? Records Management?
A common problem with SharePoint projects is not clearly defining what it’s intended for SPECIFICALLY to an organization. That’s why when you ask 10 people what SharePoint is, you’ll get 100 answers and all of them are correct. To be successful, it is important that SharePoint project stakeholders should be on the same page from the get go.
What if I were to tell you that the numbers above are arranged in an alphabetical order? Now we’re on the same page. In a similar fashion, prior to deploying SharePoint, a clear definition and understanding of the business value SharePoint brings to your organization is necessary – this can be achieved by properly developing requirements.
What’s So Special About SharePoint Projects?
Does the picture look familiar? A clueless project manager takes on the responsibility of slamming in SharePoint for the organization without clearly defining what business solutions it will deliver. Halfway through the implementation, the PM realizes SharePoint is such a multi-faceted platform that it can do everything, anything and nothing.
Realize that by definition, requirements are:
- Formally documented and written statements
- Capabilities needed to solve a problem
- Conditions of a delivered system, services, product or process
- Constraints on the system, service, product or process
It’s critical to clearly define what the requirements are because you want to make sure SharePoint is implemented so that it will address YOUR business needs effectively.
Focus on the Business First
Being a techie, I get drawn away by the whiz bang capabilities of the latest and greatest technology from time to time. A lot of people are guilty of this too when it comes to SharePoint project requirements. If you don’t believe me, try asking a SharePoint project team for their project requirements. What do you think you’ll get? In my experience, most likely you’ll end up with a document specifying the technical architecture of the implementation, number of front end servers, etc.
Having the technical requirements defined for a SharePoint project is great, however, it should not be the first step in your requirements development process. There are three related focus areas of requirements development for every project you engage in:
- Business requirements describe and justify the high-level business functionality that is needed. Sometimes this is also known as a business case.
- User requirements identify what is needed from the user’s perspective. These can be things that the system or product must do.
- System requirements define desired characteristics of the system and properties that the system or product must have.
A common situation that I encounter is that requirements gathering for SharePoint deployments is focused at the system requirements or technical level. In the diagram above, notice that the three categories of requirements map to each other. System requirements should address the user requirements, which address the business requirements identified.
Making Requirements Traceable and Testable
Prior to defining a business requirement, a business need or “pain point” should have been identified. Ideally, a highly skilled business analyst should be working with the customer and be responsible for identifying what the business requirements are.
For example, let’s say a productivity study on your organization found that on an average 8 hour workday, an employee spends 45 minutes a day looking for information. For example, when asked by a client to retrieve a specific status report, a project manager had to look for it on the network share, her email inbox, on the project folder of her computer and she even had to call up another colleague to help her find it. This typical mode of searching took up time, which could have been spent on something more productive.
Learning Opportunities
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
Webinar
Apr
5
Adopt a Modern Digital-First Marketing Strategy
Learn how to use a composable DXP to your advantage
45 minutes may not sound like a lot to you, but when I looked at the bigger picture, it essentially meant that a team of 20 people wastes 900 minutes a day. In a 3-month period, that is 54,000 minutes or roughly 38 person days.
How much does this cost the organization? Well, depending on who you’re considering, 45 minutes/day might cost $15/day for an intern or $250/day for a technical contractor.
Bottom line is, time and money is not well spent. What if an employee can regain just 7 of those 45 minutes wasted each day? This is a 15% increase in productivity. SharePoint Search can be used to fulfill this goal.
Based on this business case, a business requirement for this project can be:
SharePoint shall increase user productivity by 15 percent
It would be great if the business analyst is well versed with the capabilities of SharePoint. Once the business requirements are identified, he/she can start thinking about high-level solutions that SharePoint can provide to meet the business needs.
For example, one of the ways to fulfill user productivity increase is to allow users to have a single location to look for information. We can take advantage of SharePoint’s out of the box Search capability by connecting it to relevant content sources. This clearly supports the business requirement.
The next step is to identify user requirements around searching. A user requirement for the search results capability can be:
The user shall be able to retrieve search results within five seconds of submitting a search request that can support a maximum of 10,000 simultaneous search requests
Why do you think that the user requirement defined is very specific? Two reasons:
- Every user requirement must support a business requirement. In this case, the five seconds response time is tied to the 15% increase in productivity
- Every user requirement must be testable. A test case typically takes a single requirement and builds a highly controlled environment around the requirement and identifies an expected behavior. Without requirements, what are you going to test? This way, expectations are clear as to what the solution will do or not do. This will avoid situations where users will aimlessly ‘test’ SharePoint and ask for a thing that’s not there. (i.e. “I don’t like how it looks!”)
Once user requirements are defined, these can be turned over to your technical folks to define system requirements. Based on the user requirement for search results, a system requirement can be:
SharePoint server shall have two web front ends and a dedicated SQL Server which has at least dual processors
By approaching requirements development in this manner, you can trace and measure why a specific system requirement is defined back to a business requirement.
Up Next: 4 Key Steps in Developing Requirements
Now that you know why having measurable and traceable requirements are important, in my next post I’ll show you the 4 key steps in developing requirements namely:
- Requirements Elicitation
- Requirements Analysis
- Requirements Validation
- Requirements Documentation
Lastly, one of the sessions that I’ll be presenting in the upcoming Best Practices Conference in Washington, DC on Aug 24 -27 is “How to Best Develop Requirements for SharePoint Projects” – I hope to see you there!
