While Tweeting yesterday, I mentioned that the key to successful SharePoint implementation is properly developing requirements.
While Tweeting yesterday, I mentioned that the key to successful SharePoint implementation is properly developing requirements. Even if most people know that this is important, in my experience, only a handful of folks truly understand what it takes to do this right.
While Tweeting yesterday, I mentioned that the key to successful SharePoint implementation is properly developing requirements. Even if most people know that this is important, in my experience, only a handful of folks truly understand what it takes to do this right.
You see, in some instances, SharePoint is deployed without rhyme or reason. How can you measure its’ effectiveness and success if there are no metrics established? These metrics are typically developed during the requirements development process.
Requirements are formally documented and written statements. Fundamentally, it breaks down into three categories: Business Requirements, User Requirements, and System Requirements.
Business requirements describe and justify the high-level business functionality that is needed. Sometimes this is also known as a business case.Example: By deploying SharePoint Search, user productivity shall increase by 15%.User requirements identify what is needed from the user’s perspective. These can be things that the system or product must do.Example: The user shall be able to retrieve search results within 10 seconds of submitting a search request.System requirements define desired characteristics of the system and properties that the system or product must have.Example: The SharePoint server shall support a maximum of 10,000 simultaneous search requests.
A common situation that I encounter is that gathering requirements for SharePoint deployments is 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 addresses the business requirements identified.
Also, having proper requirements supports proper testing. 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?
So What?
@bhendu raised a great question. Here’s how you can measure productivity …
Prior to defining a business requirement, a business need or “pain point” should have been identified. For example, a common paint point is organizational inefficiency.
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.
45 minutes may not sound 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 15% increase in productivity. SharePoint Search can be used to fulfill this goal.
Once SharePoint is properly deployed, a similar productivity assessment/study has to be performed to find out if indeed the 15% increase in productivity has been achieved. There are proven techniques on how to perform such studies.
Hopefully now you can understand why proper requirements development is critical to SharePoint success – you can clearly see the tangible benefit of rolling out SharePoint other than the generic it will improve collaboration excuse.
At the end of the day, sound requirements are useless if nobody would step up to the plate and be held accountable for the metrics (i.e. 15% increase in productivity) established. Are you up for the challenge?
I presented ROI at the Best Practice conference here: http://www.cleverworkarounds.com/2009/02/11/sharepoint-roi-slide-deck-and-sample-scenario-worksheet-published/
This provides a great way to explain your tweet about “How do you measure productivity?”. The anwser? “Well, what does productivity look like?”. If “productivity” didn’t make a difference, you wouldn’t do it. Thus its the *difference* that productivity makes that you measure.
Thanks for jumping to the task and answering my question thoroughly. Very helpful!