10 Steps for Building a Governance Strategy

Having worked with SharePoint in some capacity for more than 15 years, and Microsoft Teams for 3+ years, it is interesting to look back at my body of work and the articles I’ve written and see the patterns. As with many of my peers, many of my articles and presentations are based on customer questions — and, let’s be honest, gaps in documentation. One of the most common areas for questions has been governance, and one question that I hear quite often is: How do you begin?

As with most user-driven technologies, SharePoint and Teams are often unleashed without proper planning or governance structures, and most administrators find themselves needing to retroactively apply standards across their environment. Companies tend to hoard information and may find themselves overwhelmed by the disorganization and how to even begin the process to get things under control. But the justification for sound governance practices is less about structured provisioning and orderly operations as it is about proper classification and management of content, conversations, and metadata. Spend any time working with knowledge management and collaboration platforms, and you quickly understand that without proper management, search becomes ineffective, content become silos hidden behind team sites (or even within team sites), and user satisfaction plummets.

Unfortunately, there is no easy button to fix this problem, and it’s not a problem unique to the Microsoft ecosystem. I remember writing similar guidance for our team intranet portal in the mid-1990’s, for our project and portfolio management solutions a few years later, and for the product lifecycle management (PLM) deployments I did in the early 2000’s. Even the most proactive organizations struggle from time to time with managing their system governance.

If you’re reading this, you more than likely are looking for help in strengthening this aspect of your current collaboration system, or are planning for a future deployment. In either case, there are some things you can implement to jumpstart your efforts as you look to put in place a more formal governance model:

1. Get started. As the old adage goes, “The best time to start was yesterday. The next best time is now.” Few projects begin with a green field, so don’t sit and wait for “the right time” and simply decide to get started. Draw a line in the sand. Gather with a quorum of stakeholders and start building your plan.
2. Have a plan. That’s right – a plan! Listen to the experts, comb through the relevant articles, consider those best practices, and develop a plan based on your organizational and project needs. Help your management team and end users to understand the full scope of the project – that it’s not just about a technical implementation, but that it is also a business process change.
3. Create an internal user group. Even if your plan is to release a tightly-controlled portal with strict guidelines around content types, workflow, and usage, you still need to involve the users and get their perspective. The power of SharePoint and Microsoft teams are their ability to inspire collaboration, even within a meticulously choreographed user experience. You need to tap into the community as a way to refine your model, adapt your systems to the ebb and flow of the business, and, quite simply, to learn from your users.  I suggest creating both a task force with accountability for compiling and approving your taxonomy and the governance model itself, and then to send an open-invite to all employees to participate in a broader user group. As part of your process, have the task force present their results to the user group before finalizing their plans. By allowing users to participate in and define the process, the users will have a vested interest in the success of the system.
4. Clearly define roles and responsibilities. Governance Task Force chair and members. Team and Channel Administrators. Project Owners. Approvers. Reviewers. Identifying core permissions and groups is one aspect, but modeling your governance model on your internal project methodology makes sense. If you don’t have a defined methodology, remember to keep it simple. Err on the side of ad hoc flexibility over rigid structure, as it is easier to add structure as needed than to remove it. While at Microsoft, I was a fan of the OARP model: Owner, Approver, Reviewer, Participant. It was simple and clear (when it was used). At the very least, you should understand and assign similar roles within your organization so that it is evident where accountability resides.
5. Understand any regulatory or compliance concerns. Are there any rules or procedures having to do with legal or financial guidelines that may dictate how you setup and/or manage your environment? Do you need to maintain audit trails? Reporting? Workflows? Metrics? These items would fall into the scoping and sizing of your project during the planning phase.
6. Outline your information architecture and governance policies, communicate them, and iterate. This is the most difficult aspect of governance for most organizations: putting pen to paper and outlining the rules and constraints of your system. Most organizations already have corporate and IT governance standards in place, or have a collection of industry or regulatory requirements that will define the constraints of your governance strategy. Sit down with your governance task force with a fixed amount of time (an hour) and create a high-level draft. Then publish the draft out to the end-user community for feedback. The point here is to create something, get feedback, and iterate. Follow this process several times, keeping the time short so that you have minimal impact on day-to-day business. By taking it in small steps, it also allows you to step back and reflect after each iteration. You’ll be amazed at quickly things will then come together, and, with everyone participating, your strategy will more closely reflect the way your users work, and the way your business is actually run. But remember: this is just a start. Your governance task force should perform a regular review (monthly/quarterly) of your information architecture and governance policies, sharing proposed changes with the community and incorporating feedback.
7. Be aware of how your metadata, content types, and social components are to be managed. What is the actual process involved with managing these things? Who owns it? What is the change process? Are you going to try and maintain SLAs? This might be overkill for small businesses, but is critical for larger businesses. A major impact to end user adoption is a long turn-around time for system changes. Some of these activities are simplified within Office 365, but improved capabilities don’t necessarily decrease the need for governance.
8. Create a governance site or Team. Make your policies visible. When people ask questions, point them to an ever-expanding FAQ list. Update the site regularly. Make it functional, not just a one-time dumping ground for rarely used process documentation. And be sure to constantly refresh your governance site. This should not be a static site, but a working platform from which you manage your process, take suggestions, and change as needed.
9. Enlist your end users. This goes beyond my advice for creating a user group, and relates to all end users. Give them a voice in the process. Get regular feedback from your business units and content authors. To capture this data, use search metrics, discussion threads, and polls. Once again, capturing data at regular intervals should be part of your initial project planning, as this will also provide a mechanism for reporting back to management on the progress – and success – of your SharePoint deployment.
10. Learn and evolve. Nothing is set in stone. Portals and collaboration platforms evolve. You’ll rarely get it right on the first try, but you’ll lose time and productivity the longer you sit idle, so the key is to take action and iterate, iterate, iterate.

Hopefully this guidance is useful, and encourages you to take action. My advice is fairly simple: keep your governance model simple, let your processes grow and develop organically, and keep your end users in the loop. If they understand the governance model, they’ll use it. If you are transparent about the process, and can quickly respond to user requests and changing business needs because you’ve kept it simple, they’ll trust it. And if end users are using the platform and trusting the governance mechanisms you’ve put in place, your management team is more likely to view your overall efforts as a success.
Good luck!