Managing SharePoint Feature Requests

After many months of analysis, development and implementation, you've just launched your SharePoint portal. Time to sit back and watch the magic unfold….

As people in your organization begin to see the depth and breadth of SharePoint and what it could be, their minds begin to wander. You start to have many excited visitors in your office. People are coming by saying things like "Hey, the portal's great, but you know what would be really cool is... " or "What if..." All of a sudden they want a project space. They want a new global navigation item. They want a new content type or a customized search box. Or… gulp… they you want to turn on My Sites!

Contrary to popular belief among non-IT users, the portal manager and IT do not simply control a big button that turns on a feature. There's significant effort and analysis associated to turn on any feature. There may be source systems involved, such Finance, your HRIS or AD. Maybe there some level of coding, either within SharePoint Designer and/or deeper customizations via Visual Studio. And once it's turned on, it has to be managed!

When you receive a request, the first thing you need to consider is the payoff to the business. Why are we doing this and who's benefitting? And if you just start flipping the big buttons with each ad hoc request, the portal can become bloated and directionless, sprawling into an unmanageable mess.

Understanding the Business Request

You want to encourage and engage the business, but your users will need to put some thought and justification into their requests. Any new functionality request needs to answer some important questions:

• How will this feature help the business?
• How does this feature contribute to strategic goals?
• How complex is the feature to implement?
• How does the feature align with your overall portal strategy?

Depth of Complexity

Each feature request potentially carries some level of complexity from both a technical and business perspective. To illustrate the various levels of complexity, both for your users and your development/IT team, it's suggested you map feature complexity using the following matrix (see Figure 1).

Figure 1. Mapping Feature Complexity: Low-complexity and low business requirement requests fall into the green area of the grid—they're fairly simple to satisfy with low impact to IT or the broader business. Requests of higher complexity and deeper customization to the business's requirements lie in the red area, and should be considered carefully because they likely carry significant associated costs and IT management requirements.

There's nothing new in using this methodology to estimate the business impact, and level of technical effort and complexity a feature request will require. Here are a couple of examples:

1. A user may request a simple project team library for only his or her team. The user wants all project team members to have the same read/write/edit/approve abilities. This document library will only be used by the project team, with no unique views required outside the team. No unique document templates or workflows are required, no unique workflows, content types or site columns. In this case, because the feature is only being used by a single business unit, the business requirement could be deemed a 1, and the level of complexity a 1 as well. This request has low impact, and should be an easy request to fulfill. Press on and flip the big button on this one.
2. A corporate librarian may request a new standard be created for corporate policy documents, and especially, a unique document library template that can be used by all departments. Only certain people, based upon identity (security group membership) can edit and/or approve items in this library. There may be a specific template required for all policy documents. There may also be specific workflows for approval, and upon approval, posting/surfacing via content queries on various areas of the site. Lastly, a corporate record may need to be created and transmitted to the record center whenever the document is changed and/or republished. In this scenario both the business and technical complexities would have higher ratings. You can consider the business requirement at a 3 because this new functionality will touch the entire enterprise. Because there are unique permission/approval/workflow models required, the technical complexity is also a 3.

Creating the Feature Request Framework

Creating the feature itself is simple. Create a list in SharePoint and allow any user to create items in it, but view only his or her items. Only the portal manager and IT will have view permissions on the list. Create the following columns:

• Feature Name: Fill-in field (Required)
• Created by: (auto-populated with the user's ID)
• Strategic Objective: A dropdown list where user selects the organization's defined strategic objectives. Multiple strategic objectives can be selected within this list. (Required)
• Department Objective: If your department has stated its objectives, allow the user to select those it satisfies. (Required)
• Feature Type: This is a dropdown list showing SharePoint's core functionalities, such as the document library, team site, content type, navigation item, search, blog, wiki, etc.
• Summary: A fill-in field where the user can summarize feature requirements. (Required)
• Business Requirement: A dropdown field allowing the user to select 1, 2 or 3. (Not required as a user may not realize the true depth of the business impact.) Consider a rating of 1 as low impact (such as an ad hoc request), a 2 as impacting a department, and a 3 as impacting standards across the entire enterprise.
• Technical Requirement: Another dropdown field allowing the user to select either 1, 2 or 3. Consider 1 if it's a an out-of-the-box feature to turn on, for example creating a new project site or standard document library, 2 if it's a cross-functional project or initiative, and a 3 if it requires customization and/or personalization and unique permissions. Once again, this field is not mandatory as your users may not fully grasp the complexity of the request.

Upon submission, the following workflow kicks into gear, illustrated in Figure 2.

Figure 2. The Flow of Feature Requests: Here's the entire feature request flow, from the initiating user through the steering committee.

In Figure 2, a user submits the request and the portal manager reviews the request for completeness, and compares it to other feature requests to see what design and/or business patterns may be emerging. Many requests can be combined and harmonized and this is especially true with workflow. Many of your existing unique information management processes can often be distilled down to common patterns.

Benefits

The benefits of applying a feature request framework are many, including:

1. No requests are lost; all are accounted for and responded to (either approved, parked for future consideration, or declined).
2. As the business strategy changes, so can the portal and the framework. By simply editing the dropdown lists in the feature request list, the business and department objectives can be updated whenever they change.
3. People prefer working with common workflow and design patterns when interacting with systems. You'll likely find that document approvals, workflows, content types and metadata often have similar design patterns. Harmonizing these common patterns allows users to have an understanding of what happens next vs. hitting submit and wondering what the system response will be.
4. And of course, a feature request framework makes it easier for IT to design, standardize, manage and continuously improve the SharePoint portal.

Finally, because the feature request framework is so simple to implement, you should be able to give your users the opportunity to request features immediately.