ITSM FAQs

Thursday, May 02, 2013

What is your ROI for RCA? (A Key Problem Management Metric)

The activities of Problem Management are, on the surface, quite similar to those of Incident Management, but the focus of these processes is very different.  Because of this, the type of measurements used to determine the efficiency and effectiveness of these processes are also different.  Most organizations place a significant focus on time-based measures for Incident Management.  This makes sense since the purpose of the process is, by definition, to restore normal service as quickly as possible.

On the other hand, Problem Management doesn’t have a similar speed statement, so what type of measure is a good representation of the health of your Problem Management process?  Ultimately, the prevention or elimination of re-occurring Incidents is a good indicator and represents savings realized by decreased load on support/operational resources.  But consider the investment made in Problem Management.  A root cause analysis (RCA), which incorporates significant effort by subject matter experts within the organization, can easily add up.

What measure can be made to ensure the use of these valuable staff time is not wasted and a positive return on investment (ROI) is realized?  Based on the assumption that a good RCA will result in an accurate root cause and change request to eliminate Incidents, I like to measure the ‘trial and error’ factor.

Scenario:
For each problem that has a RCA activity and resulting request for change (RFC), we are looking to determine if the change request that resulted from the RCA eliminated the error on the first try, thereby demonstrating that the investment in the RCA activity saved future repeated attempts to understand the error and ‘try’ a new potential resolution.


Ingredients:
1 Problem Management process with RCA activity and ability to track RFC’s against the Problem that Initiated the Change Request.
1 Change Management process with feedback to (and ideally, participation of) Problem Management via post implementation review (PIR)
1 Incident Management process capable of detecting Incident Trends and linking Incidents to a Problem


Directions:
Step 1: Upon closure of the Problem Record with a status of being permanently solved, the number of RFC’s linked to the Problem is counted.

Step 2: For a given period of time, look at all Problems that have been closed with a ‘resolved’ status and calculate what percent had a count of related RFC’s equal to 1 as shown below.  Let’s call it ‘Percentage of Problems with successful RCA.’  If we are to move away from ‘trial and error’ we should aim for a high percentage.

Monday, April 15, 2013

Project Management and ITIL:  Why can’t we all just get along?

 

One of the most common questions I get when teaching the ITIL Foundation course is around how Project Management relates to ITIL.  This question either comes from those currently leading project management or by those feeling the rigor around their organization’s project management practice and wondering how they can leverage some of the best practices from ITIL without ‘upsetting the peace’.  In fact, ITIL recognizes project management as a valuable and important part of IT Service Management and the Service Lifecycle.

 

Project management, as defined by the Project Management Body of Knowledge (PMBOK) is a temporary endeavor undertaken to create a product, service, or result.  There is a key idea in this definition that a project is temporary and finite – something used to get from point A to point B and then its done.  In a service based IT organization, the majority of projects (if not all) will do one of 3 things:  produce a new service, retire a service, or improve a current service (including any aspect of the service).  The key is to realize this and look at the ITIL Service Lifecycle to see what is happening.  Through the course of the project, many of the ITIL processes are being executed.  The strongest focus is generally in those processes from the Service Strategy, Service Design, and Service Transition phases.  The challenge now is mindset.

 

In project centric organizations, planning, funding, reporting, and ultimate value to the business is based on the projects being initiated and delivered.  Therefore, project management takes the spotlight and all other activities are subservient.  In many cases, little is considered in terms of long term support of the ongoing ‘service’ that lives on after the project has completed – at least not until closer to launch, if ever.  In a service centric organization, IT provides value by delivering services to the business that facilitates outcomes the business want to achieve.  IT does this by making strategic decisions, based on business input, around what Services need to be offered, how they will create value, what exactly they need to do and how they will be designed.  They manage the build and transition so as to minimize risk and disruption to the business, support it in operation and continually make improvements to ensure it always has high value.

 

Understanding the role of project management within ITIL requires a paradigm shift around the role of project management.  Organizations must think about moving through the Service Lifecycle and understand all of the processes working to take the business need through to a valuable, operational service.  To effectively accomplish this, project management is used manage resources, tasks, risks, milestones, and ensure all the activities defined in the lifecycle processes are completed as defined.  To transition to this level of realization however, the organization must be able to move past the thought that ‘those activities are part of project management’.  This can be difficult because in most cases, project management existed in the organization first.

 

Out of necessity, and for lack of any other guidance, many IT organizations adopted project management before ITIL existed or gained mainstream recognition.  Now that there is best practice more specific to guide IT organizations in managing Services, we must thank project management for its years of contribution and transition it to its new role in the organization.

 

Once we move beyond the ‘we where here first’ mindset, we can leverage project management in ensuring compliance with and moving us through the lifecycle processes.  The project plan can be built to include checkpoints and tasks tied to various processes.  For example, at the onset of the project, the plan may look to ensure a Request For Change (RFC) has been entered in to the Change Management process.  Before build tasks begin, project management can ensure that the RFC has been authorized (by Change Management) for build.  The project plan may also ensure that, in the design and requirements phase, the Service Level Management process is engaged to discuss Service Level Requirements or Event Management is involved to begin identifying and designing the appropriate monitoring.  At this point, the organization is using project management as their greatest partner and driving the full value of their defined IT Service Management processes.  So just like that sign that hung in my room as a kid, “A place for everything and everything in its place.”

 

 

 

 

Monday, July 23, 2012

Incident, Problem, and Change Management Metrics Benchmark - July 2012

The Pink Elephant IT Management Metrics Benchmark Service collects, analyzes and presents IT management metrics benchmarks. This Incident, Problem, and Change Management Metrics Benchmark update presents an analysis of voluntary survey responses by IT managers across the globe since early 2010. The surveys have thus far been limited to simpler metrics and the processes most broadly practiced.

The full whitepaper is available from the Pink Elephant White Papers site here.

Key points in this analysis:
Incident Management:
The number of Incidents is most influenced by (in order of influence)
1. The size of an IT organization (measured by quantity of IT Full Time Equivalent workers (FTEs) of all kinds (employees, contractors, and direct service providers’ workers))
2. The number of users, and
3. The number of years that formal Incident Management has been in practice
At least a quarter of all respondents have no documented basis for any Incident Resolution Interval.

Problem Management:
The number of new Problems recorded every month is just below the number of Active Problems already in progress (Problem WIP). This implies that the exit rate (rate at which Problems get resolved – or at least closed), must be pretty close to the number of new problems recorded every month.  The 4.4 month average problem average age at closure implies that some Problems are being closed very quickly – perhaps too quickly.
Change Management:
Among the several interesting metrics here is an average 90% Change Executed Right First Time (no rollback or cancelation, and as scheduled). This appears to indicate that 10% of all changes fail in at least 1 of the 3 ways - a quite disappointing benchmark.

This is an update on the Pink Elephant IT Management Metrics Benchmarks Service. Please submit your organization’s data! The more participants in our on-line metrics benchmark surveys, the better! The surveys are available at https://www.pinkelephant.com/MetricsSurvey/.

We welcome your feedback. Please comment on this blog or the whitepaper to let us know what you think, or write us at .(JavaScript must be enabled to view this email address).

Wednesday, January 25, 2012

Situation Constraints - Which To Fix First - The PQR Blog

Pink Question Reflection (PQR) Blog #3

Pink Elephant has been collecting Attitude, Behavior and Culture (ABC) exercise data in our classes and consulting engagements for almost a year now and have collected well over a thousand data points. The question for this blog is: “What Attitude, Behavior, and Culture situations did we expect our students and clients to select in their ABC exercises that are NOT being selected?”

Background: Management of people and partners requires an understanding and careful management of Attitude, Culture, and Behavior (ABC). I assert that Behavior is largely the result of Attitude and Culture. The ABC exercises use a deck of 57 cards with words and pictures describing various IT and business situations classified in four principal areas: Attitude, Behavior, Culture, and Stakeholders; and five secondary areas: Partners, People, Performance, Process, and Product. The participants work in small groups to select one card with the description that best fits their organizations’ current situation. These are the Problem situations. We follow-up with a second exercise asking the participants use the cards again to select the situation that best represents the resistance they will encounter when attempting to improve the organization to eliminate or mitigate the Problem. These are the Resistance situations. We tally the selected situations to better understand the Problems and Resistance factors in individual IT organizations and among IT organizations as a whole.

Back to the question: Of the 57 situations available, many we expected to be selected have indeed appeared in the top 10 lists below. I had four culture situations on my sure-to-be-high-profile-issues list based on experience and cultural bias. The top four culture situations on my list have a strong and unfortunate association with management practices – particularly among the many managers firmly cemented in place at the peak of their Peter Principle arc. The basis for my cultural bias is centuries of observation expressed in literature and art in cultures around round the world presenting managers as ambitious fools. Current pop culture examples include Scott Adams’ Pointy Haired Boss (PHB) in the Dilbert comic strip and the managers in the US and UK The Office TV comedies. Surely the inappropriate cultures these managers establish are reflected in our ABC exercise data!

I was very wrong. The cultural situations I most expected to be represented are NOT reflected in the data! (But wait! If they cast no reflection in the data, can we stretch and mix the metaphor even further and infer that these inappropriate work place cultures are blood sucking vampires creating new generations of poor management that can live forever? Perhaps, but better not to go there.) Here are the actual results from more than a thousand exercise data points:

“Hero culture” has never been selected as a Problem situation, and was selected only two times as a Resistance situation.
“Blame culture” Hah! Tied for 10th place among Problems, but—- was never selected as a Resistance factor.
“Punishment culture” selected only once as a Problem and never for Resistance  
“Avoidance culture” selected only eight times as a Problem and four times for resistance.

Does this mean that these situations can safely be ignored? I do not think so. However, of all the things that are not as favorable as they could be, these (except perhaps Blame) are noise - windmills tempting our quixotic spirit. More important, their relative absence tells us that the common complaints about <insert insulting adjective here> managers are relatively unimportant and that time, political capital and energy spent attempting to improve them is probably wasted. Best to focus on the greater constraints we have uncovered in our ABC exercises listed at the bottom of this blog.

We have been blogging and talking about our ABC data and published a Translating Knowledge Into Results white paper in May, 2011. Since then the data has yielded more insight - and sometimes surprising - observations and findings such as the above. The implications and application of the findings will be discussed in sessions in our 16th Annual International Conference, in Las Vegas in February, and at our 4th Annual Conference in Kuala Lumpur and Singapore in July.

The most current tally of the most selected Problems and cultural Resistance areas are listed below in order from most selected to least selected.

The situations most selected in our ABC Problem and Resistance exercises by ABC area

Most selected Problem situations:

Total Problem Behavior situations (41% of all responses)
Problem Behavior situations in the top 10 (23% of all responses)
• Everything has the highest priority….according to the users
• Maybe we should have tested that change first
• The solution the customer sees isn’t the one that IT sees
• Never mind about following procedures….just do what we usually do
• Throwing solutions (ITIL) over the wall and HOPING people will use them

Total Problem Culture situations (25% of all responses)
Problem Culture situations in the top 10 (19% of all responses)
• Not my responsibility
• Plan, Do, stop….no real continual improvement culture
• Them and Us culture—opposing and competing forces
• Internally focused
• Blame culture

Total Problem Attitude situations (25% of all responses)
Problem Attitude situation in the top 10 (11% of all responses)
• (IT has) no understanding of business impact & priority

Most selected Resistance situations:

Total Resistance Behavior situations (51% of all responses)
Resistance Behavior situations in the top 10 (43% of all responses)
• Never mind about following procedures….just do what we usually do (12%!)
• No management commitment
• Everything has the highest priority….according to the users
• Throwing solutions (ITIL) over the wall and HOPING people will use them
• We don’t measure our value contribution to strategy
• The solution the customer sees isn’t the one that IT sees
• Saying “Yes” but meaning “No”

Total Resistance Attitude situations (25% of all responses)
Resistance Attitude situations in the top 10 (12% of all responses)
• ITIL never work here
• (IT has) no understanding of business impact & priority

Total Resistance Culture situations (16% of all responses)
Resistance Chosen situation in the top 10 (3% of all responses)
• Plan, Do, stop….no real continual improvement culture

Thursday, January 12, 2012

Pink Elephant IT Management Metrics Benchmark Service Blog – Change Mgmt Update December, 2011

Pink Elephant IT Management Metrics Benchmark Service Blog – Change Management Update December, 2011

This is an update on the Change Management Benchmarks from the Pink Elephant IT Management Metrics Benchmarks Service. With more Change Management (CHG) Benchmark Survey responses in hand, we have new Benchmarks presented below. The more participants in all our metrics benchmark surveys, the better!

We welcome your feedback. Please comment on this blog post to let us know what you think.

Observations:
> The newer data includes data from a broad array of organizations. While the mean number of RFCs has dropped slightly, the median number of users supported has more than doubled and the mean has grown by 30%.
> The average RFC Life Expectancy (Interval from Submission to Closure) is 3 to 5 weeks (median and mean, respectively). At this time, we take this as an indication that organizations’ Change Control requires significant lead time to ensure adequate notice to prevent conflicts.
> The Emergency RFCs percentage has not changed and remains fairly low.
> Correlations:
- IT Staff FTEs and RFCs per month, .72 – This relationship strengthened by 10%. IT FTEs are indicative of the size of the IT environment. Certainly the larger the environment, the more changes would be going on.
- % RFCs Right First Time and % RFCs without processing issues, .69 – This reinforces the expectation that organizations with well managed changes enjoy high change success rates.
- % Emergency RFCs and IT Staff Size, .35 – The fact that this correlation is lower than the RFC correlation is a sign that larger IT environments have proportionately fewer Emergency Changes than smaller environments.
- % RFCs Right First Time and Years Change Management Deployed, .26 – This correlation dropped from .69 in the earlier data undermining the assertion that the longer an organization has been managing changes in a defined process, the better the change success rate.

Change Management Metrics Benchmarks
RFCs per Month: Median: 525, Mean: 1,791, Min: <50, Max: >5,000
% of RFCs with No process Issues: Median: 93%, Mean: 86%, Min: <70%, Max: >97%
% of RFCs Completed Successfully the First Time as Scheduled: Median: 93%, Mean: 88%, Min: <80%, Max: >97%
% of RFCs that are Emergency RFCs: Median: 7%, Mean: 9%, Min: <1%, Max: >15%
RFC Submission to Closure Interval (days): Median: 22.5,  Mean: 37.6, Min: <3, Max: >120
RFCs per Month per Service User*: Median: .03, Mean: .23, Min: <.0001, Max: >3.18
RFCs per Month per IT FTE*: Median: 1.5,  Mean: 1.9, Min: <.33, Max: >6.67
*based on heuristics drawn from survey response data:

Attributes of Survey Participant Organizations
Years Change Management Process Has Been Deployed: Median: 3, Mean: 5.5, Min: <2, Max: >10
Service Users Supported: Median: 40,000, Mean 101,500, Min: <100, Max: >300,000
IT Full Time Equivalent Workers (IT FTE): Median: 125, Mean 439, Min: <10, Max: >1,500
Industries: Financial and Insurance (25%), Public Administration (20%), Manufacturing (12%), Other (43%) [Construction, Education, Health Care & Social Assistance, Information, Retail Trade, Transportation & Warehousing, Utilities, & na]
Locations: Europe, Latin America, North America
Data qualification/rationale:
The metrics and the organizational attributes in the CHG survey responses cover a wide spectrum. All survey response options have been selected by participants with no strong bias to any one response to any question. Medians and Means are approximate as they are based on range mid-points and estimated minima and maxima where required.

Thursday, November 03, 2011

Changing People with Process Product & Partners to get Performance

I recently weighed in among other commenters on Stephen Mann’s blog on ABC of ICT blog over at Forrester. ABC stands for Attitude, Behavior, and Culture, and ICT for Information and Communication Technology. Stephen was ruminating on the relative importance of the 4 Ps (People, Process, Products, Partners) to get Performance, and pointing out that People (and sometimes Partners’ People, I might add) are the most difficult to modify and often most in need of modification to improve performance. The ABC exercises identify the symptoms - the peoples’ “worst practices”.

There was a common thread among the many experts and friends who commented on the blog - the order in which the Ps should be addressed. This is interesting, but jumps past the question; How do we change the people?

We often get this question from clients engaging in our ABC exercises at Pink Elephant. In the ABC exercise we are exposing and identifying the people problem symptoms so we can accept that we have a problem. Step 1 in the famous Alcoholics Anonymous 12 step method. We are not providing solutions to the problems we have identified.

A clear goal and a commitment by the people to achieve it - that is what makes things like LEAN, TOC, and ITSM work. Rob England (one of the commenters and the IT Skeptic) was correct in citing John Kotter as source of help. Kotter does give us the signposts. A key point he makes is that the change requires a Leader (defined here as the one chosen and accepted by the led - Konosuke Matsushita was the object of Kotter’s study) and a guiding coalition who can articulate the goal and pull people to commit themselves and make their way to the overarching organizational goal. Organizational optimization, not local optimization.

There are many change methodologies that cover both organizational and individual change. One of the older methods used by businesses is ADKAR. This method covers the change/grief cycle at both the organizational and individual level helping managers and supervisors transform themselves and all the people in the organization with Awareness, Desire, Knowledge, Ability and Reinforcement. This method focuses on changing individuals AND the organization as a result. As you might expect, it takes a lot of personal relationship building, communication and team work - not terribly strong suits in IT people promoted into management on the basis of their technical performance. For IT organizations the ABC solution opportunities rely on building this skill set - whether there is a transformation program afoot - or not.

Thursday, October 06, 2011

What Is Happening With ITIL Exams Related To The 2011 Edition?

As you have heard in the ITIL space a new edition of ITIL was published on July 29, 2011. This is an update to what was known as ITIL Version 3, now commonly referred to as ITIL 2007 Edition, the original year of publication.

As a result of the release of this edition of ITIL, syllabus documents, including book references, were updated and aligned. These syllabus documents came into effect on August 8, 2011. The Authorized Training Organization (ATO) community has been given until January 1, 2012 to update their courseware to these syllabus documents.

Knowing that certification exams reflect the course objectives and content as outlined in the syllabus - exams have and are changing. Because of the time between the early August release of the 2011 syllabus documents the effective date of the new exams in January, a transition period was established. Between August 8, 2011 and January 1, 2012 a set of “hybrid” exams are in play. This means that these exams are matched to courses developed for the 2007 edition of the relevant syllabus, and courses developed against the 2011 edition of the syllabus documents. These exams were put into production on August 8, 2011.

On January 1, 2012 a new set of exams will be brought live. These exams will be fully and solely aligned to the 2011 version of syllabus documents and will reference only material from the 2011 Edition of ITIL. All ATOs must align their course materials to the new edition by January 1, 2012 to meet accreditation requirements and ensure successful examination experiences for their students.

So student attendees will notice no difference during the transition period and will seamlessly move to the new edition in January.

This applies to ITIL Foundations, the 4 Intermediate Capability courses (OSA, RCV, PPO, SOA), and the 5 Intermediate Lifecycle courses (SS, SD, ST, SO, CSI).

Wednesday, August 31, 2011

Pink Elephant IT Management Metrics Benchmark Service Blog #2

New Change Management and Updated Incident Management Benchmarks

We now have preliminary Change Management (CHG) Benchmarks and updated Incident Management (IM) Benchmarks based on the initial responses to the Change Management Metrics Survey and additional participation in the Incident Management Metrics Survey. The more participants in all our metrics benchmark surveys, the better! Thank you to the many that have participated.

We welcome your feedback. Please comment on this blog post to let us know what you think.

Change Management Metrics Benchmarks

The Change Management survey responses have been less diverse than the Incident Management responses. There are a few surprises in the early data. It remains to be seen if the values hold as the responses become more diverse.

Interesting Change Management metric and attribute correlation coefficients include:
> IT Staff FTEs and RFCs per month, .66 – This is similar to the correlation of IT FTEs and Incidents per month. This relationship is surprising in that it is only .66. IT FTEs are indicative of the size of the IT environment. Certainly the larger the environment, the more changes would be going on.
> % RFCs Right First Time and % RFCs without processing issues, .56 – This implies that organizations that have well managed changes also enjoy high change success rates.
> % RFCs Right First Time and Years Change Management Deployed, .69 – This remarkably strong correlation suggests that the longer an organization has been managing changes in a defined process, the better the change success rate.
> % Emergency RFCs and IT Staff Size, .55 – This correlation is similar to the RFC and Incident correlations with IT Staff Size. The fact that this correlation is lower than the RFC correlation is a sign that larger IT environments have proportionately fewer Emergency Changes than smaller environments.

Incident Management Benchmark Update

The only significant Incident Management correlation coefficient is the number of IT FTEs and Incidents per month at .66. This is not terribly surprizing, as IT FTEs is an indication of the size of the IT environment, and a larger environment would be expected to have more incidents than a smaller IT environment.

It is still surprising to see that despite the increased number of respondents, the proportion of the participating organizations with no documented Incident Resolution Interval Expectation us remaining high at 20%.

Data qualification/rationale:

The metrics and the organizational attributes in the ITSM Benchmark survey responses cover a wide spectrum. All survey response options have been selected by participants with no strong bias to any one response to any question. Medians and Means are approximate as they are based on range mid-points and estimated minimums and maximums where required. Since the survey uses non-linear ranges to ease data gathering and response by survey participants and except where the response options are narrow, there is a fairly large difference between the Median (center point of all responses ordered by value) and the Mean (normal average: total of all responses divided by the number of responses) drawn from the survey responses.

 

Friday, July 29, 2011

Pink Elephant IT Management Metrics Benchmark Service Blog – Incident Management

Earlier this year, we launched the Pink Elephant IT Management Metrics Benchmarks Service. We now have Preliminary Incident Management (IM) Benchmarks based on the initial responses to the Incident Management Metrics Survey. The more participants in all our metrics benchmark surveys, the better!

We welcome your feedback. Please comment on this blog post to let us know what you think.

One surprising item is the Basis for Incident Resolution Interval Expectation with almost a quarter having none documented. The rest rely on Standards and/or SLAs.

Data qualification/rationale:

The metrics and the organizational attributes in the IM survey responses cover a wide spectrum. All survey response options have been selected by participants with no strong bias to any one response to any question. Medians and Means are approximate as they are based on range mid-points and estimated minimums and maximums where required. Since the survey uses non-linear ranges to ease data gathering and response by survey participants and except where the response options are narrow, there is a fairly large difference between the Median (center point of all responses ordered by value) and the Mean (normal average: total of all responses divided by the number of responses) drawn from the survey responses.

Monday, June 13, 2011

After June 30 can I still bridge my Service Manager certificate?

If you achieved your Service Manager certificate under V1 or V2 and haven’t completed the V3 Manager’s Bridge certificate there is still a unique path to ITIL Expert certificate after the Manager’s Bridge is withdrawn on June 30.

First, in order to be eligible to take any of the V3 Intermediate courses, you must hold the V3 Foundation certificate. You may have taken this under the Foundations Bridging option previously available.

Then you must complete either the Service Strategy OR the Continual Service Improvement certificate from the ITIL Intermediate Lifecycle stream.

The third and final component of this option is to complete the Managing Across the Lifecycle course and certificate.

This path is available only to holders of the V1 or V2 Service Manager certificate. Please note that the credit system does not apply to this bridging option.

For additional information on the complete ITIL Qualification scheme visit the Official ITIL site at http://www.itil-officialsite.com/Qualifications/ITILV3QualificationScheme.aspx

Wednesday, June 08, 2011

How do organizations achieve successful IT transformations?

Some projects to transform IT organizations into high customer satisfaction service providers have been completed, but more have been cancelled before they were completed. Of those completed, a subset achieved the desired results. Why?

Thousands of well intended people have poured their hearts and souls into IT transformation efforts to make their internal IT organization the preferred supplier of IT services for their business customers. Most fail, and as their reward, they are replaced either by new employees/management or 3rd party service providers. Why?

Of those that succeed, maintaining a preferred supplier relationship against competing providers is not as simple as just meeting SLAs. Why?

Martin Erb of Pink Elephant will examine these questions in a series of whitepapers.

Click here for the first in the series.

Monday, May 30, 2011

In implementing a dashboard for Incident Management, what type of metrics should be considered?

There are many metrics you can collect for incident management, all of which will have value. Start by focusing on a few basic ones and add as needed and as these prompt questions or dialogue:

• How many Incidents logged for the period
• How many open Incidents at close of period
• How many logged Incidents by priority
• How many escalated Incidents
• How many Incidents remained open past their SLA target

Friday, May 27, 2011

What classification of companies use ITIL and how many processes do they implement?

With classification being a general term, we’ll address that from two perspectives: industry vertical and organization size. The ITIL guidance is in use today across all industry verticals including Finance, HealthCare, Education, Retail, Manufacturing and many others. It has been implemented in small to medium sized businesses, as well as large international ones. The vast majority of organizations focus on three processes: Incident, Change and Problem Management, with more mature organizations beginning to move into processes like Service Level, Information Security and Release & Deployment Management.

Wednesday, April 13, 2011

CI Change Approvers

Are there any standards on where CI based approver data is stored?  For example, I am upgrading patch on server 123, I select the CI 123 and the appropriate approvers come in. Those actual approvers are stored where to be pulled in? or does it matter?

The real question is: Should a CI record contain an attribute indicating what person, team or role can authorize changes to the CI? And if so, where?

The answer is, Yes. Usually it is the role that is accountable for the CI’s contribution to an OLA/SLA/UC. The label may be something like Owner, Support Team/Group, etc. I’ll just use Owner here.
The Owner of CI #X may not have sole authority to authorize a change. Depending on the Change policies and controls in the organization, owners of other CIs that have direct or indirect relationships to CI #X and therefore are put at risk by the change to CI #X may also have to approve the change to CI #X. The rules for the breadth and depth of change authorizations are usually configured into the Change Management tool and are configured based on Risk, Impact, Urgency and perhaps other factors.
The Owner can be quite difficult to maintain on organizations with high turnover or lots of CIs. Tools often solve this by using Roles in the CI records, and the person in to Role - and his/her seconds, etc. - are administered in an Organization module where personnel, teams, escalation paths, etc. are maintained along with on-call schedules, etc.

Friday, January 07, 2011

If my PMO is run by a PMP why do I need PRINCE2 in my organization?

The Project Management Body of Knowledge (PMBOK) is based in a set of processes and knowledge areas. It is just that, a body of knowledge meant to provide a framework of best practices for individuals to use as they manage projects within their organizations. Training within this body of knowledge takes on an individual focus, generally aimed at those individuals managing or “running” the projects.

PRINCE2 is different than PMBOK, but they can and do work together. PRINCE2 is a methodology, and is therefore much more prescriptive in nature. The focus is much more organizational and a central intention is to provide a governance process structure to business projects within the organization. Its prescriptive nature provides a series of checklists to be used within the governance structure. All projects are meant to be connected to the business drivers. The PRINCE2 methodology is meant to ensure this connection throughout the life of the project.

PRINCE2 does provide consistency of language, words, and terminology for all project participants and stakeholders. This outcome is often listed as a second significant benefit to training project participants and stakeholders.