How to Prioritize Business Needs Before Implementing SharePoint

By Dux Raymond Sy (@meetdux) Dec 16, 2009 Comments

1 comment

"How do you like your SharePoint? Combo 1? Team site template with Wikis, Surveys and FBA on the side? Would you like to super size it?”

Taking a fast food ordering approach when implementing SharePoint is not effective in meeting business needs. The key is to initially engage with the business, understand their pain points and identify how SharePoint can provide the solution to address these needs.

You do not want to throw a toolbox to the business and tell them to go look for a problem to solve.

While facilitating “Delivering SharePoint Success” mentoring workshop last week, it was evident that two organizational challenges exist if SharePoint is truly implemented to meet business needs:

The lack of proper skill sets to work with the business, identify their needs and map it to a SharePoint solution.
Not assessing and prioritizing the relative importance of various business needs to determine which needs to be delivered first based on available IT capacity.

Why is this important? The benefits of SharePoint can only be realized if it solves the pain points that the business struggles with day in, day out.

Here are three steps on how you can effectively prioritize business needs and deliver SharePoint-based solutions to meet them:

1. Gather business requirements by educating the business about SharePoint and collaboratively engineer a solution

Asking the business what they want in SharePoint does not work because they don’t know what they don’t know. An effective requirements gathering technique is to educate the business about SharePoint focusing on how it can address key business needs.

An HR Example

For example, when engaging with the Human Resources (HR) department, ask them how their processes are being executed. Poke around and ask them if these processes fall apart because of inefficient tools that they rely on like e-mail.

An HR group I worked with vented in frustration that there were several instances a new hire reported for work but wasn’t able to do anything for a week because a desk nor a corporate Windows login was provisioned. The on-boarding process was unreliable because the “New Employee Provisioning” form was stuck on someone’s email inbox. The process was not automated at all.

In this scenario, I explained how HR can automate this form in SharePoint through workflows. Even better, someone in HR can implement this WITHOUT programming. They don’t have to rely on IT to have an “On-boarding System” built. Voila! We’ve collaboratively engineered a SharePoint solution that addresses HR’s business pain point.

First You Need Defined Processes

On the flip side, one thing that I have discovered is that a lot of business units within an organization lack relevant business processes and rely too much on tools like SharePoint to be the silver bullet.

I remember a group of managers I engaged with who wanted a “Project Dashboard” in SharePoint. They wanted the dashboard to show the status of current active projects in their company. First, I asked them what their project management process is and standards they have in place.

I found out that they didn’t have one and they were adamant that it’s not important to define a process. They want a fancy dashboard NOW!

So I took a different tact, I asked them what they wanted in their dashboard. In unison, four executives shouted ”Red, Amber, Green” stoplight. Then I asked, “What does red mean?”. Again, everybody shouted “When projects are late!”.

Okay, my next question was “What does late mean?”. Executive 1 said “2 weeks”. Executive 2 said “1 month”. Another executive said “6 weeks”. I stepped aside as all hell broke loose and watched them bicker and argue what the dashboard should represent.