CHAPTER 9

Managing Your SharePoint Demand Funnel

In this chapter, I focus on approaches to setting up a demand funnel for enhancements and expansions of your SharePoint service. This will help you have an ordered process to ensure that you do not miss or lose enhancement opportunities, but it will also help you to ensure requests do not pull you off course and leave you chasing every little feature. I offer considerations to establish a triage process where you can prioritize requests and opportunities, some of which you can then add to your roadmap while you capture others in a parking lot of deferred future items.

One key point I stress in this chapter is how to use a roadmap to set expectations, to prioritize feature and enhancement requests, and to facilitate the parking of requests for the future. I first discussed roadmaps in Chapter 7 as a planning tool, but I look at them again in parts of this chapter as an expectation management tool.

After reading this chapter, you will know how to:

• Set expectations with your internal customers and stakeholders
• Define boundaries
• Create a request triage
• Build a parking lot list of deferred feature requests
• Map enhancement demand back to your roadmap
• Forecast upcoming upgrades and new versions
• Evaluate third-party products
• Conduct cost-benefit and business value estimates

Funneling Demand

My suspicions are that if you have deployed SharePoint already, then you have probably felt the tsunami of demand from all the feature requests surging in from all over your organization. If you have not experienced this yourself, then you likely know someone who has or you might have heard tales of this happening. It relates to one of main reasons I have stayed so busy with SharePoint for so long, because SharePoint offers a vast sea of features. There constantly seems to be additional opportunities to expand a deployment and unleash new business value. This only becomes problematic when you find the demand pulling you in every direction all at once, and as a result, you find yourself swimming against a tsunami current that is sweeping you away.

A surging tsunami is certainly a vivid visual for demands for SharePoint enhancements and feature requests. Each individual request probably does not feel like a tsunami; after all, so far in this book I have showed you the ease and flexibility that SharePoint can enable new features and functionality. However, these little demand waves are not isolated, because they participate with other demand waves that all come together into a larger swell. Tsunamis come washing in from every direction, and without protection or controls in place, they can engulf you and pull you under. Some places prone to tsunamis or other surging storm waves will build controls such as dykes and storm barriers to help control where waves flow.

Your demand funnel will serve a similar purpose where it will help you to control the flow of requests and prevent them from flooding your team. This demand funnel will provide a means to process enhancement requests both for developing complex new functionality and for enabling seemingly simple features. In fact, I find requests for seemingly simple features tend to be what most often ends up consuming my time and pulling me off course. Larger development projects typically also come with a project plan and some rigor. Enabling a small feature does not need that level of overhead, but they do need an ordered way to process new requests.

You might get these requests from the end-user feedback you collect using the approaches I discussed in the previous chapter. Some internal customers might be too busy to come to you with requests, or they might just be relatively satisfied with the status quo that enhancement opportunities do not yet motivate them enough to make requests. For these customers, you can go to them and prime the demand by collecting feedback. For other customers, they might be eager to submit enhancement requests to help support their job functions. It is important to consider potential demand from both of these types of customers, because otherwise you run the risk of only responding to the needs of your extrovert customers and ignoring your introvert customers.

Demand funnels process all incoming requests, whether your customers submit them or you uncover them while collecting feedback, whether they are relatively small features to enable or they are large-scale development projects. The demand funnel processes them all and then, funny enough, it funnels the demand for you or your team to address and deliver. A few necessary characteristics required by your demand funnel include: a means to accept new demand items, a process to prioritize and triage these items, and then a way to either schedule the work or to park the item in a parking lot list. Figure 9-1 illustrates a conceptual demand funnel. I discuss details of these characteristics throughout this chapter, but first I consider how you can capture the demand and divide it into distinct items.

One option to capture the demand is to use a SharePoint list. You could configure a list such as the issue tracker list and use this to capture and track individual demand items. I like the issues list because it already has some prioritization and detail columns built in to it. You can add other columns to capture information on the risk associated with a particular request, such as the risk to the overall system stability or other types of risks. You can also add columns associated with the rough implementation costs and the estimated business value, as well as columns associated with the required effort and any dependencies involved with a particular feature. All this information can help you prioritize and schedule any work effort. I like to use columns to indicate the status of the item in the triage process, as well as what phase or sprint I want to address the item in or whether I am parking it for some unknown future date.

You will only have so much capacity to deliver features and capabilities, so you need your demand funnel to balance the demand with your capacity to deliver. This is the first objective of the demand funnel. The second is to ensure that you are delivering the highest priority items or those that will deliver the most business value relative to their cost. This exercise is largely an extension of the roadmap planning I discussed in Chapter 7, but I will shift my focus in this chapter to consider how to manage this within the demand itself. One important aspect of managing the demand funnel involves managing expectations, and I discuss this aspect in the next section.

Setting Boundaries and User Expectations

When I read the heading for this section, it almost has the feeling of a parent who is setting a child’s boundaries. This is not what I mean by it at all; instead, I am referring to boundaries for you and your team with your processes and operational procedures. They are the things that keep people from turning things on and adjusting configurations at random in response to user requests. Your boundaries define what those things are that requires a formal process and what types of requests your team members can go ahead and resolve right away.

I have discussed this idea of establishing a boundary for your service a few times now. In Chapter 2, I looked closely at how you can define boundaries of the service itself and what capabilities you offer. Then, in Chapter 4, I looked closely at how to set responsibility boundaries for each role involved with providing your SharePoint service. Your SharePoint roadmap that I covered in Chapter 7 provides another boundary, one that sets the course for what areas you have planned to accomplish. This is one place where you can bring these together, at least conceptually.

In hockey, when the pressure is on during a game and the team faces adversity, the fundamentals are what will help them push through it and bounce back. Their fundamentals are things such as making passes, completing checks, and covering an opponent or playing a particular zone. When the pressure is on and the team is slumping, focusing on the basic plays that the team has practiced over and over will help carry them through, and their fundamental systems will give them something to fall back on when fancy plays just are not connecting.

Your SharePoint team obviously faces different types of pressure situations, but having systems in place to fall back on will help everyone handle service demands and feature requests. This is why I stressed putting those fundamentals in place, because with roles defined, the service defined, and a roadmap setting the course, you will have the fundamentals you need to fall back on. This gives you the tools to effectively funnel your demand as it highlights your team’s available capacity and the necessary tradeoffs or sacrifices required for a particular feature request. The only things you need to add to this are an intake process for requests and a triage process to prioritize those requests. I return to these topics a little later in this chapter, but first I consider how this system will help you to set expectations with your end-users and other stakeholders.

End-users and stakeholders are both generally reasonable creatures. They may seem unreasonable at times, and this is because someone forced them to act with limited knowledge or a limited perspective. All they may be aware of are their own needs, and to them these may feel as if they should be the highest priority and will deliver the most value to the business. From their limited vantage point, they may even feel as if you and your team are being the unreasonable ones. After all, they might not otherwise know why they face a delay with their request or what else might be in your queue.

Granted, some people may operate at a more selfish level than others do. People have their own objectives and their own priorities, and these can easily conflict with other people’s priorities. Perhaps their objectives all link to a reward such as a bonus or promotion, in which case they may have a valid reason to want to push their own agenda for feature requests that will support their objectives. I do not find anything particularly bad about this, because you have a demand funnel with a request triage process to help you prioritize enhancement requests and balance this demand.

The goal is to provide your internal customers with a place to request enhancements or new functionality rather than leave them on their own to search for solutions. Ideally, this will establish a formal intake process that they will use and that can satisfy their needs. An important aspect of a formal intake process is it will provide you with the opportunity to take a holistic view of all the demands for your SharePoint service. It will also provide your internal customers with a holistic view of competing demands that require trade-offs and prioritization to determine what value to deliver.

Having a transparent process helps reinforce expectations because end-users and stakeholders will no longer be operating from a limited perspective. They will have insights into why you prioritized things the way that you did, and they will (hopefully) see how a particular approach will meet the needs of the greater good for the organization. Now, they might not be happy if you delay or park their enhancement requests, but understanding why should help you avoid having them resist or protest the approach. Unfortunately, you cannot satisfy every need, at least not all right away, and so you will need to make trade-offs with the needs you do fill. The essence of considering and making these trade-offs is the request triage process.

Creating a Request Triage

A triage simply means a process of determining the most important item or the degree of urgency for an item, from a large number of request items that require attention or offer an opportunity to expand the service. I have already spent some time at different points in this book discussing how SharePoint creates an environment with plenty of opportunities. SharePoint is overflowing with the potential opportunities and business value that it offers an organization and this can lead to an overwhelmingly large number of requests to come in. Your request triage provides a way to process and prioritize these requests in a systematic manner.

In a medical use, a triage provides a process where medical professionals assess the degree of urgency in a patient’s wounds or with their illness. From this assessment, they then determine the order of treatment for a large number of patients or causalities. If you went to your local hospital’s Emergency Room (ER), you would no doubt notice that they do not process patients in a first come, first served manner. Instead, they go through an ongoing triage process where they assess the severity and the urgency of incoming patients and prioritize them for treatment based on their priority relative to all the other waiting patients. They also continuously reassess patients waiting in the queue to determine if their illness is escalating.

An ER operates with a formal and systematic intake process. If a major incident occurs and causes a spike of patients to arrive in the ER for treatment, the staff might use a color-coding system to organize the priorities. An expert or specialist might do an initial assessment to determine a patient’s severity and urgency for treatment. They cannot process everyone all at once, especially if there is a large spike in their patient intake. The staff also cannot process everyone in a first come, first serve manner because someone with a more urgent need for care could die waiting while someone with an insignificant symptom receives treatment first.

You might design your intake process in a similar manner. Similar to an ER, you can establish a rolling prioritization and request triage process to ensure that you are focusing on the most valuable items for the organization. A request triage resembles a bug triage, a process such as having your team meet regularly to review the list of bugs and decide what you will address first. Figure 9-2 illustrates where a request triage can fit in an overall sample business process to handle requests. In the case of a request triage, you will schedule a regularly recurring meeting where team members and stakeholders can meet to review the list of requests and determine what the team will focus on delivering first.

When you are deciding who should attend these ongoing request triage meetings, include sponsors or key stakeholders who will represent the needs and priorities of the business. You want to include enough representation from the delivery team and the business to help validate priorities, identify dependencies, and estimate efforts. By bringing a diverse group together for these request triages, it can help build support and buy-in as they face each other and understand each other’s needs and objectives. This can also help everyone understand the constraints you are working within, and this will involve everyone in the process of making trade-off decisions as you come to agreement on what requests to address first and which ones to park for a later undetermined date.

You do not have to fix or obligate the membership for the triage meetings. Stakeholders can attend if they are interested or if there are requests that will impact their area of the service. Someone needs to chair the meeting, typically the SharePoint service manager or team lead. Everyone else is optional, although you should have a minimum representation to form a quorum before making crucial decisions on priorities. I find that by keeping membership and attendance in this group as optional, you will help to keep it productive and avoid having it morph into a chore that nobody wants to attend.

If you schedule a recurring meeting on everyone’s calendar, you can mark the majority of people as optional so they can leave a tentative placeholder on their calendar. Then, before each request triage meeting, you can send out a meeting update with an agenda that provides a concise summary of the major requests you plan to triage. This can help attendees decide whether it will be productive or relevant for them to attend the triage. You might also set up a meeting workspace or a community site in SharePoint where you post all the details about the requests you plan to triage, and you can even use this to store the meeting minutes to capture and publish triage decisions. This helps keep everyone informed even if they are unable to attend the triage.

This triage process is a crucial governance action you can take to ensure discipline on your team’s service delivery. Most notably, it keeps your team on track by avoiding informal or unplanned projects, and it prevents the chaos that comes from users pulling your team in any direction. With a request triage, you can enforce the types of checks and balances that keep your team focused on delivering the right things and delivering the right value.

Capturing Requests

To triage and process requests, you first need to capture them somewhere. Any tool that provides your internal customers with a means to submit a request will do just fine. I find the best solution for capturing requests will be one that has triage workflow capabilities built in, allowing you to automate the process and track any history of decisions and dependencies. E-mail offers minimum functionality to capture requests and set priority categories, where users can send an e-mail with their problem or need. However, it does not offer an easy way to track the work history or to link it with any dependencies. Instead, I prefer to use other types of lists to manage requests.

SharePoint offers a built-in list that provides a rich set of functionality you can use for your request intake and triage. I use the Issues list type to provide this sort of list, and then I customize it to fit my needs by adding columns and creating a workflow. With the right combination of permissions and workflow, you can make this list fit a good portion of whatever you need. You might even tie it in to whatever feedback process you set up based on my discussion on feedback processes in Chapter 8.

A SharePoint list works well for many of your needs to capture and triage requests. However, it might not fit with your change management processes or any of your existing request ticketing systems. You may already have a requirements management tool or you may want to incorporate requests into your service desk’s request management system. You might also consider using any of your existing bug and work item tracking software, such as Microsoft Team Foundation Server (TFS).

TFS is already set up to track work items, to associate them with other work items or tests, and even link them to source code that your developers check in. It has built-in process templates to manage the workflow process of an item, or you can customize your own to fit your request and triage processes. It also has built-in fields to categorize an area of the system that the request relates with and you can specify an iteration that you want to schedule any work. Another thing that I like about using TFS to manage requests and work items is that it already has built-in reports for reporting on progress, such as your burn-down rates.

Using TFS, you can capture your requests, risks, issues, scheduled work, and test cases from within the same tool. This can give you a view of the work your team is preparing and it gives your internal customers a single place to submit bugs or enhancement requests. You can manage the backlog of items through the iteration field, which is initially blank when a user creates the item. You can later set the iteration value during the request triage. One option is to set it for a scheduled iteration if you want to complete it during a known cycle of work.

I also like to add an iteration that I call “Someday Maybe” or “Parking Lot” to designate the iteration for items I am not yet scheduling for work. This captures the item and its details, allows me to assign a priority and work estimates, and it assigns the request to an unspecified backlog iteration. This way you can process the request triage by selecting any item that does not yet have an iteration set. Later in this chapter, I return to discuss the idea of a parking lot to park requests for a future undetermined date.

Whatever solution you use to capture the requests in a list, you need to ensure that you also capture relevant details that you can refer back to in the future. You can attach extra files to supplement the details of the request and help your team as they prioritize and estimate the request. This information will also help you later to design the solution. The following lists several of the types of attachments you might want to attach to the request item, depending on its complexity and size.

• Use cases
• Wireframes and mockups
• UML diagrams
• Entity-relationship (ER) diagrams
• Process and swim-lane diagrams

As you can no doubt tell, capturing requests involves capturing different amounts and different types of data at different times throughout the funneling and triage process. You might triage an item and decide it needs more information, and so you can assign it to a team member to investigate further. You might assign it to a business analyst to gather more requirements or to a solution architect to add some preliminary designs. I find it is valuable to capture this extra information while the request is fresh in everyone’s mind. Often this process might be a feasibility study and an initial assessment that can later feed back into the triage process.

If team members pass a request between them while they analyze the requirements or they contribute preliminary solution designs, they need a place to add comments. This offers people a generic field for text where they can ask or answer unstructured questions. They can also add other notes if ideas or assumptions come to them, thereby capturing this information in the tool so it is not lost later. In TFS, this can be the history field, and in SharePoint, this can be an append-only comment field.

Once you collect all the information, you have a package consisting of solution designs, estimates, and the like, all of which you can use for prioritizing and planning your team’s delivery. It also helps to define what success looks like and where you are going. If you do not know what success looks like, then how will you know when you have achieved it? And even more critically, how will you determine what direction success is in if you have no concept of it?

If you built a SharePoint roadmap, as I discussed in Chapter 7, then you have a direction and the roadmap will provide waypoints to guide you through your triage process. In the next section, I discuss how to map requests back to your roadmap.

Mapping Requests Back to Your Roadmap

Setting priorities, estimating effort, and identifying potential value in a request are all important for analysis, but you cannot schedule work based on that information on its own. You also need to consider your roadmap with what else you have scheduled, including any other related work. Your roadmap will also identify whether fulfilling the request will take you in the correct direction or leave you delivering one-off solutions. As I discussed in Chapter 7, your roadmap sets your overall course for how your SharePoint service will evolve. For this reason, it is critical to include it as you triage and schedule work for enhancement requests.

First, you need to identify whether you already have an item scheduled in the future. If you do, do you need to adjust that schedule and reprioritize the roadmap? Ideally not, but sometimes this becomes necessary as you learn more about a requirement or as business conditions change. If you do not already have it scheduled, then you need to determine whether it depends on other work in your roadmap. Your roadmap gives you a good at-a-glance view of the feasibility of a particular request and any of its potential ripple effects throughout your system and your team’s resourcing.

Your roadmap sets your baseline for where you want your team to focus their efforts based on multiple factors, such as resource availability, underlying system maintenance or upgrade plans, and dependencies between capabilities. This guides the triage process and helps you to make quick decisions about whether to schedule or park a request. Therefore, as you consider an item, consider whether it fits with your strategy and the overall direction that you want to take your SharePoint service. Sometimes you just need to accept that an opportunity is not right for your strategy, or at least the timing is not right for it. I discuss the idea of parking an item in the next section, so for now, let’s assume that the item is work you want to schedule.

Once you have prioritized an item and determined that you need to schedule it to enhance your SharePoint service, the next step is to determine when. As I mentioned previously, identifying any dependencies can help give you a general sense for where in the roadmap you can slot in the work. This helps you to avoid over-utilizing your resources and it allows you to consider whether your team is working on any related items that would complement a particular feature. It can reveal these types of synergies as well as any dependencies that you are planning to deliver.

This approach helps you to avoid chasing features. Chasing features in your project delivery might make your internal customers happy at first, but chasing them might eventually sink you in a pit of quicksand. I do not know if you have experienced this yet, but I sure have. This occurs when people get excited about a seemingly simple feature that someone wants to add to your project’s scope. Without doing any analysis, the team then goes ahead with the assumption that the feature is as simple as it appears, but they begin to discover that there are dependencies they need to address. One after another, these unanticipated dependencies begin to add up and they form the quicksand that sinks the team.

Earlier in the book, I also referred to a related risk as I discussed the idea of a similar scenario where you find yourself caught in a death by a thousand paper cuts. This is similar to the quicksand example, but rather than having a stream of dependent work activities engulf you into a pit, it is a practice where you continuously add independent features. Each additional, nice-to-have feature by itself does not seem to add excessive scope, and the added value it would deliver is too tempting. Eventually, just as the quicksand will consume a team, these paper cuts will add up and wear you down.

A roadmap helps alert you when your team is trending toward sinking in quicksand or you are experiencing a slow death by a thousand paper cuts. When work items and the demand you are chasing does not align with your roadmap, you should take a step back and ask yourself if you are trending off course in one of these two danger areas. Your roadmap serves as more than a planning tool, because it also helps to reveal the health of a project and it guides how you prioritize your service delivery.

I touched on it briefly in Chapter 7, but just to reiterate, this is where your roadmap supports your efforts to maintain a certain course in your service delivery. It helps you set your overall direction and plan your resourcing as you consider the upcoming projects you have planned. Beyond this though, it gives you a support tool to refer back to and rely on to keep you and your team grounded. It really is easy to find yourself carried away with all the wonderful features SharePoint can offer your organization, especially without a plan or focus. Your roadmap gives you that plan and it generates the focus you need.

Your roadmap opens up a path that allows you to build momentum to deliver on. You can use this as part of your demand funnel to identify where you can leverage related efforts and follow a wave of momentum with a particular feature. So, if you have not read Chapter 7 and built a roadmap, I strongly encourage you to work on this. In my experience, this will be one of the best gifts you can give yourself and your SharePoint service. It gives you a tool to guide you, and it helps you to avoid being blinded with the excitement of new features that you do not have the capacity to deliver or that would pull you too far off course.

As you map your new requests back to your roadmap, you will consider where an item can fit within your roadmap. You will base this consideration on the dependencies you identify between other items, the item’s priority, and your available resourcing to deliver a feature, as I discussed in this section. But what if you have a request and it simply does not fit with your roadmap? Either its priority is too low or it has too many dependencies that your roadmap does not accommodate. You will likely face times when people want things that you just do not have the capacity to deliver right away. In those cases, you will find it is still worth capturing their ideas and the details about the opportunity, yet not plan to deliver the solution. One place you can capture these types of requests is in a backlog or a parking lot list.

Building a Parking Lot List for Future Enhancements

You cannot be everything to everyone, at least not all at once. You will face the need to make tradeoffs and prioritize what you can deliver and when. This trade-off decision and prioritization is the main output from the request triage. This is also what keeps your team focused on delivering the right value to best meet the needs of the business. Some items are what you will want to get to right away, while others are ones you will schedule for some later date. Many are items you will defer until some undetermined date, and these are what you will capture in your parking lot.

On development teams, I have always sensed a sort of anxiety among stakeholders whenever I needed to cut features. It is almost as if these features make their way off into some black hole, never to be seen again, and these stakeholders are mourning their loss. In their defense, this was often the case as I cut features and promptly forgot about them while moving on to what I would deliver. Without a place to capture those items that I needed to cut, they would be lost. I often refer to it as a parking lot where I can park requirements I am not currently addressing. You might call it your backlog, or any other name you find meaningful. The important point is that without this net in place catching these requirements, they will likely be lost.

A parking lot helps to capture the details about requirements and it saves them for some unknown future day when you want to address them. You might want to reference the information you collected as part of the requirement to help you answer questions about another requirement. Or better yet, you might clear your queue of work items and want to deliver on those lower priority requirements that you deferred to your parking lot. Whatever the reason, capturing this information provides you with the option to recall it at a later date. It also provides direction and knowledge transfer to anyone else who may take over and look to deliver some of these requirements or look to understand the reasons why you deferred them.

Building an informative repository of deferred requirement details is one reason you will find a parking lot list of requirements useful. Another is that it will assure your team and your stakeholders that their input is not simply lost, or worse, ignored. Capturing the details can help validate their input, even if you are not going to act on their requirements today. This can help reduce the urge for stakeholders to resist having their requirement cut, because if you capture it in a parking lot then you have not cut and lost it, you captured and deferred it to a later time that is to be determined.

Your parking lot may exist in the same list as the items your team is planning to deliver, where you update the status of a field to indicate whether the item is current or parked. As I mentioned earlier, this might be the iteration field for your Team Foundation Server work item where you designate a special parking lot iteration. This allows you to maintain a single list that you can filter into multiple views based on field values, such as a parking lot list or by feature area. The benefits of maintaining a single list are that you can maintain your items and their history in the same place. It also allows you to easily re-categorize a work item that you need to defer or your team was unable to complete in a given iteration.

You also might consider opening up your parking lot list for your internal customers to view. This can help them to understand the trade-offs that your team faced and why you made the decisions that you did in selecting a particular scope. They might not read through the list and all the details you collect, but in scrolling through, they can see the vast number of requests you had to balance. I have found this level of transparency can help build support for the demand funnel and the request triage process, especially if you include representative stakeholders in the process. This all reinforces the notion that you and your team are working with your internal customers to provide the right service that meets their needs, rather than simply forcing some IT initiative on them.

As you work through delivering a phase or iteration, continue to collect new ideas and new requirements as they come up. You cannot control when great ideas will come to people or when they will discover some new opportunities. All you can do is have a system in place to capture them when people think of them. Once people can capture their ideas, then their creativity is not lost and your team can continue with your current delivery. This allows you to capture the creative process, yet not have it pull you off course.

Once you complete your phase or iteration, then this should align with another request triage meeting. In the meeting, you can triage the new requests and revisit the parking lot items to determine what to prioritize for the next phase or iteration. This allows you to continuously cycle through your parking lot as you evolve your SharePoint service. As I mentioned, it ensures that ideas and deferred requirements are not lost, and it helps you to manage scope.

Forecasting Upgrades and New Versions

In Chapter 7, I discussed the idea of the software support lifecycle and the eventual need to plan for software upgrades. In Chapter 11, I come back to this topic to look at planning considerations for upgrades as I discuss this topic in more depth. For now, I want to consider upgrades from the perspective of feature requests and your demand funnel. Your support lifecycle helps you determine those dates you might want to upgrade before in order to remain within mainstream support, but this might not necessarily align with the demand you are funneling for new features found in those newer versions.

An upgrade project can be a significant piece of work and it is something you should represent on your roadmap if you are considering one. You will face several dependencies and things you can do to prepare for an upgrade, as I discuss in Chapter 11, but the process to funnel demand remains the same. You still need to break down a request into the dependencies and start to estimate all the work efforts involved. This is similar to how you would expand your roadmap if you were considering expanding your service with a major SharePoint capability such as business intelligence or enterprise content management. The details in the actual work activities vary, but the demand funnel process remains consistent.

If and when Microsoft announces a new version of SharePoint and your users get excited about a new feature in that version, then that new feature is the request and all the steps in the upgrade make up the dependency. Similar to rolling out a major new capability, you will have a variety of planning, analyzing, and testing activities to prepare for the upgrade. These are all the dependency work items you can include in your roadmap to help you schedule when your team can reasonably accomplish the upgrade.

I find it is best to begin considering when you can approach an upgrade as soon as you know a general timeline for when Microsoft will release the next version of SharePoint. I have had several customers who prefer to wait until they have demand from the business – they sort of delay the inevitable. Many enterprise products seem to work well with this approach, but I find SharePoint is slightly unique with how quickly excitement and demand from your internal customers can build. I always prefer to be proactive when considering upgrades to prepare myself for when that demand does come.

When you forecast and prepare in a proactive way, you will have the answer when your demand funnel begins to process requests for features that the next version offers. You will know all the dependencies and the related work activities that your team will need to perform before you can approach an upgrade. This gives you the insight you need during the request triage to assess whether your team can take on the work and when, or whether you need to park the request in the parking lot list until you have more capacity.

Another benefit from looking ahead to the next version is that you will be aware of the features and capabilities it will offer. This will help you avoid developing or purchasing those capabilities if you can avoid doing so by delaying until you upgrade to the next version. When users request features that you know Microsoft has developed into the next version of SharePoint, you will have a good explanation for why you would rather delay and leave that request in the parking lot.

One good trick to stay ahead of the curve is if you can get on some sort of early adopter program with Microsoft. It has gone by catchy names such as Technology Adoption Program (TAP) and Rapid Deployment Program (RDP), and essentially, it involves you deploying early alpha and beta versions of the next version of SharePoint into your organization’s production environment. This also gives you a chance to provide feedback directly to the product team. A warning though: this is not for the faint of heart. You read that right a couple of lines ago, I did say deploy to production.

You can also plan to deploy a pilot farm of the next version once it ships. This will allow you to learn about the features and to start getting a sense about the impacts and dependencies you will require. You might even go through a trial upgrade, and this will give you a good indication about what an actual upgrade will require. Again, this will all help you understand what it will take to perform an upgrade and where you can fit it on your roadmap, so that if your demand funnel begins to process requests for an upgrade then you will be prepared to triage them.

Evaluating Third-Party Products

Another area in which your demand funnel may collect requests is for third-party products. Your internal customers may find a third-party product that extends SharePoint to provide additional functionality, and this functionality may fulfill a business need or add value to some business process. This is not a lot different from your approach to evaluate and plan for an upgrade of SharePoint itself. However, a typical third-party product does not usually require as many dependencies that require your attention as a SharePoint upgrade would.

Third-party products can range in size and complexity, from a simple SharePoint App or web part, to a complex server application. They contain some level of new functionality that they add to a SharePoint farm. These products may affect the entire farm or just a single site. Even though their size and scope varies, the process I use to evaluate third-party products remains consistent. I treat them all as new components that pose a potential risk to the SharePoint farm and the overall stability of the SharePoint service.

There are many third-party products available in the market that vendors sell as an install package for your SharePoint farm. In addition, you can find many open source projects that you can download and install in your farm. I treat both commercial and open source solutions in a similar fashion and consider them both as third-party products. They both offer new functionality and enhancements to extend the SharePoint service, and they both require a similar evaluation process to ensure the product is a suitable match for your environment.

Third-party products do involve some complexity, and this is why it is important for you to give them extra consideration through your demand funnel and request triage. The challenge can be that users have a perception that a packaged solution should be easy and straightforward. After all, all you have to do is install it, or so they assume. Unfortunately, there is more to it than that, and this is where a little extra rigor can help you. I like to focus my attention on a few key areas to evaluate a third-party product. The following lists my considerations when I am selecting a vendor and a third-party product solution.

• Evaluate the product’s functionality
• Test the product’s stability and compatibility
• Assess the vendor’s support policy
• Project the product’s upgradability

Of course, price is an important consideration as well, but for now I will assume you have an internal customer offering to fund the cost and you are deciding whether to install the solution in your farm. Notice that the functionality makes up only a part of my overall considerations. I am much more interested in how stable a product is and what level of support I can expect for it. I care the most about what types of implications it will have on my eventual upgrade efforts, whenever they may come, and how well I can sustain the product.

Assuming you want this product, you might also want to pilot it on a pilot or staging server farm. Eventually, you will be ready to actually deploy the software components on your production server farm. Once installed, you will need to configure the solution and finalize the deployment. Some third-party solutions may also have integration, migration, and training requirements. All these evaluating, testing, deploying, and configuring activities have dependencies you need to consider and factor in to the overall decision. If you have decided to move forward with the third-party solution and you have thought through all these details, then you are ready to update your roadmap with the work activities.

Before you begin to select third-party solutions, you may face the question of whether to develop the solution internally, or purchase a product. I refer to this as the build versus buy decision. This decision is not always as straightforward as it may seem. However, you can go through a similar process as I discussed previously and consider the different products with their support and long-term sustainability. If a vendor offers the solution that you need, it meets your evaluation criteria, and it is cheaper to buy or license than to develop yourself, then you likely want to buy the solution.

If you cannot find the right solution or something about developing it yourself makes it cheaper or more attractive for you, then you likely want to build the solution. One reason this would be true is if you want to license or sell the solution in the future to recover some of the development costs. Another might be for competitive reasons, where you create a competitive advantage and a point of differentiation by developing your own custom solution. I discuss development considerations in more detail throughout the chapters in Part IV of this book.

Piloting Enhancements

I have mentioned deploying pilots a few times in this chapter and in other places in this book. I truly believe in using pilots and proof-of-concepts as tools to vet requirements, designs, dependencies, and estimates. Everything is simply theory until you deploy actual working software and have users begin to try to use it. Theories are useful because they help us to understand problems, to build hypotheses, and to think in abstract terms to solve complex problems. However, much remains unanswered while you consider theories. You can glean information about the feasibility of an approach or a solution quickly by running a pilot or a quick proof-of-concept. This gives you a chance to test your theory and some of your early hypotheses. Pilots give you and your team a great chance to validate your ideas and confirm a particular solution.

Pilots also give you a chance to learn from your users. Because you are putting working software in the hands of users, you can observe to see how users interact with the software and whether it meets their needs. You can validate user requirements and you can refine your understanding of user requirements as they use the software and explain why it does or does not meet their needs. This helps you confirm that you are working on the correct solution and that it delivers the intended business value.

Through a pilot, you can also learn about what types of support requirements it will require and what user training you will need to accommodate. It gives you a chance to learn about how much effort it will take to deploy as well as a detailed list of the steps involved. It will also help you uncover any hidden issues or challenges you otherwise might not be able to predict. This helps you learn about the solution’s implementation details and it enables you to fine-tune any designs early in the process.

Ultimately, piloting reduces the risk by proving the feasibility of a solution and validating that it meets the business needs. It aligns well with the gradual approach of incremental and continuous improvement by introducing a small change. Once you have piloted it, you can then plan to deploy it into production. Not only do I like to take small incremental steps as I deploy new features and enhancements, but I also like to take small incremental steps with how I deploy them. By piloting, I can restrict how much I affect to a limited number of users in a controlled and non-production environment.

To set up a pilot, you can deploy an isolated farm. This helps you to keep your pilot separate and avoid affecting your production environment. I find an isolate farm works best and it offers the most flexibility because you do not have to worry about affecting normal operations if you need to perform maintenance tasks such as restarting a server or deploying an update. It also offers you the option to deploy different product versions. Most importantly though, an isolated environment ensures that you do not leave any artifacts and the like on the production servers or in the production database after the pilot concludes.

One approach I usually take to manage pilot environments is to use virtual servers. I find this makes it easy to rollback changes, which allows me to test ideas without worrying about causing a lot of extra work for myself. Using virtual servers gets a pilot environment up and running very quickly. On a project, I am constantly in a state of wanting to pilot things and prove concepts, something I can practice when I make the process of provisioning a new pilot environment as quick and easy as possible.

To achieve this ease, I prefer to set up a virtual server with the SharePoint software and all its patches installed, but not configured. I use a PowerShell script to quickly provision a farm after I clone the virtual server. I provision the farm using a shared SQL Server database server, often a cluster in a lab designated for test and pilot farms. Figure 9-3 illustrates an example of a pilot farm consisting of a single server sharing the same SQL Server database server as a production farm with load-balanced SharePoint web servers.

I try to avoid sharing the production SQL Server instance whenever I am provisioning farms where I want to perform load or stress testing. Whenever I expect a pilot farm to consume excessive database resources, I also avoid sharing the production SQL Server. Typically, this would be for applications that consume heavy processing or memory resources on the database tier, such as business intelligence or analytics applications. I would separate these more resource-heavy applications so as not to negatively affect the production farm during the pilot.

Estimating Cost-Benefits and Business Value

At some point, you probably need to calculate a rough estimate on the cost of the solution and its projected benefits. You can use this information to help you prioritize the work required to enable the solution, and this can help you determine where to schedule it on your roadmap. You might already have a good idea about what the expected costs are from considerations such as your build versus buy decision, your effort estimates, and the licensing costs. This gives you a great starting point and it provides a reasonable rough order of magnitude on the costs involved.

In Chapter 3, I discussed some considerations you can use to map SharePoint features to business value. I also looked at some approaches for how to calculate a dollar value for any efficiencies or savings that a solution introduces. Those are still certainly useful and they provide you with the most accurate business value information, but they can be time consuming to calculate. To work around this and get a reasonable indication of the potential business value, I like to assign a category for a rough order of magnitude during the request triage. This gives me a sense about the scale of potential business value and I can use this to get a sense of its priority.

Table 9-1 lists several sample cost-benefit categories you can use as an indicator and an estimate of potential business value. This can help you make an initial assessment based on limited knowledge as you process a request in your demand funnel. In your request triage, you can use this information to help prioritize the item or to schedule additional analysis of the potential business impact and business value.

These categories help give you a rough sense about the type and degree of business value a potential solution can provide. You can reword them, add or subtract, or adapt the list to fit with how you and your team can visualize categories of potential business value. The point is to use something that gives you a sense of the business value and that supports your decision-making during your request triage. This helps you increase your effectiveness and your efficiency as you process your demand funnel, and that helps you to avoid an overwhelming sense of demand. It also helps you avoid having low-priority requests pull you off track.

Meeting Demand and Fulfilling User Needs

The one thing your demand funnel is not is a means of resistance to change. I mention this because too often, at least for me, an IT group may come across to its users as resistant. Often this seems to stem from IT facing their own constraints: resource constraints, budget constraints, and even regulatory constraints. These constraints are important and they are a legitimate reason why you cannot meet a user’s request. However, when you become overly fixated on your constraints, then you often come across to your internal customers as resisting their needs. I have sometimes heard jokes related to these perceptions where stakeholders refer to IT as “the department of ‘No’” – a particularly negative perception.

How can you avoid these negative perceptions when constraints are a reality of any operation? I already discussed how you cannot be everything to everybody. How can you avoid becoming the department of No even when you have to say no at times? The answer is the reasoning behind my entire demand funnel process. When you encourage stakeholders to participate in the decisions and you offer transparency behind the trade-offs and decisions, you show you want to work with your internal customers. You validate their needs and work to collaborate with them to fulfill those needs where possible.

The outcome can often be the same in both approaches: you might be too constrained and unable to deliver on a particular request. However, I have found the perception in the collaborative approach of managing and processing a demand funnel generates a perception of teamwork and service, not resistance. This creates a department of “Let’s see what we can do together!”

As you build this collaborative cycle, remember that you are the expert there to analyze their business problems and envision solutions for them. You are not there to simply take an order and then go off to start fulfilling the list of requirements they gave you. Your internal customers are domain experts in their business process and they can provide you with details about the problems they face or the opportunities they perceive. Your job is to analyze this information and design a graceful solution. Therefore, your demand funnel is not simply a list of wants in the form of a checklist of items that your users submit. Instead, it is a list of solutions, each of which you can trace back to specific business problems or other needs.

Consultant Comrade

One thing I like to do when I engage with a new client is to start with an envisioning engagement. In this, I can deploy a pilot SharePoint instance with a default install and basic functionality for whatever the client wants to utilize. I like to keep this part very quick and very basic – no bells and whistles or fancy features, just out-of-the-box functionality. I like to start here because I have found that clients can easily start dreaming about all the magical things that they think SharePoint can do for them. When they have a basic pilot deployed that they can try out, then this resets some expectations.

This pilot SharePoint deployment gets my clients using SharePoint and in the process, it sets their expectations. In setting their expectations, I am also managing my own demand funnel because when they see it working, they keep their requests from drifting too far from the general area of what we want to accomplish. When SharePoint remains only in their imagination, it seems to be harder to see the relation between it and their feature requests, and thus it gets easy for them to wander off course into unrelated areas.

I mentioned in Chapter 8 that I like to use this pilot SharePoint deployment to set up a survey and begin to collect requirements and feedback from my potential users. Here is another opportunity to begin to guide your client’s SharePoint usage and adoption. When I worked for Microsoft, we called this dogfooding our products – this is where Microsoft IT deploys a product internally and the company uses it to support the business functions to ensure the product is ready to release to Microsoft’s customers. If your customer does not have TFS or some other work item tracking system, then setting up a pilot SharePoint deployment and SharePoint lists to track risks and requirements is another great way for you to get your customer dogfooding SharePoint early.

As a consultant, you can add a lot of value to your client by helping them to establish this process. If it is a new deployment, then you can get them started with a pilot deployment. Moreover, if they have an existing deployment that you are helping them enhance or stabilize, then you can still help them get started with this process by having them list and prioritize your tasks in a SharePoint list. Once they build out a list, you can work with them to work through the request triage.

I find that sometimes when I help to prime the process in this way, it helps give clients confidence on how they can continue the process after my engagement with them ends. Another effect that this has is we start building a parking lot list together. Usually by starting the parking lot list with them, I help them work through any anxieties or resistance to parking an item for some undetermined date. This usually helps my client to see that it is okay to save some items for another time and focus on the truly high-priority items.

This has two effects: your client internalizes the process under your guidance, while you also get them started with prioritizing and organizing your work. Through this pilot and envisioning engagement, you can guide them toward disciplined practices that will help manage scope during your project delivery, but it will also lead them to continue with the good habits after you roll off your project. They will ideally adopt the triage and parking lot habits that you teach them, and this will help them plan future enhancements in a sustainable, disciplined manner.

Other benefits you realize from getting your client started with a triage process are scope control and expectation management. As new requirements or enhancement requests come up, you can give your client practice with a triage meeting. This is great because it helps build their skills and confidence with conducting a triage, but it is also great because it forces them to face the trade-offs in your project scope as well. If you are engaged to deliver a portal and all of a sudden they want a full enterprise content management solution as well, then you can help them work through the triage for this chunk of work.

Rather than dismissing the item by declaring it as out of scope or too large of a piece of work for your resources to achieve, you can walk them through the process to where they come to that conclusion on their own. In my experience, this helps them internalize and understand why something is too large and complex to simply tack on to an existing project scope. Whenever I have tried to just declare it as out of scope or too large, frequently people on my client’s team resisted and maybe even resented that I was excluding something from scope.

I have found this resistance is because they are usually interested in a capability within SharePoint that they perceive as valuable, but that they do not know much about, particularly with the ramifications of tacking it on to our current scope. However, when I work through the triage with them and I start to discuss the rough order of magnitude I would require in effort and the trade-offs for the current initiative, they get a better sense of what it would involve and they are more likely to accept that it is not feasible within my present project.

For me, when a client seems emotionally invested in a capability that I am not there to deliver, I like to pay particular attention to any dependencies involved during a triage session. Once they start getting a sense of the dependencies, I reframe what may appear to them as a simple capability and I start breaking it down into all the pieces of work that need to occur. For example, if they suddenly become interested in records management, I walk them through all the activities such as content classification, enterprise taxonomies, retention policies, and the like. Once they begin to understand the scale of business analysis that this capability would require, they get a sense for how quickly this would take us off course from whatever else I am there to deliver. Only then are they more likely to accept the approach and the project’s scope.

This may seem as if it is a time consuming effort, but it gets your client into good habits and it helps you manage scope. Best of all, it can help you help them build a roadmap of future opportunities that you can help them deliver. This keeps everyone focused on the current priorities and it ensures that everyone understands what tradeoffs any changes to scope would require. In my experience, this has been the only consistently effective way to negotiate an acceptance of scope with all the project stakeholders.

Inside Story: Notes from the Field

Years ago, I worked for Electronic Arts (EA), a video game software development and publishing company. I worked in the worldwide IT department and I was based in Vancouver, Canada while most of my team operated from Redwood City, California. Despite any of the benefits that I may have realized if I was in the same location as my team, having the team spread out helped provide access to different internal customers. I am a firm believer that nothing beats face-to-face. I love how far technology has come with video conferencing and the like, but it still does not beat face-to-face interaction with users and stakeholders.

EA had a couple of large studios in the Vancouver in those days, but they have since consolidated those into a single studio in the area. Each studio runs in a semi-autonomous fashion with their own leadership and they focus on the game titles that the studio develops and needs to ship. Game titles roll into franchises, which loosely map to studios. EA also has a large publishing division responsible for marketing and distributing the games to retail outlets. Some of these publishing units share locations with studios, and some have their own locations. Each location has their own needs and priorities to support their teams (some game teams can have 200 or more people, while others have just 10 or 20, depending on the franchise and the title).

These quasi-independent studios and publishers exist all over the world. Some are small and can adapt to whatever service is already in use by the larger locations, while other locations such as Vancouver are large and demanding. My job was to provide a global SharePoint service consisting of multiple farms on multiple continents, serving a diverse set of needs. The challenge was to prioritize my resources across my internal customers. This, of course, was not just a challenge for the SharePoint service, but held consistent across all of what my team referred to as service lines – the different platform services we offered the business.

One way IT approached this was to collect and funnel the demand from each of our internal customers. For our larger customers, such as the Vancouver area studios, some team members acted as account managers. These internal account managers engaged with the business, working to understand their needs and priorities. They then funneled this demand back to the worldwide IT group to triage and prioritize. For major projects, IT maintained a plan of record. This was a prioritized list of approved and funded projects for the upcoming period.

For me as the SharePoint lead, I coordinated between two lists of projects. For major projects, the IT executive level funded and scheduled these. They would triage and prioritize the work for me, coordinating resource availability and change management across the different service lines and other organizational constraints. I would contribute some items to the demand funnel and offer recommendations for the triage process, and then I would work through the process with the rest of the IT organization. Once the plan of record is set, then I could adapt my roadmap and service delivery plan based on the projects approved and planned for the next couple of quarters.

For smaller or more routine projects, I managed the backlog and triage process within the SharePoint team. There were constantly quick wins or value-add opportunities rising. The prime candidates for me to deliver were those that did not require significant funding or resourcing. I like to think of these sorts of opportunities as low hanging fruit – the bounty I can easily reach and quickly deliver value to the business. These types of activities add incremental value, and I prefer to evolve a SharePoint service by adding incremental value rather than through large projects. This lowers the risk and delivers value quickly.

To give an example, when I wanted to deploy an enterprise search platform, I included this in the plan of record because it would involve resources to analyze the different content sources I wanted to index and the different user experiences I wanted to provide. At the same time, some of our internal customers wanted access to add an RSS feed to their team sites. This was before the RSS feed web part came as part of SharePoint, so I looked at developing my own. Because I could build a basic RSS feed web part with little risk and use it to satisfy several internal customers, I prioritized this against my team’s capacity and delivered it as incremental value.

Other activities I included in my request triage process were consolidation and migration efforts. I had a bloating of SharePoint farms across the organization. There are many reasons for this: some came through company acquisitions, some I inherited from other teams, and some were simply discovered as a covert service deployed under someone’s desk. If you have ever been involved with a large-scale migration effort involving hundreds of sites and thousands of users, then you share my pain and know what is involved. I needed to schedule downtime, URLs had to change and caused broken links, and in some cases I wanted to promote sub-sites to their own site collection.

I could not migrate everyone all at once, because teams were on different schedules. I did not want to simply move an entire web application to consolidate farms and retire servers. Instead, I wanted to reorganize and correct some of the issues I inherited, and part of this involved this migration effort. Even though this is more a maintenance task, I still processed it through my request triage because it involved effort and required prioritizing. By using the triage process, I was able to coordinate my migration efforts with other initiatives. This allowed me to regularly work away at the backlog of sites I wanted to migrate or reorganize.

This example shows how you can coordinate between different types of initiatives when prioritizing resource activities. Your demand funnel can funnel requests from the business and requests from the service delivery team. I consider these latter activities more as investment requests – those requests users might not care for and probably did not ask for, but that the team knows will improve or make the service more manageable in some way. It also shows how you can use your roadmap to coordinate activities with an organization-wide list of IT projects with your team’s list of smaller initiatives.

Wrapping Up

In this chapter, I discussed approaches to setting up a demand funnel for enhancing and expanding the SharePoint service, including considerations for establishing a triage process. I looked at ways to set expectations, build a parking lot list of enhancement requests, and how to map requests back to your roadmap. I also considered the need to forecast future upgrades to plan for their eventual impact, and I looked at when and why you might want to pilot enhancements to learn more about their impacts and to validate their underlying requirements.

As you funnel the enhancement requests through your demand funnel, it will lead you toward growing and expanding your SharePoint service to offer these new features and capabilities. Some of these enhancements will consume additional resources on your servers, requiring you to grow and scale your SharePoint farm. In the next chapter, I look at how to plan for growing your SharePoint farm. I consider the scalability and expansion capabilities architected into SharePoint and how this allows you to avoid over architecting the farm up front.