Committing Sponsorship and Ownership of Customizations
Not everything that is faced can be changed. But nothing can be changed until it is faced.
—James Arthur Baldwin
In this chapter, I focus on the idea of sponsorship for your SharePoint service. I start by looking at sponsorship in a general SharePoint sense, and then I look at sponsorship specifically as it relates to customizations such as custom developed components and even end-user site customizations. As I review sponsorship of customizations, I walk through an approach to establish a policy that links sponsorship to any server customization. I also offer guidance on requiring a chain of custody for any enhancements and considerations for global customizations. Finally, I discuss how to isolate and delegate ownership of customizations to site administrators using Apps for SharePoint and other delegation capabilities.
One key point I stress in this chapter is to ensure that someone owns or is accountable for different aspects of your SharePoint service, and in particular, those political aspects and those areas that relate to customizing your service.
After reading this chapter, you will know how to:
- Describe the purpose for sponsorship and its importance
- Link sponsorship to a RACI chart
- Set sponsorship conditions for any customization
- Establish a chain of custody for service customizations
- Identify sponsors to fund customizations and development
- Explain sponsorship considerations for global customizations
- Plan for and utilize Apps for SharePoint for customizations
- Delegate ownership of customizations to site administrators
Sponsoring Governance
Sponsoring different aspects of governance must be important, for it seems to play such a pinnacle role in almost any governance presentation or governance “plan” I come across. I am not necessarily referring to sponsorship in the sense that may be common in these other governance discussions. I think I share the intrinsic theme of sponsorship as any other SharePoint governance approach, but I do seem to differ in its application. As you read through this chapter, I share these differences, and I ultimately answer the question about how to establish effective sponsorship.
Before I jump into my practice of sponsorship within a SharePoint service, I want to quickly explain what I think sponsorship is not. As I looked at governance references and guidance, sponsorship appeared to play a pretty significant role. To paraphrase and over-simplify some of this governance guidance, it said that I needed to document some governance “plan” based on a template, and then identify a sponsor. From there, it recommended that I set up a governance committee to meet regularly with the sponsor, who would presumably be the ultimate decision maker. Just to be clear, sponsorship is not simply the chair of some recurring governance committee meeting.
Unfortunately, the typical governance guidance seems to end there – fill out a template and then have a committee meet regularly, and everything else should just fall into place. This type of advice falls short of answering what a sponsor actually does or what they are accountable for. I find the advice also does not provide much direction on the governance committee meetings it recommends, nor does it identify any outcomes or goals for these regular meetings. You may find these meetings valuable, but for now, I will just assume that we all have enough wasteful or aimless meetings on our calendar. Later in this chapter, I come back to explore the idea of a governance committee and some different ways that you can structure it to make it effective.
If sponsorship is not simply someone who signs off on governance documentation and policies, and it is not simply someone who chairs a governance committee meeting, what is sponsorship? To answer this, I want to return to the very beginning where I quoted the definition of governance as the actions one takes in order to govern. I unpacked this idea to think of SharePoint governance as the actions, behaviors, and commitments that contribute to running a healthy and intentional SharePoint service. Essentially, I want to focus on the things you need to do to offer a stable and valuable SharePoint service.
Important Sponsorship in governance is about who you need to involve so that you can do what you need to do to offer a stable and valuable SharePoint service.
So, what does a sponsor do then? To answer that, first let me return to my trusted Oxford English Dictionary and consider the definition of a sponsor. A sponsor is a person who provides funds for a project or who holds official accountability for its actions and outcomes. Based on this dictionary definition, I can paraphrase sponsorship into the following:
- A sponsor is someone who funds and owns the budget for a SharePoint project or an aspect of a SharePoint service
- A sponsor is someone who owns the ultimate accountability for a SharePoint project or an aspect of a SharePoint service
Therefore, a sponsor is someone who is accountable for a budget or accountable for an outcome. A sponsor can wear one or both of these hats. You can have multiple sponsors for different aspects of a SharePoint service or a SharePoint project, but you need to ensure that you do not have any overlap of accountabilities. If you look back to Chapter 6 where I discussed roles and responsibilities, I stated that only one person can be accountable for a particular area or aspect of the SharePoint service. As you develop and enhance a RACI chart for your SharePoint service, your sponsor roles will hold the accountability for certain tasks and activities that the service depends on.
A sponsor can set the commitment aspect of your SharePoint governance. They can commit to a particular approach or a particular behavior, and they can provide their commitment and support to the resources that the RACI chart identifies in the different roles. They can manifest their commitment and support through providing adequate funding to do things in a preferred way, as well as by reinforcing the notion of following a disciplined process and avoiding shortcuts or hacks. They hold ultimate accountability for an area, and as such, they typically are the ultimate authority and decision maker for that area.
You might wonder why I delayed the topic of sponsorship until now, in this last part of this book. I had a couple of reasons for this. First, I wanted to signal that establishing sponsorship is not necessarily a prerequisite to deploying a SharePoint service and establishing SharePoint governance. I find that when sponsorship gets too much emphasis too early in the process, the rest of the governance initiative begins to fizzle and wait on a sponsor to wave their magic wand and solve all the issues. However, there are actions that you can take to govern your SharePoint service in the absence of sponsorship, as this book shows. You can drive these behaviors long before you establish a sponsor or a governance committee, if they even fit with your SharePoint governance needs. I delayed this discussion until now to highlight that the need for a sponsor should not stall any other progress you can make.
The other reason I wanted to discuss sponsorship in this part of the book relates to the nature of customizations and development. SharePoint as a product is quite resilient. Even when things feel as if they evolved in some ugly way, SharePoint still manages to work and provide value. Its site structure may be a hodgepodge from some random hierarchy generator. Its servers and databases may feel clunky. It may not be as optimal as you would prefer, but in most cases it still works. However, once you throw in a bunch of custom development, this resilience can quickly degrade. Therefore, I find sponsorship in a default environment is something that leans more toward a nice-to-have aspect in an action-focused habit of governance. Whereas I find sponsorship plays a crucial role whenever you are customizing your SharePoint service.
The bottom line is that someone needs to own a SharePoint project and someone needs to own each aspect of a SharePoint service once it is implemented. They may not do the work, but they own the accountability if the work is not done correctly. They may not involve themselves in the day-to-day details, but they own any decisions that a team is unable to resolve and needs to escalate to them. A sponsor completes your RACI chart by giving you the person you hold accountable and establish ownership with.
Importance of Ownership
In economics, there is a theory referred to as the tragedy of the commons. This occurs where a group of people who are sharing a common resource each act rationally and in their own self-interest as they deplete the common resource. The tragedy occurs because even though they are aware that over-depletion of the common resource is not in any of their best long-term interests, in their self-interests they will continue to deplete the common resource. This is because they all share ownership and their self-interests end up outweighing their collective long-term interests. Generally, in the absence of private ownership, it is the government’s job to protect the long-term interests of a common resource.
My point is that without ownership you will have to act as that government and balance all the interests and motives for the different ideologies. Even with an executive sponsor owning the entire service, you still have to do some balancing. Presumably, your SharePoint service is a common resource, shared by different groups within your organization. Your job is to balance the service so that one group does not over-consume and deplete the service. One strategy I looked at is to define the service and its boundaries. Another strategy you can use is to delegate ownership of different aspects of the service.
By establishing ownership, you can delegate some of the balancing, and preferably to someone with authority to push compromises for the greater balance and everyone’s long-term interests. The challenge though, is that their self-interests will typically drive them because they do not own the entire service. However, they will balance the interests within the area they own within the boundaries you define. The onus is still on you to act as the government body that protects the entire service, to govern, to define the service and balance the interests of each group with the long-term interests of the service.
If you return to my RACI chart discussion from Chapter 4, then you will hold the responsibility in the RACI chart for balancing and protecting the long-term interests of the service. If you establish an executive sponsor for the entire service, then they will hold the ultimate accountability while you retain the responsibility. Delegating ownership then is essentially delegating accountability for particular areas. It may not solve the tragedy of the commons problem, but it will help you deal with it. To refresh your memory on the difference between accountability and responsibility in a RACI chart, I will briefly describe the two roles again.
- A role you list as accountable holds the ultimate accountability for the work or the decisions.
- A role you list as responsible identifies the role that actually performs the work. If you do not list another role as accountable for this work, then the role you identify as responsible is both responsible and accountable for the work.
The most important aspect of defining ownership is that it establishes accountability. To quote a phrase that former U.S. President Harry S. Truman made popular during his presidency by displaying it on a sign on his desk, “The Buck Stops Here!” The phrase referred to Truman’s belief that the President is accountable to make decisions, and the President must accept the ultimate responsibility for those decisions. You want ownership where you can establish accountability for a particular area or a specific customization so that the buck will stop with someone.
An owner with authority can drive decisions, and using the owner as a decision maker can resolve political situations or disagreements on an approach. Even in the most politically charged situation, you can have them make the authoritative decision and mandate the direction or approach when you need to move things along. Although I always prefer negotiating and building support for an initiative, sometimes you may find yourself facing polar opposite stakeholder opinions with those stakeholders unwilling to change or compromise. On top of that, sometimes you may find yourself facing stakeholders who simply enjoy bureaucracy and dragging processes out to avoid doing any work. In those cases, you may just need an authority to own a decision and move an initiative forward.
When you establish ownership, you will also generate order and a certain amount of organization. By establishing an authority that you hold accountable for a particular area, you begin to form a hierarchy of accountabilities and responsibilities. Better yet, you delegate the forming of much of an area’s hierarchy to the owner of the area by specifying their accountability. This structure of ownership also helps to create an effective escalation path when something does go wrong or when someone has a suggestion.
In short, sponsors add structure and they provide accountability for a particular area, and this adds stability to your SharePoint service. It organizes and adds stability either to an operational area, a project delivery, or to customizations and enhancements. You can use this stability to plan around, such as when you create service-level agreements similar to those that I discussed back in Chapter 2. You can also use this stability to plan your roadmap that I discussed back in Chapter 7. Your ultimate goal for identifying sponsors and the underlying importance for delegating them ownership then is to build stability in your SharePoint service through the accountabilities that you associate with sponsors.
Although these principles apply to sponsorship for any aspect of your SharePoint service, I want to focus on how sponsors can help stabilize customizations and any other custom development. As I mentioned earlier, SharePoint as a product already coordinates its different features and capability areas. When the product team discovers an issue, they work on developing a patch. Therefore, in this sense, Microsoft plays the role of a sponsor for the product’s code-base. When you develop your own features, you do not automatically inherit sponsorship from a vendor for the code and any enhancements it requires. Nevertheless, you still can set up accountability for any code or customization by requiring a sponsor for any customization, and I discuss an approach for you to consider in the next section.
Requiring Sponsors for Any Customizations
You may find a common role for a sponsor on a project delivery team. They may fund the project or approve the resources and each resource’s time to deliver on a project team. You may copy them on status update emails, and they may even come to the odd status meeting. However, they probably are not hands-on with the project, and instead they delegated that responsibility to a project manager or a team lead. Once the project completes, they might check it off their list, hand it off to operations, and in the process, they might also hand off their accountabilities that they held as a project sponsor.
Here comes the danger: where does the ownership lay and whom do you hold accountable for a customization? This void does not end there, as the lack of ownership directly adds risk and instability to your SharePoint service. When a project sponsor simply hands off a project delivery to an operations team and they absolve themselves of ownership, they leave the team with a number of questions, many of which go unanswered and will place a burden of risk on the operations team. The following lists some significantly important questions that you might consider before accepting any project hand-over.
- What happens if you later discover a bug and you require more development effort to fix the issue?
- Who owns the source code and who will have access to it?
- What happens if you find this customization is no longer compatible with future versions of SharePoint? Will someone rebuild it or migrate the code? Can you simply remove it?
- Who will respond to support tickets that relate to the customization?
- What happens if another group begins to also use the customization and they want to enhance it to better fit their needs? With whom can they coordinate with and will they even have access to the source code?
- Who will perform an architectural review of the design and how sustainable the solution will be in the future with a wide adoption rate?
Too often, I find these questions seem to go unanswered, and the result ends up putting the onus on the operations team to fill in the gaps when things go wrong – and chances are, things will go wrong if you are accepting customizations without considering fundamental questions such as these. You can address these issues ahead of time by putting these questions front and center before you ever agree to move forward with deploying any customizations. This adds a level of discipline to your process that helps prevent short-term hacks from becoming the norm. If you make your process known, including the requirement to identify the ownership who will hold accountability for these questions, then the checkpoint should come as no surprise and your internal customers should anticipate and come prepared to meet the sponsorship requirement.
People may find it easy to simply throw their name in as the owner for any customizations, or they may try to bully their way through. You need to prequalify that they hold the necessary authority to take on the required ownership, and on top of that, you need to capture their commitment for you to hold them accountable for the those areas I identified previously. You definitely do not want a situation where you felt as if you did your due diligence by identifying an owner, but later discover they were just going through the motions to get a component deployed that they need.
It is an imperfect world and this is an imperfect system. Occasionally, you may have someone who commits to own the ultimate accountability for a customization, only to later have them evade their commitment and shift the responsibility. You did what you could: you ensured that they held enough authority to make the commitment, you explained what they were committing to, and you walked them through what that commitment meant and how you would later rely on them. At the time, they agreed profusely and maybe acted a little offended that you would spend so much time explaining their commitment to them. Yet, when the time came, they welched on their commitment.
Usually, when you identify an owner with the appropriate level of authority and list the details about what you will hold them accountable for (such as answers to those questions listed earlier), then they will honor the agreement. Most people are reputable, or at least I like to believe so. Even if they turn out not to be, then you can rest assured knowing that you did what you could. The reality is that any number of reasons could prevent them from following through with their sign-off on their commitment to ownership, including some of the following:
- Their budget is now frozen or significantly reduced
- People on their team have since resigned and moved on
- They moved on to a new role and no longer have the authority
- Enough time has passed that they no longer feel accountable
- They were overly optimistic on how few defects they expected
I would not ask an executive to sign their name in blood, unless I was looking at a reasonably significant project and I faced serious risk. However, I would still recommend that you have some formality to the sign-off on a sponsor’s commitment so that you can explain your increasing support costs to your own manager later if the sponsor does not follow through on their commitment. It would not be an ideal situation, but on the other hand, it would not be very different than if you did not have the process to identify owners for customizations in the first place. Therefore, even if it is not perfect in practice, you will still be better off than if you did not identify owners at all.
In most cases, I find that establishing ownership with their commitment to address any issues is a practice that works quite well. For one reason, it incentivizes them to have their developers follow a disciplined approach so that the customization will not come back to cause them too much grief down the road. This process encourages good habits early on, particularly as they involve you to work through these preconditions on the ownership of customizations. With you involved in their development process, you will have the opportunity to offer architecture guidance if this is in your skillset, as well as the chance to coach them on adopting disciplined development standards and testing processes.
Note Please see Chapter 14 for a deeper discussion on development standards and testing processes that you can encourage teams to adopt if they want to deploy global customizations to your SharePoint service.
My approach for establishing ownership typically involves some form of a service-level agreement. For example, if an internal customer came with a request to deploy a web part that they developed so they could make it available to the entire organization, then I would work through a service-level agreement with them to answer all of the questions I noted earlier. Within the agreement, I would identify the owner who will hold the accountability to uphold the agreement. I would also identify the support plan if any issues arise, and what their patching or updating policy will be. Finally, I usually then include a clause that states something to the effect that if support issues come up and they are unresponsive, then operations will uninstall the component and discontinue its availability.
When you identify owners, it is important that you base the owner on a position (job title) rather than on a named individual. People change jobs – they receive promotions, they retire, they quit, and they face layoffs. Someone may hold the authority today to commit to the accountabilities you both agree to in a service-level agreement, but if they switch jobs, they may not hold the authority to act when an issue comes up. Or worse, if they leave the company, then they definitely will not hold any authority. However, if you associate the ownership with their position, then whoever holds that position can fulfill the obligations of the support commitments.
You may face times when a sponsor will not be available. I shudder to think about these situations, but they do occur. This may stem from an internal customer who needs custom features, but who is unable to take on accountability for those features. For these situations, I usually try to find a compromise somewhere and I would look for funding to compensate for taking on the added support maintenance for the customization. Typically, most plans are a hybrid that mixes existing support and operations with what the requestor of the application contributes. This makes good sense in many cases as well, because for instance, you probably do not want to start introducing several different frontline support groups, as this adds complexity to your service desk processes. Figure 12-1 illustrates a sample flowchart of a support transition from the project team to the service desk during a warranty period.
Figure 12-1. A sample flowchart for a support service request during a transition period from the project team
Table 12-1 provides an example of how you might structure ownership of accountabilities for a custom developed web part for a corporate communications group. The project sponsor holds accountabilities during the actual project and the warranty period – the period of transition from the project development and delivery team to the operations team. This model offers a compromise where the business sponsor holds a high degree of accountability during the warranty period, but eventually he or she transitions all accountability except funding for bug fixes to another owner as the enhancement moves into operations.
Table 12-1. An Example of Transitioning Ownership in a Service-Level Agreement for a Custom Web Part
| Accountability | Warranty Period Owner | Regular Operations Owner |
|---|---|---|
| End-user support | Business sponsor | Service desk |
| Funding development for bug fixes | Business sponsor | Business sponsor |
| Funding development for upgrade compatibility | Business sponsor | SharePoint service team |
| Architecture review and sign-off | SharePoint service team | SharePoint service team |
| Funding for enhancement requests | Business sponsor | Requires a new sponsor |
THE SURPRISE CUSTOM APPLICATION
A while back, I was working in an IT department, and my team discovered that one of our customers, a group within the organization, had hired an intern to develop an application for them. My team tried to get involved to help influence the architecture and ensure they thought about the supportability of the application, but they refused. They claimed that their intern was going to do a fine job developing it and that they were going to own and support the application anyways, so there was no need for IT to get involved.
If you have been in IT long enough, then you know things never work out that way, no matter how insistent the business might be. My team knew it was only a matter of time. Low and behold, eventually the intern student went back to school and they released the Ruby on Rails application into the wild. It was, as any senior developer would expect, largely a student development project and definitely not an enterprise-grade application. The application had scale issues, which was a problem because its user base was growing rapidly.
Seeing things not follow the happy path that they had hoped and with their intern student now back in school, the group was ready to wash their hands of this application and hand it off to IT. Now it was my department’s problem (though thankfully it was not my problem directly as it went on another team’s plate). I imagine the only thing worse than trying to stabilize an intern student’s code in production might be the pain of having to live with many of his or her architecture decisions because no one will fund a redevelopment effort.
These are the custom applications that you want to avoid popping up in your SharePoint service with an unexpected support challenge. By establishing checkpoints that require ownership sponsors and other standards that I look at in the chapters still to come, you can help to reduce your risks for the surprise custom application.
Establishing Ownership and a Chain of Custody
When I am managing a SharePoint service, the first and paramount precondition I seek is access to any source code before I deploy customizations and custom development. In the rush of things, developers may move on from the company and forget the source code on their desktop; vendors can disengage after project sign-off and forget to hand-over any source code. I have been stuck in this position before, and it has come back to haunt me when I needed to fix a defect or redevelop a component for compatibility with an upgrade. Therefore, now I am extra vigilant about getting a copy of the source code and I check that into my own source repository as a precondition to any deployment – including any deployment update.
In the case of a third-party product, then I understand that the vendor probably does not provide any source code, but they will provide a warranty and an ongoing support policy. My precondition in this case shifts to where I verify their support policy in lieu of access to the source code. Including this step ensures that you capture the vendor support information before any deployment, and thus before anyone rolls off a project and disappears with the details. I usually set up a SharePoint site where I can store vendor details and support information about any products that I have deployed.
I find that capturing the source code or the vendor support details is valuable, as the operations team may require it someday, and this precondition ensures that you have captured it somewhere. However, it does not mean that the operations team has taken ownership of the customization. You still need to answer the questions I pointed out in the previous section when I looked at why it is important to require sponsors. Capturing the code and support policies is merely a step to check in the process to ensure you have what you need stored in a known location before you need it. It also gives you access to the things you need to test and to validate customizations before you accept them.
Note I discuss testing processes for customizations in more detail in Chapter 14.
For me, putting the right checkpoints and change management processes in place helps to enforce discipline, and this helps you keep a healthy SharePoint environment. Part of this approach would include having teams identify valid ownership to sponsor a change, and part would include preparing a change package that includes any source code, installers, and support or other documentation references. If these things are “coming” then you freeze the deployment. The checkpoint enforces that you have all the required pieces in place before deploying any customizations or third-party products. It is not that I do not trust these teams; I just have the checkpoint to enforce the rule for everybody so that I do not have to track follow-up items.
I may come across as a little militant when it comes to controlling my SharePoint environment, and the truth is that I can be. Rather than thinking of myself as being overly controlling and militant with the environment, I prefer to think of myself as safeguarding it. When I am responsible for a SharePoint environment, then I am the last line of the defense and my job is to ensure everyone meets standards and that I am not hacking together a future nightmare. I also need to make sure that someone is not trying to play hot potato with the added support and maintenance costs down the road because they cut some corner today.
If you know who Chef Gordon Ramsay is, then the idea of having someone maintain standards might sound familiar. One of my favorite television shows is Hell’s Kitchen. It is one of the only reality shows that I watch regularly, but I enjoy it on many levels. (It even inspired me to learn how to cook a risotto recently because it is one of the dishes I watched the contestants mess up.) Chef Ramsay is relentless with upholding standards. He would rather have the kitchen recook a dish and send it late rather than send anything out that is less than perfect. He constantly stresses standards and doing things right. I do not think of myself so much as a gatekeeper for a SharePoint environment; I prefer to think of myself more akin to an expeditor in Chef Ramsay’s kitchen: someone with an eye for detail and a drive to uphold standards.
Just as not every chef holds the same standards as Chef Ramsay, your standards will be unique to you as well. I looked at some of the ways you can set performance standards for the servers in your SharePoint environment back in Chapter 6. Setting standards for the core infrastructure is part of the puzzle. However, at some point you may need to go beyond out-of-the-box functionality for all sorts of reasons, such as to add business value to a process, to meet additional user needs, or even to integrate with another system to reduce data redundancy. In those cases, you should maintain your high standards and expand them to include checks that relate to customizations.
The effort to uphold standards pays itself off with a healthy SharePoint environment and a stable SharePoint service for your internal customers. It creates a habit of excellence, which takes your ongoing efforts to stay disciplined; otherwise, it would just be a habit of average. Whenever you find yourself wondering how incessant you need to be with your standards, just watch an episode with Chef Ramsay and note how many things he lets slide in his quest for excellence. This often helps me put my own discipline to maintain standards into perspective, particularly when it comes to the checkpoints in my release process.
Note I look at how to formalize a release process in Chapter 16, where I also work through how to build a code promotion process to facilitate an ordered and disciplined deployment.
Earlier in this chapter, I mentioned the two areas for sponsorship: funding and ownership. I have predominately focused on sponsors who will take on the ownership for a customization. However, what happens for those internal customers who do not want to outsource the development of a customization and who are unable to do the development themselves? Does your team prefer to manage any vendors and take on the ownership for any outsourced customizations? Perhaps your team offers development services to internal customers. In these cases, you or your team will take on the ownership aspect of sponsorship, while your internal customer takes on the funding aspect. In the next section, I discuss considerations for managing sponsorship for short-term customization and development funding.
Charging Customization and Development Funding
If you operate a SharePoint service and your team has the skills and availability to offer development services, perhaps you will want to take on the ownership of any customizations in the environment. Typically, these would only entail the global customizations, unless you have enough resources to provide such a hands-on service to individual sites. Even in this case where your team takes on the ownership of customizations, you will still need a sponsor to fund any development efforts.
Some teams may not operate with a chargeback funding model, and so this section may seem less relevant. Nonetheless, somewhere along the way, someone has to approve funds for a development project. If departments in your organization do not pay for each individual service that they consume and each project that they request, then they pay at the organization level. For example, finance may allocate a certain amount of budget for IT operations, and these funds come from the organization’s same general ledger account that each department contributes to or operates under. A Chief Information Officer (CIO) can then allocate that budget across projects within his or her department.
This top-down approach to funding projects can help to ensure IT delivers on a global view of the organization and its needs, rather than simply favoring departments with the most funding. With this funding approach, an IT department can operate strategically by balancing different departmental needs and long-term goals. In these cases, the sponsor directly funding a development project may be the CIO, who is also the sponsor who will own the ultimate support and maintenance accountability for the customization. Even still, I would prefer to include the CIO as a stakeholder in the project and find someone else from the business to be the sponsor.
It is easier to identify a project sponsor from the business when there is someone who owns the budget and funds the projects, otherwise it may require some discussions and negotiations to identify a sponsor when the funds come from a general organization-wide pot. Nevertheless, a sponsor from the business will help to keep a focus on contributing value to the business rather than on IT efficiencies, and so I find it worth having one regardless of where the funding comes from. This approach will also give you someone to signoff on the delivery, which is important because it will give you a way to track whether you are delivering the right solution or you are simply managing scope and checking off work items in a list.
You might not provide internal development services or you might not always have the available capacity to take on development requests. However, you might still want to take on the ownership of any development activity by managing the vendor and their delivery rather than have each department engage their own SharePoint consulting firm. Even if your team is not doing the development, you probably still possess a certain level of expertise on the product – or at least probably more so than a typical internal customer from the business does. This can put you in a position to guide the process and enforce standards with the vendor throughout the entire project.
Another benefit of taking on the ownership of a project delivery even when you are outsourcing to an outside vendor is that you build relationships with a group of regular vendors. These SharePoint consulting firms get to know your standards and expectations, which helps them to plan their project delivery process. They can also work closer with you and your team to understand the wider organization goals and direction with your SharePoint service, rather than having them operate and design a solution within a single silo view of the organization based on the needs of a single group or department.
Ultimately, taking ownership of customizations can give you the control to promote and enforce standards throughout the entire development process. You can manage accountability for the support and maintenance of the customization while your internal customer can sponsor the funding to ensure that what your team develops aligns with their needs. Whether you are set up for chargebacks to change a group directly or your funding comes from a general organization pot, I find it is useful to identify a sponsor and discuss the project in terms of cost. This helps the team and the customer think in terms of the project as a cost to the organization, which helps guide any cost-benefit discussions that may come up.
As you are calculating your costs for a customization, I recommend you also factor in future costs that a customization will involve. This will help you understand your true costs. Will a customization require extensive training for the operations team or for end-users? Will your team have to absorb bug-fixing costs or upgrade costs? You should consider these costs ahead of time and factor them into the cost of deployment. These costs can be true whether you are developing a solution in-house, outsourcing development to a vendor, or are purchasing a third-party product.
FACTORING TOMORROW’S SUPPORT COSTS TODAY
Whether or not you provide development services, you will still need to factor future support and maintenance costs as you determine the cost of customizations. This is true even if you defer billing for any support or maintenance cost until the actual expense occurs. This approach may work well if you have a reliable internal customer for whom you are confident that they will pay any of these costs when they come up. Alternatively, you may charge for any of these anticipated costs upfront to ensure a type of insurance and avoid any need to chase down support funding later.
I can find an example of this type of upfront charging within the mining industry. Some local governments may allow a mining company to set up operations to mine minerals or other resources from a local site, but the government may also worry about whether the mining company will live up to its obligations to clean up the mining site and offset any environmental impacts from their operations. The worry is that a mining company can set up a temporary corporation to absorb all of the parent company’s liabilities, and then they will simply bankrupt the temporary corporation and abandon any of their responsibilities.
To prevent this, a government can charge the site environmental cleanup and restoration costs upfront. This security deposit can ensure that the funds are committed and that the mining company will not leave the local taxpayers with the burden to regenerate the land and reverse any impacts from the operation. A security deposit can hold a mining company accountable upfront before any operations begin, and then it passes on the ownership of that accountability to the government who holds the deposit.
In a similar fashion, you and your team can take ownership of the accountability for future support and maintenance. You might apply this idea of collecting a security deposit in a number of ways. For example, you can charge funding to pre-purchase vendor support and maintenance hours. Alternatively, you might charge a recurring maintenance chargeback as part of a service-level agreement, such as those I mentioned back in Chapter 2.
Considerations for Global Customizations
The idea of making a global change usually gets my attention right away. It is similar to when you are lying in bed, about to drift off into a nice sleep. The surroundings are fading away and you can feel yourself approach dreamland. Then all of a sudden, you jolt up remembering that you forgot to purchase the tickets for your holiday – tickets that are only on sale tonight! That is the kind of attention-grabbing jolt a request to deploy a customization with a global change to a SharePoint farm that I am managing.
Global customizations are probably inevitable in a busy farm where you want to tailor it to meet user needs and provide value to their processes. They are good things because they can help standardize processes and they can help multiple groups leverage the same investment. Global customizations add efficiencies to a SharePoint farm. They do not grab my attention because of anything bad; they grab my attention because they warrant attention and they can require special care and planning. The wider the scope of a change, the greater the number of users a change will typically affect. The greater the number of users affected, the more planning and attention a change requires; otherwise you are looking at a recipe for an overwhelming flood of user support calls and complaints.
First and foremost, you need to assess the compatibility of a customization. If you have a wide deployment and your user sites have an array of customizations already, this can be a significant task. This is the first step in your release management process, but it can also be the most critical. Before I can deploy a global change, I need to be confident that it will not break existing functionality that sites depend on.
Note Please see Chapter 16 where I discuss release management in more detail.
One example of a breaking change would be a delegate control that overrides any existing delegate control that shares the same delegate placeholder. What if the placeholder only accepts a single delegate control (a web control you can add to a placeholder by deploying and activating a SharePoint feature)? It sounds as if it is a simple example, but when you have different teams developing solutions independent of each other, it is not far fetched. Long before you get to the deployment phase, you can coordinate these development teams and influence their approach to maximize compatibility.
Along with compatibility, a global customization needs to be scalable. If you deploy something globally, it needs to be able to scale to handle a potential load of the global user base. In order to scale, it has to properly and efficiently manage resources such as sessions, caching, site objects, and database connections. Basically, I need to ensure a global customization does not consume significantly more server resources within the SharePoint farm as the user load increases.
After compatibility and scalability, my next biggest concern is usually how reusable a team designs a global solution to be. If they are developing something that I have to deploy globally because of how they have to develop it, then it has to be at least somewhat usable for everyone. Not everyone will use every feature, so I would not expect every global customization to be so generic that it can appeal to everyone. Instead, I just want the team to design it to be generic enough that multiple groups can find a use for it.
On top of all of that, you need someone to sponsor the change. Your sponsor will need enough authority to sponsor a global customization that can potentially affect everyone. If you do not establish a sponsor who holds enough authority and has funding to fix any bugs, then you are potentially putting your team at risk for having to take ownership of these issues. As users adopt the new features, they will grow to depend on them. If things only go wrong under load, then that means issues will only develop once you have a critical mass of users adopting and depending on the customization – a critical mass of users who will contact you and your team if any problems arise.
Hence, this is why requests to deploy global customizations get my attention. There are a few crucial aspects to consider and plan for to ensure that such a change goes smoothly. Mostly, I just want to make sure it does not create some ripple effect that has me chasing problems – I do not want to introduce weird dependencies or to create a fragile environment that can crumble and fall apart at any moment. Sadly, I never have the luxury of having excess capacity on my team to risk anything like this. As a result, I handle global customizations with care.
They add some extra due diligence to my process, but the end result is that global customizations provide a sweeping opportunity to deliver value to all my users. One group has a need and develops a solution to meet their needs, and now every site can take advantage of that group’s investment. This creates a Dr. Jekyll and Mr. Hyde situation for me: I want every customization generalized enough so that I can make it available and useful enough for everyone, but I also want to minimize any risks associated with a global change that will affect a large user base.
Not every global customization has to be a global change that can instantly affect everyone. You can make a global customization available to everyone yet not automatically affect everyone. This approach can help reduce the risk of deploying a global customization. You can make a global customization available to everyone in a disabled state by deploying it using the SharePoint feature infrastructure. By default, you can have the feature deactivated, and then whenever a site administrator wants to utilize your customization, they can activate the necessary feature. Alternatively, in SharePoint 2013 you can deploy the global customization as a SharePoint App and make it available in the SharePoint App Catalog, which I look at next.
Utilizing the Apps for SharePoint Catalog
One approach to organize global customizations with the customization owners who will manage and support them is to deploy them in the Apps for SharePoint Catalog. Developers can develop Apps that contain functionality for an application, functionality that runs on another server outside your SharePoint farm. Their Apps also provide functionality to any site owner who wants to add the App to their site, and they can discover it by browsing the App catalog.
Your team’s role can then become something of an internal marketplace provider, as you manage the catalog and provide the platform for the Apps. You can require that any Apps to first have a support policy and an owner before you add it to the catalog. Similar to any other customization, you can require this sponsorship so that when your users adopt any Apps, you can be reasonably confident that the users can find a support structure and a point of contact for different Apps.
You can set up a SharePoint site to host and manage your internal App Catalog. In addition, you can share the same App Catalog across farms, which allows you to centralize the hosting and management on your main enterprise farm while other subordinate farms can consume the catalog and the Apps it lists. Figure 12-2 provides a screenshot of the Manage App Catalog page located in SharePoint Central Administration. You can navigate to this page by clicking the Apps link in the left navigation area, and then clicking the Manage App Catalog option. From this page, you can crate a new App Catalog site or enter the URL for an existing one.
Figure 12-2. A screenshot of the Manage App Catalog page in SharePoint Central Administration
Once you configure the catalog and enable Apps, site administrators and page designers can then add the additional Apps to their site. Figure 12-3 provides a screenshot of the Your Apps page, where end-users can select the available Apps that they want to add to their site. From here, they can add internally published Apps as well as those that come with SharePoint. In addition, notice the SharePoint Store link in the left navigation area where site administrators can go to purchase additional Apps available from vendors who publish their Apps in the Microsoft marketplace.
Figure 12-3. A screenshot of the Your Apps page available in a SharePoint site
Enabling the SharePoint Store and allowing site owners to purchase their own Apps directly will provide you with an effective way to allow users to procure the functionality they need without having to request a global change on the SharePoint environment. As such, Apps can provide an alternative to global customizations, whether you purchase Apps from the Microsoft marketplace or you make Apps available in your internal catalog, or both.
You may not want your users to purchase Apps directly for a variety of reasons, but I imagine the most common reason will be to mitigate risks for any potential support and training issues. Another reason might be to centralize the purchasing and procurement of Apps through a formal IT process. Instead of allowing direct purchases from site administrators, you can configure Apps in your SharePoint farm to receive requests. Your internal Apps catalog will capture user requests for different Apps, allowing you to process and make the App available if you want to allow them on your SharePoint farm.
Apps provide a nice alternative to traditional server customizations, and especially for minimizing the number of global customizations where possible. They can also provide a venue to provide customizations from an internal development team to the organization. You can use the Microsoft marketplace to help remove some of the bottlenecks on a SharePoint team by purchasing Apps that meet one of your needs from SharePoint vendors through the SharePoint Store.
Ultimately, Apps offer a platform with a nice fusion of all the customization approaches I discussed in this chapter, and you can maintain supportability by requiring an owner to sponsor each App before you add it to catalog. You can also delegate App decisions to site administrators. Whether you are simply delegating the decision to add an available App to their site or you are empowering them to purchase the Apps they need directly from the Microsoft marketplace, you can decide how much freedom you want to grant and how much you want to involve your team in the process.
Apps are not the only aspect of SharePoint that you can delegate to site administrators, but they do provide one powerful option for putting site administrators in charge of their own destiny. However, delegating ownership of site operations to site administrators comes with some special considerations – most notably, you have to consider whether your users can handle the accountability that comes with sponsoring their own sites. In the next section, I share considerations for assessing the types of ownership your users are prepared to take on, as well as some approaches to identify potential sponsors for a site.
Delegating Ownership to Site Administrators
One of the reasons that SharePoint is so successful is its ability to distribute and delegate administration. It removes the burden (and bottleneck) of IT to respond to every little user request. You can delegate a significant amount of ownership to site administrators to control their own destiny. Of course, as in the Marvel Spiderman comic where Peter Parker’s Uncle Ben quotes Voltaire, “with great power comes great responsibility,” your site administrators might not be ready for that responsibility or even interested in it. Nonetheless, it does provide a wonderful option to simply allow your site administrators to make their own choices and live with any consequences.
Note In Chapter 13, I look at strategies and approaches to enabling end-users with functionality to customize site features and user experiences. Throughout that chapter, I provide more of a discussion on the tradeoffs and considerations for how much you delegate to your end-users.
Some tasks are excellent candidates to empower users with, especially if the product team has simplified the user experience in SharePoint for working through that task. Quickly changing the look and feel of a site is one example of a regular business user-friendly process in SharePoint 2013. Figure 12-4 provides a screenshot of the “Change the look” page in a SharePoint site, where a site administrator can click the sample that they like, and then easily update the look of their site without knowing HTML and without possessing any web design skills.
Figure 12-4. A screenshot of the Change the look page for a SharePoint site
It is easier said in theory than actually carried out in practice, but one option I have used in the past was a support policy where I would reset the site to the site definition and deactivate any custom features if a site had any support issues. You might consider a policy such as this if you have a community of users who want to be in charge of managing their own customizations and fulfill their own business requirements. If they mess things up badly and cannot seem to back out of whatever issue that they created, then you can hit the reset button for them. However, you do not want to be the one to make this decision and you certainly do not want to be the one who has to break the news to each site user. Instead, you will want a site sponsor who will own the decision and any user fallout.
A good site sponsor candidate might be the site collection administrator. They basically own the site and control its destiny (and they can also hold enough privilege to hit the reset button themselves without any IT involvement). The trouble is that there can be more than one site collection administrator, so this complicates the process in determining who the site sponsor is. Another complicating factor I have found is the site collection administrator can often be the sponsor’s executive assistant rather than the sponsor themselves. For example, the sponsor might be a director or some other department head who holds ultimate authority and accountability for a site, but they do not get involved with the actual administration of it – they delegate this to their assistant or someone else on the team.
Therefore, part of your planning and preparing for delegating to site owners will require that you capture who the site sponsor is. Perhaps you can customize the self-service site creation form to collect this information as users provision the site in the first place, if you allow your users to self-provision. Alternatively, if you use a site request form or if you require users to submit a ticket to the service desk to request a new site, then you can require the requestor identify a site sponsor as part of the request. I would probably create this process as a workflow that first validates the site sponsor holds enough authority to be a sponsor (such as requiring a director level or above to sponsor a site), and then request their approval to sponsor the site.
With an identified sponsor and support policy in place, you will be set up well to delegate many of the decisions and implementation details to your internal customers. I am of two minds on this approach: on the one side, you are getting out of their way to enable them to implement their priorities as they see fit; but on the other side, their expertise may not be in technology and so they may not know how to map the right technology to their business needs. They probably are not IT professionals and therefore do not have the expertise to make decisions as they relate to information technology.
Things you may find simple within IT may not seem so obvious to a regular user, and so they may struggle with decisions on what to do with their site. For example, many technical people in IT are familiar with the concept of account permissions and security groups, but for a regular user, their experience with managing permissions may be fairly basic or non-existent. These users may have an even more difficult time making sense of how to manage User Solutions and their site resource quota, as shown in Figure 12-5. This knowledge and experience gap can be problematic when you delegate ownership of these types of things to a regular business user.
Figure 12-5. A screenshot of the site User Solutions page and its resource quota
You might fill some of these gaps by offering end-user training where they can learn about the different features available in their SharePoint site, as well as how to effectively use them. Within the training material, you can include guidance on when to use a particular feature and how it aligns with a business need. This type of direction can help your site users to make an informed decision on which core features they will need in their site to function in a way that will support their processes and needs. It will also help to make them aware of the different ways to use the tool as the training resources steers them toward different use cases.
Note Please see Chapter 5 for more guidance on planning and designing end-user training resources.
Alternatively, you might offer support services for your users to help them work through specific functional tasks. You can empower your more technologically adept users to go ahead and customize parts of their site to suit their needs. For your other internal customers, you can do the site setup for them. When the site sponsor or their delegate has a particular need, they can submit a service request and someone on the SharePoint team can configure what they need. For example, they may submit a ticket to add new users to a site or to help them create a new document library. What end-user services your team offers depends on your users’ level of confidence and experience using the technology. Of course, what services you offer will also depend on resource availability on your team to fulfill these requests.
Ideally, I recommend that you try to find a hybrid of all the options and seek the right balance between enabling your users and supporting them. The world really is not so black and white, as there are many shades of gray and different hues of colors in between. I find choices and tradeoffs are never so binary with a single correct answer. Similarly, I do not have an easy formula that you can use to calculate what the balance should be for your internal customers. Instead, I suggest that you experiment with different mixes of empowering your users until you find an effective tolerance.
I discuss this idea of how to effectively empower end-users and their sites in more depth in Chapter 13, where I look at the range of tradeoffs and options available for you to set at the end-user site level. Part of finding this tolerance and making this decision involves input from your internal customers. When you identify a site sponsor, you also name a point of contact who can provide input into this decision. Or better yet, a site sponsor can own the decision with you serving as their advisor.
Consultant Comrade
When I get involved as a consultant to advise a client on sponsorship, I try to help them focus on the concepts of a sponsor who funds a project and one who will hold accountability for the decisions and work that will come out of a project. From there, I walk them through the idea of a transition period and the potential of handing off sponsorship to another owner for ongoing operations. By clarifying the idea of sponsorship, you can focus on who the sponsor or sponsors are, and then you can work on getting their commitment. Otherwise, this exercise can quickly grow problematic and disrupt or stall the project.
As a consultant, I try my best to remove any dependencies that block or stall a project from moving forward. I do this because I am engaged with a mandate to deliver consulting services for a piece of work that I agreed to in a work order or a statement of work. As such, I need the project to move forward to meet my deliverables, and one area I occasionally need to work around is the notion of identifying an executive sponsor when no executives are available or interested. From my sense, this vague idea of sponsorship requirements seems to stem from a misguided notion that you need to establish an executive sponsor before a project can go well.
Indeed, a sponsor will help a project go well, and you should have your clients identify one on every project. However, the sponsor you require does not necessarily need to be an executive. That might be overkill for what the project needs. Instead, you should guide your client to consider what you need from a sponsor and what role they will play in the project. By working through and answering the following questions with your client, you can help your client understand what they need in a sponsor.
- What is the relative scope of the project in relation to the organization?
- How much resistance or political opposition to the project is there?
- Who funds and approves the budget for the project?
- What level of authority does the project need to resolve any roadblocks?
- How much risk and organizational change will the project entail?
- What degree of sponsorship involvement does the project require?
Without understanding what you need from a sponsor, you will have a hard time articulating the commitment you need. Quite frankly, sponsors do not usually like to take on the accountability for open-ended and ambiguous commitments. For me imagining myself as a potential sponsor, this would be a non-starter, because the ambiguity would mean that neither of us would be set up for success. After putting myself in the potential sponsor’s shoes, I can see that I need to clarify the role of the sponsor first, and then use this information to identify the appropriate level on the organization chart I need a sponsor from rather than simply defaulting to the executive level.
I also prefer to explore and define sponsorship with my clients to steer them away from any preconceived notions of sponsorship. One in particular that I try to help them avoid is a generic notion of an executive sponsor. Executives do not usually have time to sponsor every little initiative – and probably even less time for those ambiguous requests for sponsorship. This can affect a project if the team ends up in a holding pattern waiting for the elusive executive sponsor before they feel they can move forward. Worse still would be the team that pushes ahead without any sponsorship – essentially delivering a project without any authority or accountability.
I am downplaying the need for executive sponsors on purpose only because you will not always need one at that level. However, I am not downplaying the need for sponsors in general. Ownership on a project team and in operations is a critical role because it defines the authority and accountability structure. Without it, you risk finding yourself stuck in situations of indecisions or the wrong decisions. At its extreme, a lack of ownership risks developing a culture where team members neglect responsibilities by passing the buck or shifting the blame. The buck has to stop with someone if the project is to have any chance, and I identify who the sponsor is on day one of the project before I conclude the kick-off meeting and move forward with the project.
Another reason I work with my clients at the very beginning of a project to help them identify a sponsor is to establish an escalation point. In my experience, it is always easier to identify who the escalation point will be and to get their commitment to hold that role before something goes wrong. When things are on fire and a project is falling apart, people avoid it as if it were a sneezing passenger on a public transit bus during the swine flu outbreak. I always want to plan for these worse cases, and then put the right pieces in place so that I have what I need to work through any issues as they arise, all planned for and decided before issues arise.
In short, although I might not require an executive sponsor, I do require a sponsor – someone who holds enough authority to take on the ownership and accountability of the project or the ongoing operations. I have found that a team can quickly become dysfunctional without a sponsor in place. Even if they are not active on the project or daily operations, they hold the accountably and are available to get involved if I need to escalate any issues to them. As such, I find that identifying the sponsor or at least the acting sponsor is a good checkpoint before a consulting project can move forward.
Inside Story: Notes from the Field
Several years ago, I was engaged on a project with a client to deploy a SharePoint farm. They wanted help to install and configure the infrastructure to setup a basic team site environment to enable online document collaboration. This project comes to mind as I discuss sponsorship because I had a great project sponsor from my client who knew how to move things forward and unblock any roadblocks. He was their chief architect and formerly their CIO. Although he was not an active member on the project team, he was always available to immediately resolve any escalations I raised.
At the start of the project, he stressed how important it was to move the project forward and deliver a victory for the IT department. He then made a joke about how whenever a roadblock came up, I should let him know and he would provide me with a tank to smash through it. What a sponsor! This sponsorship approach and support was effective for my project for three main reasons:
- He held enough authority to influence and move things forward
- He knew how to navigate their internal politics and bureaucracy
- He was committed to the project’s successful delivery
I took him up on his offer and stuck with the tank metaphor. Whenever things seemed to lose momentum, he would ask how the project was going and I would tell him that I needed the tank. He would then reply, “The keys are right here,” and then he would ask what I needed. True to form, he quickly smashed any roadblock and continued to move the project forward. He meant it when he offered his commitment to remove anything that stood in the project’s delivery path.
It did not matter what came up; if I escalated an issue to him, he would either resolve it directly or send the support I needed to work through the issue. He never once came to a status meeting, and instead he preferred to receive a synopsis of the project’s status in a couple of words informally as we passed in the hall. If things were going well, then he left it to us; and if things were struggling then I just had to mention what was causing grief. There were no long discussions and almost no meetings, yet I could depend on him to be responsive and to get results – sometimes immediately, and sometimes within a day or two. Roadblocks would simply disappear without a word or warning, and things would start moving along again.
This experience, naturally, left me with a taste of what effective sponsorship can be like and what it can add to a project’s delivery. I had to reflect and wonder how I could establish similar sponsorship on every project, with every client. Sadly, other clients’ sense of ownership and overall commitment to a successful delivery are things that are beyond my control and influence. I can suggest and describe the kind of sponsorship that I found to be the most effective, but if they do not buy in to the vision or they simply just do not possess a tank, then this type of power sponsorship will be unavailable.
Nevertheless, when I describe this sponsor and the tank metaphor, clients seem to understand what I need and the impact a strong sponsor can have on the project. I may not be able to smash through any roadblocks, but I will ideally identify a sponsor who can help navigate any political or bureaucratic situations. This can work very well and help to ensure the project can work through any issues that arise. Besides, sometimes just blasting through any objections or obstructions will be less effective than negotiating and soliciting buy-in on the approach. Although the styles differ, the sponsorship outcome of mitigating or resolving issues is the same. This outcome is what matters the most.
You might be wondering what I do if I find myself on a project where my client has not identified a sponsor or they have an inappropriate one filling in the role. As I mentioned earlier, I try to address this during the project kick-off meeting, or better yet, during the project scope and work order planning session. Sponsorship is something I require to deliver the right aspects of the project. Without it, I have no one to check-in with regularly and get sign-off on my progress, or at least no one who I will feel confident as having the necessary authority that I can depend on. Once I describe the risk and talk through what I need in place, I can usually get the right sponsor to commit to sponsoring the project.
Some months later, I found myself back engaged with the original client who started the tank metaphor for sponsorship. I was kicking off another project with a different group, but I still had access to the tank if I needed it. Before I even kicked-off the project, I had confidence that I could deliver and be successful. Having such strong and committed sponsorship is a treat and it can generate confidence for the entire team, which helps to build momentum and move a project forward.
Wrapping Up
In this chapter, 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.
Not all customizations will involve the SharePoint service team. End-users may customize their site and maintain their customizations on their own. SharePoint provides capabilities that you can enable to allow end-users to build their own solutions without affecting other sites and users that the SharePoint service supports. In the next chapter, I discuss how to facilitate these end-user customizations in a safe and isolated manner so they do not negatively affect the performance of the overall service.