In this chapter, I provide a list of all the areas with roles that a typical SharePoint deployment affects and depends on. I use this list to provide guidance on how to map the roles to specific responsibilities that a SharePoint service requires to meet different needs and ensure availability. I also discuss when you might formalize your communication protocols to ensure that you have a process to notify any relevant people in the case of any disruptions of service.

One key point that I stress throughout this chapter is the importance of ensuring end-to-end coverage, which determines what roles and responsibilities are required for coverage, and thereby identifying what resources you need. To illustrate how to link roles with responsibilities and map them with actual resources, I provide several sample RACI charts and I discuss considerations for tailoring them to fit your own organization’s needs.

After reading this chapter, you will know how to:

• Identify what roles you require and what their responsibilities are
• Adapt and use a RACI chart as your roles and responsibilities matrix
• Ensure that you have end-to-end support coverage
• Formalize your communication protocols

Understanding the Roles and Responsibilities Need

SharePoint seems to touch everything. It is one of those enterprise applications you deploy that seems to intertwine itself with many other applications and services. Right away, it utilizes services from SQL Server and Active Directory, and it might interact with Exchange. A basic SharePoint service that only integrates with these basic servers already integrates with some significant enterprise applications, and perhaps these are even some of the most significant enterprise applications on your network.

On top of those core systems that SharePoint integrates with, you may also add integration points or dependencies with your other enterprise application software. You may connect with other enterprise applications through Business Connectivity Services (BCS) and then consume their data within SharePoint, or you may output data from an InfoPath form or a SharePoint workflow to another enterprise system. You may even wrap the user interface for an enterprise system within SharePoint to provide a consistent experience for your users.

There are many reasons why your SharePoint environment can grow complex and become intertwined with all these other enterprise applications. Some examples of additional enterprise applications you may integrate with include:

• Enterprise Resource Planning (ERP) systems
• Customer Relationship Management (CRM) systems
• Content Management Systems (CMS)
• Business process management systems
• Business intelligence systems
• Enterprise service bus systems
• Master data management systems
• Order processing systems
• Inventory management systems
• Accounting systems
• Human Resources Management (HRMS) systems
• Learning Management (LMS) systems

This is just a sampling of the popular categories of enterprise applications that SharePoint can integrate with or depend on to some degree. Not many applications have the reach for connecting with other enterprise applications that SharePoint does, and not many other applications provide the value from integrating with all these applications in the same compelling manner as SharePoint does. There are good reasons to integrate SharePoint with all these systems. Hence, the line I opened this section with: SharePoint seems to touch everything.

I find all these touch points are also the danger with how SharePoint can explode in an unchecked and unmanaged fashion throughout the enterprise. Of course, I want the adoption of SharePoint to explode, but I want this to happen in a sustainable manner that I can manage, particularly when it comes time for me to patch or upgrade the environment. Spending some time working through this chapter will help you manage your SharePoint service and keep it in a supportable and maintainable state. A crucial aspect of this process leads you to identify and understand all the systems that SharePoint depends on, and all those that depend on SharePoint. Through this understanding, you will understand your SharePoint service and what the service needs to operate with more confidence and comprehension.

On the one hand, you need to know all the roles that are directly involved and required to provide your SharePoint service, and what are each of their responsibilities. You also need to know all those other roles that are indirectly required with providing your SharePoint service, because your SharePoint service depends on them in some fashion, you need to include their dependence in your roles and responsibilities matrix as well. As such, my discussion in this chapter drifts out broader than strictly focusing on SharePoint resources to help you ensure that you have end-to-end coverage. Before I get into those specific roles, I first want to consider how you can get started with identifying all the different roles and responsibilities involved in your unique environment.

Identifying Roles and Responsibilities

As I mentioned, you can have many different people involved in providing a SharePoint service, some directly and some indirectly. The number of people and how specialized each are will vary depending on your organization and your deployment. I see this number vary and depend on a few factors, such as the type and size of your organization, the size of your SharePoint deployment, the criticality of your SharePoint deployment to the business, and of course, the amount of budget available in your IT department.

The size of a SharePoint team can vary from polar ends of the scale, ranging from a one-person operation where a single generalist is the IT department, all the way up to a small army of IT resources, each specialized in a specific area. I have seen it spread everywhere in between. One is not better and there is no single optimum number or single formula for determining a team size. Often an organization will have people from human resources working with the finance department to plan and set the organization’s headcount numbers. Whether or not you feel your headcount numbers are adequate, this is not for me to say nor a debate for me to get involved with. Enterprise resource planning and headcount budgeting are outside of the scope of this book (although I have worked on IT systems I built to support these activities).

For my purposes in this chapter, I want to look at the resources you currently have available and focus on optimizing their allocation first. From there, if you find gaps or if you find certain resource areas are spread too thin, then you will have valuable information on the details, and this can help you articulate what additional resources you need and it can help to justify why you need them. This discussion will set you up well with some valuable tools that can help you build your resourcing case, even though I will not be providing a direct formula for a precise number of people you need.

Although team size varies from a one-person operation to a small army (to a literal army), the concepts and activities remain consistent from team to team. A single IT administrator who supports a small family business and manages the IT services for them is not wildly different in concept from a global services IT outsourcing organization that consists of several thousands of resources. Both these organizations provide a range of IT services for their customers, and their main difference is a matter scale. The larger IT organization operates on a much larger scale, and so it has more roles with specialized resources performing the tasks for which it is responsible. Yet, conceptually, they are both providing IT services, just at different degrees of scale.

I like using this comparison for this topic on roles and responsibilities, because it helps frame the commonality of IT resourcing that is consistent across organizations, even though each implementation will have a difference in their degree of scale. This abstraction helps me begin to standardize and order the roles involved in providing a service, and then to identify their responsibilities that are required. I use roles, because roles are more abstract and I can apply them consistently from one organization to another. Once I have decided on all the roles I require, then I assign them responsibilities, and finally I map actual resources to those roles. For the small organization in the earlier example, I map that one individual IT administrator as the resource for all the roles, while the larger organization will include multiple resources with each potentially mapped to only a single role. By abstracting the roles and then applying resources to them later, I am simplifying the process so that it will work for your organization, whatever its size, and better yet, you can adapt it as the size of your organization changes.

During any initial discussions for new SharePoint deployments, I get a common question from clients and it relates to the number of resources that they will need. Clients usually ask how many resources they need to allocate to the project if I am to deliver a SharePoint deployment, and then they want to know how many resources they will need to budget for to manage the operations and ongoing sustainment of it. Now of course, I have experience as a SharePoint administrator, one who was spread thin at times across support activities trying to maintain an acceptable level of service, so I like to see ample coverage and infinite budgets with infinite resource availability.

Infinite budgets and infinite resource availability sounds nice. Who would not want to live in a world like this? Well, I imagine the finance person accountable for the budget might not want to live in this world if the budget is wasteful and excessive. Sadly, I have no magic numbers and all I can do is help my clients work through what features and capabilities they want to include in their SharePoint service, and what level of service they want to provide. From there, I help them list the roles and responsibilities involved by building their roles and responsibility matrix. They can then take the RACI chart we produce and plan how they want to allocate resources and how much they want to invest in a particular service area.

To build a RACI chart, I take an overall view of the SharePoint service and I look at all the activities and tasks that the service needs to operate. From there, I group these tasks and associate them with a role. Some roles I know about ahead of time, such as the SharePoint administrator – someone has to manage the service unless you are consuming a service hosted in the cloud. Other roles will depend on what features the client enables. For instance, including a data mart architect will only be appropriate if the client includes a business intelligence component that warrants this role.

In naming the roles, I usually stay reasonably consistent with how the market names a similar role, and I do this so my client will have an easier time filling the role with qualified candidates. I also do it because some clients will fill the role using internal candidates they are planning to train and develop, and consistent naming will make it easier for them to identify the appropriate training for their candidates. Sometimes I may break a role into multiple roles if I expect that my client will have different resources who are going to perform the role’s tasks. In that case, I get a little more creative with naming the roles.

After I have listed the roles and grouped their responsibilities within them, I then start mapping actual resources to each role. I usually do this in a table following the RACI chart that identifies named resources for each of the roles. In many cases, I have more than one resource to associate to a particular role. This is okay, and usually even preferred. With these cases, I will then identify a primary resource for the role who is ultimately responsible and who is the first point of contact for any of the activities related to the role. Usually this primary resource is the lead for a particular area that you have grouped into a single role. The rest are secondary and are the lead’s delegates.

To start, I divide the service into different feature sets or capability areas. I begin this way because I like to group role tasks by similar features or functions to keep their overall responsibility efficient. This division helps when I want to delegate different parts of SharePoint to an administrator or another resource to manage. The more you divide your SharePoint service, then the easier and less complex it makes your process for setting the boundaries for a resource’s area of responsibility.

You decide how granular you want to be with the feature sets or capability areas that you use to define your roles, and you base this mainly on how large and specialized you expect your team to be. On a large team with many specialized resources, you need a more granular listing of the different roles involved with providing the service, and this more granular list enables you to allocate resources to these more specialized roles. On the other hand, you might have a team of one, and in this case, you might not find it necessary to get overly granular with your list of roles because you are allocating a single resource to them all.

Even in the case of very small teams, I still prefer to list multiple roles and allocate resources to several roles. I try to avoid making a one-to-one relationship of roles and resources, or at least I avoid having the number of resources directly dictate the number of roles. There are several reasons for this, and one big reason is that I want to keep my role list flexible and easy to adapt as my team changes. Perhaps the team will grow and add additional team members later on, at which time I may redistribute the roles and areas of responsibility. However, my main reason is that I like to keep the roles granular because having several groupings of responsibilities are easier to manage and comprehend, for resource planning purposes and for the resource themselves.

How specialized you make your team depends on the scale of the service you are providing, and in addition, your team structure depends on how your organization typically organizes teams. Is your organization’s culture one with specialized roles where resources have a narrow scope of responsibility, or does your organization prefer more generalized roles with resources who overlap and share responsibilities within a particular domain? Understanding this culture helps you to determine how granular and specialized you need to make your SharePoint service delivery team.

For our purposes, I will assume a modest size team with fewer, more generalized roles. This will keep the examples reasonably straightforward, yet with enough division of labor to help illustrate the concept of identifying roles and their responsibilities. I favor less specialized teams within a capability area where it makes sense, because this approach often helps maximize resource availability where one teammate can take over or relieve another to keep production moving forward. At the same time, I favor a defined list of responsibilities for every team member, and I always want to identify someone and only one person who will hold the ultimate responsibility.

This practice stems back to what I learned in business school about providing team members with a defined list of responsibilities. I remember my management theory and human resources classes, and one point they hammered home is that I should provide a job description to every resource so they will never have to guess at what their priorities should be. Now, like several things I learned in school, this does not always translate into what actually happens in practice, or at least it did not for many of the positions I have held. Yet, whenever I am in a position where I do have a defined list of my responsibilities, whether on a project team or an operations team, I feel more confident in my role and everything just seems to run smoother. Often times I have to define my own list of responsibilities, especially when I engage with a client for a new project delivery, and this gives me a feeling of clarity for my purpose and my objectives. It also gives me the confidence that everyone else shares the same understanding about what I am there to do and for what I am responsible.

One area I often perceive as an underlying reason for opposing this idea of listing responsibilities for each role seems to grow out of a general sense of not wanting to limit a resource. The idea as best as I can tell rests on a premise that a job description might influence a worker in a way that they adopt too narrow of a view of their responsibilities, where their worry is then that the worker would not step outside their own area to take any new initiative or help teammates. There almost seems to be a belief that if one leaves the job description open, then they might avoid constraining the worker’s potential. Whether this philosophy is valid does not interest me as much, although I do not buy in to the idea that having a job description would constrain the attitudes and narrow the focus of team members. I find defining a list of responsibilities helps to avoid missing things or leading to situations where team members assume someone else will tend to something. It also gives resources a certain comfort level in clarity of what is expected of them.

I do not think of roles and responsibilities as necessarily a contract, but they do set implicit expectations for what activities need to occur. In this sense, I think of them more as a minimum, and they provide a measure about whether a team member meets their obligations on the team. In a performance evaluation, I would measure my team members against their responsibilities, and those areas where they miss responsibilities will provide me with an opportunity to look at how I can help them improve. Everything they do above these responsibilities serves to highlight where they are exceeding in their job function, which might include activities such as extra initiatives they have taken or cross group collaborations where they assisted a peer. By looking at and valuing these other measures of a resource exceeding expectations, I have found that having defined responsibilities only helps to facilitate this rather than acting as any sort of constraint. For instance, when high achievers know what is expected, they know where they can excel.

Better yet, this process identifies the skills required and it can serve as a career progression map. You might use the responsibility list to help you define what makes a senior resource versus an intermediate or junior resource. Team members can use it to help decide where to concentrate their learning and development activities, and they can base their career progression plan on these descriptions. As such, detailed descriptions of roles and responsibilities not only provide clarity on what you expect from resources today, but they also provide direction for career growth down the road.

If you define a list of responsibilities for a given role, then you are also providing direction and setting expectations for the resource or resources who you assign to that role. This is a recipe for a productive team, and ultimately it is a recipe for success. At this point, I hope I have succeeded with convincing you how valuable this exercise can be – so valuable in fact that I have dedicated an entire chapter to the topic! The biggest challenge I see people face with specifying the roles and responsibilities lies in their potential lack of depth with all the technical aspects within SharePoint. That is okay, because I will get you started. First, let’s begin the discussion with those SharePoint specific resources, those whom are directly responsible for providing the SharePoint service.

Identifying Roles for Your SharePoint Service

There are some global roles involved in a SharePoint service, such as a general SharePoint administrator, SharePoint solution architect, and infrastructure architect. At its most basic level, the SharePoint administrator is a common role in most environments. This role might perform SharePoint central administration tasks, such as provisioning web applications and service applications, or it may include tasks such as installing service packs or solution packages. The architects plan and design the solutions that the SharePoint service provides and the infrastructure it runs on. You might incorporate more application specific tasks as responsibilities for these roles as well, or you may break those out into separate roles based on different applications or capabilities.

Other core roles that are typically global across SharePoint include service desk and support roles. Your service desk might be a separate service from your SharePoint service, but at the very least, they might need some training or someone to write support articles for their knowledgebase. You might also include support escalation engineer roles, where the service desk can escalate service request tickets and have them provide a tier-two or tier-three level of support. Closely related to support, most deployments will also want to include training roles for your end-users to facilitate adoption and productive use of the SharePoint service. Another training role you might consider is one to provide training to the operations team so you can grow its capabilities.

As I mentioned earlier, a convenient area to start and define roles that are more specific begins with considering the capability areas. I like to break SharePoint 2013 into seven core capability areas: collaboration, social computing, portals, search, records management, business intelligence, and composite applications. These areas often provide a useful guide to start thinking about all the different roles I need. I like to start with each area and branch out to identify all the different roles involved with that particular area. Once I have a list and I am satisfied with how comprehensive it is, then I consider whether merging some roles will make more sense or be a better fit for the client I am working with.

The first capability in my list is collaboration, and at its very basic level, this can involve activities such as provisioning team sites or facilitating self-service provisioning, managing quotas, and administering permissions. I usually include this role in the generic SharePoint administrator role, particularly for deployments where these tasks are largely self-service. This role might also be the place where I assign basic SharePoint training or tier-two support responsibilities. For me, I often tend to represent the collaboration capability as the cornerstone of a SharePoint deployment, and because of this, I like to simplify the core roles I define within it.

Social computing encompasses another broad category, but for my purpose to define roles related to it, I will focus on the primary social features within SharePoint 2013. To provide and support social computing within SharePoint, I typically start by enabling user profiles, MySites, tags and ratings, and community sites. Some roles you might consider to manage these features include a profile administrator and a folksonomy manager. You might also consider a community manager or community evangelist roles you can use to facilitate communities of practice and seed the social interactions as part of you user adoption strategy.

Portals typically serve as a gateway to other information and processes, or as a channel for communication. In this sense, a portal can include roles such as a communications manager and a content manager for publishing, and it can include an information architect to manage its structure and navigation. They also have a visual identity and style standards, which a brand manager can plan and manage. You might include other roles such as a graphics designer or illustrator, publisher, and a copyeditor, depending on the nature of your portal.

Search overlaps the other capabilities the most because it depends on them to provide content that the search engine will return in search results. Within the search service itself, it requires a search administrator to manage and tune the service, and a search analyst to analyze search queries and other usage reports to identify opportunities for improving the search experience and the value it delivers. Most search engines interface with other systems to index and include their content in search results and a part of planning which systems to interface with and crawl requires a search architect role to plan and design the search architecture.

Records management involves controlling the lifecycle of an organization’s content. At the helm, you need a records manager who coordinates and manages policies applied to content stored within the records repository as well as other transitory content stored in other locations. A significant portion of records management entails classifying content, which requires roles such as a librarian or taxonomy manager to design the classification scheme. Another major component of records management involves compliance, and this can involve roles such as a compliance manager and legal analysts or advisors.

Business intelligence (BI) typically involves integrating or interfacing with a variety of data sources to query and report on the data they provide. This can involve developing data marts, data interfaces, and data transformations; these are all in addition to developing the business intelligence reports themselves. The roles that support the integration and data access typically involve a data architect and systems integrator. The BI developer roles typically handle the queries and data manipulation, while report designer roles design and build the BI reports.

Composite applications tend to involve activities that develop and customize an application to host within your SharePoint service. Often with these types of applications, you need a business analyst role to gather requirements and analyze the current business problem, and you need a solution architect role to design a solution. After you have a solution designed, you need roles to build and implement it, such as developers, user interface designers, and user experience designers. Finally, to ensure quality and stability, you need tester roles to verify the functionality, a release manager to control the release, and a system administrator to actually deploy the solution to an environment.

Throughout this section, I looked at some typical roles that are specific to SharePoint and each of its capability areas. These roles should give you a running start as you define what roles you need and group different responsibilities within them. Yet, as I described earlier in this chapter, a SharePoint service depends on more than just the functionality within the software, and so it depends on more roles than just the ones related to its capability areas. Most notably, you may have noticed I did not include a SQL Server database administrator when I highlighted the core SharePoint roles such as the SharePoint administrator. I like to think of these as the roles the SharePoint service depends on, and I have broken those out into the next section.

Identifying Roles Your SharePoint Service Depends On

A SharePoint service can quickly grow complex as it interacts with different systems and acts as a central entry-point for data and processes on the network. It can morph into the glue that holds different enterprise systems together. Because it provides this service, you need to identify what all these different systems are and how the SharePoint service depends on them to fulfill its duties and deliver business value.

One of the first systems you will identify is one that every SharePoint farm depends on: SQL Server and the databases that support the SharePoint farm. In the previous section, I mentioned this idea of treating SQL Server as a service that SharePoint depends on. This may seem weird, because you can deploy SharePoint and SQL Server on the same server, and you can never configure and deploy SharePoint without SQL Server. You might wonder why I would not just include them together because they go together with such a non-negotiable dependence requirement. My main reason is to frame the right perception, because SQL Server is an enterprise system and it warrants you treating it as its own distinct enterprise application.

I am always surprised by how common it is for people to deploy SharePoint and SQL Server in a one-to-one relationship: they deploy a new SharePoint farm, so they also deploy a new SQL Server farm. Some people treat the two products almost as if they are the same product that goes together in a deployment, and this is just a misunderstanding or inexperience with the two products and how they relate to each other. This way of thinking often only leads to an unnecessary bloating of SQL Server deployments where you have an excessive number of SQL Server instances to manage. This has management and support costs, as well as licensing and hardware costs.

Let me clarify if something along the way has led you to believe you need one or more dedicated SQL Server instances for every SharePoint farm: you do not. You certainly may, depending on your expected load and your performance requirements, but it is not a requirement nor is it a set rule. It is easy to get caught up in that way of thinking though, because wherever you see hardware and software requirements for a SharePoint farm, almost inevitability they will also include details on the SQL Server requirements. They are just clarifying the minimum requirements for the database service that the SharePoint service will rely on.

In the spirit of thinking of SharePoint as a service, I also like to think of the underlying SQL Server database as a service the SharePoint service consumes. In consuming these services, I prefer to delegate providing and supporting that service to the database team, including letting them decide how best to allocate the SQL Server resources and optimize the service. You need to provision a number of databases and they require a certain level of hardware and system resources. You might need the database team to provide clustered databases, a frequent backup schedule, and different performance targets. These are all requirements from the database service, and they are parameters you can provide the database team to manage as you delegate the rest of the implementation details for them to manage. Even if the database people are on the same team as the SharePoint people, I still like to treat this as a separate service that SharePoint consumes.

Once you capture your service’s dependency on SQL Server, you next need to look at all the other systems the SharePoint service depends on. The easiest way to approach identifying all the systems SharePoint depends on is to start with your SharePoint service and work your way out from there. List all the different systems that it interfaces with, and note the data dependence and data flow. In this case, I adapt the famous phrase that Deep Throat supposedly whispered to reporter Bob Woodward to advise him on how to find the truth about U.S. President Nixon’s Watergate scandal, “Follow the money.” Follow the data, and you will find the truth about all the systems that your SharePoint service depends on.

To help follow the data back through the different systems, I use a data flow diagram to map out the flow of data in the enterprise. It is a tool that I find helpful for tracking the data and identifying all the system interfaces involved. These data flow diagrams provide a visual depiction of how data flows throughout the organization, illustrating what systems are involved with what data process. I have used basic flow charts to capture simple data flows, and I have used formal data flow diagrams (DFD) with proper DFD notations. Use whatever diagram format that communicates the best for your audience.

A data flow diagram can support data analysis and it can ultimately help lead to an even more valuable tool for understanding the enterprise data architecture, a data dictionary. These provide a look-up reference that documents and defines every data field in a system, or ideally, across the entire enterprise. Obviously documenting an extensive list of data fields can be a monumental undertaking and a tedious task, but once that information is available in  a data dictionary its value quickly becomes apparent. I discuss the idea of creating a data dictionary in Chapter 15.

Throughout this chapter, I pointed out several enterprise systems that your SharePoint service might depend on, and one is your identity management system, such as your Active Directory environment and all of its domain information. Your profile data and authentication process may depend on Active Directory or a custom forms-based authentication application. You may allow SharePoint sites to provision Exchange mailboxes, or you may depend on Exchange or another e-mail service in other ways to provide communication capabilities. These are all enterprise applications your SharePoint service may depend on, and if so, you need to include the applications in your list of what your SharePoint service depends on.

Your security solution might depend on firewalls and proxy servers to secure requests and protect the SharePoint environment. You might depend on a virtual private network (VPN) service where users can securely access the SharePoint service remotely from the public internet outside your corporate network. There are other services related to handling access to SharePoint that you might depend on. For instance, you may have several SharePoint web front-end servers to process requests, and they may depend on a network load-balancing (NLB) service to balance and route the requests among the SharePoint servers. Again, these may be services that you need to include in your list of services your SharePoint service depends on.

Once you have identified all the external services on which your SharePoint service depends, you then identify the roles within each of those services and the tasks grouped within those. You might get this list from the teams directly, if they already have one, or you may have to do some analysis to identify all their different roles in the same fashion as you used to identify the SharePoint roles.

I have now identified all the roles involved in providing a SharePoint service, both those directly involved on the SharePoint service operations and those providing services that the SharePoint service depends on. Now that you have all these roles, you need to link them to the tasks that each is responsible for performing. My favorite tool to accomplish this linking of roles and responsibilities is to create a roles and responsibility matrix, and I create this matrix as a RACI chart. In the next section, I give you an overview on the RACI model and what a RACI chart is, and then I share a few sample RACI charts to help get you started.

Using a RACI Chart

At its core, a RACI chart consists of a roles and responsibilities matrix. I find RACI charts incredibly useful on any team, whether you use them to chart roles on a project delivery team or those roles within an operations team, they add clarity and set expectations for different activities you depend on. Despite its simplicity, a RACI chart is powerful because it organizes activities and the resources who need to be involved, and it communicates this at a glance. It also helps you ensure you have coverage for all the activities you have planned.

There are six basic elements to a RACI chart, which is a grid that relates roles in columns with tasks in rows. The first element is the roles, as I mentioned, and you allocate them each in a column in the RACI chart. The second element captures all the tasks and lists them in rows going down the RACI chart. The final four elements specify the relationship between the role and task where the column intersects with the row. You specify this relationship between the roles and the tasks by using the four letters, R-A-C-I, and placing the appropriate letter in the intersecting cell. Your choice of which letter to place in the cell corresponds to the following criteria:

• R: Responsibility. This identifies the role who will perform the work. There must be exactly one “R” in every row, ensuring that every task has a role and only one role responsible for the work to accomplish the task.
• A: Accountable. This identifies the role who is ultimately accountable for completing the work or making a decision. There may be zero or one “A” in every row, and you should only use it for key tasks or decisions where the role responsible for the task is different from the role who holds ultimate accountability for it.
• C: Consulted. This identifies the role or roles who must be consulted with before completing a task or making a decision. Each task does not need to include a “C” but it can have more than one, as appropriate.
• I: Informed. This identifies the role or roles who must be informed after completing a task or making a decision. Each task does not need to include an “I” but it can have more than one, as appropriate.

Using this description of the roles and how they map to tasks, you can see how RACI charts define clear ownership of tasks and what communication is required for each. I find having both the clear ownership and communication expectations are aspects that are invaluable on any team, and both of these aspects together are at the essence of a RACI chart. I discussed the idea of roles and their responsibilities, and I hope you will see how a RACI chart can help you capture this information in a simple yet clear chart. At the same time, another aspect of the RACI chart involves the other half of the letters: consulted and informed. The main difference between consulted and informed is how a role is consulted as part of the task and that role then has the opportunity to weigh in and influence the activity or decision, whereas a role is informed after the activity or decision completes to keep them in the loop and up to date.

A RACI chart ensures everyone involved in a project delivery or an operations service delivery are all on the same page – literally and figuratively. The physical page allows you to use the chart to ensure you included all the roles involved and you have defined what the expectations are for each role and task. It captures everyone and their activities or involvement in a single place that helps to establish a clear and shared understanding about who is responsible for what.

You can make a RACI chart in several formats, from informal accounts to formal documentation. For instance, you can write your roles and responsibilities matrix on a whiteboard in a team war room where everyone on the team can see it, and you can even use this to track progress through the project as tasks are completed and communication occurs. You might find this is a nice informal approach that still keeps the team aware of who is responsible for what task and what communication. For me, this is one of my favorite approaches to track a project because it keeps the chart constantly visible for everyone and it is easy to keep updated. I can also watch my task burn down progress as tasks are completed and communication occurs. It morphs into a whiteboard reflection of a functional and effective team.

Another approach you might use to create your RACI charts includes using an Excel spreadsheet or a table in a Word document. Both make formatting and printing a RACI chart straightforward. You can print them, e-mail them to the team, or post the files on a SharePoint site. You can also use a SharePoint task list to create a RACI chart by adding columns to the task list. I like to change the caption of the “Assigned To” column and update it to become the “Responsible” column. I then add an “Accountable” column, a “Consulted” column, and an “Informed” column. I make the Responsible column a required field and limit it to a single person, and I leave the rest of the columns optional, with the Accountable column limited to a single person and the other two unlimited. You can then associate workflows and different views on the task list, set dependencies, add additional notes, and even import the list into Microsoft Project 2013 and then save any changes back to the SharePoint task list. Although I prefer the simplicity and visibility from having my RACI chart on a whiteboard, there are times where I do appreciate some of these added features that SharePoint 2013 and Project 2013 provide, particularly for larger project teams or projects with a lot of cross team dependencies.

The best way to understand a RACI chart is often to look at a sample. In the next section, I provide sample RACI charts for an initial SharePoint project delivery, and in a later section, I provide samples for a SharePoint service operations team. Pay particular attention to how I have included communication aspects in addition to the responsibilities of tasks. Remember, these are merely samples to give you somewhere to start and help clarify how a RACI chart works and why I find it so useful and valuable. As such, please do not get too caught up in the specifics of what roles I selected and what tasks I included, and instead focus on how the RACI chart works and the value it adds to a team. My discussions in the other sections of this chapter will help you identify the roles and tasks to include in your own RACI chart.

Ensuring End-to-End Coverage

Coverage can mean support coverage, delivery coverage, or service coverage. Essentially, it looks at whether you considered and incorporated everything necessary to provide the overall purpose behind all the tasks in your RACI chart. You can use coverage as a means to look at where you over-allocated resources and where you have gaps.

The first step you need to take is to ensure that you have included all the tasks and the roles in the process. This involves a closer look at your RACI chart, and often you can discover where you omitted tasks or roles by having your team review the RACI chart and provide feedback. You can also have someone like a business analyst audit the RACI chart to validate that it incorporates all the tasks and roles. Once you are reasonably confident that your RACI chart includes all the necessary details, the rest of the process is easier and relatively straightforward for ensuring end-to-end coverage.

Next, you need to go through each row and ensure that each task has one and only one role specified as being responsible for the task. This ensures that you have coverage with a role identified as responsible for every task. In the process, you also need to ensure that each task has the appropriate roles identified to consult and inform, as well as any role who holds accountability for the task but is not responsible for performing the work on the task. Once you are satisfied with the coverage in your roles and responsibilities matrix, you are ready to ensure resource coverage.

You map resources to roles, so through this, you can ensure coverage by validating that every role has a resource allocated to it. You need to look beyond just whether or not you mapped a resource to a role though, because if a resource is over allocated or not available during some hours that you need them, then you have a gap. You can determine how utilized a resource is by determining what proportion of their time and how much of their time that they spend on each of the tasks or each of the roles you allocate them to. If you find you are not satisfied with the amount of time a resource can spend on the tasks of a role, then you may have over allocated that resource.

The working hours of a resource indicate what hours he or she provides coverage, and so if there is only one resource allocated to a role or all the resources maintain the same working hours, then your coverage for a particular role is limited to those working hours. There may be off-hour exceptions, but these are exceptions and not the standard coverage times, otherwise utilizing resources during their off-hours provides another indicator of over allocation, and therefore would not be a sustainable coverage plan.

Not every service requires around the clock coverage, so if you are limited to a resource’s working hours then that can be perfectly acceptable in many cases. The point is to go through this process and be aware of what your coverage window is, and if this meets the window for the service level that you want to provide, then you have coverage. If it does not meet the window that you want to provide, then you have gaps.

Building out a RACI chart solidifies the coverage of your team, whether that is a temporary project team or an ongoing operations team. It helps to understand the expectations around what your team needs to deliver and where each team member contributes toward the overall delivery. It also identifies communication requirements among the different roles, which can be formal or informal, depending on your needs and the needs for the task involved. In the next section, I cover some considerations and approaches to establish formal communication protocols.

Formalizing Your Communication Protocols

Your RACI charts identify some types of communication that need to occur, with expectations for resources to consult or inform other resources on their activities and decisions. What form should that communication take? In some cases, the form that a particular communication requires is probably evident or is fine to leave to the discretion of the resource performing the task. In other cases though, you might want to formalize what form this communication must take and what its process must be.

SharePoint and other ticket management systems do a good job handling formal communications and automating the processes around them. In one approach, you can design a workflow to implement your formal communication protocols and associate that with certain tasks in SharePoint. Your service request ticketing system might also provide workflow capabilities that allow you to follow a formal communication procedure. A workflow, as in both of these examples, can automate some of the communication, but they can also enforce the procedure and capture an audit history.

You could use a workflow procedure for tasks related to approval decisions and change management processes. This ensures that you involve everyone who needs to be involved. The workflow makes the procedure for these types of tasks largely routine and systematic, and it remains consistent from one instance performing the task to the next.

Creating a workflow and standardizing the communication protocol within it sounds like a nice solution, and it is, but it is probably overkill to implement this solution for every task. For some task communication, you may opt for just an informal e-mail or a team meeting. You might use this communication technique for those tasks that do not require approvals or similar types of formality. Remember, formalizing the communication protocol does not necessarily mean you need to formalize the communication channel; you can use an informal channel such as e-mail with some guidelines around when to send the e-mail and to whom.

Your communication requirements may extend beyond a small group of roles related to your task, and it could even involve mass communication to the entire organization. For example, in a support RACI chart, one of your tasks might relate to informing the organization about a planned outage for system maintenance or upgrades. You can take one of several approaches to notifying the organization, and one of those might be to send out a mass e-mail to everyone with the details that you wish to communicate.

Another option for handling mass communication requirements of this nature could include adding a message to the portal ahead of time to announce the planned outage. You may publish a news article to the portal or use a standard announcement list and web part, or you could create your own web part for mass communication alerts of this type and include that on all of your site master pages. This way, when you do post an alert, all those web part instances will subscribe to the alert message and display a notification on each SharePoint page so that users are likely to see it and be aware of its content.

During the actual maintenance period, you could also set up a temporary web redirection to a page that explains the maintenance occurring and when you expect to restore service. I use this process of enabling a temporary web redirection to these types of maintenance notification pages to provide users with information during planned maintenance windows and during unplanned outages. Providing this type of communication can often help reduce the number of service request tickets that users open while the service is unavailable.

Creating a Service Level Agreement

A service level agreement (SLA) typically involves a formal agreement between the service delivery provider and the service consumer, and it includes topics such as the terms of the service, minimum availability, and expected performance levels. In Chapter 2 I briefly touched on the idea of an SLA and I discussed topics that are relevant for you to include in an SLA, especially those related to defining your SharePoint service boundaries, service request process and prioritization, and chargeback-funding models.

You will find useful aspects in every chapter in this book that you might want to include in your SLA, but Chapter 2 combined with this chapter provide the fundamentals of an effective SLA. While Chapter 2 covers the bounds of what the service entails, this chapter covers who provides and supports that service. You can use these chapters, as well as the others in this book, to guide you in making decisions about what you want to incorporate in an SLA for your organization, and you can take and adapt the topics that fit with the degree of formality you need to capture.

Often an SLA is an agreement between an IT department and decision makers from the business. It serves as a contract between those providing the service and those consuming the service and it defines the official policies and procedures involved with the service operations. An SLA can be strictly formal and bureaucratic, particularly in cases where it may need a lot of formality such as when a business unit depends on it for its own business operations. Indeed, this uncovers the purpose of an SLA: it defines the level of service that a customer can depend on and consume with confidence, and without having to get involved with any contingency details or any complexity around how the service might perform at different times. The SLA commits to a consistent and minimum level of service that the customer can rely on, while they trust and delegate to the service provider to worry about any contingencies to maintaining that level of service.

To gain this trust and build the confidence to rely on your service, this may require a formal and even contractual agreement that you both sign and establish as a commitment together. When you both commit to an agreement and to each other, you need to make the relationship and expectations official, and this can mean working through many details as you find common ground. Throughout the process leading up to an agreement, you will likely find a lot of effort goes into working through the details and finding that common ground. Your agreement has to represent both the service provider and service consumer, and any process that has to reconcile interests from two or more parties will always involve trade-offs and compromises. You negotiate towards balance and a settlement for an SLA that works to address everyone’s essential requirements.

Your negotiations will involve more effort working toward common ground as you increase the number of people included in the process and the different interests they represent. It can be a lengthy process where you address many different aspects of a service and comb through minute details involved in the service. Depending on the significance of your agreement, you may need an exhaustive account of every aspect of the service and address every expectation. You may require extensive text detailing different aspects of your service within your SLA, because you cannot leave grey areas in contracts that people depend on or else you could quickly find that this leads to misunderstandings and possibly even disputes – exactly the types of things you are trying to avoid and mitigate with an SLA.

Not every organization will be at a stage where you can introduce a formal SLA. Your service delivery team might not be mature enough in its processes to be at a point where you can commit to a certain service standard, or your organization might not be familiar enough with their own needs to feel comfortable enough with committing to a certain service level. Everyone may just be anxious with making any sort of formal commitment. They might worry that a formal agreement will introduce rigid processes that make IT unresponsive to change, or they may just worry about whether they have thought of everything.

This worry or resistance against a formal commitment can obstruct your ability to establish an SLA, and I find this type of reluctance toward an SLA is very common. You can address everyone’s uneasiness through techniques such as working in contingencies for changes, agreeing to a time limit or a trial period, gradually amending the SLA to cover additional areas rather than making it comprehensive for the service all at once. Even after hedging the SLA with these types of techniques, you may still face some resistance. Perhaps your customer lacks any interest for even going through the process or for committing to a service level. Perhaps you are just not comfortable enough yet with what service level you can provide and maintain.

Whatever the blocker to establishing a formal service level agreement, if you want to establish something of this nature regardless of whether it is formally agreed to, then one solution is to consider a service level objective (SLO). A colleague of mine, Arlene, suggested this to me years ago when we were working on an SLA initiative and found ourselves lacking enough involvement from the business to really consider the output as an agreement. Instead, we treated the entire process the same, but we called it an objective we targeted and against which we held ourselves accountable. The business was disinterested with getting involved with negotiating any service levels or committing to an SLA, so we made our best efforts putting a stake in the ground to define our service levels and to then hold ourselves accountable against them.

Documenting a Governance Plan

Throughout this book, I have left any formal governance documentation up to your own discretion, and I will leave the formality of your service level agreement (SLA) documents up to you as well. Some people swear by the need for a documented governance plan and they slot this on the critical path as one of the first things you need to do, making a blanket claim that they suggest should cover every case. I am not opposed to this nor am I saying it is wrong. I am merely suggesting that you first ask the question: is extensive documentation the most effective approach and optimum solution for the current situation you face?

Every situation is different, and every organization has their own comfort level for how formal they need to record things. Some relate governance to some sort of bureaucracy, maybe because “governance” sounds like “government” and governments can infamously involve a lot of bureaucracy. This can be valid if it fits an organization’s situation and it works for them, but at its essence, SharePoint governance embodies the actions and manner in which you manage and administrate your SharePoint service.

Whether or not your actions and manner for governing SharePoint involves rigorous policies and procedures detailed in governance documentation will depend on your needs and your situation. On one extreme, if actual lives depend on a certain order of things in SharePoint, well then I would say you probably require more thoroughness in your SharePoint governance documentation. Over on the other end of the spectrum, if you use it for simple ad hoc collaboration and no lives depend on how SharePoint functions, then I might not expect you to require as much diligence in your documentation efforts.

Certainly, I feel having good documentation can communicate expectations to the team well, but not every team member will study and frequently refer back to a lengthy document. You can communicate and ensure a shared understanding using other less formal methods as well, as I frequently point out in this book, but sometimes an organization just needs the formality as part of their process.

An SLA is a good example of when you will typically require formality. Different parties are involved in a formal sign-off and they are agreeing to the service level, and you might then establish it as a contract between everyone. I find this type of situation almost always requires a lot of formality because of the nature of having different people with different needs, all of which is a recipe for misunderstanding and conflict when you do not clearly define things. With a degree of formality and thoroughness in the SLA documentation, you can establish a shared understanding and set common expectations for how the service will operate.

Of course, governance plan documentation can serve this same purpose: it gets everyone on the same page with a shared understanding and sets common expectations. You might wonder why I have a preference to formally document any SLA while I am more nonchalant and neutral when it comes to deciding how formal to make the governance documentation. The answer is because an SLA has some weight to it; people have committed to meeting targets and they actually hold each other accountable for them.

For me, a degree of accountability makes the difference for how effective documentation will prove to be. Service providers and service consumers in an SLA hold each other accountable, and they specifically hold those accountabilities around each other’s expected actions. Documentation can serve to capture knowledge and archive it for the future, but if you want it to be effective today, it needs to have actions that lead toward an outcome, and you need to hold someone accountable for those actions. Otherwise, you are just archiving something for the future.

You can typically have two main objectives for documenting your governance plan. One serves to capture the knowledge and decisions that encompass your actions and manner for managing your SharePoint service, and you want to save it for future reference. The other serves to hold people accountable for those actions you expect from them. This book overall, and this chapter especially, identifies many of those actions for which you might consider using to hold people accountable, and this information can assist you as you establish the appropriate level of documentation for your situation.

Consultant Comrade

This topic is very exciting for a consultant, because you can help answer those mysterious questions your clients face. You come as a SharePoint expert and you get to be the hero who guides them and who helps them work through the design of their SharePoint team. Trust me, this is no small matter.

The RACI model arms you with a tool you can use to drive the process and with it you are set up with a deliverable around which you can build out your consulting engagement. I listed many roles and provided several sample responsibilities to get you started. As you build out the rest and tailor it for your client, think about what the role will entail and follow my advice in the section in this chapter on adapting the sample RACI charts to your situation. The process will largely be the same, except your client has you as their expert to guide them and help them make sense out of what the roles mean.

I enjoy these types of engagements because they look closely at how a client structures their teams and how their IT department is structured. Often this allows me the chance to reveal structures and dependencies that my client did not even realize existed. It brings potential issues to light and uncovers overlap or gaps that otherwise might remain hidden and be difficult to detect when related problems arise. Not only do I get to learn about my client’s environment, but also I facilitate them learning about themselves.

Going through this process helps differentiate you as a professional, because most other SharePoint consultants probably will not provide this level of detail or insight. I hope more will now that I detailed the main steps in this chapter, but you still have a lot of room to add value and differentiate yourself. As you probably noticed, there is no standard RACI chart to fit every client and every SharePoint service. Although the process of developing one is straightforward, it is not systematic enough to go through using a simple survey. If it was, I would have just included that in this chapter and moved on.

For me, I find the best time to address this is at the beginning, before you kick-off an engagement delivering SharePoint or a solution that you are deploying to their SharePoint environment. Whether they have a SharePoint team already or are looking to establish one, this is still a valuable step. You might sell this as an engagement all on its own or as part of a planning phase leading into a project delivery phase. When it is leading into a project delivery, the primary activity should be an extended project team RACI chart, extended to include the client resources the project depends on as well as any stakeholders or occasional project members from your team or from the client.

Once you have a project RACI chart, a project plan, and a pre-project checklist of activities that need to occur before you kick-off, I like to then move into planning what the operations team will look like. Building an operations RACI chart, at least at a high-level, will help set expectations with your client and help them begin to plan for what they will need when it comes time for you to hand over the delivery of an operational SharePoint service.

If your client has an existing SharePoint operations team, this is your chance to learn about who all the players are, who is responsible for what, and whether there are any gaps in coverage. This is often invaluable information to have throughout the lifecycle of the project, and it can help make your hand-over a smooth transition, as you will have all the right people identified and ready to involve. It also gives you an opportunity to raise warnings if you are delivering to gaps in the RACI chart that you need the client to fill. The information is useful, and it can help solve problems before you even get started!

I mentioned earlier in the chapter how I love to have the project RACI chart on a whiteboard where everyone can see it and use it to track our progress. If you have this option, I encourage you to try it out and experiment with it. This can be a powerful tool, for the client and the project team to monitor progress, to understand expectations, and to manage scope. It is more difficult for anyone to try to introduce any scope creep into a project while they are facing a whiteboard of tasks and fully utilized resources. This makes the consequences and required tradeoffs much more visible and readily available. Scope creep is not just simply about a change request and additional billable hours; it affects the plan and upsets the balance of the project. Sometimes it is necessary, but with your RACI chart on a large whiteboard in the project war room, you can see and prepare for the ripple effects that the change will cause.

The RACI model is one of my favorite tools to mitigate risk and optimize my chances of success. I cannot stress enough the degree of how clear it makes expectations for everyone. Everyone can see what is expected of them and what they can expect from everyone else, and not just with what tasks will occur, but also with what communication is required. It takes a little upfront effort, but it pays off in dividends through the awareness it instills.

Inside Story: Notes from the Field

I could almost take my pick from any of my projects that had success challenges, and no doubt, it could serve as an example of the dangers when projects do not have the roles and responsibilities defined. All my strong projects included a RACI chart, and all my more problematic projects seemed to also be the ones where they omitted the RACI chart. Nevertheless, I trust you can probably imagine scenarios where projects can drift off course or they have too much overlap in resource responsibilities that only lead to frustrations or conflicts.

Truth be told, I have a couple of examples in mind, and I thought about sharing one of them in this section as a great example of how dysfunctional a project team can become when no one knows who is responsible for what. You may not have experienced this situation, and in that case, I will have to ask that you trust me when I tell you that there was plenty of people working completely uncoordinated with each other, they made an excessive amount of assumptions, and they hardly had communication with the rest of the team. The project sponsors initially thought that everyone is a professional and should know what to do; they did not want to babysit or micromanage because they felt the team was competent enough to manage on their own.

You got me, I still wanted to work a little of the bad in before I got to the good. My point is that even with a team of some of the best resources, you still need to define the roles and responsibilities. Every team needs some coordination and direction. Even elite hockey players on an NHL team have a coach who lets a player know what their role on the team is and what responsibilities the team expects from them on a given shift. If a coach wants a player to be a checking forward during a game to shut down an opposing team’s line, the coach will assign what the player’s responsibilities are to keep that opposing line from generating any offense. Elite and championship hockey players need a coach to work out the roles and responsibilities on the team before they can function as a team, and long before they can reach success. As far as I know, every sports team functions in this way. Establishing your roles and responsibilities is never something to skimp on or try to skip, because they are part of the fundamentals that allow a team to function.

Now I want to get to the good and provide you with an example of a RACI chart working and laying the fundamentals for a highly functional team. One example I like was a few years ago when I engaged with an office services outsourcing company to deploy a SharePoint cornerstone phase with collaboration team sites. We did not have much time or margin for error; we needed to get SharePoint deployed and functioning quickly and hand it off to the operations team. We took the project approach that I always prefer, which was to have an initial planning engagement where we worked through the project objectives and the operations handover plan. Most importantly, we worked through the list of all the roles we needed involved for the project delivery and the operations roles the service required for a successful handover. From there, we built out a list of all the responsibilities for each role, and what communication needed to take place.

Some people broke down their tasks into minute detail while others just focused on the highlights. Both worked well, and better yet, both worked well together. The more detail we had for a role, the easier it was to reallocate resources for portions if we needed to, but for the most part these were experienced domain experts who were quite familiar with their tasks and the requirements for each task. Capturing all the tasks helped us ensure that we missed nothing and that we made everyone who needed to be involved available and a part of the project delivery team. A business analyst could then take and audit this task list to ensure we had coverage before we kicked off the project.

With our RACI chart in hand (or more precisely, on a whiteboard in our project war room, just the way I like it), we kicked off our project. Everything unfolded like clockwork. Team members knew when we required their contributions and they could easily stay aware of the team’s progress. Just like a hockey team where everyone knows the position they need to play and can rely on where their teammates will be, we cycled through the tasks as if they were routine. Everything and everyone fell into place in a perfect orchestration of activities and outcomes.

When you have the fundamentals in place and your team is functioning in a healthy state, you can rely on these pieces to carry your team through tough times or difficult challenges. If everyone knows what role that they play and what they are responsible for, then they can feel confident that they are working on the right things, and that their teammates are also working on the right things. The whole process can almost feel routine, even if there is nothing routine about what you are tackling, and this is all because we have it all laid out and everyone has clear direction and coordination.

Wrapping Up

In this chapter, I discussed what resources you require for your SharePoint service and how to identify their responsibilities. I also looked at RACI charts, how to adapt a RACI chart for your team and your organization, and how to use the RACI chart to ensure that you have end-to-end support coverage and defined communication protocols. All this leads to a functional team that knows who is responsible for what and who depends on each other’s tasks. It leads to a team that delivers without hesitation and indecision, as each team member knows what they should be working on and where to go next. The RACI model with its roles and responsibility matrix looks after the fundamentals so a team can focus on providing value.

I just looked at all the different types of roles that a SharePoint deployment depends on and what responsibility those roles often hold. With all the people who are involved with the SharePoint service, you need to ensure they possess the technical knowledge and skills to meet their responsibilities that you identified. In the next chapter, I discuss technical readiness strategies you can use to train and prepare your resources to support your SharePoint service. I also look at approaches to end-user training that you can adopt to enhance your user adoption strategy.