What is the difference between a major and significant change?

Dear All,

What is the difference between a Major change and a significant change?

Tags:

change management

16 Answers

Answer Vote

Hi Pradeep,

you had me scratching my head with this one.
We all know that changes are typically classified as Normal, Standard or Emergency
Normal changes go through the normal change management process whereas standard changes are typically preauthorized and emergency changes are a response to a production system outage.
(The joke in many companies is that emergency changes are "normal" :-)

Now I could not remember the difference between a major and a significant change so I looked on http://wiki.octopus-itsm.com and found the following description:

Major Changes:

The major changes involve a significant amount of preparation and work with complex situations or major expenses.

Examples:

Implementation / upgrade of a corporate business application
Moving a computer room

Significant Changes:

Significant changes involve preparation and work, evaluation, authorization and planning for change.

Examples:

The purchase and installation of a new server
The re-segmentation of network

The introduction of a new application to a small group of users

Minor Changes:

Minor changes can be evaluated and authorized outside the authority of the CAB (eg by a coordinator).

Examples:

The application of a "patch"
Installation of a new printer model

Looking forward to hearing how other classify changes!

Bob Aiello
Editor in Chief

Answer Vote

Thanks Bob!

Looking at the above description it seems to me like Significant changes only need CAB level approval ( and no need for Management approval).

Answer Vote

I think its hard to tell what is a Major change versus a Minor Change and that we have to be careful here. Sometimes minor changes can create MAJOR Problems.

To add to Bob's comments, I think you need to address the maturity of your organization. Do you have a hero or cowboy mentality. If either of these exist you run the risk of introducing errors and issues through Minor changes or just a little fix, or this shouldn't affect anyone kind of release. These have a tendency to bring a system to its knees.

Answer Vote

Thanks Joe!

As you mentioned, it is sometimes difficult to classify between major and minor changes.

But, if we have a mature CMS in an organization with good CI relationship mappings, then it would become easier to classify the changes. Like you said, a minor change might have a major impact because it may affect many interrelated CI's. If the organization has a mature and stable CMS or some reliable CI metadata repository, then its possible to classify the change as major. Without such sofistication, it would become difficult to classify changes.

~ Pradeep

Answer Vote

Hi Joe,

please take another look at what you wrote. I could agree that there is fine line between major and significant changes. I am actually polling a few of my colleagues to get their take on the difference between major and significant changes - and getting differering answers :-) .

But minor changes indicate that there is less risk involved. If a minor change causes an outage then it really was not a minor change - essentially it was misclassified.

Again there is a topology for classifying changes within the ITIL framework and that is what we are discussing here.

Bob

Answer Vote

A minor/trivial/normal/bau/pre-authorised change is:

The change that we want to get through without going through the pain of scoping it properly, getting it tested and then going through a (mature) authorisation and scheduling process for deployment.

A major/significant change is:

Any change that they want to get through................. but where we obviously wax lyrical about proper process, risk assesment, authorisation etc.

An emergency change (of course) is :

a) What happens when they get away with a minor/trivial/normal/bau change

b) What happens when one of their changes impacts on one of ours.......

</Cynical Hat>

Obviously "we" and "they" is totally interchangable to suit my perspective at the time.......

Emergency changes become the default when "the suits" decide the organisation is going to follow "Flavour of the Month-Whizz Bang" process with ridiculous lead times for hugely over engineered processes without any understanding of business reality.

ie Change is a black&white choice between "fullblown massive project process cycle" & "JFDI"

</Very Slightly Less Cynical>

In any normal conversation "Major" and "Significant" are all but interchangable so (IMNSHO) shouldn't be used as categorisations in a single scale (unless their usage is defined and agreed UP FRONT - and even then I would discourage it).

Small - Medium - Large might lead to arguments at the boundries but is easily understood by anyone

Major - Significant - Large - Substantial - Considerable - Momentus ..... that way is madness!!!!

</Head in Hands>

Answer Vote

Bob,

Thanks for your reply, what I was trying to say was what Drew presented. Change is relative to your perspective and degree of difficulty as well I think. A supposed "minor" change can sometimes be disruptive, it all depends on who initiates and categorizes that change. Business users who have been burned in the past by reckless developers may see a minor change as something major based on past experience.

Regards,

Joe

Answer Vote

Drew/Joe,

I believe that the question was actually being asked from within the perspective of the ITIL framework.

Bob

Answer Vote

Hi All,

Thanks for your responses.

As Bob mentioned, this question applies for Change Management within the context of ITIL framework.

~ Pradeep

Answer Vote

Sorry Bob & Pradeep - I stand by my answer.....

One of the reasons I dislike the "ITIL Silver Bullet" (or to be fair any "Silver Bullet")........

I may be "shouting at the devil" or "pissing in the wind" but I ALWAYS contest using categorisations that are unclear.... ITIL isn't faultless!!!

I know ITIL uses Major and Significant (I also know that its unlikely they will change it for me :-( ) but the use of these terms is so obviously WRONG (not least because it causes so much confusion)......

Just search any ITIL discussion forum for examples..... "Nobody" knows the difference so they have to make their own (local) definitions......

The general consensus is that "Significant" is "BIGGER" than "Major"........
(Sometimes this means Major needs/gets "Local CAB" approval and Significant needs/gets "Global CAB" approval etc but that is also (correctly) down to local process definition)

If your description of a Change (or Incident, Project, Implementation etc etc) based on "Categorisation" is not clear then you have to make them clear. If the words are interchangable you MUST be using the WRONG words.....

Example:

Cat 1 - Minor or Trivial change that can be carried out during working hours with little or no impact
Cat 2 - <insert words of choice> change that will have impact on multiple users in a single location/impacts users of a single system.
Such changes need to be approved by local CAB and scheduled with user agreement or outside core hours.
Cat 3 - <insert words of choice> change that will impact multiple users in multiple locations/impacts multiple systems.
Such changes needs to be approved by local CAB and scheduled with user agreement or outside core hours.

List of words to choose for insertion: Major, Significant, Major & Significant, Major or Significant

If you (just) Used Cat 1, Cat 2 and Cat 3 it wouldn't be immediately obvious (except that by using numbers there is an impllied scale - you only need to work out which way it runs) - but the definitions would clarify.

If you (attempted) to use Minor, Major and Significant - Major and Significant are patently still confusing (until you read understand the wording round approval etc).

So Minor, Major & Significant are NOT CLEAR ENOUGH to use as categorisations because "Joe Bloggs off the street" cannot possibly understand them!!! So why on earth would you use something so fundamentally wrong!!!???

Some "ITIL implementations" add another category of "Urgent" (or Emergency etc) where as some (more correctly IMHO) model that "Urgent/Emergency" changes could still be Cat1, 2 or 3 AND Urgent/Emer.

Apologies for the rant but (as you might have gathered) it is a point I feel strongly about (one of many :-) ).

Answer Vote

Hi Drew,

many of us criticise (and also praise) the guidance described in the ITIL framework. Your argument would be much stronger if you first stated what the framework suggests and then give your own opinion. In either case, this thread was about the guidance in the ITIL framework.

Many of us work in environments where we must meet audit and compliance requirements. This is best done by following the guidance in one of the industry accepted frameworks (e.g. Cobit, ITIL, CMMI) or standards (e.g. IEEE, ISO, EIA). If you want to pass an audit or comply with federal regulatory requirements then following an industry standard or framework is essential.

So I am ok with having a thread about "what's wrong with ITIL" (go ahead start it and I will participate and promote it). But lets at least demonstrate that we have read and understand the framework. You will not pass an ITIL certification exam without demonstrating that you have read and understand the material. CM professionals are increasingly being asked to play critical roles in supporting everything from nuclear power plans to life support systems. You would certainly expect doctors to know medical protocals and lawyers to know case law. CM Professionals are making salaries that demand that we show the same level of professionalism - which I am sure that you do in your day to day work!

Bob Aiello
Editor in Chief

Answer Vote

Bob

As far as I see it - I am free to give my opinion and make my contribution to the board in whatever way I see fit.

I don't think you (or anyone) should be dictating how I should make that contribution or how I could make my arguments "stronger" .... The OP (and anyone) can take from it or ignore it as the see fit.

I am not trying to pass any exams on this board - as far as I am aware its not marked!!

If the OP wanted the answer from a manual he could read the manual.....

I assumed and continue to assume that this board was a forum for discussion..... Let me know if that changes and I need to follow some strict format (above and beyond general curtesy and respect which I trust you agree I continue to show despite not always seeing eye to eye)....

Answer Vote

Drew,

everyone's opinion is always respected and desired on CM Crossroads. That is not what this discussion is about. Pradeep asked a question about an industry framework.

Bob Aiello
Editor in Chief

Answer Vote

The answer to this question is the "planned/expected" impact of the change.

A one-line change is major if it means that I can no longer click on the X in the top right corner to close any window.

It's major if users have to be retrained.

It's major if it significantly affects the quality of the product (e.g. had to change 20% of the code - that means quality problems will arise, even if it were just for a 1% performance improvement).

It's major if it requires significant changes to the way developers of the product have to work (and hence the higher possibility of bug injection).

On the other hand, a 50% performance improvement may be considered a minor change if it doesn't affect software qualtiy (e.g. only a handful of lines were changed), and it doesn't affect the user interface, other than putting smiles on faces.

A major bug fix is not a major change if it restores the product to the expected requirements. No new documentation, no training, no impact (other than removing workarounds for the bug).

So the real question is: what impact does it have on the customer? Any change to rocket launch software is a major change (subject to the ability to fully test the impact of the change). A change to Windows that introduces yet another bug will likely go unnoticed unless it's in a commonly used area. Impact on customer is not easy to measure - you have to assume the role of the customer and assess how major it is. In aerospace and defense, the revision code change indicates how major or minor it is. Unfortunately, a major change is often hidden under a minor revision code change. And it's often desireable to create a new major revision level even though the changes are minor - sorry - can't do it - too expensive!

So the bottom line: major depends on impact to the customer, the deployment and maintenance team, to the support team, to the development team, to the verification team, to the end users, etc.

Answer Vote

Generally, these terms as used in scienc eresearch have the following meanings:

Negligible change: <5%

Slight change: 5 - <10%

Minor change: 10 - <15%

Considerable change: 15 - <30%

Significant change: 30 - <50%

Substantial change: 50 - <75%

Major change: 75 - ~85%

Overwhelming change: ~85 - 95%

Fundamental change: >95%

However, note that >95% is usually rare in science research as we usually deal with around +/-5% uncertainty, unless the change in question is where that type of change is possible (e.g., whole county changes their vote from Left to Right! but that's not strictly science anymore).

You will see slight variations o fthe above qualitative classification with intended quantitative ranges in various papers, but the above I belive covers the most common one. I'd be thrilled to hear any thoughts and/or corrections. Thanks.

Answer Vote

Significant change means a major decline or improvement in the tenant’s status which does not normally resolve itself without further interventions by staff or by implementing standard disease-related clinical interventions that have an impact on the tenant’s mental, physical, or functional health status.

Major Change means any of the following: (1) introduction of a new process, new process equipment, or new regulated substance; (2) any change in safe operating limits; or (3) any alteration in a process, process equipment, or process chemistry that introduces a new hazard or worsens an existing hazard.

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.

Apr 27	STAREAST Software Testing Conference in Orlando & Online
Jun 08	AI Con USA An Intelligence-Driven Future
Sep 21	STARWEST Software Testing Conference in Anaheim & Online

On Demand	Building Confidence in Your Automation
On Demand	Leveraging Open Source Tools for DevSecOps
On Demand	Five Reasons Why Agile Isn't Working
On Demand	Building a Stellar Team
On Demand	Agile Transformation Best Practices