Summary: Managing scope on an intranet project is not easy, due to the variety of stakeholders from various parts of the business. What’s important to some may be less important to others. Combine that with the dimension of technology, making it unclear what should go first and what’s next. The winning strategy is to decouple business priority discussion from technical troubleshooting. Here are the 4 steps on how to do that.
STEP 1. Brainstorm Top Business Priorities
We recommend gathering all of the relevant intranet stakeholders together and brainstorm all of the priorities for their business areas.
There are few ways to facilitate this brainstorming process. Depending on the number of stakeholders in the room and the experience of the facilitator you may need one or two workshops. … and yes, these can be facilitated remotely which, depending on the culture, sometimes works even better.
Regardless of the approach, your team will end up with a list of all of their “priorities” in no particular order just yet. Below is an example of brainstorming output for Office 365 customer who needed a fair number of configurations and enhancements.
At this stage none of the items here have set priorities yet. It’s just a laundry list of everything from everyone.
Ask each of the stakeholders to briefly explain their suggested scope items so that everyone has the context.
STEP 2. Assign Business Priorities
Next step is to assign priorities to each of the items. We like to rank them Low, Medium and High.
We also like to provide a visual illustration through this process so that everyone sees how things are transforming.
As an output, we end up with something like this below, where our stakeholders have ranked their priorities from Low to High. Each of their nominated items end up on a scale.
STEP 3. Rank them According to Feasibility
At this point, you’ll need your experts in technology: SME’s, developers, and other technology folks. Whether in-house or consultants, you need their input on the technical aspect of each of the priorities.
SME’s will need to rank each of the items according to their feasibility: Low, Medium or High.
In the intranet business, here is what we mean by Low, Medium, High:
Customization, Writing Code and Scripting
Something you need a developer for
Something that will take more than a day of effort to implement
Configuration, Administration, Third Party
Something you may need administrator to do
Third party product you need to purchase like a web part
Now, the ability to spend additional cost on the app may influence your “feasibility“, so you may need to bump that back down to “Low“ if required
Out of the box configuration
Something an advanced user, Power User, Site Owner can do
We like to include tech SME’s in the same workshop as business users from the get go, so they have a context of what each of these items mean. It speeds up the process and a lot can be accomplished in 1 workshop. Some items may require research before understanding their complexity, so give your SME’s time they need. In Office 365, those can be every-changing features and capabilities.
At the end of this process, we introduce an additional dimension: Feasibility. We then, rank business priorities “horizontally“ based on how feasible they are to implement.
Here is the end result of this.
At this point we know what are top business priorities and what’s the technical feasibility associated with each, so what’s next?
STEP 4. Agree on Next Steps
At this stage we have all the data we need to determine next steps. We like to present the following graph to help stakeholders see what to tackle first, then second etc.
The green section is your home run. Those features are easy to implement and they’re very important to the business.
The second, yellow sticky’s are your big bets. They’re not the easiest but they have importance to the business.
The last section is what we often call “phase two”.
The important aspect here is for everyone to see how their requirements have transformed from “let’s do everything now“ to “let’s do things sequentially“.
This process doesn’t suggest that anything is out of scope. It’s up to stakeholders and budget approvers to see the effort associated with the priorities, decide on commitment, and have clear expectations.
Devil’s in the Details
Beware of dependencies in multi-part items
If there are “easy-items” which depend on "larger effort items”, they must go together in “larger effort items“ unless the functionality can be separated.
For example: If I’m aware of free 3rd party app that does exactly what I need, but IT needs to spend a day configuring the server - then that easy 3rd party app has now been downgraded to “Medium or Low“ in terms of feasibility.
Beware of “easy” technical items requiring lots of collateral labor
Example #1: I need to configure metadata on the Document Library in my SharePoint.
The actual process of metadata configuration is easy and out-of-the-box. The effort required to design Information Architecture to drive the metadata may required several workshops.
Example #2: I need to enable business partners to download marketing collateral from our SharePoint site.
The functionality to download is out-of-the-box. The effort associated with determining governance and access control to various parts of the site might take more time.
It’s hard to sort through priorities when there is more than one dimension to go by. By separating business priorities from technical feasibility you can make decisions clearly without jumping into troubleshooting and technical discussions right from the get-go.
How do you manage scope on an intranet project? We’d love to hear from you!
Pre-built SharePoint intranet, tailored to your organization in 3-6 weeks.
Yaroslav Pentsarskyy is the founder of OrigamiConnect, a rapidly growing service and product offering which enables organizations to get an intranet designed for them without starting from a blank page. He's also 8 time Microsoft MVP, speaker at many local and worldwide tech events, and a published author of several SharePoint related books.@spentsarsky