Over a short period of time in the SharePoint community, the term "governance" has evolved to describe a class of software products or features. Yet, IT governance has nothing to do with what tools a SharePoint administrator has. Instead, IT governance has everything to do with the people and processes side of things; and the decision making framework that, when in play, can be used to determine that a portal should exist, who should manage it, who it should serve, how decisions will be made affecting it. Governance is really about policies, processes, roles, responsibilities, and priorities (Ross, 2004).
The scope of an effective Information Management Governance Model spans beyond a specific solution, such as SharePoint Intranet or collaboration portal, and encompasses the Information Management practices occurring throughout the organization. A SharePoint governance model should be a subset to that. Putting this in the context of documentation, an overarching Information Management Statement of Governance document should exist and define the framework at the global level, while specific statement of governance documents should be maintained for each Information Management system within the organization; SharePoint being one of those.
The IT project management framework is another significant and relevant topic to governance. The project management framework established the processes followed to initiate, plan, and execute IT projects. These processes should include such activities as the evaluation of new SharePoint projects in the context of the organization's overall information architecture. Aligning the project management decision making with Information Management, business, and IT decision making results in solutions that have backing, are sustainable, and actually provide business value.
The spirit of governance is really about defining what the processes should be, and if generous enough, explaining why to some extent. In the end, governance models maintain decision making integrity amongst people...that is not something a portal administrator can do by running a report or recovering a deleted site.
Reference
Ross, J., Weill, P. (2004). Recipe for Good Governance. Retrieved August 4, 2010 from http://www.cio.com/article/29162/Recipe_for_Good_Governance.
Showing posts with label Governance. Show all posts
Showing posts with label Governance. Show all posts
Wednesday, August 04, 2010
Tuesday, July 27, 2010
Why Information Silos Are So Persistent
Information silos are disparate entities that exist as rogue systems, utilities, spreadsheets and Access databases. Actually, an information silo might be anything that is not centrally managed or does not conform to existing design patterns. Silos may or may not be considered an official part of the enterprise...awareness about the silo doesn't change its definition.
Most of the time, these tools were developed to fill a gap. A gap between what the enterprise offers and what certain areas of the business actually need to function. They serve a purpose; and in many cases they are significant to the processes that they support.
Considering where technology is today, why are are information silos so persistent, more prevalent than ever? Why can't IT just build something into the enterprise architecture?
One reason (or cause) is because of the technology, which has become easier to work with and more accessible to people inside and outside of IT Departments. A person of any role can go on the Internet and figure out how to set up an Access database. In many cases, this is much easier than approaching a centralized IT department with their requirements. The Internet isn't going to say "no." By circumventing IT, nobody asks for funding, tries to minimize or question the need, or compromise the intention in any way. But, if the request did go to the IT department might, there might be resistance.
Secondly, a rogue solution is much less risky for a business person in terms of exposure and process transparency. By setting up a tool of their own, a business person may struggle a bit with configuration, but at no point is their process going to be visible to other people for criticism. If the person was to bring their requirements to the table and ask for help, then a lot of questions might be asked, putting guarded knowledge at risk. Unfortunately, for protective types, this means that the process would, in fact, become more transparent. The original process owner would become a "stakeholder" with influence rather than an "owner" with full control.
Beyond that, information silos also exist when an organization's methodologies and practices for providing holistic solutions are not mature enough to truly help. For example, IT organizations which are disorganized and reactive, might not be capable of helping the business person with their needs. There's no process, no authority, no plan to handle this sort of thing.
All of these situations challenge a centralized Information Management strategy.
Most of the time, these tools were developed to fill a gap. A gap between what the enterprise offers and what certain areas of the business actually need to function. They serve a purpose; and in many cases they are significant to the processes that they support.
Considering where technology is today, why are are information silos so persistent, more prevalent than ever? Why can't IT just build something into the enterprise architecture?
One reason (or cause) is because of the technology, which has become easier to work with and more accessible to people inside and outside of IT Departments. A person of any role can go on the Internet and figure out how to set up an Access database. In many cases, this is much easier than approaching a centralized IT department with their requirements. The Internet isn't going to say "no." By circumventing IT, nobody asks for funding, tries to minimize or question the need, or compromise the intention in any way. But, if the request did go to the IT department might, there might be resistance.
Secondly, a rogue solution is much less risky for a business person in terms of exposure and process transparency. By setting up a tool of their own, a business person may struggle a bit with configuration, but at no point is their process going to be visible to other people for criticism. If the person was to bring their requirements to the table and ask for help, then a lot of questions might be asked, putting guarded knowledge at risk. Unfortunately, for protective types, this means that the process would, in fact, become more transparent. The original process owner would become a "stakeholder" with influence rather than an "owner" with full control.
Beyond that, information silos also exist when an organization's methodologies and practices for providing holistic solutions are not mature enough to truly help. For example, IT organizations which are disorganized and reactive, might not be capable of helping the business person with their needs. There's no process, no authority, no plan to handle this sort of thing.
All of these situations challenge a centralized Information Management strategy.
Friday, April 09, 2010
Inconsistency in Information Management System Governance, Projects is Kryponite
I continue to revisit the thought that a SharePoint governance model (policies, procedures, standards, resources, etc.) can be undermined if an organization does not employ proper and consistent governance for all of its information management activities and systems.
Consistency is important because it level sets the way that people approach information management projects, including SharePoint projects. If some projects were to take a fly by the seat of your pants approach, disregarding governance concepts, it is bad because the resulting deliverables will be inconsistent from what the guiding principles that the governance model is supporting. What is worse is the sloppy result is the one that is achieved first, since it takes less time to do things when you circumvent processes.
Meanwhile, you might have some projects following the rules and progressing a bit slowly while the wild wild west ones are moving fast and crossing the finish line earlier. By the time the "good" project finishes, the wild wild west has already become the de facto standard. A precedent is set and now all of those "unnecessary" rules are perceived as pockets of resistance and momentum builds in avoiding the rules rather than following them. This is a vicious cycle and requires quite a lot of effort to reverse the damage. It is much easier if the executive sponsors can support the governance concepts, then promote and mandate accordingly.
The benefits of the formal approach to projects and adherence to information management governance is obvious to anybody who has experienced a complete project life cycle and then stuck around long enough to observe the after effects. This topic is very much philosophical; do you want to manage projects short-sighted to get the project completed or do you want to manage projects for the greater good, long term to support the guiding principles of the governance model?
I will draw an analogy. You live in the mountains and have a wood stove. You can spend cheap money buying an axe, then hurry to chop wood with it to meet an immediate need of filling the stove once. Or, you can invest more money on a chainsaw and then be able to provide wood for the stove, more efficiently, every time you need it moving forward. It is called return on investment. Sustainable efficiency and the ability to produce higher quality deliverables (which are easier to maintain) is the result of following a slow and steady approach to information management projects; taking the time to remain aligned with the principles of the governance plan.
Consistency is important because it level sets the way that people approach information management projects, including SharePoint projects. If some projects were to take a fly by the seat of your pants approach, disregarding governance concepts, it is bad because the resulting deliverables will be inconsistent from what the guiding principles that the governance model is supporting. What is worse is the sloppy result is the one that is achieved first, since it takes less time to do things when you circumvent processes.
Meanwhile, you might have some projects following the rules and progressing a bit slowly while the wild wild west ones are moving fast and crossing the finish line earlier. By the time the "good" project finishes, the wild wild west has already become the de facto standard. A precedent is set and now all of those "unnecessary" rules are perceived as pockets of resistance and momentum builds in avoiding the rules rather than following them. This is a vicious cycle and requires quite a lot of effort to reverse the damage. It is much easier if the executive sponsors can support the governance concepts, then promote and mandate accordingly.
The benefits of the formal approach to projects and adherence to information management governance is obvious to anybody who has experienced a complete project life cycle and then stuck around long enough to observe the after effects. This topic is very much philosophical; do you want to manage projects short-sighted to get the project completed or do you want to manage projects for the greater good, long term to support the guiding principles of the governance model?
I will draw an analogy. You live in the mountains and have a wood stove. You can spend cheap money buying an axe, then hurry to chop wood with it to meet an immediate need of filling the stove once. Or, you can invest more money on a chainsaw and then be able to provide wood for the stove, more efficiently, every time you need it moving forward. It is called return on investment. Sustainable efficiency and the ability to produce higher quality deliverables (which are easier to maintain) is the result of following a slow and steady approach to information management projects; taking the time to remain aligned with the principles of the governance plan.
Thursday, January 07, 2010
Governance Concepts, Strategy, and Authority
One of the initial challenges with establishing governance model is organizing the concepts appropriately. In order for governance to be effective, the concepts need to be grouped according to the appropriate scope, authority, and audience.
Information Management is a concept that may apply across an entire enterprise; same with corporate polices and procedures. However, the SharePoint platform may only be responsible for organizing a sub-set of an organization's information and therefore the scope of this is smaller. Additionally, SharePoint is technical in nature and so the emphasis on Information Technology audience is greater. For these reasons, it makes little sense to try to encapsulate all of the governance topics for an organization's information management needs, within a SharePoint governance plan. Instead, topics should be divided and organized appropriately.
For example, if you were on a whiteboard brainstorming and creating idea clouds for the purpose of outlining your governance topics, you might start to group topics like this:
Thinking about these concepts right is a prerequisite to creating governance documents and perhaps even beginning to model any new, collaborative solutions. Authority needs to be defined and delegated up front. Without a central managing body having necessary authority, the decision making process will be a constant road block.
Consider this classic scenario; a hypothetical Information Technology department owns and manages technology systems for an organization. They don't happen to possess authority to own or commence initiatives around analysis, design, and integration of information architecture policies and processes. This department decides to deploy SharePoint as a technology offering. A likely, potential result of this is that the deployment becomes a commodity service. The odds that this platform will do much to improve information management practices throughout the organization, are thin. The initiative was not started by the body which governs information architecture practices for the company.
Now consider a variation. Consider that this hypothetical business unit now has the authority to work with other business units collectively, and facilitate a company wide initiative to analyze, interpret, and parse the information management requirements of the company, the teams, and the individuals. They also have authority to facilitate the creation and management of information management policies and procedures. Finally, they retain the authority to own and manage technology systems. This scenario has a much greater potential to produce a full bodied SharePoint deployment, adding lots of value throughout the business by integrating information management capabilities. In this scenario, the technology can actually be used to mandate how documents are organized, where they are stored, and how they are tagged.
Having said this, a commodity service may be the right next step for an organization, who is to say. But evolution of processes tell us that one day, silos of information will want to be joined. Progression is a natural thing and it should be embraced. SharePoint as a commodity service is not the end game, it is a starting point. Strategy is recognizing progression paths and figuring out how to make it happen. There will be people fighting the progression and arguing the direction is wrong, that they have different ideas. There will be resistance. Strategy demands authority. Governance provides it. The right combination of these pieces can act as one hell of a steam roller.
Information Management is a concept that may apply across an entire enterprise; same with corporate polices and procedures. However, the SharePoint platform may only be responsible for organizing a sub-set of an organization's information and therefore the scope of this is smaller. Additionally, SharePoint is technical in nature and so the emphasis on Information Technology audience is greater. For these reasons, it makes little sense to try to encapsulate all of the governance topics for an organization's information management needs, within a SharePoint governance plan. Instead, topics should be divided and organized appropriately.
For example, if you were on a whiteboard brainstorming and creating idea clouds for the purpose of outlining your governance topics, you might start to group topics like this:
Information Management Statement of Governance
- Overview
- Roles and responsibilties
- Decision making processes
- Explanation of information architecture
- How taxonomies are developed and integrated
- References to file naming conventions
- References to policies and procedures
SharePoint Governance
- Overview
- Roles and responsibilities
- Operating processes
- Explanation of the applied use of SharePoint with respect to Information Management
- References to SLA
- References to policies and procedures
Policies and Procedures
- Information Security policies
- System Use policies
- Support policies
- Request processes
- Project processes
Thinking about these concepts right is a prerequisite to creating governance documents and perhaps even beginning to model any new, collaborative solutions. Authority needs to be defined and delegated up front. Without a central managing body having necessary authority, the decision making process will be a constant road block.
Consider this classic scenario; a hypothetical Information Technology department owns and manages technology systems for an organization. They don't happen to possess authority to own or commence initiatives around analysis, design, and integration of information architecture policies and processes. This department decides to deploy SharePoint as a technology offering. A likely, potential result of this is that the deployment becomes a commodity service. The odds that this platform will do much to improve information management practices throughout the organization, are thin. The initiative was not started by the body which governs information architecture practices for the company.
Now consider a variation. Consider that this hypothetical business unit now has the authority to work with other business units collectively, and facilitate a company wide initiative to analyze, interpret, and parse the information management requirements of the company, the teams, and the individuals. They also have authority to facilitate the creation and management of information management policies and procedures. Finally, they retain the authority to own and manage technology systems. This scenario has a much greater potential to produce a full bodied SharePoint deployment, adding lots of value throughout the business by integrating information management capabilities. In this scenario, the technology can actually be used to mandate how documents are organized, where they are stored, and how they are tagged.
Having said this, a commodity service may be the right next step for an organization, who is to say. But evolution of processes tell us that one day, silos of information will want to be joined. Progression is a natural thing and it should be embraced. SharePoint as a commodity service is not the end game, it is a starting point. Strategy is recognizing progression paths and figuring out how to make it happen. There will be people fighting the progression and arguing the direction is wrong, that they have different ideas. There will be resistance. Strategy demands authority. Governance provides it. The right combination of these pieces can act as one hell of a steam roller.
Outline for Disaster Recovery Plan Document
The purpose of this post is to share a disaster recovery plan outline. This is an outline that I have been evolving for several years. And, although this outline was intended for SharePoint environments, it can be used for any system or application.
The reason I like this outline is because I know it works. Unlike many other plans on the Web, I think this outline provides more complete coverage of the business and technical aspects of disaster recovery. Many of the plans I have seen are merely explanations of the SharePoint product features and limitations, or advertisements for third party products. Detailing what SharePoint's strengths and weaknesses are with regards to backup and restore will not do you an ounce of good in the event you need to perform a recovery of some sort. Additionally, no matter what tools you have for backing up and restoring, you still need a good plan to address the process. Different tools only change the content of the backup and recovery procedure section of the plan, they don't change the structure of the document or eliminate the need for any of the sections of the document.
The audience for this document can include the tactical team members who execute the plan, but also the business stakeholders, sponsors, and business process owners who are affected by the availability and recovery policies and procedures. Everybody should be involved with contributing to and reviewing the plan. This review process is very healthy because it resets expectations and keeps everybody on the same page.
SharePoint Disaster Recovery Plan Outline
I. Overview
a. Explanation of the document
b. Explanation of when to use the plan
II. Business Profile
a. Application or system owners, points of contact
b. Application or system summary
c. Related business processes
d. Usage information
e. Availability requirements (link to SLA)
f. Recovery requirements (link to SLA)
III. Technical Profile
a. Hardware inventory
b. Software inventory
c. Related systems
d. Vendor contact information (contact, support agreement information, etc.)
IV. Failure Scenarios
Matrix listing all failure scenarios with description of each scenario
V. Backup Procedures
Instructions for each method of back up used to support every possible recovery scenario
VI. Recovery Procedures
Instructions for recovering from each failure scenario
VII. Verification Procedures
a. Functional testing
b. Security testing
c. Performance testing
d. Checklists
VII. Appendix
a. Glossary
b. Links to policies, procedures
VIII. References
The reason I like this outline is because I know it works. Unlike many other plans on the Web, I think this outline provides more complete coverage of the business and technical aspects of disaster recovery. Many of the plans I have seen are merely explanations of the SharePoint product features and limitations, or advertisements for third party products. Detailing what SharePoint's strengths and weaknesses are with regards to backup and restore will not do you an ounce of good in the event you need to perform a recovery of some sort. Additionally, no matter what tools you have for backing up and restoring, you still need a good plan to address the process. Different tools only change the content of the backup and recovery procedure section of the plan, they don't change the structure of the document or eliminate the need for any of the sections of the document.
The audience for this document can include the tactical team members who execute the plan, but also the business stakeholders, sponsors, and business process owners who are affected by the availability and recovery policies and procedures. Everybody should be involved with contributing to and reviewing the plan. This review process is very healthy because it resets expectations and keeps everybody on the same page.
SharePoint Disaster Recovery Plan Outline
I. Overview
a. Explanation of the document
b. Explanation of when to use the plan
II. Business Profile
a. Application or system owners, points of contact
b. Application or system summary
c. Related business processes
d. Usage information
e. Availability requirements (link to SLA)
f. Recovery requirements (link to SLA)
III. Technical Profile
a. Hardware inventory
b. Software inventory
c. Related systems
d. Vendor contact information (contact, support agreement information, etc.)
IV. Failure Scenarios
Matrix listing all failure scenarios with description of each scenario
V. Backup Procedures
Instructions for each method of back up used to support every possible recovery scenario
VI. Recovery Procedures
Instructions for recovering from each failure scenario
VII. Verification Procedures
a. Functional testing
b. Security testing
c. Performance testing
d. Checklists
VII. Appendix
a. Glossary
b. Links to policies, procedures
VIII. References
Monday, December 28, 2009
Governance: Capability Driven, Not Platform Driven
Although I have no survey or poll results to support this; I believe that the SharePoint community as a whole is putting more weight on the topic of governance as time moves forward. I am basing this on the number of blog posts, conference presentations, third party products, and research available on the Web. Microsoft even has made a SharePoint governance plan template (SharePoint Products and Technologies Governance Plan) available for download.
I have mixed emotions about some of the messaging in the community. I think the topic of governance has become so SharePoint-centered that the original intent of governance becomes lost. Taking a few steps back, I thought I might weigh-in on the subject.
When push comes to shove, SharePoint is simply a platform, a means to an end. It is a tool to facilitate a capability. If that capability happens to be information management, then SharePoint is providing the technical functionality required to make managing information better.
My take on governance planning is that an organization should first address the capability (e.g. information management) as a whole, and then develop a plan for it. Once that overarching effort is in motion, it should branch off into defining the policies, processes, and measures specifically addressing SharePoint.
The flaw I see in creating a governance plan starting with SharePoint platform is that too many questions and risks about the overall initiative of providing that information management capability exist. This flaw may be a symptom or an indicator of larger ailments in the organization such as a lack of clarity or a lack of sponsorship (or a lack of clarity within its sponsorship). The way I see it, if an executive management team is willing to embrace the idea of using the SharePoint platform, then it ought to be willing to accept and embrace the larger initiatives at hand; which is where governance should originate.
In conclusion, I think that in order to maintain long term credibility with the subject of governance planning, we in the SharePoint community should share more ideas about how to integrate SharePoint governance into existing corporate governance as well as how to properly originate governance where it does not already exist. And, in order to do this I think it requires stepping out of the world of SharePoint and taking a wholistic view of the organization and understanding the fundamental policies and processes at play, as well as understanding what is the underlying intent and purpose for which SharePoint is being deployed.
I have mixed emotions about some of the messaging in the community. I think the topic of governance has become so SharePoint-centered that the original intent of governance becomes lost. Taking a few steps back, I thought I might weigh-in on the subject.
When push comes to shove, SharePoint is simply a platform, a means to an end. It is a tool to facilitate a capability. If that capability happens to be information management, then SharePoint is providing the technical functionality required to make managing information better.
My take on governance planning is that an organization should first address the capability (e.g. information management) as a whole, and then develop a plan for it. Once that overarching effort is in motion, it should branch off into defining the policies, processes, and measures specifically addressing SharePoint.
The flaw I see in creating a governance plan starting with SharePoint platform is that too many questions and risks about the overall initiative of providing that information management capability exist. This flaw may be a symptom or an indicator of larger ailments in the organization such as a lack of clarity or a lack of sponsorship (or a lack of clarity within its sponsorship). The way I see it, if an executive management team is willing to embrace the idea of using the SharePoint platform, then it ought to be willing to accept and embrace the larger initiatives at hand; which is where governance should originate.
In conclusion, I think that in order to maintain long term credibility with the subject of governance planning, we in the SharePoint community should share more ideas about how to integrate SharePoint governance into existing corporate governance as well as how to properly originate governance where it does not already exist. And, in order to do this I think it requires stepping out of the world of SharePoint and taking a wholistic view of the organization and understanding the fundamental policies and processes at play, as well as understanding what is the underlying intent and purpose for which SharePoint is being deployed.
Subscribe to:
Posts (Atom)
