Governance, Compliance, and Ongoing Operations Planning

One of the first formal project management training courses I attended back in the mid-1990s provided some planning guidance that has stuck with me throughout my entire career. At the time, I was working as a technical PM for a shared services team at Pacific Bell, a regional phone company headquartered in the San Francisco Bay Area. The class was part of a program to provide “refresher” training around requirements gathering and managing the software development lifecycle. I had been the primary PM for a massive data center restructuring project, and the guidance provided by the instructor struck a chord:

The level of governance and administrative overhead that is required depends on the gaps between requirements and platform capability.

A few years back, I participated in a webinar and co-created some content with former SharePoint MVP Nick Kellett (@NickKellett), who now serves as Founder and CEO of Deploy Software Solutions, based in Quebec, Canada.  Nick is a software architect and technologist with deep roots in product and project management, and after sharing some of our notes and ideas on governance best practices, we found that we shared a number of project planning best practices, including strikingly similar planning methodologies that we outlined in a 4-step process:

The idea is simple enough: on one hand you have your business needs, which are your requirements or system constraints. Think about your reporting and compliance requirements, any legal or regulatory rules your systems must follow, and any other policies or procedures that need to be met. On the other hand, you have the technology service, or platform. At the time, we were discussing this in context to a SharePoint deployment, but it is equally relevant to any other enterprise platform.

As you begin to map your requirements to the platform, it is not likely that every requirement can be met. You will need to make some decisions, either modifying your requirements, or agreeing to move forward (or stop the project) due to these constraints. And if you do move forward with modified requirements, it is important to monitor and regularly improve operations management as system updates and service packs are released, or when (if) your requirements change, each of which could change the governance activities needed to manage SharePoint.

In our webinar (which was entitled ‘Governance Compliance and Monitoring in the Real World‘) Nick and I outlined some of the common pitfalls of SharePoint deployments, and the compliance concerns that are common across most environments, such as permissions and accessibility, privacy issues, regulatory guidelines (such as PIPEDA, HIPAA, SOX, and ITAR), auditing and e-Discovery requirements, and overall service quality of the platform. While individual scenarios may vary, there are common threads across almost all SharePoint deployments.

To help organizations understand the path to process and compliance maturity, Nick and I expanded on the model above:

1. Identify your compliance requirements. As with any technology deployment, you must first understand the business requirements of the system before you can develop solutions.  For highly regulated industries, your governance compliance requirements are defined by the governing entity. For less regulated organizations, your requirements may come from industry best practices or by reviewing internal and external case studies. The key is to develop a shared understanding between end users, functional management and the leadership team as to the requirements.
2. Map your requirements to platform functionality. Once defined, you can then identify which requirements can be met through out of the box functionality, and which may require customized monitoring and reporting, or possibly an appropriate 3rd party solution. Be mindful of keeping the identification of requirements and the mapping of requirements to platform functionality as two discrete activities. This should be true for any technology platform — if you look at your requirements through the lens of the platform limitations, you may not identify the appropriate solutions (from the business standpoint) . Define your requirements first, and then whether those requirements can be met with the platform.
3. Establish governance model and policies for these requirements. Your governance model is defined by the compliance requirements to be met, and the limitations of the platform. You may be able to automate some policies because of robust platform functionality, while others may be very manual due to functional limitations. Governance is about helping you achieve your business goals, and ensuring that all roles and responsibilities are clearly defined to meet those goals.
4. Determine compliance monitoring approach and tools. There are four key governance compliance scenarios for SharePoint that may require separate monitoring approaches and tools, based on the maturity level of the organization’s IT processes. These include content analytics, permissions management, auditing, and storage management. These areas may exist in other enterprise platforms — or there may be totally unique scenarios. Leverage the community for feedback on compliance areas on which you should focus.
5. Monitor (and automate!). Once your governance model has been defined and deployed, the next, and ongoing, step is to monitor your environment, and to constantly look for ways to automate and improve on what you’ve built.

As I tell audiences almost every time I present on the topics of governance and administration, massive enterprise platforms like SharePoint are not static — you cannot deploy once and walk away. Anything that large and powerful tends to be a living, breathing platform with evolving business and end user requirements, and as such requires constant compliance and performance tuning. A mature governance and compliance strategy will help you both maintain and grow with the technology.