Wednesday, January 31, 2007
ITIL Implementation RoadMap (Release Management) – Part 8
Keeping It From Blowing Up On Landing
One of the most misunderstood processes in the ITIL library is Release Management. A common error is the assumption that Release Mgmt. is primarily about deployment. While the bundling and pushing of releases is definitely part of the process it represents the literal tip of the iceberg perhaps even less than 10 % of the total effort. By far the vast majority of the blood sweat and tears of this process happens prior to the release being placed in the production environment.
The goals of Release Management include the assurance of quality, production readiness and deployment of any new or modified element being introduced to the live customer environment. To accomplish this, the Release Management process collects requirements from each stakeholder group and then matches those requirements to release types that are defined by an agreed risk impact model. Based on these release types, the appropriate number of requirements is applied in order to assure production readiness. It is the role of Release Management to broker which requirements apply for each type and at each milestone of the release lifecycle. The efficiency and effectiveness of the process is based on the right sizing of the number of requirements for each type based on business risk. The challenge of Release Management lies in the fact that there are numerous stakeholder groups that all have very strong views on the subject.
Typical stakeholder groups would include:
- Application Development
- Project Office
- Security Group
- Architectural Engineering
- Facilities / Cabling
- Computer Operations
- Production Support
- Quality Assurance functions
- Change Management process
- Configuration Management process
- Service Level Management process
- THE CUSTOMER
Many organizations struggle with their Change Management process due to the fact that Release Management is missing. Change Advisory meetings reviewing the forward schedule of change become long drawn out and laborious affairs because the CAB attempts to determine if the change can be determined as safe and ready to promote (The role of Release Management). The problem with asking if enough documentation, training, testing, communication…. etc. has been done at this point is that it is way too late to be asking quality questions. (That horse has already left the barn)
In an organization that has implemented a healthy release process the quality checklist and templates are handed to the release builder at the earliest part of the release lifecycle and are completed and validated before the change process considers it for promotion into production.
Typical Release Mgmt. Implementation Phases:
- A first level of maturity for this process typically places the quality assurance role in the hands of the Change Management process. Change advisory meetings are long and tedious due to the fact that questions have to be asked and requirements validated as to the quality and completeness of the proposed change request. At this level of maturity, there is a strong dependency on a change process at the level defined as Change Control.
- The second level of implementation typically focuses only on the stakeholder groups, which are seen as the production support groups. A Release process at this stage of maturity is often called a “Production Handover Process”. Release requirements are only focused at the last milestones of the lifecycle which occur just prior to and during deployment in to the production environment.
- A fully mature Release process includes requirements for the full release lifecycle from all of the groups listed above. Release types are defined which have been allocated the appropriate set of requirements. These requirements are published and integrated into the application lifecycle as well as the project management methodologies. Change Management at this point looks to Release to attest to the fact that all requirements have been met and that the appropriate sign-offs have been achieved. While many processes integrate with the Release Management process, the primary relationships are Change and Configuration Management. Troy’s thoughts what are yours? “I’d take the awe of understanding over the awe of ignorance any day.” ~ Douglas Adams
Monday, January 29, 2007
ITIL Implementation Roadmap (Configuration Management) – Part 7
Configuration Management a Life Long Journey
While not recommended as one of the first processes, you will eventually discover the basic truth that all IT Management process deal in a currency of data and information. Consider that the acronym “IT” stands for Information Technology and that we live in an age where the accurate management and use of information will either enable strategic advantage or its loss will bring about financial ruin. While reality is not quite so dramatic anyone who works in IT would have to admit that we know how to delivery on the technology but the information part is a bit more challenging.
This challenge is no where more obvious than in your typical Change Management meeting where 10 – 15 of the key players in the IT function have to be present to correctly assess the risk of any proposed change. In most organizations the CMDB is stored in the grey matter of our subject matter experts and has to walk into the room each time we need to make an important IT Management decision.
So if the creation of a CMDB is so important why would this logically not be one of the first parts of ITIL an organization should implement? The answer to this question is that logic has nothing to do with it!
Very few people once informed of the purpose and the need for a CMDB will not agree that it is a good idea which we should do one day. Current technology and tools make the implementation of a CMDB more realistic than ever. Yet still many organizations put the creation of a CMDB off or fail miserably the first time they attempt a Configuration Management project due to the nature of IT Culture, organizational design and domain focused tool procurement practices.
I have written several posts on the nature of this subject but for a summary I refer you to a post called Not Ready For The CMDB
However I do believe that all IT shops will eventually come to the place where a CMDB is a recognized core business requirement.
For those Organizations I offer a high level description of key project elements of Configuration Management:
Planning for Configuration Management should include the following main tasks:
- Establish the objective of Configuration Management for the IT organization
- Establish the scope of the Configuration Management process
- The definition of policies, standards around control and administration (Centralized vs. Decentralized)
- Define the process ownership, management and coordination roles
- Define the functional tool requirements and selection criteria for the CMDB
- Developing the process and tool related procedures for performing the Configuration Management activities: identification, control, status accounting, verification and audit
- Interfacing the CMDB with other processes (e.g. Change Management)
- Design of the CMDB Data Model
- Define CI naming conventions and labeling procedures
- CMDB customization and population
- Development of a Performance Management Framework including group and individual key performance Indicators (KPI’s)
While there is much to be said about the Configuration Management project in the end it all comes down to who gets to keep this database up to date. For this reason I thought at the risk of making this post too long you would be interested in the key roles of this process.
Roles And Responsibilities:
The initial planning phase of the project must include the establishment of the role of a Process Owner for Configuration Management. This key role will be accountable for the overall quality of the process, the management of, and organizational compliance to, the process flows, procedures, data models, policies, and technologies associated with the Configuration Management process.
The Process Owner for Configuration Management plays the important role of Champion, Design Lead, Advocate, Coach and Protector. The Process Owner who is accountable for Configuration Management should be a senior level manager who carries prestige, credibility and authority across the various areas affected by the process implementation. Positional power is particularly important to the selection of the Configuration Management process owner due to the distributed nature of administration and number of cross-organizational groups and departments integrated with the process. The Process Owner will be required to have the ability to influence and assure compliance to the policies and procedures put in place across the cultural and organizational silos of the IT organization. Depending on the size of the organization the Process Owner may or may not be the Configuration Manger.
The Configuration Manager is responsible for managing the operational activities of the process. The Configuration Manager is involved in ensuring integration with the other Service Management processes such as Change and Release Management. The Configuration Manager is also involved in developing the CMDB data model, core policies, maintenance processes and procedures, key performance indicators and producing ongoing management reports.
Examples of the responsibilities involved Include:
- Facilitates the negotiation of the scope of the Configuration Management process in collaboration with the project steering committee, Process Owner and IT and business stakeholders
- Identifies which CIs need to be managed and controlled from this basis of Inventory, Asset and Configuration Management
- Proposes and agrees to the CI types and level of detail at which CIs are to be identified
- Ensures that the CMDB reflects the real-time state of the IT infrastructure
- Produces and distributes management reports for Configuration Management
- Defines integration requirements to support other IT Service Management processes
- Audits the CMDB against the infrastructure to measure and report on data integrity and compliance
- Updates the logical CMDB Service Structure when an IT Service is implemented or changed
- Continually reviews the Configuration Management process for efficiency and effectiveness
- Plans and executes the population of the CMDB (manual or automated)
- Leverages system management tools to assist with CMDB data integrity
- Performs regular housekeeping on CMDB and plans for growth
Configuration Management Coordinator:
Each technical domain is traditionally responsible for maintaining a record of the assets under their management and control. Typically, these areas are maintaining various data repositories in spreadsheets and databases, which need to be transferred or federated to a central CMDB. It stands to reason that due to the complexity of the infrastructure and the sheer number of CIs to be managed these technical domains should maintain the data within the physical layer of the CMDB data model under their control. A key recommendation of this post is the establishment and formalization of this role for each technical domain responsible for the update of the CMDB.
That being said, logic would dictate that while the maintenance of this data would be basic activity for each of these groups, very few keep their existing repositories up to date to a level that would be useful for management decision-making and support for the other ITIL processes. Unless reward and measurement systems are changed to raise the profile of this activity in order to measure the compliance to the Configuration Management processes, the CMDB will end up in the same state as most of the existing data repositories the organization has today. For this reason, it is critical the Configuration Manger keeps a close eye on and reports on the integrity of the data and the compliance by various groups involved. When areas of concern are identified, it is up to the Process Owner to provide the necessary influence to facilitate the cultural changes required to maintain the database.
Examples of the responsibilities involved:
- Define which CI types are to be tracked within their technical domain
- Define what attributes will be tracked for each CI type
- Upload the data from existing data repositories into the central CMDB
- Update the CI records under their control on an ongoing basis
- Maintain the system and service relationships of the CIs under their control
- Assist with periodic integrity audits on the CIs within their domain
Troy’s thoughts what are yours?
Tuesday, January 23, 2007
ITIL Implementation Roadmap (Problem Management) – Part 6
Problem Management Screws Up Our Metrics!
How many time have you seen the glint in the executives eye when he or she proudly proclaims a first call incident resolution of 80% percent or higher at the Service Desk?
This single metric is often held high as the sacred metric of efficiency and effectiveness for an IT support organization. However, have you ever stopped to think that perhaps the exact opposite may be true?
Consider that the best way to achieve a high first call resolution is to repeatedly see the same issues called into the Service Desk over, and over again. Once this predicable pattern is documented the repeat incidents are quickly identified and the workarounds are applied within minutes. As my good friend George Spalding is fond of saying. “Show me an IT organization with an extremely high first call resolution metric and I will show you a Service Desk which is covering up for a dysfunctional IT Shop.” It is true that the Service Desk is doing a fine job of dispatching Incidents without bothering 2nd level support, but this is primarily due to the fact that no one is fixing anything permanently. If the organization was to actually identify repeat incidents and remove them from the environment (Problem Management) then the first call resolution metric would actually go down and the only ones who would be happy about it would be the customers since they don’t have to call the Service Desk.
We in IT live in a culture where repeat Incidents are an accepted norm! It cannot be a coincidence that Problem Management is consistently ranked as one of the least mature IT processes assessed in over a hundred ITIL process assessments conducted by Pink in the last five years.
Insanity: doing the same thing over and over again and expecting different results. ~Albert Einstein
The key reason that ITIL splits Incident and Problem Management into two separate processes is that they have very different objectives.
- Incident management: Restore service (fix the user)
- Problem Management: Identify the error and remove it (fix the technology)
Problem Management is typically started in the second wave of process projects due to the fact that it is a back office IT process and that it also depends on the output of a mature Incident process. Ideally Incident Management produces consistent record classification and data for trending in support of problem identification. Once Incident Management can reliably produce this level of output, the data can be trusted to support the implementation of Problem Management. Organizations approach implementation of this process in a typical pattern.
- One of the first activities the organizations implement that are traditionally associated with the Problem Management process is the “Major Incident Review” process, often referred to as a postmortem activity. The premise of this activity is to review high impact incidents (the really embarrassing ones) to determine root cause and implement measures to avoid a re-occurrence. This activity is often implemented under the management of the incident restoration process and is often led by a service desk lead or manager. This can be considered as reactive Problem Management and is further explored in the blog post ITIL Problem Management vs Root Cause Analysis
- The next level of maturity is the realization that Problem Management is a distinct process that requires its own process models, policies and resources and is supported by incident reporting and trending activities. While at this point the process is implemented at a level of maturity that has significant benefits, the majority of activity is still focused on reactive problem identification and elimination.
- The third level of Problem Management implementation typically includes the identification or proactive issues for the explicit purpose of incident avoidance. An example of this is where the patch management process is understood to be part of the Problem Management process. When a vendor signals that a security vulnerability or deficiency has been found in their product, a Known Error record is opened for the purpose of impact analysis and assessment before the incident occurs in the organization. If the Known Error is deemed to be applicable, then the Release and Change Management processes are engaged to validate, test, approve, and deploy the patch into the production environment. Obvious process dependencies include Release, Change and Configuration Management.
Jack Probst: One of my co-workers at Pink summarizes the challenge nicely in the following statement. “Perhaps Problem Management is such as challenge due to the fact that we have lost sight of the forest by focusing on the daily grind of managing trees! Or perhaps a more accurate statement is that we don’t have a forest or trees problem at all. What we have is a bark problem – we are far too close to the technology issues to even envision that we have a problem.”
Troy’s thoughts what are yours?
“A S.E.P.,’ he said, ‘is something that we can’t see, or don’t see, or our brain doesn’t let us see, because we think that it’s somebody else’s problem. That’s what S.E.P. means. Somebody Else’s problem. The brain just edits it out; it’s like a blind spot. If you look at it directly you won’t see it unless you know precisely what it is. Your only hope is to catch it by surprise out of the corner of your eye.” ~Douglas Adams