In this appendix, I summarize and review the concepts I covered throughout this book to provide you with quick reference material where you can refresh yourself with the highlights from each chapter at a glance. I also provide you with action checklists for each chapter to highlight for you the next steps and actions I suggest you take.

Figure A-1 illustrates the idea I have been stressing throughout this book, the idea of balancing actions with your governance needs and your desired governance outcomes. Governance simply refers to the actions you take to govern your SharePoint service, those things you do to provide a reliable and valuable service. This appendix provides you with a rapid overview and several checklists for some of those actions you can take.

Chapter 1 In Brief

In Chapter 1, “Understanding SharePoint Governance,” I orientated SharePoint governance and defined it for the purposes of this book. I discussed the approach I take in the book to address governance and the primary audience for this book. The following lists the rapid concepts from Chapter 1:

• Governance goes beyond documentation. Documentation captures and communicates processes to ensure everyone is on the same page, and it can provide a lot of value. Yet, documentation in itself does not affect any change. This book focuses on the actions that do drive change and I leave the documentation options to your discretion.
• Governance encompasses actions, behaviors, and commitments. This involves a way of thinking that matures into values, doing actual things that need doing until they become habits, and staying dedicated to these values and habits.
• This book is for you if you work with SharePoint and you have an interest in learning more about my SharePoint governance experiences with customers in the field. I wrote this book in a manner to enable you to read the chapters that follow in numerical order, or you can skip to particular sections.
• SharePoint 2013 adds exciting new capabilities and it enhances some existing features that aid in achieving different governance objectives. eDiscovery provides the infrastructure for managing and governing content from individual items to entire site collections. SharePoint Apps allow users to purchase and provision their own functionality without modifying or affecting the underlying farm. The site access request process makes permission management and request management more straightforward for ordinary users, and this helps with governing access control as a result. Managed navigation associates a site’s navigation with a term set in the Managed Metadata Service.

Chapter 2 In Brief

In Chapter 2, “Defining Your SharePoint Service and Service Tiers,” I discussed how to make the scope of your SharePoint service explicit and intentional, how to set up different service levels, and how to design a chargeback-funding model. The following lists the rapid concepts from Chapter 2:

• Consider your SharePoint deployment as a service, and this will go hand-in-hand with treating your users as internal customers. You are providing SharePoint to deliver value that meets the needs of your internal customers. Consider your service's competitive advantage. How will it attract and satisfy your internal customers?
• Look to deliver quickly, deliver frequently, and deliver incrementally. Limit your SharePoint scope and have the confidence that you will continue to add value and expand the capabilities that your SharePoint service provides over time.
• Define your SharePoint service by starting with identifying the scope of what your service offers. A service can grow and expand its scope over time, and it can have different service levels with different scopes to meet different customer needs.
• A functional service request process includes a triage step where a resource assesses, prioritizes, and routes a ticket to the appropriate group. A valid priority level can be determined by using a rubric that defines each level using measurable metrics such as the number of affected users and the cost of potential revenue loss.
• Base your service tiers on multiple dimensions of the factors that define them. Those dimensions can include things such as the number of features, amount of system resources, number of users, size of content storage, range of support services, and the like. Chargebacks can charge a fixed amount for a service tier and then a variable amount for additional options that a customer adds to their service.
• Determine maintenance windows by building out a schedule on a visual timeline for each farm and then layer on each of the activities that occur, such as backups, crawling content, and the like. Coordinate global tasks with those in the local farm and the local peak usage. Finally, highlight core-operating hours for each location.

Chapter 3 In Brief

In Chapter 3, “Determining Your SharePoint Features and Functionality,” I looked at some of the new features in SharePoint 2013 and what its core capability areas are. I also discussed how to plan for and limit features, and how to map features to business value. The following lists the rapid concepts from Chapter 3:

• SharePoint 2013 provides a wealth of new features and capabilities, yet its underlying architecture is largely consistent with SharePoint 2010, which eases the relearning and training burden when upgrading to SharePoint 2013.
• The key investment and enhancement areas in SharePoint 2013 include eDiscovery and records management, social computing, search, business connectivity services, and request management, among others. SharePoint 2013 core capability areas include collaboration, social computing, portals, search, records management, business intelligence, and composite applications.
• Business value consists of the outcomes that a particular feature, capability, or composite application provides to end-users. You can measure it through dollars such as cost savings or extra revenue produced, amount of time saved in a process, extra contact points in a mass communication campaign, improved goodwill or morale, and the like. There are no shortcuts or cheat sheets that provide a master list mapping SharePoint features to business value, as the perceived value will be unique for each organization. One effective tool is to build use cases for the as-is and to-be states, and then use that to compare the business value gained from the solution.
• You can limit features by restricting permissions to them through web application policies or service application permissions, where available. You can completely disable some features by stopping their service or you can only associate service applications to the web applications you want them to be available within. You can also use custom actions to remove menu items you do not want available to your end-users.
• Evolve your SharePoint service by enabling new features over time. Focus on features that build on existing functionality for frequent and incremental improvements that deliver continuous value, rather than those breakthrough improvements that require a more radical change.

Chapter 4 In Brief

In Chapter 4, “Establishing Your Team's Roles and Responsibilities,” 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 organization, and how to use the RACI chart to ensure you have end-to-end support coverage and defined communication protocols. The following lists the rapid concepts from Chapter 4:

• A RACI chart provides the format for a roles and responsibilities matrix, in which you map roles to the tasks they are responsible or accountable for completing. You also map which roles require communication and involvement as part of the tasks by identifying which roles to consult and inform.
• Identify the tasks and roles your SharePoint service depends on by starting with the SharePoint farm and working your way out. Follow the data flow to identify all the systems that interface with your SharePoint environment to identify all the dependencies.
• Ensure end-to-end coverage by verifying that you can account for every task and included it in the RACI chart, that each task has a role specified as responsible for it, and that each role has a resource allocated to it. You can formalize your communication protocols by using a custom workflow within SharePoint that will standardize procedures such as approvals and change management processes.
• You can use your RACI chart to prime and guide your efforts in creating a service level agreement (SLA) because it lists details on all the tasks and roles involved with providing the service, and you can use this to determine what level of service you can provide. An SLA is a formal agreement between the business and IT on what level of service they can depend on.

Chapter 5 In Brief

In Chapter 5, “Shaping Your SharePoint Readiness and End-User Training,” I discussed the need for providing the operations team with readiness opportunities to ensure they have the right skills to support the service, and the need to provide end-users with training to help maximize their productivity using the service. I discussed approaches that utilize classroom and online training, peer mentors, and quick start guides. The following lists the rapid concepts from Chapter 5:

• Training can take many forms, from formal classroom workshops to online self-paced e-learning. Books provide a great return on your training investment and provide a means to reuse them by starting a team reference library. You can also approach learning through blogs and videos, or you can explore and discover functionality on your own.
• People learn best what they try to teach others. For an operations team, you can maximize the learning potential in this concept by dividing the potential topics among team members or pairs of team members to go learn, and later they can teach it to the rest of the team.
• Classroom training and conferences can generate ideas and inspiration for new possibilities and different approaches for solutions. They tend to target a wide audience and can be generic, but they also save time because someone else has already thought about the connection between topics and how to explain them.
• Peer mentoring involves a relationship of peers who can provide alternate perspectives and advice outside a superior-subordinate relationship. You might use peer mentoring to onboard a new team member to the team, or to develop skills in a particular area. The important point is that the relationship is neutral and does not involve any type of reporting or evaluation relationship.
• When you design custom training, design it around the learner and what skills you want the learner to acquire. The formula is to create learning objectives as an action phrase that you can later measure, break each learning objective into the tasks involved with accomplishing it, and then deliver the training to address each task. Measure how well the learner can perform the learning objective to evaluate the effectiveness of the training.

Chapter 6 In Brief

In Chapter 6, “Measuring and Reporting on Your SharePoint Service Performance,” I discussed techniques for monitoring and reporting on the health of your SharePoint service. I looked at metrics to measure and thresholds that can warn about potential problems, and how you can use that information to proactively respond and tune the SharePoint service. I discussed how to respond to an incident and how to conduct a root-cause analysis when an incident occurs. The following lists the rapid concepts from Chapter 6:

• You cannot measure and report on everything with the same scrutiny, because there is just too much information drowning out details from each measure. You can manage the amount of information by filtering out the noise and highlighting what is meaningful by setting thresholds and triggering alerts. You can use this process to keep your finger on the pulse of your SharePoint service and to maximize its availability.
• Availability relates to how available the SharePoint service is for use at a desired level of capacity. You can determine your availability needs based on your tolerance for downtime or reduced capacity in normal operations and in extenuating circumstances.
• You can measure and report on operational metrics that support the SharePoint service, such as human input and other indicators of the discipline and effectiveness of your operations team. You can measure on farm and system performance metrics by using tools such as SQL Profiler and Performance Monitor to measure the utilization and availability of resources. You can also use the SharePoint Health Analyzer to evaluate different aspects of your farm’s health and notify you when it detects problems.
• Having an incident response plan will help you when things go wrong. Your plan will guide you to a systematic response with a methodical list of activities, such as the information you need to collect, the people you need to notify, and your note taking procedure. An effective incident response plan will help relieve some stress and avoid blame as it guides you to assess the situation and work through the issue.
• A root-cause analysis is an investigative process to examine an incident or situation to look beyond any symptoms and determine the underlying cause. The point of this analysis is to understand what went wrong to prevent the issue from reoccurring.

Chapter 7 In Brief

In Chapter 7, “Creating Your SharePoint Roadmap,” I discussed techniques for planning and building a roadmap for your SharePoint service. I looked at what makes a roadmap valuable and how you can get started. I examined maturity models and how you can assess your maturity levels for different capabilities, and how this can contribute to your roadmap. The following lists the rapid concepts from Chapter 7:

• SharePoint is a large and complex product with a vast array of features and capabilities. It can quickly overwhelm a project team who tries to deliver too much at once. Focus on delivering smaller portions of value quickly and frequently to increase your success.
• A roadmap lays out a clear picture of where you are going and what you plan to accomplish. You can use it to track your progress and set expectations on what’s to come, and it can help you set the pace and scope to support program management. It highlights priorities and reveals impacts from any potential changes. Ultimately, they give you and your team direction, and they can help your vendors and partners share your vision.
• Start your roadmap planning by assessing your maturity levels against an IT maturity model. Use the gaps in the maturity model between where you are and your desired maturity level to identify the opportunities and activities for your roadmap. Prioritize these activities by listing dependencies, expected business value, and estimated costs.
• Apply the maturity model to assess your maturity level: chaotic, where you operate in an unpredictable manner; reactive, where you operate in a fire-fighting manner; proactive, where you operate in a predictive manner; managed, where you operate as an IT service provider; and optimized, where you operate as a strategic business partner.
• Apply the maturity model to assess your maturity levels for each of the seven core capability areas within SharePoint: collaboration, social computing, portals, search, records management, business intelligence, and composite applications.
• A visual summary infographic of your roadmap is the essence of your roadmap and is its primary communication tool. This provides a visual representation of the order of delivery as well as any dependencies. You can create it using diagramming tools such as Microsoft Visio or the SmartArt graphics inside Word.

Chapter 8 In Brief

In Chapter 8, “Promoting a Feedback Process,” I discussed different techniques to gather user feedback about your SharePoint service, including feedback on new opportunities where the service can expand to add additional value and feedback on what problems interfere with their ability to perform certain tasks. I looked at how to gather feedback by using surveys, analyzing usage reports, and interviewing and shadowing users. The following lists the rapid concepts from Chapter 8:

• Feedback can come from upfront requirements gathering and analysis or through ongoing usage. It can reveal the business value that you can deliver to your users, and this can help you understand how to make the SharePoint service more relevant to users.
• You can collect feedback through a variety of approaches, such as surveying users, analyzing usage reports, conducting user interviews, and shadowing users performing their business processes. Surveys and usage reports can scale to collect feedback from a large number of users, whereas interviews and shadow activities do not scale as well.
• Your feedback survey will work best if you balance the amount of time you require for responses with the perceived value in responding. To minimize the amount of time required for a response, you can use predetermined answers such as selection lists or ratings for survey questions. This fixed range of answers will also help you aggregate responses and analyze trends. However, it will also limit some of your ability to discover new findings.
• You can use SharePoint Usage Reports and other types of system-generated metrics to gather user feedback. This information can reveal what is the most popular and what available functionality users might be overlooking. It can help you discover workarounds or areas users have abandoned.
• Interviewing users requires open questions focused on the user and their business processes rather than on technology. Practice active listening to stay focused on the business value and avoid prematurely jumping into a solution design. Avoid leading or solution-focused questions. When shadowing users, focus on passive observing.

Chapter 9 In Brief

In Chapter 9, “Managing Your SharePoint Demand Funnel,” I discussed approaches to setting up a demand funnel for enhancing and expanding the SharePoint service, including considerations for establishing a triage process. I looked at ways to set expectations, build a parking lot list of enhancement requests, and how to map requests back to your roadmap. The following lists the rapid concepts from Chapter 9:

• You can use a demand funnel as a systematic routine to process requests for enhancements or expansions to your SharePoint service. A strong process will help protect you from the chaos of having requests pull you in all directions. It will also help you focus on constantly delivering the highest and optimum business value.
• A request triage assesses requests to determine their relative value, cost, and priority. To assess a request, you should include a representative group of stakeholders and team members who can contribute in the prioritization of an item. You should designate one person to chair the triage and they should facilitate consensus within the group.
• Encourage your team to capture as many details as they can for each request. You can attach design documents such as use cases, wireframes and mockups, UML diagrams, ER diagrams, and process and swim lane diagrams. You can then use this information to build estimates for the cost and effort required to deliver the solution. You can also estimate a rough magnitude of business value.
• A parking lot list or a backlog provides you with a repository of requirements and opportunities your team has captured for an undetermined future solution. This allows you to capture details of ideas as they come to people, while avoiding having the ideas pull your team off course and out of scope.
• For third-party products, you will want to look beyond isolated features as you evaluate its match potential for your SharePoint service. This includes both commercial and open source third-party products. At a minimum, you should evaluate the product’s functionality, test its stability and compatibility, assess the vendor’s support policy, and project the product’s upgradability.

Chapter 10 In Brief

In Chapter 10, “Growing Your SharePoint Service,” I discussed how to plan for growing your SharePoint service, including considerations to scale for availability, general infrastructure components, and the server roles in a SharePoint farm. I looked at the ability for SharePoint to evolve and grow over time as the usage pattern changes, and how this eliminates the need to feel constrained or to over-architect the farm upfront. The following lists the rapid concepts from Chapter 10:

• A SharePoint service will evolve and grow in a variety of ways, such as from expanding the capabilities available and increasing user adoption. However, it needs someone to plan and shape its growth. SharePoint does not have artificial intelligence capabilities built in to it to handle all of this work for you.
• You can scale your SharePoint service by scaling up or scaling out. Scaling up refers to adding or improving the resources in architecture’s existing components. Scaling out refers to adding additional components to the architecture. For example, you can scale up by adding additional RAM to servers while maintaining the same number of servers in a farm, and you can scale out by adding additional servers to a farm.
• A SharePoint farm consists of one or more SharePoint servers and one or more SQL Servers. Some farm architectures conceptually divide the SharePoint servers into web server roles and application server roles, and the implementation details then are a matter of starting or stopping the appropriate services on each server. Other servers you may involve in a farm’s architecture include Office Web Apps, Exchange, Lync, Active Directory, and Forefront Unified Access Gateway (UAG).
• You can join a new SharePoint server to an existing farm by first installing SharePoint 2013 on a Windows Server. Then you can apply all the latest service packs and patches, language packs, and any third-party components to match the other servers in the desired SharePoint farm. Finally, you will run the SharePoint Products and Technologies Configuration Wizard to join the server to the farm.

Chapter 11 In Brief

In Chapter 11, “Preparing for SharePoint Upgrades and Patches,” I discussed how to build policies and standards that maintain the supportability of the farm and maximize its compatibility with upgrade processes. I looked at considerations for designing solutions in a manner that takes advantage of structures within SharePoint, and implementation strategies that offer the lowest risk against interfering with cumulative updates, service packs, or version upgrades. The following lists the rapid concepts from Chapter 11:

• Maintaining your SharePoint environments with the latest patches and service packs can help contribute to a healthy SharePoint service. It will correct any known security vulnerabilities, correct any other known defects, apply any performance improvements Microsoft identifies, and maintain a current version.
• Microsoft designed SharePoint to allow you to adapt it to fit changing needs as more information and new opportunities arise. If you feel particularly constrained by historical decisions that led your SharePoint environment to where it is today, you can migrate the content into a fresh environment. Knowing this option is available can help to relieve any anxiety about potentially painting yourself in a corner.
• Maintain product supportability by not making changes to system files and not directly changing data in any of the SharePoint databases. You can also optimize supportability by applying the latest service packs and by following the guidance in Part IV of this book when implementing customizations or custom development.
• A rollback plan is only valuable if you create one and test it before you need it, because then you will have it to simply undo whatever change caused a problem. Your rollback plan will typically consist of first capturing a snapshot of the server state and the databases before applying any updates or attempting an upgrade. Then if something goes wrong, you simply revert to the previous state.
• You can prepare for upgrades by maintaining your SharePoint environment in a supportable state. Typically, Microsoft will not provide you with many details too far in advance of a new version releasing, so it can be difficult to predict before the actual release. You can set yourself up for a good upgrade experience by spreading your site collections across several smaller content databases rather than a few large ones. You can also prepare by completing any site experience upgrades left over from upgrading the previous release.

Chapter 12 In Brief

In Chapter 12, “Committing Sponsorship and Ownership of Customizations,” I discussed the benefits of establishing sponsorship for customizations to commit ownership or funding for sustainable customizations. I looked at capturing a chain of custody that leads back to commitments to fix defects and mitigate upgrade issues. I also considered topics that relate to support policies for global customizations, utilizing Apps for SharePoint, and delegating ownership of customizations to site administrators. The following lists the rapid concepts from Chapter 12:

• A sponsor can be someone who funds and owns the budget for a SharePoint project or an aspect of the SharePoint service operations. A sponsor can also be someone who owns the ultimate accountability for a SharePoint project or an aspect of the SharePoint service operations.
• Identifying ownership will help to prevent neglecting and shifting of responsibilities. An owner with authority can help to drive decisions and resolve any political disagreements. Ownership can also help organize structure and create an effective escalation path.
• A customization’s costs continue long after the actual development and the deployment costs. Customizations may require user support and training, bug fixes, and rework to make them compatible for future upgrades. Sponsors for customizations can commit to own the burden for bug fixes or future upgrade costs, typically for a given duration.
• With global customizations, you first need to assess their compatibility with the existing environment, and then you will need to assess the overall scalability of the customization to ensure it will not consume unnecessary server resources in the farm. You will also need to determine whether your team will own the accountability for customization, either by taking on this accountability from another group or by developing it yourself.
• Apps for SharePoint provide modular functionality users can add to their site. SharePoint 2013 includes built-in Apps readily available for site administrators to use and it provides a connection to the SharePoint Store catalog where vendors sell their Apps through the SharePoint Store. You can also host an Apps catalog for internal Apps.

Chapter 13 In Brief

In Chapter 13, “Facilitating and Isolating End-User Customizations,” I discussed how you can facilitate end-user customizations and how you can isolate those customizations so they do not have a negative impact on the performance of your SharePoint service for other users. I looked at how to empower your users in a safe and contained environment so that they can adapt and tailor the service to meet their needs without introducing an unnecessary burden on support. The following lists the rapid concepts from Chapter 13:

• As you are determining how much you want to delegate site management to site owners and empower your end-users, avoid having pessimism consume your thinking. You may hold fears of empowered users leading to potential demand on support, and this can blind you from considering whether the benefits will be worth any added support cost.
• Empowering users can increase adoption rates, and it lets users tailor their site experiences to meet their needs while reducing the IT burden and bottleneck for changes and customizations. Empowering users is not a yes or no option, and instead it involves a range of permission levels and functionality to enable or disable for a user.
• SharePoint Design Manager enables interface designers to use whatever HTML and CSS editing tool that they are comfortable and proficient with to design a custom interface for a SharePoint site. This removes the barrier to entry because they can code their markup and styles without requiring any specialized SharePoint knowledge. Design Manager then translates pages into a SharePoint construct.
• Planning and providing a default site experience will provide all users with a consistent base, a common place to start from and a common way to meet the majority of your users’ needs. It should offer the newer or less technical users a simplified and intuitive way to accomplish tasks. Use wizards and promoted links to guide users to add features to their site and avoid bloating a default site with empty folders and Apps.
• You delegate management control of a site to a site owner by granting them the necessary permissions within their site; they in turn can manage the permissions of others.
• A site collection provides an isolated container to separate end-users and their customizations. You can apply a site quota to set boundaries around a site collection.
• Apps for SharePoint are self-contained pieces of functionality that end-users can add to their site. Site owners can discover Apps through different catalogs, such as Apps available in the site, in an organizational catalog, or in the SharePoint Store.

Chapter 14 In Brief

In Chapter 14, “Designing Your Development Standards and Testing Processes,” I discussed how to establish development standards for customizations and what testing processes can help enforce those standards. I looked at how development standards and processes can help lower the risk a custom component poses to the SharePoint service's availability, and how you can automate tests to detect issues early. The following lists the rapid concepts from Chapter 14:

• An architect can help you coordinate different development efforts and they can help you avoid the cycle of developing around issues. They take a global view of the system and all its parts, and they think through wider reaching implications such as future support and maintenance needs.
• Customizations of a global nature require forethought and consideration for any impact on the global availability and sustainability of the SharePoint service. The main issue with global customizations is the scope of potential impact and the number of affected users if something goes wrong.
• SharePoint Apps provide a simplified and centralized way to purchase add-in components from third-party vendors in the SharePoint Store or select from your organization’s catalog. Apps provide you with the safest option for extending your SharePoint farm with new functionality and they help to maximize your flexibility when developing future upgrades. However, they are limited to things you can develop with the client object model and contain within a site collection. For all other customizations, you need to develop them as SharePoint features and package them within solution packages (WSP).
• Developer boundaries do not have to come with a lot of overhead and tight restrictions. They can take the form of general guidelines or specific areas to avoid certain things that you want to restrict. Set these boundaries to address specific things so that you can validate any customization to confirm whether or not it meets the boundary criteria.
• Instrumenting and tracing code allows you to instrument different parts of your code to provide information while it runs. This can provide you with verbose information about state information and the control flow of the code as it excutes in production without having to attach a debugger.

Chapter 15 In Brief

In Chapter 15, “Framing Your Information Architecture and UI Standards,” I discussed how to define standards related to the information structures, layout organization, and visual design. I looked at how to build a controlled vocabulary and enterprise taxonomy to tag and organize content, and I considered how to apply this metadata to documents and people profiles. The following lists the rapid concepts from Chapter 15:

• Design your pages to keep them consistent from one page to the next so users will find your site easy to use. This also orientates and maintains familiarity for your users. You can create wireframes and mockups to roughly draft the layout of elements on pages and the interaction between pages.
• A functional navigation provides a dual purpose: it enables your users to ascertain their position within your SharePoint service and it equips your users with a route to follow to move through the different sites and web properties within your SharePoint service. Your navigation structure needs to provide a way for users to navigate to where they are trying to go, and it needs to provide a way to head back the way they came so that they can always get to the homepage.
• Managed navigation allows a site administrator to associate their site’s navigation menus with a term set in the managed metadata service.
• An enterprise taxonomy is a hierarchal structure of terms your organization uses to categorize and organize information. Users categorize their information by tagging a unit of information with a term from the taxonomy. To build an effective enterprise taxonomy, you have to analyze all the different types of information within your organization and identify all the attributes that can apply to each type of information.
• You can import much of the data for your people profiles from your identity management system or a Business Connectivity Services application using the User Profile Service profile synchronization job. You can also make SharePoint the source repository for people profile properties and allow users to edit them through their profile.

Chapter 16 In Brief

In Chapter 16, “Coordinating Your Code Promotion and Release Processes,” I discussed considerations for planning a change management process and designing a release management process that encourages maturity and discipline in your deployment practices. I looked at how to automate integration testing and how to promote code through testing and staging environments to ensure stability before you deploy it to production environments. The following lists the rapid concepts from Chapter 16:

• Your release management process involves multiple environments to physically separate development and testing from production use, which helps you to keep your production environment more stable. As you promote code through the preproduction environments, you move the release testing closer and closer to the production conditions.
• Preproduction can include the following environments: development, build or integration, test and quality assurance, user acceptance testing, and staging. You can expand or contract this list of environments based on your own needs and your processes.
• The integration stage offers you an opportunity to implement an automated build and continuous integration process. This will help you merge all your developers’ code frequently. Adopting an automated process will help you catch compatibility issues early, and if it detects an issue the system can open and assign a bug automatically.
• One key indicator for how mature you are with your release management is how thoroughly you test customizations throughout the development lifecycle. Have your developers and quality assurance group build a suite of automated and manual tests.
• User acceptance testing (UAT) is an opportunity for your users to let you know whether or not you built the right solution. You are conducting UAT to collect user feedback and identify opportunities to make improvements and better meet their needs.
• A rollback approach for customizations needs a more granular strategy than restoring backups of server state and databases. This is because you will not schedule downtime to deploy most customizations and users can continue to make changes to their sites. The best rollback plan to back out of any customization changes is to create a rollback script. Typically, this is a PowerShell script that reverses any changes the customization introduces.

Final Thoughts

We have come a long way, and in the process, I have shared all my practices and approaches to successfully govern a SharePoint service. I tried to especially share those techniques that I found work well, but that I do not hear about often enough in the market. Really, I wanted to fill the gaps and move beyond what appeared to be an overly fixated discourse on simply documenting a governance plan.

Documentation can be very valuable, and it can serve to establish a shared vision and a shared understanding with everyone. In taking a focus on those actions you can do, to actually have a tangible and immediate impact on your SharePoint service without some extensive governance planning exercise, I purposely avoided discussions on documentation. At the same time, I tried to avoid diminishing the value documentation can provide and I encouraged you to find the right level of documentation for your situation.

Your governance documentation should reflect the actions you are taking to govern your SharePoint service, and it should reflect it in a way that is consistent with your organization’s culture and standards. When you start with a generic governance planning template and become too fixated on its static aspects, you trend away from building documentation to reflect actions. In my experience, I have found generic governance templates simply do not reflect dynamic actions you do to govern, and this is because those templates tend to be overly prescriptive and policy-driven. Policies are nice and they are certainly essential, but you need actions before you will have any effect.

Throughout this book, I considered many actions you can take to govern your SharePoint environment. Now that you have a good sense about what actions you want to take, you are ready to go on now and build whatever documentation you feel will reflect those actions. Your documentation can help establish a shared understanding of how your SharePoint service will run and what actions everyone will take to govern it. I encourage you to consider many of the templates and prescriptive guidance on documenting governance artifacts, because many of these might have relevant and valuable parts you can adopt and adapt. As you move forward with your documentation efforts, try to approach it as a reflection of actions.

SharePoint governance can feel tough and certainly a little mysterious. This is because SharePoint can fit so many situations and scenarios – it packs a lot of punch and delivers what can at times feel like an overwhelming amount of potential value. Through all of this, it is able to adapt and fit whatever circumstances it finds itself in, whether that is well planned and highly orchestrated, or it is a more organic and free flowing. SharePoint can find a way to adapt.

A while back, I saw a nature special on TV about raccoons. These little creatures seem to adapt no matter what conditions they face. When development brings urban sprawl all around them, they find new sources of food in urban waste. When roads bring traffic, they learn how to negotiate crossing the road mostly avoiding cars. When developers cut down forests for neighborhoods, they find new places to nest and new ways to navigate the area. Country raccoons hunt while urban raccoons scavenge.

Not that there is a direct parallel between SharePoint and raccoons, but they share the concept of adapting to find a way to fit whatever situation they face in their environments. This might be why SharePoint governance can feel challenging at times, because SharePoint finds a way to adapt and work to some degree. Herbert Spencer coined the term that Charles Darwin later made famous, “survival of the fittest.” Both used fittest to refer to how well something can adapt to fit a situation, not in the sense of what is the strongest or most physically fit. SharePoint adapts to fit different situations particularly well, but it also packs a lot of punch, so perhaps it fits no matter how you want to read fittest.

I hope you have gotten a lot out of this book. I tried to pack a lot of information and experiences from a variety of perspectives that you can apply to a broad range of environments. I tried to wrap all this into a concise book that you could read quickly if you need to, but at the same time to provide you with a book that would have the answers you need and concrete direction on what actions you can take.

I would very much appreciate hearing about what your experience was like reading this book – what you liked and what else you were hoping to learn. Please do send me a tweet @SteveGoodyear and let me know what your reading experience was like, what your favorite tips or features were, or simply what you thought of the book. I look forward to hearing from you and I wish you the best as you take the actions and tips that I shared in this book and put them into practice to govern your own SharePoint service!