In this chapter, I focus on the process for creating a vision and a roadmap that describes what a SharePoint service will evolve into over time. I discuss approaches to building a timeline view of enhancements that provide an at-a-glance view of plans and the timing for the SharePoint functional capability areas. From there, I offer you some considerations for prioritizing and identifying dependencies between capability areas. Finally, I provide a sample visual roadmap that builds on each of the core SharePoint capabilities to continuously evolve the service and enhance the value it offers.

One key point I stress throughout this chapter is the need to pace rollouts and transformations, because your team only has so much capacity to deliver and your end-users only have so much capacity for change. A roadmap can help you set that pace and provide direction on where to go next.

After reading this chapter, you will know how to:

• Eat the SharePoint elephant
• Describe the value in a roadmap
• Assess your maturity level as an IT organization
• Plan your big picture feature areas
• Understand your users’ capacity for change
• Pace changes and transformations
• Create a roadmap for your SharePoint service

Eating the SharePoint Elephant

One especially beautiful aspect of the SharePoint architecture is it can expand and adapt to changing needs and situations. As an organization’s needs evolve, they can also evolve their SharePoint deployment. This capability of the product is particularly helpful to support organizations that take a phased approach to deploying SharePoint in smaller manageable chunks over time. A big portion of the value SharePoint delivers is the vast degree of capabilities that address a diverse set of business needs, yet achieving this value can often feel overwhelming for anyone who tries to do it all at once.

Taking on the breadth of SharePoint feels like the adage of eating an elephant. Like an elephant, SharePoint is smart and it has a fantastic memory, and it is also quite large. The best way to eat an elephant is to cut off smaller pieces and eat those. Then, when you are ready, cut off the next piece and eat that. As you continue that cycle, eventually, you will have eaten the elephant. Likewise, rather than trying to tackle every aspect of SharePoint at once, it is best to focus on smaller pieces.

When you try to eat an entire elephant, you will eventually hit a wall that will drag you down. It will eventually sink you. Plus, it would take a long time before you deliver any value, if you eventually make it to delivering value. You can take a divide-and-conquer approach and break it up into different work streams where different teams attack different parts, or you can break it down into phases that focus on delivering incremental value.

This advice sounds a little obvious, but I see it constantly on projects: customers of the SharePoint service get so excited after looking at all the capabilities and value available in SharePoint that they start wanting everything right away. Sometimes the hunger for the range of benefits available in the product grows too tempting and you end up trying to swallow everything all at once. Before you bite off more than you can chew and end up choking, pace yourself; you will get there. Hold yourself back and do not blind your better sense by the delicious buffet in front of you. Even though people will push for more, and your mind might play tricks on you as it tries to talk you into overloading your plate, you need confidence that the rest will eventually come. You will eventually cut off another piece of the SharePoint elephant and enjoy that too.

When you find yourself caught up and pulled in different directions, it not only distracts the delivery team, but it also compromises the probability and the degree of success the team can achieve. That is not to say that you should ignore all the value from those capabilities. After breaking it down into manageable chunks, small discrete phases with a beginning and an end, you can then schedule the individual phases. Over time, you can eat that SharePoint elephant and eventually you will realize all its different benefits.

For me, it is critical to break up larger SharePoint ambitions into chunks. You might have a bureaucratic process or your procurement department just might not want the added overhead to deal with smaller chunks, but you can work around these concerns. You might bundle a series of smaller phases into a larger funding budget, and this will allow you to secure the budget but still treat each part as smaller distinct phases. Or, you might just push back and accept the added administrative overhead because of how valuable a smaller phase can be to you. However you get there, the more focused and discrete each chunk of work is, the greater I find the chances of success.

Often you just cannot work around an amalgamated procurement process or you only have the nerve to ask to procure consulting services once. I sometimes refer to this as not wanting to go back to the well again. Another reason is that you might be trying to upsell your internal customer or your client to commit to a larger project. There are many motives pushing you toward piling too much on your plate, but they do not have to drive individual phases (or courses). One approach is to set a master budget for a larger program and then establish the scope of a limited, focused phase that has both project objectives as well as a defined shutdown point if things veer too far away from the plan. This approach can provide the same structure as a series of smaller projects.

I find structure helps to deconstruct the process into manageable pieces. Just like how a dinner menu helps to divide and pace courses of a meal, you need a structured way to divide and pace how you will approach SharePoint. Enter the SharePoint roadmap. A SharePoint roadmap sets the priority of functional areas that relate to business value, arranged on a timeline or through some other organization strategy that coordinates activities and work streams.

Understanding a Roadmap’s Value

A roadmap’s value stems from building a clear picture of where you are going. Think about a paper roadmap you would unfold and use on a drive across the country: it lets you know which highway to drive, what turns are coming up, potential checkpoints to track your progress, and the like. You can unfold it and see the big picture, or fold it up to just have an immediate view of the route. You can also have several roadmap versions to provide different levels of detail to view the journey, such as city maps with neighborhood details and country maps with only the main highways.

When I was a child, my family drove across Quebec, a province in Canada, and I remember tracking our route on a roadmap. I could see where we were going and I could talk about the highways coming up, and I traced our progress by marking the route we travelled with a highlighter. We could see our progress at a glance, as well as how much driving remained (it is a large province and takes a full day to drive across). When I build SharePoint roadmaps, I like to model them on this same concept and have them communicate where the SharePoint service is going, what I can expect, and how far I have progressed already.

Your SharePoint roadmap provides value in a similar fashion: you can track your progress from where you have been and set expectations on what to expect with where you are going. Most of all, it helps to set the pace at a time when you do not face the pressure of delivering everything at once – you can take a step back and build a roadmap with a clear understanding about what the priorities are and what your team can reasonably deliver in a phase. You can use it then to relieve any pressure by pointing out when you plan to address any particular needs and why you slated them for when you did.

A roadmap highlights priorities of activities that you want to address and feature areas you want to release. In addition to its value as a planning tool, it communicates these priorities well. It calls attention to dependencies between phases, which can have a significant influence on the order you approach development activities and releases. It also points out how any changes will affect plans for other phases, either in the trade-off you have to make in your limited delivery capacity or in the workarounds for any dependencies. Often with this information, what might otherwise seem like a small change that requires little effort instead enables you to properly assess the impacts.

You just cannot be everything to everyone, and having a roadmap will help keep you from drifting off into the abyss trying to be everything to everyone. I find a common scenario involves an internal customer who somewhere along the way developed a tendency to try to yell the loudest or exaggerate the urgency of their request to have the IT service delivery team address their needs. If a team is used to trying to be everything to everybody, then it bounces from issue to issue without any triage process to handle requests. As a result, they train their customers that they need to stress everything with urgency and yell loud to get the team’s attention; otherwise, they may just fall through the cracks. A roadmap helps to prevent you from having customers pull you in every direction as you try to respond to what sounds important.

Roadmaps give you and your team focus and direction by helping you to avoid falling into short-term reactionary and chaotic situations. They set the bigger picture context for the rest of your governance strategy and operational priorities. They make budgeting and resourcing convenient because they can give you a sense of the required effort’s rough order of magnitude. You might even find that roadmaps contribute to a team’s motivation as everyone can see where the service will eventually go and how different pieces build on each other to get there, rather than a misguided impression that a piece of work is unnecessary or a lower priority. This transparency and insight into where the service is going can be beneficial to support your planning process, your customers’ expectations, and motivate your team. It can even be beneficial to share with your vendors.

Why would you share your roadmap with your vendors? Often I find an outside consulting firm will have a beginning and an end to an engagement that you contract them to deliver, and this set duration and set deliverables tends to limit their perspective. Although they are probably interested in your long-term direction, their primary focus is on what they are delivering in the short term. By sharing your roadmap, you help them to avoid making any assumptions about your direction and your priorities. It can help them provide you with the best advice, and of course, it can also help them plan how else they may be able to offer to help you.

Another area your roadmap can help with your vendors is through a Request for Proposal (RFP) process. Often times I see an RFP process is less effective than it could have been because they tend to concentrate on functional requirements. By sharing your roadmap, potential vendors can see where you are going and what your ultimate goal is. They do not have to make as many assumptions about where your priorities lie and what will depend on the work they deliver for a particular RFP. They can also help you as you plan your RFP, because you will know more about the desired outcomes rather than a vague sense of configuration tasks. You will also have a better sense of the constraints to specify for your vendors so that they do not make incorrect assumptions in their pursuit of a low-price bid, which could ultimately limit your SharePoint service. Without a roadmap to help ensure vendors have the full picture, these shortfalls might not be apparent until later.

On top of all this, your roadmap can serve as a baseline and something everyone can turn to and share a common understanding about the direction and goals of your SharePoint service. It is a reference point for future requests or enhancements because it communicates the plan as well as the trade-offs necessary to adjust and reprioritize the plan. It can also help to focus attention and to help you think through opportunities with the product – perhaps there are hidden uses that people can use it for that you will discover in the process.

The other thing I like about roadmaps is how they communicate the big picture with all the dependencies and required capacity. People have their own agendas, and a roadmap will help manage their expectations in a way that can help reduce the motive to bloat an earlier phase with things the roadmap slated for later. It also helps your team see your ultimate direction with the SharePoint service, and this helps them avoid making decisions that will limit you later.

I have found that roadmaps offer value in so many ways. They help give you and your team direction, they help to set everyone’s expectations, and they can help your vendors and partners provide you with better service. In the next section, I look at where to start with building a roadmap and then I discuss other considerations for your roadmap planning throughout the rest of the chapter.

Starting with a Roadmap

Sometimes, you might find it obvious where to start with a roadmap, particularly if you have a series of feature areas that will build on each other. Your roadmap could be as simple as putting them in order on a timeline and that is as much as you need. In this case, your roadmap strictly focuses on features you want to deploy and you are using a roadmap as a scheduling tool. This is a perfectly legitimate and useful roadmap, and I return to this approach later in the chapter, but first I share some other aspects that I often include in roadmaps because of the value that they can add.

I usually start by assessing the IT organization’s capabilities, and I do this by determining their maturity level in a range of categories. This comes before listing the major feature areas, because I often find dependencies between a capability level and a feature area. For instance, if the maturity level of the organization is still early in a developing stage for a category such as enterprise search, then the roadmap will need to reflect a plan to evolve enterprise search from what is possible in their environment and with their capabilities currently to the maturity level they want to reach.

The capability and maturity model that I am most familiar with is the Infrastructure Optimization model that Microsoft uses. For SharePoint, Microsoft has the Business Productivity Infrastructure Optimization (BPIO) model, and this includes capabilities listed at different maturity levels. This model is a bit dated now as it was more popular a few years ago, but I find its concepts are still useful. They have divided the maturity levels into four stages: Basic, Standardized, Rationalized, and Dynamic. Understanding what your maturity level is for a particular capability will help you identify your roadmap plans to evolve and mature your organization for that capability.

I find there is a danger in building a roadmap driven by the feature areas you want to deploy. This approach can risk leading you into a situation where you find yourself deploying aspects of SharePoint just for the sake of deploying SharePoint. Whereas when you start with a capability assessment and use your desired maturity level to drive the roadmap creation, you maintain a business focus. This leads to a roadmap that links to organizational goals and business value. Start by building out a chart that models different maturity levels for capabilities that interest you.

One option is to use the BPIO model from Microsoft, as it already has a list of SharePoint-related capabilities and their maturity levels. Microsoft based the BPIO model on other maturity models, particularly on the work Gartner did. Table 7-1 lists a few common maturity models and their respective maturity levels.

I discuss how to assess your maturity levels more in the next section. For now, you can consider which maturity model that you would prefer to work with. Once you pick a maturity model, then you can assess your organization’s maturity level for each of the capabilities that interest you. Your next step is to recognize the desired maturity level that your organization would like to mature to for each of the capabilities, and then identify the gap. You can use your roadmap to build a plan to fill any gaps.

When assessing different capabilities, I prefer to be pessimistic rather than being overly optimistic about which maturity level a capability fits. This is not a performance assessment to pat myself on the back and calculate how much of a bonus I deserve. It is a situational assessment that serves as a baseline for the growth and development plans in your roadmap. For the progress and maturity you achieve on the other hand, you can and should use this to assess performance and to pat yourself on the back once you achieve your target maturity levels.

In a capability assessment, I like to consider the gaps. What maturity level does my organization fit, and what is the gap between the current state and the desired maturity level? Most of these gaps relate to business processes and some relate to technology feature areas. These gaps are the tactical capacities that the roadmap addresses, and you can use the maturity model to prioritize and identify dependencies while you design your roadmap. As the gaps identify the major activity blocks on the roadmap and a sense of their priority, they also provide insights into the business value they can provide.

Estimating business value for capability gaps helps you to prioritize them on your roadmap. Along with the business value, I also like to estimate a rough order of magnitude for how much effort the piece of work will take. This information gives you a sense of the cost involved, and you can compare this cost with the business value you anticipate. This in turn offers even more help as you prioritize your roadmap.

I find it is sometimes useful to involve potential sponsors at this point. You might not seek their commitment as sponsors, but you can share your roadmap and solicit their feedback. You might interest them in the maturity assessment and gaps that you identified so far, and they might have valuable insights to contribute. Your potential sponsors might be managers within your IT organization or managers from the business. Even if you are not ready for formal sponsors at this stage, this is a good chance to get your initiatives on their radar.

This probably feels like a strange time to bring up sponsorship considering I am this far along in the book. Sponsorship is important and I devote Chapter 12 to additional aspects of sponsorship. That is in the final part of the book, and that probably feels even stranger because I noticed that sponsorship is usually one of those topics people seem to bring up first. I avoided bringing up the topic earlier because I did not want it to stall any of the governance progress that you can make before you have a sponsor established.

I have found that sometimes facing the daunting requirement to establish a sponsor can bring governance progress to a halt because it feels like a prerequisite you need to fill before you can make any progress. Sponsorship is valuable and can help substantiate your roadmap or any other topic I cover in this book, but as I hope you are discovering, there are actions you can take to build governance momentum even before you establish sponsors. For now, I just want to point out how you can use your roadmap as a good opportunity to engage potential sponsors.

I return to discuss sponsorship more in Chapter 12. In the next section, I look at how to assess your maturity levels and how this can help design and prioritize a roadmap.

Assessing Your Operational Maturity Level

The process to assess your operational maturity level is largely consistent across the different maturity models. Although each have their own approaches and practices that you may find useful, I focus on working through the core concept of maturing along a progression from a state of reaction into a proactive and intentional state.

To start, you might consider performing the type of assessment that I discussed in Chapter 6 when I looked at how to perform a root-cause analysis. You can use those assessment techniques to get a sense for how your SharePoint service is operating and where the trouble areas are. This also provides you with a handy reference for identifying your maturity levels for different capabilities. I find this can also help to give teams a dose of reality, particularly if they are blissfully oblivious to how basic and chaotic their operations are.

For my purposes in this chapter, I have adopted a hybrid of maturity levels and I use them for this discussion. You can use whichever model you find fits well with your organization. Personally, I like the naming convention of this hybrid for the maturity levels, because I find they are descriptive and less abstract than the others are. They do a good job describing the state of maturity for a particular level, so much so that you can often identify with just the name alone.

However, “feeling chaotic” is probably not scientific enough as an assessment. As such, the following lists the maturity levels and I have added a rubric for each that describes your general state of operations. Note that I largely base the rubric descriptions on my own blended process for assessing maturity levels with my clients, and these may deviate from how Microsoft or Gartner or CMMI defines their model. This rubric should help you recognize and identify your operational maturity level. Remember, this is not an exercise in trying to boost our egos; this is an assessment to understand a baseline and highlight the focus areas for improvement.

• Chaotic: You operate in an ad hoc, unplanned, and unpredictable manner. You do not have a complete inventory of deployed software and infrastructure. You do not automate your processes and you have not documented your procedures. You manually manage your infrastructure on an individual bases. You manually distribute desktop software. You discover and respond to problems by user call notifications.
• Reactive: You operate in a fire-fighting manner. You do not have business sponsors and your IT executive drives decisions. You have an inventory of deployed software and infrastructure. You have limited automation for your processes and you have documented some procedures. You have a centralized system to distribute desktop software. You discover and respond to problems through an alert and event management process. You implement a problem management process and you measure system availability.
• Proactive: You operate in a predictive manner. You set thresholds and predict problems. You have moderate automation for your processes and you have documented many procedures. You centrally manage your IT infrastructure. Your problem, configuration, change, asset, and performance management processes are mature. You measure application availability.
• Managed: You operate as an IT service provider. You have defined services, service levels, and pricing. You understand costs. You have maximum automation and integration for your processes. You have fully documented Service Level Agreements and you have linked them to business value. You have a capacity management process. You measure and report service availability. You have fully defined your governance policies and you have automatic reporting to enforce them.
• Optimized: You operate as a strategic business partner. You collaborate with the business to improve business processes and engage in business planning. You have fully automated the management of your infrastructure. You have real-time infrastructure management and provisioning. You measure and report on IT and business linked metrics.

Once you recognize the operational maturity level you most closely identify with, you will begin to get a sense of what your roadmap will entail. The rubric itself can uncover phases in your roadmap, such as moving from chaotic to reactive to proactive and beyond. You can use descriptions such as your level of automation, and build a plan in your roadmap to develop and evolve the types and amount of automation in your operational processes. This alone can help give you a sense of the high-level topics you can mature and progress.

As you progress through these maturity levels, your operational focus also progresses and matures. At the chaotic level, you primarily focus on leveraging tools. As you mature to the reactive level, you begin to focus on engineering operational processes. As you mature to the proactive level, you focus on engineering service delivery processes. As you mature to the managed level, you focus on service and account management. Finally, as you mature to the optimized level, you focus on managing IT as a business.

Again, I want you to notice that rich governance documentation comes later in the managed maturity level. Of course, you can generate documentation as you progress through the earlier maturity levels, but I want to stress that this is not the driver, and you should smash any expectations for jumping right to the detailed and sophisticated documentation and skipping the evolving nature in those earlier maturity levels.

I regularly see IT organizations and consulting firms try to “solve” governance by skipping the groundwork that will mature an organization. They seem to try to jump right to establishing an executive sponsor and detailed governance documentation. It reminds me of when I used to teach snowboarding at a local resort in the mountains near Vancouver, Canada. At the snow school desk, we had a menu of different types of lessons that correlated to different levels of ability. A level one would be someone new to snowboarding, and a level two would be someone who could link a few sliding turns with some success on a green run, and so on. Guests would come and they would want to skip the basics to jump right into the advanced skill they wanted to learn. The result would be a beginner snowboarder who lacked any balance and control signing up for a class to learn how to take jumps. They just were not successful and did not get anything out of the group lesson because jumping required that they had balance and control on the ground first before they achieved it in the air.

This is true for your SharePoint governance as well. You will have an easier time documenting procedures once you mature out of a chaotic or reactionary maturity level, when you can begin to look at your processes and procedures with an intentional emphasis. This change in perspective will allow you to act in a strategic manner where you align your operations with delivering business value, rather than simply attempting to adopt generic SharePoint policies that are popular on the web. The policies and procedures may be the same, but how you apply them and the value you derive from them will depend on your maturity level.

Your overall operational maturity level will give you a good sense about where you are operationally. It can also reveal where you would prefer to be. My clients often find it revealing when we meet and I present where they fit in this maturity rubric. They can recognize it and usually affirm they had suspicions but they now have a clearer picture of their maturity level. More revealing still is the other maturity levels, particularly the latter ones they can mature to and achieve. You might share their experience as you recognize your organization on one of the earlier maturity levels and visualize the operational excellence you can achieve in one of the other levels.

You can take this description of where you fit in the maturity model and the potential for operational excellence by maturing to another level, and you can use it to solicit buy-in and support for your SharePoint governance initiative. You can present a vision of how your operations can run at a more mature level and how that can benefit everyone. You can show where that will make a team member’s job easier or how it can make an IT manager look good. You can show how this can make your internal customers and end-users more satisfied. You can show how a progression of incremental improvements can lead you to achieve these benefits. Most of all, you can highlight how maturing your operations can lead to saving money.

Ultimately, I think that this maturity model can and should frame your roadmap and your entire SharePoint initiative. It highlights where you are and your potential opportunities and it provides direction on how to approach a progression. The different maturity levels can serve as wayfinders in your roadmap – they can establish major points along your journey to help you get your bearings and orient yourself.

Transforming the operational maturity level of your IT organization is an ideal, but it might be beyond your influence. Perhaps your reach is limited to the SharePoint operations, or maybe even just a subset of that. It is still good to assess your organizational maturity level to get a sense of the limitations and constraints that you will face. This could lead to change down the road, or it could just serve as a benchmark to guide your own SharePoint service planning.

Once you have a sense of your overall operational maturity level, you can begin to assess the maturity level for individual capabilities. You may have noticed that you fit with some aspects of a maturity level, but with other aspects, you are more mature. This is particularly true once you break down an application into areas of more granular capabilities. Every organization has its own priorities and may have matured particular areas more than other capabilities. In SharePoint, this can highlight different areas you want to mature and include on your roadmap. With our operational maturity level in mind, I next move on to identifying the capability maturity levels.

Assessing Capability Maturity Levels

As I mentioned in Chapter 3, I focus on seven core capability areas within SharePoint: collaboration, social computing, portals, search, records management, business intelligence, and composite applications. In this section, I step through each of these and look at some of the characteristics of each for each maturity level. This will help you identify your current state in a particular capability and where you would like to mature it. For now, I focus on assessing the maturity level, and in the next section I walk through how to understand the maturity gap and translate that into your roadmap.

The first core capability area is collaboration. With this, you assess the maturity level for how users collaborate with each other. Primarily, I focus on their process of creating and sharing documents as an indicator of a client’s overall collaboration maturity level. You can add other characteristics to this table, such as versioning and alerts. Table 7-2 lists the maturity level characteristics for collaboration.

The second core capability area is social computing. With this, you assess the maturity level related to people information. Primarily, I focus on how well users can discover each other as an indicator for a client’s overall social computing maturity level. You can add other characteristics to this table, such as colleagues and online presence indicators. Table 7-3 lists the maturity level characteristics for social computing.

The third core capability area consists of portal sites. With this, you assess the maturity level related to portal publishing, including intranets, extranets, and public websites. Primarily, I focus on the publishing experience as an indicator for a client’s overall portal maturity level. You can add other characteristics to the table, such as standards and accessibility. Table 7-4 lists the maturity level characteristics for portals.

The fourth core capability area is search. With this, you assess the maturity level related to the search experiences and capabilities. Primarily, I focus on enterprise search capabilities as an indicator for a client’s overall search maturity level. You can add other characterizes to the table, such as search analytics reporting and featured search results. Table 7-5 lists the maturity level characteristics for search.

The fifth core capability area is records management. With this, you assess the maturity level related to records management and its related processes. Primarily, I focus on assessing the records repository as an indicator of a client’s overall records management maturity level. You can add other characteristics to the table, such as legal hold and auditing capabilities. Table 7-6 lists the maturity level characteristics for records management.

The sixth core capability area is business intelligence. With this, you assess the maturity level related to the business intelligence reporting and scorecard solutions you develop. Primarily, I focus on how standardized the data and the centralization of business intelligence are as indicators for a client’s overall business intelligence maturity level. You can add other characteristics to the table, such as notifications and self-provisioned reports. Table 7-7 lists the maturity level characteristics for business intelligence.

The seventh core capability area is composite applications. With this, you assess the maturity level related to the composite applications you build and deploy. Primarily, I focus on how advanced the forms and related processes are as an indicator for a client’s overall composite application maturity level. You can add other characteristics to this table, such as web part development and Apps from the SharePoint Store. Table 7-8 lists the maturity level characteristics for composite applications.

These maturity levels and their respective characteristics for each core capability give you a place to start with assessing your current maturity levels. Remember, these are guidelines based on what I use to assess my client’s maturity levels and they do not represent an exhaustive list of characteristics. Depending on the client’s priorities for their organization and its operations, I will adjust these characteristics. Sometimes other characteristics will be more relevant to their business. This should give you a start and a good baseline, and you can use it as is or you can apply it to another maturity model.

With the SharePoint capability maturity levels identified for both the current state and the desired level, I move on now to look at the gap between the current and desired state, and how to apply this to your SharePoint roadmap.

Understanding Capability Gaps

As I mentioned earlier in this chapter, the gaps can reveal the details for your roadmap. Taking this perspective centers your roadmap on maturing your operations and your capabilities to align them with your organization’s goals, and this helps you to deliver business value.

You can identify the gaps by comparing the characteristics of the capability at different maturity levels between the level you are at and the level you want to attain. Although you do not have to step through each maturity level, you do have to address all the capabilities in a level on your way to the next level. Thus, if you want to move from a paper-based forms system to an electronic forms and workflow, you need to address departmental forms before you can reasonably achieve enterprise forms and workflow. You will also need to integrate your forms with line of business systems and processes before you can enable an enterprise-wide orchestration of forms and workflows.

Some gaps are larger than others are, and the gap size depends on how sophisticated and optimized you want a particular capability to be. This is a useful place to start listing any dependencies or existing constraints that affect filling a gap for a particular capability. Along with these dependencies and constraints, you can also look at whether you can break up a gap into phases to fill smaller portions of the gap at a time. At this point, it is also useful to estimate a rough order of magnitude for how much effort and how much related costs would be involved with each portion of filling the gap. In addition to effort, I also like to estimate any expected durations the work would take. Finally, and probably most importantly, I like to identify the expected business value that filling a certain gap will deliver or an anticipated business problem that it will solve.

Once you have these details, you can list the gaps you want to fill. Basically, this makes up the substance of your roadmap. When you have it in a list, you can begin to prioritize the order you want to address the gaps. You may address a portion or a phase of a gap at one point and then come back to the rest later in your roadmap. This helps to keep it flexible and it allows you to make some progress on a mixture of capabilities rather than having to over-invest in a single capability.

Other factors contribute to how you prioritize these pieces of work on your roadmap. Some relate to the importance of the customer or the wider business opportunity it will support beyond the immediate business value it delivers. Some relate to issues such as your users’ capacity for change or your infrastructure upgrade cycle, two considerations I come back to and discuss in more detail later in this chapter. At this point, you should have a working priority of opportunities for the different capability areas. As you work through the rest of the chapter, you can continue to reprioritize this list until you finally have a working roadmap that you and your team can use as a guide to mature your SharePoint service.

These capability gaps map to product features within SharePoint 2013. Next, I look at the big picture feature areas and how you can use the maturity model assessment and capability gaps to determine where to slot them on your roadmap.

Determining Your Big Picture Feature Areas

I first discussed determining your main SharePoint feature areas back in Chapter 3. One thing I discussed was how business value consists of the outcomes that a particular feature, capability, or composite application provides to end-users. I also discussed the technical aspects you can use to limit and later evolve your features over time. That discussion becomes useful again here, because part of your roadmap may include those features that you limited back in Chapter 3 and you still need a plan to enable them over time.

How you decide which features to enable relates to the priority list of capabilities you began in the previous section. I chose capabilities that encompass SharePoint feature areas on purpose, and I discuss these capabilities consistently throughout the book. This is why I divide the maturity assessment into capability areas and used this to help you consider the maturity level of each. Now you have a prioritized list of capabilities mapped to business value, and you have already associated a set of features to each capability.

As I go through this process, I look at the maturity levels separately and then I look at the SharePoint capabilities from a product perspective. Some things in SharePoint just go naturally together or build on each other with little extra effort, depending on what your goals are. These relationships might not be as apparent when you strictly look at maturity levels, so it helps to consider them from a product perspective as well. For example, a portal would probably benefit from including a search component. Adding search within SharePoint 2013 in a subsequent phase can enhance and complete the portal; and if the search phase only delivers a lightweight search with limited content sources, then it can enhance the portal without a lot of added effort.

These kinds of product decisions can help you reprioritize or fine-tune your priority list of capabilities and phases for your roadmap. At this point, you can review your list of capabilities and consider which are complementary to each other in SharePoint and how one can enhance another. You might consider breaking a capability gap down into smaller phases to deliver some lightweight functionality early, and then address the rest later when you reach its priority on the roadmap.

A constraint you face is that you usually cannot simply enable every feature, or at least you cannot expect wide-scale adoption rates if you do. One aspect of this constraint is your users’ capacity for change, and I discuss this more in the next section.

Understanding Your Users’ Capacity for Change

I mentioned the idea about people’s limited capacity for change when I discussed training and readiness back in Chapter 5. People can handle change if you make it easy on them and you set it along the path of least resistance. But too much change can stress people out, particularly if they are ever confused or unsure how to do something. Stress can erupt and cause a backlash if you do not relieve the pressure from time to time.

People can grow frustrated after a while of being in a constant state of change too. Everyone needs a break to settle and experience some stability at some point; otherwise, it eventually leads to fatigue, and this eventually leads to frustration. In my experience, I noticed this is not a gradual decline either. Things seem to be going well and everyone seems to be tolerant of the changes, and then all of a sudden it seems people are upset. Once you reach that point, you will have a harder time getting people motivated again.

It is a balance. On the one side, you do not want to change things too quickly because this causes stress. Yet, on the other side, if you drag the change out too long, this leads to fatigue and then to frustration. This balancing act depends on how dramatic of a transformation you are planning and how much tolerance your users have. It also depends on the nature of the transformation.

If you have planned to make extensive training and support resources available, then your users will likely have a greater capacity for change. Some of the strategies I discussed in Chapter 5 will help increase the capacity for change and can accelerate your timeline to implement a successful transformation. A successful transformation is usually one that is accepted and adopted, and you typically can only achieve these things with sufficient training and support.

Another consideration to understand your users’ capacity for change involves identifying priorities in the business cycle and how the job functions of your users relate to those priorities. For example, if your users earn bonuses and it is a particularly crucial time of the year to earn those bonuses, they probably will not have much capacity or tolerance for change. If your business is in the retail industry and it is sometime in early December, your users are not likely to have much capacity for change. If your organization is in the middle of a labor dispute and your users are considering job action, then your users will probably not have any capacity for change.

These are just some random examples, but they highlight the need to consider what is going on in the world of your users. The more you can understand about what else is vying for their attention and consuming some of their capacity, the better sense you will have with how much change you can successfully introduce. You may need to pace your changes to avoid interfering with their actual job duties.

As I mentioned earlier, you may also pace your changes to help ease the amount of stress the transformation causes your users so that they have time to adjust and get comfortable with one change before you introduce another. You might also pace the changes to give your project team time to deliver and implement those changes. There are many reasons why you might want to pace your changes, and in the next section, I discuss some strategies to help you set a pace.

Pacing Your Changes and Transformation

When I looked at capability gaps and feature areas, I suggested breaking some gaps into phases. The more you can break things into smaller chunks that you can spread across phases, the more flexible you will find your prioritization and scheduling of your roadmap. You will also find this handy for when you want to pace changes and transformations, whether to accommodate your users’ limited capacity for change, your team’s limited capacity for change, or your team’s limited capacity for project delivery.

One technique that project managers often use is they add lead or lag time to a task when they build a project schedule in a Gantt chart. Figure 7-1 illustrates the different between a lead and lag time. Lead time means a certain amount of time needs to elapse before work on a task can begin, usually an amount of time between a task and a preceding task. Lag time means a certain amount of time needs to elapse after work completes on a task before work on the next task can begin. When a project manager enters lead and lag time information in a project plan stored in software such as Microsoft Project 2013, then the Gantt chart can automatically update the schedule when earlier task durations change.

You can use this concept of lead and lag times on your roadmap to set a pace for changes. You also might leave a block of time to accommodate user training and adoption activities. As you review your list of capability gaps and phases, consider where you might include lead or lag times to accommodate any pacing requirements you suspect. You can use this information to help schedule activities.

This is also a good point to consider any busy periods in your organization’s operations that you might prefer to block off and avoid implementing any major changes. You might also consider popular vacation times when many of your users will be away, making this either an ideal time or a poor time for major changes, depending on the nature of your change and the level of user involvement you require. Gather these more global and enterprise-wide schedule impacts and requirements to help you further prioritize and refine the schedule of your roadmap.

As you build a list of schedule and delay requirements and align those with your prioritized list of activities, you will begin to get a preliminary sense of your roadmap’s schedule. This can serve as the basis of a SharePoint program schedule or a schedule for a series of projects. Alternatively, if you do not want to commit to dates on a schedule, it can be your roadmap for what comes next when you get time or budget. It can but does not necessarily require a scheduled date for when the work will take place if the majority of the roadmap is still tentative or requires approval. Sometimes you might use milestones or checkpoint gates to pace the roadmap, and if you have effort and duration estimates, then you can schedule the work tasks when you activate the next phase and you prepare to deliver its work activities.

I looked at capability areas and their respective maturity levels as priority drivers in many of your roadmap activities, but some activities might not be included in maturity characteristics. Some activities might relate to the underlying infrastructure maintenance and replacement schedules or the software upgrade cycles. In the next section, I look at considerations for capturing these activities in your roadmap.

Considering System and Infrastructure Upgrade Cycles

Eventually vendors release new versions of their software and hardware. Servers break down or newer models begin to look more attractive. This upgrade cycle is the nature of technology, and how frequent the upgrade cycle affects you depends on how cutting edge your organization is with respect to technology. For some, the cycle might be barely noticeable as you find yourself still content with using Windows XP for a little while yet. While for others, as soon as a beta version becomes available they start to think of the last version as now legacy software.

Whatever your upgrade cycle, it is important to include that in your roadmap. You might recall my discussion in Chapter 4 when I looked at all the roles and responsibilities that SharePoint depends on, and not just those directly involved with SharePoint. Similar to that, you also need to consider the upgrade cycles for all the systems that SharePoint depends on as well. For example, consider the coordination complexities you might face if you plan a major document repository migration without realizing it is at the same time the database team has planned to upgrade SQL Server or the storage team is replacing the SAN.

All this information will prove to be very useful. It can reveal additional dependencies or constraints that can help you prioritize the order and schedule of your roadmap, and it can save you headaches in the end. It can also serve as a check to help you verify that you plan for these work items and maintenance tasks. The following lists some examples of these types of external system considerations:

• Known system upgrade or replacement plans
• Infrastructure and network support agreements
• Infrastructure consolidation or virtualization projects
• Known software upgrade plans
• Expected software version release dates
• Expected system requirements for future versions
• Software support agreements

These can all help give you a good indication that you have not overlooked anything or overbooked a delivery as you build your roadmap. Sometimes you already know the upgrade dates for the foreseeable future, and they can slot right in on your roadmap, but other times you have to infer dates based on support agreements or changing minimum system requirements. On the other hand, you might be aware that you have to upgrade a piece of software, but identifying the date for its end of support lifecycle will help ensure you are not planning an upgrade after the software falls out of support.

Your team’s available delivery capacity is another reason you might include a major upgrade work stream on you roadmap, even if it does not relate to SharePoint and SharePoint does not depend on it. If another upgrade project utilizes part of your team or resources that your team depends on, then they probably will not have capacity to contribute to the planned activity in your roadmap. Planning for these upgrades, or any other major project for that matter, can help you design a dependable and realistic roadmap. This is just another dependency or another set of constraints that will help you plan a realistic roadmap.

Often I will represent this information as an infographic, usually with a chart listing the software and infrastructure vertically and time horizontally. I then add lines in the chart for each row to represent the support window and I add milestone diamonds to the line for activities that I will notate. Figure 7-2 shows an example of an infographic that details mainstream support dates for software.

I usually like to include an infographic of the upgrade and support lifecycle as supplementary information. In the next section, I describe a visual summary infographic that I like to create for the roadmap. I usually keep the upgrade and support lifecycle infographic separate because it can clutter and distract from the roadmap. Sometimes I will combine it if I need to stress an impending end of support date, but not often. Typically, I use the visual summary to communicate the roadmap with its details as concise as possible for effective communication.

Creating a Visual Summary Infographic

A visual summary might be the only part of your roadmap that most people read. People are busy beings, and they might not be interested in all of the details in your roadmap; perhaps they just want a synopsis of what affects them. Even your team, who are more likely to be interested in the details of your roadmap, will still find a visual summary useful since the most important information is available at a glance and they will not have to search for it in the document.

The other thing I like about a visual summary is how you can color-code it. Colors can add some energy to the roadmap, but they can also help organize information. You can put different phases in different colors, you can separate capabilities by color, or you can emphasize different priorities with different colors. You can even track progress by highlighting completed phases in a specified color. A few years ago when we on a project together, I noticed that my colleague Annie Kalfayan used this technique in her status reports, where she had a visual representation of the project stages and she highlighted completed stages in yellow. Ever since, I have liked this visualization as a progress communication tool and it can fit particularly well for tracking progress in your roadmap.

Inside a modern version of Microsoft Word, there is a feature where you can insert a “SmartArt” graphic. (Look for it on the Insert menu/tab). This does a great job at creating a visual infographic for your roadmap, particularly with the SmartArt in the “Process” category. I often use the Vertical Chevron List or the Staggered Process. I also like the Increasing Arrows Process when I create an infographic for onboarding. Figure 7-3 provides an example of a visual roadmap that I created using a SmartArt graphic in Word.

Visio also offers similar capabilities with richer features for diagraming your roadmap infographic. I find it easier to edit the styles and the structure of a graphic in Visio, and this is probably because I am more used to editing diagrams in Visio while I am more used to editing text in Word. You can also attach a Visio diagram to a data source, so if you are feeling extra keen, you can make your roadmap data driven and dynamic. You can also render a Visio diagram as a web page using Visio Services in SharePoint 2013. This makes it easy to add a visual summary infographic of your roadmap to your SharePoint site by rendering the Visio diagram directly.

Your roadmap documentation might consist solely of this visual summary. If you find this is all you need, then you are all set. Sometimes a visual summary fits my purposes just fine and then that is all I will use. Other times, I find a more detailed document is necessary to share information across the team or for funding purposes. Although even in those cases when I need to produce a roadmap with more details, I still include a visual summary. I like to include an infographic of the roadmap early in the document as a type of executive summary, and then continue with the rest of the document.

Once you move beyond a visual summary, what should you include in a roadmap document? In the next section, I discuss an approach to create a roadmap document.

Creating a Roadmap

In my roadmap documents, the visual summary is the essence of the roadmap. As such, I put it at the front of the document because this is often all many people will care to read. As you build out your visual summary of your roadmap, use the lists you created throughout this chapter to determine the priorities and scheduling requirements.

The visual summary carries most of the communication weight for a roadmap. Most people can grasp what you are planning and when each activity occurs after they look at your visual summary. Nevertheless, some people will look a little deeper and will want to understand why you prioritized it the way you did. Following the visual summary, I find it is useful to include a description and list of your constraints and limitations. You can also note any of your assumptions and any other information you used to prioritize your list.

After the visual roadmap and the supporting information, I like to include relevant schedule information such as the software and infrastructure support lifecycle schedules. You can also include expected vacation schedules and anticipated peak business periods. This is where you can discuss any lead and lag time you built in to your roadmap activities, as well as any adjustments you have made to accommodate your team or your users’ limited capacity for change.

One aspect that I find useful to include in a roadmap is use cases. These can describe the expected user experience for different facets and capabilities of the system as you progress through your roadmap. They can help to articulate any expected business value and they communicate expectations for the experience the roadmap is working toward delivering. You can include use cases for different types of users or different usage scenarios.

Another aspect I like to include in a roadmap document is a parking lot of deferred features or requirements. Here I can describe what I am not planning to address in the scope of the roadmap and I might explain why. Perhaps it is because I do not have the budget or there are higher priority opportunities. Whatever the reason, there were features I considered or requirements that were raised, and I excluded them from the roadmap. It is important to capture why, but I find it is especially important to capture the items themselves so I have an artifact to consider in future incarnations of the roadmap.

As you build your roadmap document, include any supporting information you capture or use to assess maturity levels or to make decisions about priorities. This information will provide others with background details on the roadmap and it will help to justify the roadmap itself. With the visual summary being the essence of the roadmap, the rest of the document provides supplementary and supportive information.

Consultant Comrade

Creating roadmaps is one of those activities that can benefit everyone. In earlier sections, I described ways that it benefits my clients, where most notably it helps provide direction, manage expectations, and pace transformations. It can also benefit a consultant, because it involves you as your client’s long-term advisor who can also help them deliver a lot of the work in their roadmap.

Sometimes I find in the course of delivering what I like to call the SharePoint cornerstone – that initial SharePoint deployment phase – I can generate many ideas with my clients for addressing all of the opportunities that arise. It can often feel as if all those potential follow-on engagements will keep me busy for a long time; yet, once I roll off that initial phase, the momentum seems to fizzle. What happened?

People generally need direction on what specifically the next steps are. It is one thing to say how valuable social computing will be as a follow up to the current deployment, but this can sound abstract and vague, particularly with identifying what is the first step and what it will involve. It leaves questions, such as how big will it be, and who needs to be on the team? When anything leaves more questions than direction, then momentum can instantly stall. Of course, lack of budget or competing priorities are among the other reasons that progress comes to a standstill, but when it becomes a permanent hiatus, it is usually relates to a lack of a roadmap and direction.

A roadmap provides that direction, it illustrates what comes next, and it produces a master checklist. I am especially fond of checklists in their many forms, as you no doubt can infer from my organization throughout this book. As such, this might explain why I value roadmaps so highly. Another benefit is that they leave a legacy of your expertise, so even if the client works through some of the roadmap without you, they still have a reminder of you. When they reach a part that turns out to be over their head, then you are probably their first call. Roadmaps are win-win and benefit consultants as well as your clients.

Another thing that I like about roadmaps as a consultant is that they give me the chance to leave my client with expert guidance they can refer to even after I roll off the project. Whether or not I can engage to help deliver a later phase, they have the direction they need to keep going, perhaps building on a SharePoint cornerstone deployment that I helped them deliver. This allows me to roll off an engagement with a client and feel confident that they have the direction they need to be successful. Otherwise, I might feel nervous as if I am abandoning some dependency. Best of all, if I do engage with them again down the road, I will not have to help them backtrack from heading too far in the wrong direction – these engagements are never as exciting as the ones where I can focus on new possibilities and delivering new value.

Because they offer so much value, you might consider how they can fit with a consulting service you offer. I recommend packaging it with an initial assessment, perhaps an assessment that includes some of the evaluation approaches I discussed in the root-cause analysis section in Chapter 6. Your assessment can also encompass a capabilities assessment where you analyze and identify what your client’s maturity level is for different capabilities. From there, you can help them identify potential business value that they can realize from filling the gaps. Finally, you can help them prioritize and create a roadmap that can guide them to mature their operations and practices.

I consider this type of consulting as one where you engage as a strategic advisor. Roadmaps are about building a strategic plan for the future, and as you can see, the effective ones involve more expertise and insight than simply listing the specific technical features for your client to deploy. As such, this also offers the opportunity for premium consulting or a closer partnership with your clients.

Inside Story: Notes from the Field

Several years ago, I engaged with a client to deliver a SharePoint cornerstone project and help them get started with SharePoint. I scheduled the final portion of my engagement to focus on building a roadmap to point them in the right direction for where they could go after I rolled off the project and I had to leave them to continue on without me. This is the nature of consulting relationships; unfortunately, I will eventually have to move on and let my clients swim on their own. Knowing this, however, I usually try to leave them with enough direction on where to go next so that they have what they need to continue making progress on their own.

I went through the process I described in this chapter, starting with identifying capability gaps they wanted to fill as they matured to another level. I identified scheduling constraints and other priorities that would affect their roadmap. Finally, I built a visual summary of the capability and feature areas, prioritized based on the order they would address them.

This left them with some direction: a prioritized list of work activities they could chip away at while they enabled new features and delivered new business value. Often this seems as if it is the most difficult part, as SharePoint is so vast it can be difficult to determine where to start and what to address next. When it is broken down into a prioritized list, then I have addressed the hard part and all that is left is to slowly chip away at the list of activities on the roadmap.

When I have left a customer with this level of direction, I feel comfortable disengaging and moving on to my next project. I feel confident that I left them with the right information so that they can be successful as they continue working their way through the roadmap. I know some initiatives fizzle after I wrap up, and I often catch up with those clients down the road and discover that momentum was lost. This happens for many reasons, but I try to make sure that it does not happen because they did not know what to do next.

It was great catching up with the client in this example a couple of years later and seeing them diligently working their way through the list of activities on the roadmap. Sometimes I can return to a client and time has stood still since my last project with them, at least as far as their SharePoint initiative is concerned. Other times, such as with the client in this example, I can return and it seemed as if time has sped up for them since I was there. In these cases, I usually have to play catch up.

In this case, I created the roadmap and I included it as part of a project close out report. I like to wrap up my client engagements and leave them with a close out report – sometimes it is an informal email report, and other times it is a little more formal in a Word document, it all depends on the project and the client. In my engagement close out reports, I like to include a recap of all of the key activities I performed and the planned and extra (value-added) deliverables that I delivered. I like to highlight how I performed compared to the original budget and what knowledge transfer activities I managed to accomplish.

Finally, in my engagement close out report, I like to include a section on next steps. These can be immediate next steps or a longer range of next steps that my client can take. I usually list these in the form of a checklist and I append a note on the bottom encouraging them to contact me if they have any questions or if they want to plan to engage me again if they find they need some help addressing any of the next steps. This can serve as a short-term roadmap of activities.

Sometimes I also include a longer-term visual roadmap of capabilities to augment the checklist of next steps. Again, I include a reference to engage me again if they need help enabling capabilities in the roadmap, and to update me on their progress if not. This is how my client reconnected with me, to update me on how well they were working through the roadmap and how useful they were finding it, and this is always satisfying to hear.

Wrapping Up

Throughout this chapter, I discussed techniques for planning and building a roadmap for your SharePoint service. I shared some considerations for what makes a roadmap valuable and how you can get started. I then looked at the concept of maturity models and walked through how to identify maturity levels for different capabilities. From there, I looked at accommodating your users’ limited capacity for change and your upgrade cycle requirements that both affect your roadmap’s activities and schedule. Finally, I covered how to combine all this into a visual summary of your roadmap and other elements you can include in a roadmap document.

Even with a well-thought-out roadmap, you will still discover new opportunities you can add to your SharePoint service. One source of discovery is by capturing feedback from your users. In the next chapter, I look at ways you can capture user feedback and how this can help you stay allied with your users. Finally, I also look at ways you can drive adoption by utilizing the feedback you capture.