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 CIO. Show all posts
Showing posts with label CIO. Show all posts
Wednesday, August 04, 2010
Saturday, July 24, 2010
General Business Requirements vs. Solution Requirements
What came first, the solution or the need? Let's hope the need, but we all know that is not always (often not) the case. With the great technologies available to us today, rapid application development enables us to solve problems. But, does the ease of development actually create a new set of problems? Yes, it does.
When the software development process is lengthy and drawn out, it forces many planning activities such as requirements analysis, design specifications, and planning. Not doing these things leads to costly adjustments later. The lengthy process also forces organizations to really think about what solutions they are developing and how these solutions fit into the big picture. We've got it pretty easy today. With portals, collaboration, search, BI, content management, and workflow platforms today, some times doing it "wrong", undoing it, and doing it again is actually less expensive than the cost of planning and documenting.
Yes, I am familiar with the twelve principles of the Agile Manifesto (Agile Alliance, 2001). I like agile development when it follows some organized processes and produces artifacts that can be used for reference later. You still need documentation for future development, disaster recovery, and repair.
However, what I don't like is "premature solutioning" or the practice of directly jumping from a problem to a solution design without any sort of further questioning, analysis, thought, or sanity checks. When you encounter a problem, and immediately form a solution and begin developing it, a lot is lost. You are not considering what other stakeholder needs are, what other colleagues are already working on, and how this "fly by the seat of your pants" solution actually fits in (or doesn't) into your overall information architecture.
Working with my colleagues, we recently began formalizing our thoughts around the solutioning process. One of the first roadblocks we encountered had to do with semantics. We began observing that our push for "requirements" was being misunderstood. When a problem-solution situation arose, we would explain that we needed to analyze requirements. The response to this typically included design specifications. We would then stop and say, no, we don't want detailed design specifications, what we want is to understand the problem better and understand how it impacts other people, so we can create a solution that will fit into our information architecture in a way that adds value and doesn't undermine anything else we are doing.
After a few more of these scenarios we decided that we had to make others aware of our solutioning process and how we think, so that everybody would be able to communicate with each other better. The first thing we did was make a distinction between the types of requirements that we would discuss in the course of solutioning.
We decided on the following:
General Business Requirements - Facts and opinions that help understand the problem better. These are not design specifications and do not explain a solution. Instead, this information explains what the business needs are.
Solution Requirements - Facts and opinions that define how a solution is supposed to look, feel, or act. This information directly dictates the design specifications.
So, now when a new request arises, we start by gathering "general business requirements." We then consult with stakeholders, policies, procedures, standards, goals, etc. and analyze the information. Once we have all the facts, we begin to design a solution. At that time, we ask stakeholders to help us define the "solution requirements." The result of the latter activity is a design specifications document. Next, we schedule and plan the development activities and proceed from there.
Reference
Agile Alliance (2001). Principles Behind the Agile Manifesto. Retrieved July 24, 2010 from http://agilemanifesto.org/principles.html.
When the software development process is lengthy and drawn out, it forces many planning activities such as requirements analysis, design specifications, and planning. Not doing these things leads to costly adjustments later. The lengthy process also forces organizations to really think about what solutions they are developing and how these solutions fit into the big picture. We've got it pretty easy today. With portals, collaboration, search, BI, content management, and workflow platforms today, some times doing it "wrong", undoing it, and doing it again is actually less expensive than the cost of planning and documenting.
Yes, I am familiar with the twelve principles of the Agile Manifesto (Agile Alliance, 2001). I like agile development when it follows some organized processes and produces artifacts that can be used for reference later. You still need documentation for future development, disaster recovery, and repair.
However, what I don't like is "premature solutioning" or the practice of directly jumping from a problem to a solution design without any sort of further questioning, analysis, thought, or sanity checks. When you encounter a problem, and immediately form a solution and begin developing it, a lot is lost. You are not considering what other stakeholder needs are, what other colleagues are already working on, and how this "fly by the seat of your pants" solution actually fits in (or doesn't) into your overall information architecture.
Working with my colleagues, we recently began formalizing our thoughts around the solutioning process. One of the first roadblocks we encountered had to do with semantics. We began observing that our push for "requirements" was being misunderstood. When a problem-solution situation arose, we would explain that we needed to analyze requirements. The response to this typically included design specifications. We would then stop and say, no, we don't want detailed design specifications, what we want is to understand the problem better and understand how it impacts other people, so we can create a solution that will fit into our information architecture in a way that adds value and doesn't undermine anything else we are doing.
After a few more of these scenarios we decided that we had to make others aware of our solutioning process and how we think, so that everybody would be able to communicate with each other better. The first thing we did was make a distinction between the types of requirements that we would discuss in the course of solutioning.
We decided on the following:
General Business Requirements - Facts and opinions that help understand the problem better. These are not design specifications and do not explain a solution. Instead, this information explains what the business needs are.
Solution Requirements - Facts and opinions that define how a solution is supposed to look, feel, or act. This information directly dictates the design specifications.
So, now when a new request arises, we start by gathering "general business requirements." We then consult with stakeholders, policies, procedures, standards, goals, etc. and analyze the information. Once we have all the facts, we begin to design a solution. At that time, we ask stakeholders to help us define the "solution requirements." The result of the latter activity is a design specifications document. Next, we schedule and plan the development activities and proceed from there.
Reference
Agile Alliance (2001). Principles Behind the Agile Manifesto. Retrieved July 24, 2010 from http://agilemanifesto.org/principles.html.
Saturday, December 05, 2009
I Respectfully Disagree
As I was searching for some references for a risk management white paper that I am writing, I stumbled upon an old PowerPoint on the Web titled, "Risk Management and ROI: The IT Leadership Financial Conversation." It was created by Peter G. W. Keen of Delft University in Sepetember 2004. This PowerPoint was used to educate an IT Leadership community attending a CIO summit.
As I looked through the PowerPoint for some insight to use in my paper, I started finding statements such as:
"ROI from IT: There is none. There never will be." (Keen, 2004)
"ROMI not ROI: Return on Minimized Investment" (Keen, 2004)
"80% of IT costs are hidden below the surface - and a navigation threat" (Keen, 2004)
The more slides I viewed, the more I realized that I completely disagree with the intent of the message; essentially to encourage CIOs to view IT as a business liability which needs to be tightly controlled and driven primarily by its cost drivers.
I disagree because I think a better approach for CIOs to take is to understand the purpose of the technologies their teams are evaluating, understand the costs and benefits, and choose projects which support the objectives of the organization. Managing cost should be part of the decision making process, but it should not be the primary driver. When cost is measured, all aspects of cost should be included. And, the financial benefits of the project should also be measured and included.
The objective of Information Technology is to facilitate two very important capabilities for today's businesses:
1. Revenue generation
2. Business productivity (process efficiency)
Most leaders in the IT space generally understand the financial benefits of the IT projects they choose to pursue, but perhaps the IT industry as a whole generally does not place enough emphasis on methodologies and practices for measuring and translating these back to the financial statement. This would require more focus, analysis, calculation, and validation.
To be clear, I am not saying that all IT projects are sensible and they should be done blindly. However, what I am saying is that it is incorrect to characterize IT as a business function that shows no return on investment.
If you deploy a technology that allows people to attend meetings over the Web instead of traveling to another location, then your costs are those which are required to implement and maintain the technology while your savings are those which you do not spend to travel? Both sides of equation need to be considered, not just cost.
I also disagree with the claim that 80% of IT costs are hidden. I believe that if budgeting is done properly, most IT costs are completely visible and manageable. There are always some unforeseen costs with IT, but by learning from past experiences, it becomes possible to anticipate these variations.
In summary, I disagree with the PowerPoint. Information Technology can have a positive ROI, and costs can be manageable and predictable. I think the real problem is some organizations just don't know how to measure these things effectively.
References:
Keen, P. (2004). The IT Leadership Financial Conversation. Retrieved December 5, 2009 from www.peterkeen.com/presentations/IT%20Risk%20Management.ppt.
As I looked through the PowerPoint for some insight to use in my paper, I started finding statements such as:
"ROI from IT: There is none. There never will be." (Keen, 2004)
"ROMI not ROI: Return on Minimized Investment" (Keen, 2004)
"80% of IT costs are hidden below the surface - and a navigation threat" (Keen, 2004)
The more slides I viewed, the more I realized that I completely disagree with the intent of the message; essentially to encourage CIOs to view IT as a business liability which needs to be tightly controlled and driven primarily by its cost drivers.
I disagree because I think a better approach for CIOs to take is to understand the purpose of the technologies their teams are evaluating, understand the costs and benefits, and choose projects which support the objectives of the organization. Managing cost should be part of the decision making process, but it should not be the primary driver. When cost is measured, all aspects of cost should be included. And, the financial benefits of the project should also be measured and included.
The objective of Information Technology is to facilitate two very important capabilities for today's businesses:
1. Revenue generation
2. Business productivity (process efficiency)
Most leaders in the IT space generally understand the financial benefits of the IT projects they choose to pursue, but perhaps the IT industry as a whole generally does not place enough emphasis on methodologies and practices for measuring and translating these back to the financial statement. This would require more focus, analysis, calculation, and validation.
To be clear, I am not saying that all IT projects are sensible and they should be done blindly. However, what I am saying is that it is incorrect to characterize IT as a business function that shows no return on investment.
If you deploy a technology that allows people to attend meetings over the Web instead of traveling to another location, then your costs are those which are required to implement and maintain the technology while your savings are those which you do not spend to travel? Both sides of equation need to be considered, not just cost.
I also disagree with the claim that 80% of IT costs are hidden. I believe that if budgeting is done properly, most IT costs are completely visible and manageable. There are always some unforeseen costs with IT, but by learning from past experiences, it becomes possible to anticipate these variations.
In summary, I disagree with the PowerPoint. Information Technology can have a positive ROI, and costs can be manageable and predictable. I think the real problem is some organizations just don't know how to measure these things effectively.
References:
Keen, P. (2004). The IT Leadership Financial Conversation. Retrieved December 5, 2009 from www.peterkeen.com/presentations/IT%20Risk%20Management.ppt.
Subscribe to:
Posts (Atom)
