Thursday, June 28, 2007
IT Governance a Compass Without a Map?
Does your IT Governance output provide you with a detailed strategic blueprint and plan for business value generation or is it a compass without a map?
Over the last few weeks I have been dealing with issues at a very operational level related to topics such as the correct use of classification schemes or how to handle emergency changes. While these are important topics I find that many organizations have a fundamental problem with a more strategic issue.
Perhaps many of the challenges that we face today are a reflection on the state of maturity of IT Governance structures and roles. In part this is due to the fact that many people disagree on the definition and role of IT Governance and to quote one of my favorite sayings “what is not defined cannot be controlled, managed measured and improved.”
Troy’s abbreviated summary: IT Governance is responsible for (defining, establishing and measuring) the enterprise IT (vision, strategy, policies, structures and capabilities) required to support business value generation and corporate governance requirements.
To use a building analogy, IT Governance is responsible for understanding business requirements, legislative constraints and technology opportunities. It then takes this knowledge and drafts the master blueprint and architecture for how to build, run and improve the IT organization.
In this blueprint key design decisions are documented:
- IT Accountability and decision making framework
- Enterprise IT Policy
- The IT Service Portfolio & Architecture
- Organizational Structure and Supplier Model
- Operating Model, IT Capabilities/Processes
- Technology and IT Tool Standards
- IT Investment and Funding Models
- Performance Dashboard Characteristics
Based on this blueprint, it is the responsibility of IT Management (the skilled tradesmen who build based on the blueprint) to adopt, implement and comply with the established vision and strategies. However it remains the responsibility of IT Governance to ensure that management does in fact implement and remains in compliance with the established blueprint.
Without these elements having being clearly documented and communicated IT management and project investment decisions are made blindly in isolation without consideration or in alignment with an enterprise IT strategy.
The key words from this summary are: (Define, Establish and Measure). It is my belief that the responsibility of IT Governance includes but extends beyond setting high level principles, policy and decision making models (the compass). Unless IT Governance defines the details around its operating model (the map) the vision and strategy is limited without, context and direction.
The central problem I believe is that many organizations view the role of IT Governance as too heavenly minded to be much earthly good. Their approach to IT Governance goes as far a developing a high level vision and strategy but falls short of defining enough detail to support the creation of the IT organization they envision. Or at the very least what is defined at an executive level is not effectively communicated down to an operational level.
However defining vision/strategy and establishing a blueprint is still only 2 out of 3 key activities. For IT Governance to be ultimately successful an executive level measurement model or dashboard needs to be established for all aspects of the blueprint. The purpose of this dashboard is to initially baseline in order to identify gaps and priorities and then to support continual improvement and ensure organizational compliance. (What is not measured is not done!)
This post represents my personal views on the scope of IT Governance and I am aware that many people may believe I have pushed into the domain of IT Management. However, consider that IT Management is typically focused on technology domains or lines of service. What I have described as the role of IT Governance is related to establishing a comprehensive operating model for enterprise IT which establishes the rules of engagement and cooperation for all IT service provider types (business unit IT, shared IT and external suppliers).
Two respected organizations that research and write on this topic are the IT Governance Institute and the MIT Sloan Center for Information System Research. Please consider the following quotations from these two sources in light of what I have shared so far.
IT governance is the responsibility of executives and the board of directors, and consists of the leadership, organizational, structures and processes that ensure that the enterprise’s IT sustains and extends the organization’s strategies and objectives.
Furthermore, IT governance integrates and institutionalizes good practices to ensure that the enterprise’s IT supports the business objectives.
~IT Governance Institute – “COBIT 4.1”
IT Governance is the decision rights and accountability framework for encouraging desirable behaviors in the use if IT. IT Governance reflects broader corporate governance principles while focusing on the management and use of IT to achieve corporate performance goals.
IT Governance encompasses five major decision areas related to management and use of IT in a firm, all of which should be driven by the operating model:
- IT principles: high level decisions about the strategic role of IT in the business
- Enterprise Architecture: the organizing logic for business processes and IT infrastructure
- IT Infrastructure: centrally coordinated, shared IT services providing part of the foundation for execution
- Business Application Needs: business requirements for purchased or internally developed IT applications that both use and build the foundation for execution.
- Prioritization and Investment: decisions about how much and where to invest in IT, including project approval and justification
~ Harvard Business Review / MIT Sloan “Enterprise Service Architecture as Strategy”
Notice that while the two have subtle differences they share common characteristics and are both action oriented. IT Governance is active, directive and ongoing!
One last thought:
Consider that when organizations are making decisions to adopt and implement best practice IT Management frameworks such as ITIL, CMMI or PMBOK they should in theory be motivated to do so by an established IT governance blueprint. These frameworks are in reality a set of tools that provide a means to an end. If the blueprint has already identified a need to adopt practices around Information Security, IT Service Management, or Application Lifecycle then these frameworks can be used to achieve pre-determined governance requirements.
However, when this blueprint is missing we often find organizations struggling to explain the benefits of why they should adopt good practices such as a single change management process or a CMDB strategy for coordinating and presenting enterprise IT data.
Without this critical blueprint it often appears if the tail is wagging the dog.
Troy’s thoughts what are yours?
“There is a theory which states that if anybody ever discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened” ~Douglas Adams
Tuesday, June 19, 2007
Service Request vs. Request for Information
In the spirit of recent posts related to ITSM implementation considerations I would like to toss another practical topic into the ring that goes slightly beyond but does not break the good practices documented in ITIL. Many of the readers of this blog may be aware that ITIL v3 has acknowledged that Service Requests as handled by the process of “Request Fulfillment” and found in the Service Operation book has been acknowledge in ITIL v3 as its own process and is not tied to Incident Management as some would espouse.
I for one never saw eye-to-eye with this view and found myself on the side of the debate that preferred to think of a Service Request as a low risk change focused on the request for something that a user did not have or a modification of something they already did.
E.g.: I want a laptop, a new user account, or access to a report that is beyond my access rights
With Request Fulfillment being acknowledged as its own process outside both the domain of Incident and Change Management this effectively silences the ITIL geeks such as myself on this topic and forces us to find some other minor issue to debate as we down our recreational beverages.
The challenge that still remains however is whether there is a difference between a request for service and a request for information. The general description of a Service Request covers both.
From the ITIL v3 glossary we can find the following definitions:
Service Request: A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted. See Request Fulfillment.
However in practice when implementing an ITSM tool or setting up a Service Desk it has always been my advice to create a different classification for each of the following:
- Service Request: Standard / Pre-approved Change
- Request for Information: Advice, information, on the phone training
- Password Reset: Not an incident since the service is still there ready and waiting, more like a request to let me back in
Note: All of these record types are different from an Incident ticket that supports the restoration of service.
It is my view that a distinction has to be made by the service desk between each of these different types of records both from a management information and process workflow perspective. Regardless of the question of ITIL v2 or v3 this distinction has always been needed when implementing these practices.
Troy’s thoughts what are yours?
Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning. ~Sir Winston Churchill
Monday, June 11, 2007
One of the single most important requirements for mapping services and processes in relationship to technology and people is a well thought out and detailed categorization structure for IT workflow tools.
The ability to classify workflow records in the same way across the various processes that enable the delivery and support of IT services is a foundational building block for automation and integration. The processes of Incident, Problem, Change and Release Management as well as other major aspects of service management require this consistent approach to process classification to be effective. The ability to accurately classify process records consistently is a critical success factor for automation, integration and the production of qualified and trusted management reports.
These classification structures act like a spinal cord linking the processes together and they are just as critical to service management as the spine is to a healthy body. Damage your spine and you will be in a whole world of hurt!
Classification – ITIL V3 Glossary
“The act of assigning a Category to something. Classification is used to ensure consistent management and reporting. CIs, Incidents, Problems, Changes etc. are usually classified”
The most common mistake that IT organizations make when they design a categorization structure is that they approach it from a purely technical or single process perspective.
Each process record requires a combination of the following four basic and common classification structures.
- Service: What IT Service is being restored, changed or requested
- Organization: What customer is being impacted or which IT function has been assigned the process record
- Priority: How quickly and it what order must the IT service provider address this issue at hand
- Technology: What type of technology is being restored, requested or moved
Note: for more information on Priority check out the post called. The Practicality of Prioritization
Each process record relating to IT Service Management requires access to the same basic four classification structures. However, it is also important to note that some processes may require additional structures that are unique to that process.
For example, Incident Management: Requires a closure code classification structure for the likely root cause of the Incident to support Problem Management. (Eg: hardware failure, process failure, Software failure, human error, etc…)
Also due to the shared nature of the four basic classification structures it is important that they remain generic and do not contain specific verbs or actions related to a specific process. Actions such as reset password, add user or move PC should be found in their own drop down field outside of the four structures listed above.
Other areas of service management that rely on the common categorization coding structures are:
- Request Fulfillment
- Event Management
- Knowledge Management
- Information Security Management
- Service Asset and Configuration Management
- IT Procurement
Examples of automation driven by the usage and creative combination of these classification structures are:
- Record assignment
- Identification of change approvers
- Filtering of CIs in support of CMDB association
- Escalation & Notification Rules
- Impact / Urgency / and priority population
- Rapid record population
- Incident matching to Problems
- Knowledge Management information and Support Scripts
Categorization Best Practices
- Spend adequate time in the definition of the scope and level of the category tree. Lack of detail will inhibit management information. Too much detail will make the tree impractical for use.
- KISS: Keep it simple and structured, otherwise the categorization system will in not be used in a consistent manner. Studies show that most people will not pick from a list that is too long at any level. Typically from what they can see without scrolling.
- The categorization structure does not have to be limited to the same number of levels for every branch of the tree structure.
- The use of an “Other” or “Unknown” categorization must have a management process supporting and controlling its use. This option can provide important information about the relative usefulness of the current coding system or the knowledge level surrounding it.
- The classification structures must be under strict change control
- Avoid having more than one way to classify something with extreme prejudice
Troy’s thoughts what are yours?
“There’s a good chance that the structure of the question is encoded in the structure of your brain - so we want to buy it off you.” ~ Douglas Adams