Last week, I posited that governance is a word best left unspoken (and undefined). I laid out one of several “frameworks” with which to approach governance without falling into the easy trap of narrowing governance down to simple administration (e.g., permissions) or change management (e.g. adoption).
This week, I’d like to share with you one approach I use with customers to get them moving through governance for a specific solution or workload that they want to deploy onto SharePoint.
This approach is one that proposes “questions of governance.”
The Questions of Governance are questions that need to be asked in order to touch as many of the “governance bases” as possible, so that you can hit a home run with a thoughtfully architected, well delivered, tightly managed solution.
The list below is admittedly a simple one because this is a short article about a big topic, and I’d love to hear from you about the questions you’ve found valuable to ask. Feel free to comment below the article, on facebook, or shoot me an email.
I’ll break the questions down into the broad strokes of governance I laid out last week.
MANAGE CHANGE
Innovate a solution to a business need (innovation)
First, define the problem you’re trying to solve (the “workload” or “scenario” or “solution”)
What are the desired business outcomes?
This is the most important question of all. Alternately phrased as, What are you trying to achieve? This should lead to a business-centric definition of the scenario or workload, with little or no discussion of technology.
Ideally, this question was asked well before the workload landed in the lap of SharePoint governance. Ideally, some layer of business governance exposed a need, and some layer of IT governance decided that it was best suited to SharePoint as opposed to some other technology service in the organization’s portfolio.
Why is it important?
This question elicits an understanding of the business value of the solution.
To whom is it important, and who will be impacted by the solution?
This question exposes the political realities of the solution—the players, their motivations and interests, and the dynamics between them.
How will we know it worked?
Be sure to define, even if broadly, ways that success can be measured: metrics.
Next, look at the information associated with the solution. The answers to these questions drive information architecture in the purest definition of the term:
What classes of information are involved?
Define information classes or categories. What types of content are you working with?
How do you describe [each class of information]?
This question starts driving towards information architecture elements including metadata (columns)
How will users find [each class of information]?
Answers will drive decisions about site map, taxonomy, and search optimization
What will [each metadata property of [each class of information]] contain, who will populate it, and how?
Further your understanding of taxonomy and column definitions.
Now we continue to information management considerations:
What are the relevant information management policies that apply to [each class of information]?
Your organization should define policies for managing information whether that information is on paper or electronic; and whether it’s in SharePoint, Exchange, a file server, or Dropbox. This is a “killer question” because most enterprises are not equipped to answer this question effectively. I’ll return to this question in more detail in a column in the near future.
What does the information lifecycle of [each class of information] look like?
Define the who, what, where, when, why and how of each stage of the information lifecycle: creation (capture), maintenance (store), deliver (present and secure), preserve, and remove (delete, archive)
How can the information architecture better support effective and efficient information management?
There’s a relationship between information management and information architecture. The relationship is tight enough that many products, consultants, articles, training resources, etc. lump them together as “information architecture.”
I’m a big believer that you should be very cognizant of the distinction between information architecture (describing information so that it is usable, findable and, yes, manageable) and information management (which defines security, record policies, and information lifecycle). There are often very different players with interest in and ownership of these two distinct disciplines, and they need to come together and to consensus.
And then, finally, to service management:
- What does the workload require for availability (uptime), data protection (integrity), and continuity (disaster recovery)?
- What is the expectation for performance (responsiveness)?
- What is the impact on storage, network infrastructure, and other components of the IT service portfolio?
With this laundry list of questions and the answers they generate, you’ll be ready to design and build the solution.
- What are the project constraints: Are they timeframe, money, people skills?
- Are their other constraints?
Deliver that solution into the service and the customer base (delivery)
Now, how will you deploy that solution:
- How will the solution itself be moved from development to test, to staging, and to production?
- How will changes to the solution be managed after initial deployment?
- What message and content needs to be given to users to ensure that the solution is successful according to the metrics?
MANAGE OPERATIONS
Manage the service and the business solution, the information it hosts, and the users that interact with it (administration)
- What administrative processes are necessary to support and manage the solution?
- What are the risks associated with the solution and how are those risks mitigated, addressed, or ignored?
MANAGE THE SERVICE PORTFOLIO
Monitor and measure the service to ensure that the solution is being delivered and utilized as expected (insight)
- What must be measured and monitored?
- To whom and in what fashion must the information be exposed?
Adjust the service or the solution if it is over or under critical metrics (remediation)
- How will anomalies, problems, and concerns be escalated?
- What will be the trigger for revising the solution?
IMPROVE
Incorporate lessons learned so that you can do it better for the next business solution (improvement)
- What did we learn from the last solution we deployed?
- How will we keep track of and incorporate learning from this solution?
These questions, if addressed in the early phases of a project, should themselves illuminate the path towards a well-governed solution. And, as each new solution is deployed, you end up with a well-governed service. Again, this list while an effective one is not “exclusive” or “exhaustive.” I look forward to your feedback!