A Tale of Two Governances - Part 1 Health Benchmark

When you read about governance, it is often focused on what I call the foundational governance.  In the case of information technology (see my definition) we focus on foundational information governance, or the way we intend to use our information within the organization.  This however is only one of two parts of the actual governance needed for the management of our information. The second portion which is often not considered as governance, encompasses the processes and procedures needed to maintain the systems that are used to manage and transmit information.  I refer to this governance as operational governance and it consists of the structure, policies and procedures to ensure a stable and consistent information management solution.

Operational Governance

The governance of the sustainment processes within an organization are typically hit and miss.  Most organizations will have some type of backup and recovery process, but how many have a process for the creation of sites in an ECM like SharePoint?  Now don't get me wrong, some organizations are very dutiful in creating what they perceive as needed for processes to maintain and administrate their systems, the problem is that many do not, and those that do, don't necessarily get everything they need. As a consultant I come into organizations that are experiencing pain, usually in the governance of their solutions, my job is to determine the gaps and remediate them.  Now one of the best ways to evaluate gaps in the operational governance of a solution (regardless of the technology) is to interview the administrators and key business users, perform a health assessment of the system and make recommendations on best practice based on the gaps; in some cases we would then move to remediate those gaps as a final step.  These steps serve to quickly identify what exists and what does not exist and helps me understand the technical skills of the administrative team.

In this first part we will walk through finding our current state, then in a future post we will look at the rest of the operational governance that should be considered to ensure a properly sustained environment.

The Interviews

The first steps in the process are the interviews, in a SharePoint solution I like to site down with the farm administrators, the site collection administrators and the service desk manager.  These three groups or persons can provide insight into pain and into items that take up a significant portion of their daily activity, here are a few questions I will typically ask and why I ask them.  It is also important that you are clear with them about your purpose, as a consultant coming in they may perceive you as critiquing them on their job, but we are there to help them be heard and to fix their pain.

In other solutions, you may have different roles, as long as you can extract the pain and issues for the solution, your interviews can be with whoever can best provide the answers.

Farm Administrators

Farm administrators are your best source of information when it comes to issues with operational governance.  They know the solution better than anyone else and have to deal with everything and anything that goes wrong.  Often it is easiest to just sit down over coffee and a notebook and ask them what is wrong with the solution and what they would fix, then sit back, let them vent and take notes; but I like to have a plan so I typically compile a list of questions to ask before hand (let me know if you have some good questions and I can add them).

1. Do you have anything that maps out your daily routine? This is asked to first establish the existence of a "Run Book" or standard operating procedures (SOP).
2. Do you have any tickets assigned to you that are more than 30 days old? If yes, what are those tickets and what is preventing you from closing them?  This will help identify not only gaps in knowledge, but also pain areas in architecture or process.  There is often an in depth conversation into cause and what they would like to see happen to help resolve these issues.
3. Are there any issues that keep recurring or that never really go away?  This provides insight into pain areas where they may have a work around or an area where they have decided to perform something a specific way and it is not working.  This is another area we will have additional conversations about how they think it should be.
4. Do you have any performance issues with the current farm?  if yes, do you know the cause? and have you researched a solution? performance issues identify issues with the farms architecture and/or configuration that may be hampering the solution and preventing it from performing as intended.  Also it helps gauge knowledge level and root cause problem solving capabilities.
5. Which group or groups are the most active on your farm? This will identify who to interview from a site collection administrator perspective, concentrating on the site collections that are the most active and the most need of support.
6. Do you have remote offices that access the farm?  how good is their connection? Do you get performance tickets from those offices? Often remote connectivity is an issue, identifying where these connections are occurring and if there are issues up front will save you time and effort.  Follow the premise that it is easier to ask the question than search for it, tools are great, but the farm administrator will have insight the tools can't provide.

Notice I didn't ask them questions like how many farms, the servers on the farm, the number of content databases and their size.  These can be asked, but typically you know those things before you begin the engagement and even if you don't, reports from SPRAP or any other health assessment tool will clearly give you all this information.  At my office we have developed our own health assessment tool to answer all the farm questions and to touch over 100 different areas in the farm.  I have included the areas in my post, What should I Check With a Health Assessment? and would love any feedback you have on the points and questions.  With your help I can make it the most complete health assessment list available.

Once we completed we can move on to the Site Collection Administrator questions.  Site Collection Administrators have less knowledge of the configuration, but provide a direct point of contact with your key stake holders.

Site Collection Administrators

Based on question 5 above, you should have an idea on which Site Collection Administrators are needed for this portion of the questions.  In smaller organizations, the Site Collection Administrators may be the Farm Administrators, you should be able to figure that out quickly when beginning the engagement.  The Site Collection are a SharePoint solutions first line of direct contact and problem solving in the business, they are the most likely to know what the users want changed and what issues are recurring the most from a User Experience perspective.

1. Do you have anything that maps out your daily routine? This serves a different purpose than with Farm Administrators, here you are looking for what is taking up most of their day.  If they don't have it mapped out, you should sit down with them and ask what a typical day would look like.  They may have trouble providing it, so another approach is to ask them to do some logging activities for a couple days, recording what they are working on.  You can then review it and confirm if the tasks are typical or not.
2. Do you have any requests from your business users you have not been able to fulfill?  If yes, what has prevented you from fulfilling them?  This will often identify issues with configuration, policy or knowledge level, use it as a sounding board to ensure the architecture meets the business needs.
3. Are there any issues that keep recurring or that never really go away?  This provides insight into pain areas where they may have a work around or an area where they have decided to perform something a specific way and it is not working.  This is another area we will have additional conversations about how they think it should be.
4. If you could change anything about the solution what would you change?  Site Collection Administrators often have good feedback on improvements specific to user experience and functionality, make note of the changes, then identify them as future state requests for remediation and road mapping.

Remember these are really meant to draw out the pain points and issues with the environment.  You may hear the same answer from many different people, that should raise the importance of the issue.  Some of the answers may be symptoms of a deeper problem, it will be your job to determine that before attempting to remediate it.

Service Desk Manager

The Service Desk Manager can provide you tangible numbers on where issues are occurring, open tickets and typical complaints that users have made about the system.  They are the support of what has been discussed with the farm and site collection administrators and will provide additional insight and numbers behind the importance of certain issues that have been identified.

1. Can you provide a report of ticket opened for SharePoint in the last 6 months?  This should provide ticket count, time to close and total percentage of tickets for each category.
2. What are the main complaints your team hears in regards to SharePoint?  The Service Desk is the first line for support, so they hear most of what the users like and dislike about the solution.
3. What would you change about SharePoint if you could?  This is an open ended question and should elicit conversation on improvements and pain that they feel from their environment.

Remember the questions above are a starting point, you want to draw out their pain experience.  In some cases it might be better to talk directly to the business units, but always remember these are about insight into issues about the environment.

Health Assessment

As mentioned above the Health Assessment portion is usually done through a tool that compiles all the information about the environment.  I analyzes your solution and provides feedback on all areas that need to be considered.  Please refer to What should I Check With a Health Assessment? for actual check points and complete it in whatever manner you wish.


Report and Remediation
From the interviews and health assessment a report of gaps and issues with the design can be created and presented to organizational decision makers.  From the report you will also be able to identify the criticality and with discussion, the priority of the issues involved.  Use this information to build a remediation plan, that includes the issue, it's criticality, priority solution to the issue and the effort needed to resolve the issue, then sit down with the decision makers and work out the remediation plan to resolve the issues.  The plan should provide a timeline for each resolution and the resource allocation needed to resolve it.


Next Part
In the next part of this series, we will look at other parts of your operational governance and what it takes to ensure your environment has the operational governance it needs.  Feel free to read my other posts and follow me on Twitter: @DavidRMcMillan and @DevfactoPortals.

ECM Governance - Post 3

Guiding Principles continued

Hi Everyone (or me, myself and I, not sure if anyone reads this...) sorry for the delay in this next post, I having been busy doing and not spending enough time writing about it.  In my post 2, we examined the idea of guiding principles and how they are used to set a foundation for our ECM.  We identified several categories or "Areas of Impact" that these principles could be separated into and this week I would like to start by detailing the intent of each of those categories.

General Principles

The general principles are principles that do not fall into any other category, they are usually the least specific (or most general) and often refer to governance rules and policies and how you intend to use them.  A good example of a general rule is the scope of the governance plan or how we intend to apply principles as a general rule.

For example, we want consistent governance across the entire solution and exceptions need to be recorded whenever a site or site collection does not follow the set of policies defined.  In that case, we can create a general principle to define that need:

Governance Scope
Principle
All governance principles, policies, standards and training are tied to the scope and intended purpose of the entire solution. Governance applies equally to all sites and all site areas.

Implication
While some policies will be enforced across the entire organization, others may be determined by each site owner. The Governance document is not intended to define the site specific policies, but is intended to provide the foundation for all sites. Deviation from the governance policies is by exception only and should be recorded and approved by the steering committee prior to implementation.

Security Principles

Security Principles deal with the need for security and how we plan on using security in our solution.  We address things like the security architecture, the use of roles, external access and permission management as security principles.  It is important that we keep security principles as general as possible, to allow for better granularity at the policy and configuration level of the solution to meet the organizations security needs.

As an example we can look at a principle that is common to any governance plan, the use of roles to manage permissions within the solution.  Again the principle is defined and then the implications to the way the solution will be used are outlined.

Role-based Security Model
Principle
Use of a Role-based security model will govern access control and permissions to the SharePoint Portal.

Implication
Users may have different permissions on different sites or areas of the site, which has an implication for both governance and training. This permission is based off the roles that are assigned at any given level. Direct permissions should not be used; if it is found that direct access is being provided, the roles should be reviewed to determine if a GAP exists in the role structure. If a GAP exists, a new role should be defined to prevent the future need for direct security permissions.

In my next post, I will go over the remaining principles Document Management Principles, Publishing Principles, Collaboration Principles, Business Process Principles and Esthetic Principles. Also if you want to learn more in person, I will be presenting on governance at the SharePoint Summit Vancouver 2013, October 28 & 29, I hope I see you there!

ECM Governance - Post 2

It has been a few days (and a weekend) since my last post, which for me is a lightening fast response.  In this weeks post, I would like to continue along the ECM governance work we started and delve to the core of what defines governance.

Guiding Principles

If you want to consider implementing governance of any type, you are going to need to define a foundation on which we can build our rules for how things will be governed.  As an example, our society is governed by legislation and laws, but in reality, legislation and laws sit on a morale foundation for their existence.  This morale base can be referred to as the principles of our society or the "Spirit of the law".  As society defines the morale base and politicians and law makers interpret the morale base to make the laws and legislation, so to does the business define the guiding principles for ECM.  The actual interpretation of the guiding principles into the making of rules will come later on when we talk about the job of the steering committee, but I think you already have an idea of their role.

In the case of ECM governance, the foundation needs to be clearly defined through what we refer to as guiding principles.  The guiding principles are general rules that help guide us toward the vision we defined in our previous weeks exercise.  With each Principle we have two parts, the definition and the implication.  The definition defines what the principle intends to set rules around, while the implication provides context and understanding of how the principle will affect business users.  If we look at an example (one that should exist in all governance plans), we can see how the principles provide a foundation for use.

All Content is Owned  

Principle
All content must have a clearly identified “owner.”
Implication
Users need to know who to contact if information is out of date or inaccurate. The owner is responsible for the content in a site and for ensuring it is up to date.

This is a simple principle, but the implications can be quite extensive in an organization.  As mentioned in this basic example, ownership implies accountability for content and all content must be owned.  Notice the principle is short and concise, while the implication should be as detailed as needed to ensure that it identifies all the areas affected by the principle.  Our example is currently not detailed in the implication, but that is because the implications are typically specific to each organization.

If we were to look at these principles they can be categorized into several areas of impact.  These areas are as follows:

• General Principles
• Security Principles
• Document Management Principles
• Publishing Principles
• Collaboration Principles
• Business Process Principles
• Esthetic Principles

Each of the above areas cover off the usage and capabilities of the ECM, but additionally help you guide and focus on rules that are important to an ECM.

In our next session, I will examine each of these principle areas and outline the types of principles that you would expect to see in an organization.  For all our future examples, I will use SharePoint as the ECM of choice, though these principles could be applied to any ECM.

ECM Governance - Post 1

Introduction

If you were ever looking for a main cause for the failure of SharePoint implementations, look no further than ECM Governance.  Over the next couple weeks I am going to share some insights I have experienced with governance of enterprise content and what organizations need to do to ensure the successful implementation and use of solutions like SharePoint and OpenText Content Server.

I am a solution architect who has been working in SharePoint and OpenText (and integrating the two) for many years.  I have seen many implementations fail and they all stem from the same cause, a lack of governance.  It isn't just that organizations fail to plan, though that is part of it; it really has to do with how the organization prepares for the changes that a new system brings.

There is nothing worse than building a system and just letting everyone do whatever they want with the system.  Not only does it breed anarchy, it guarantees a poor user experience and a failed result.  The failure to plan is why so many organizations have no governance in place; we need to think ahead and decide how we are going to steer people towards proper use of the solution, that steering or guiding of people is known as governance which makes sense when you consider the source of the word.

The word governance derives from the Greek verb κυβερνάω [kubernáo]which means to steer and was used for the first time in a metaphorical sense by Plato. It then passed on to Latin and then on to many languages. (Origin from http://en.wikipedia.org/wiki/Governance)

In a modern sense, governance is the act of governing.  It involves determining where the organization needs to be and the rules that need to be followed in order to get there.

The Hydra

Every organization has its own ideas and reasons for using a system and this driving force is where we need to start when we talk about governance.  This driving force is actually a multi-headed beast, hence the section title.  The reason it is a Hydra has to do with the organization itself, companies are setup in silos, based on function and there is no way around it.  Engineers will use a system differently from accounting and so on.  In order to figure out the direction the organization needs to take, you are going to need to involve every group that is going to use the system.

Once you have the reasoning behind each groups use of the system, you can begin finding a commonality to their use.  This commonality will define the "Vision" of your governance plan.  It is the core of how the organization will use the solution, while the uniqueness of each group will provide variances that will be used later on in the governance definition process.

If we were building a governance plan, we now would have two sections ready to fill in, the business cases, which summarize your finding from speaking with each group in the organization and the vision, which defines the direction we need to take the solution.

Next Week

Next week I will explore the idea of guiding principles and how we can make those principles a reality in your organization.