CMMI Version 3.0, the newer version of CMMI which adds three new domains to the CMMI model

CMMI Version 3.0 or V3.0 or v3 is the newer version of CMMI.

The newer version, CMMI Version 3.0 or V3.0 or v3, adds three new domains to the CMMI model

• Data management
• People management
• Virtual work

The previous version of CMMI, CMMI Version 2.0 or V2.0 or v2, was released in 2018.

The central idea behind the emergence of CMMI V2.0 was to provide a single, extensively comprehensive and truly integrated framework with a highly fluid and customizable structure.

This would, by design, allow plug and play of the various model components to better align with the business needs and operating model of any organization.

The above, in turn, effectively offered organizations lot of flexibility to "pick and choose" what they thought was the appropriate combination of the available domains in the CMMI model.

CMMI V3.0 was released in Apr2023 and it further extends the footprints of the CMMI model.

The current major content updates to the CMMI model brings three new domains into the fold - data management, people management, and virtual work

Data management domain

• Provides guidance and best practices for managing the complete life cycle of data management in an organization
• The scope of applicability runs through the identification of the need to collect certain data to defining the operational measures, data collection, storage, validation, processing, analysis and use to its disposal and archiving.
• This, interestingly, can be viewed as the bonsai version of the erstwhile DMM model which was discontinued/retired effective Jan 2022.

People management domain

• Provides guidance and best practices for managing the organization's workforce and its alignment with the business objectives and execution strategy
• The scope spans through setting up the mechanisms and tools to enable people using defined processes to deliver against the business objectives.
• This, interestingly, can be viewed as the bonsai version of the erstwhile PCMM model which was discontinued/retired effective Jan 2022.

Virtual work domain

• Provides guidance and best practices for optimally leveraging virtual, remote and hybrid arrangements for managing work
• The scope spans through different combinations of varied scenarios like work from anywhere, work from home and work at office.

The recent model content updates got released in April 2023. 

The first set of interested existing lead appraisers are expected to get their credentials upgraded and become certified lead appraiser for CMMI V3.0 by Q4 2023.

If this happens as planned, appraisals for new domains will start getting accepted from Q1 2024.

The three traditional domains of new product development (DEV), service delivery (SVC), and supplier management (ACQ) continue to be there. 

There were two other domains which were added earlier - security and safety. 

And, after the latest model content updates, there are three more domains - data management, people management, and virtual work.

So, with the latest additions, CMMI V3.0 now encompasses best practices across eight domains.

In summary, it can be safely said that CMMI has gradually, but truly, evolved into a full-fledged maturity framework.

In its current form, Version 3.0 of CMMI would serve as an effective tool that can be flexibly leveraged by organizations to drive their enterprise-wide performance improvement and business excellence programs.

CMMI Model and CMMI Appraisal in CMMI V2.0 - Some Interesting Thoughts

CMMI model and CMMI appraisal have undergone several changes in CMMI V2.0, the latest version of the CMMI product suite.

How effective these changes are and how much thought has gone into these changes is anyone's guess.

The key point, however, is that the CMMI V2.0 is being projected as a bettered version of the CMMI suite, which again is open to debate.

CMMI V2.0 or, for that matter, any other model or framework are essentially benchmarking tools and are as good as the business value they create for an organization.

CMMI V2.0 has laid strong emphasis on business objectives and business performance, and rightly so.

So, changes and improvements that can further improve and deepen the alignment of CMMI V2.0 with business priorities would make it even better.

This post dwells upon two such aspects that can help in doing that.

CMMI Model Online Portal

The first aspect is related to the CMMI model online portal.

One of the key things in CMMI V2.0 is that the CMMI model is available as an online portal which is probably getting updated very frequently.

This is being cited as a strength.

Unfortunately, that view is not logically sound.

Any model or framework serves as a reference and can be used to benchmark its usage in a specific situation against the accepted base which is the model or the framework itself.

Models can change and do change but the changes should get introduced in a thoughtful manner and only at periodic intervals separated by a reasonable time gap.

The new version of a model should come out only as per the above principle unless there is some problem or "bug" in a particular version of that model, making an immediate "rectification" release necessary.

Frequent changes lead to a situation of trying to hit a moving duck, which is never a good idea as far as benchmarking is concerned.

Interestingly, one of the types of CMMI appraisal is now called as "benchmarking" appraisal.

So, in a way, the above is apparently a crucial structural challenge with CMMI V2.0 appraisal.

An organization starts its CMMI V2.0 implementation with CMMI model around a certain time duration.

When it is time for appraisal, let us say after 2 years, the extant copy of CMMI model might be different.

Incidentally, the CMMI model portal has the provision to download a pdf copy so it is possible to store a copy of CMMI model, as it was, at a given point in time.

The question that is but natural to be asked is:

"Which copy of CMMI model should be used for appraisal - the one from two years back or the one which is there now?

In case the changes introduced are significant, then ensuring all of them are adequately incorporated will be a logistics and coordination challenge for the organization.

But in case the changes are not significant, then this is not an issue per se.

That, then, brings up another point.

If the changes are not significant, why to change frequently?

Would it not be better to accumulate the change requests and improvements from actual experiences shared by the users and other sources and bring a new version?

And do that as a strategic event and not as a routine procedure.

The earlier arrangement, where a model version used to get released at a certain time interval was a better one for the model users and implementers.

The online portal would still be useful for the model developers and model maintainers as they can use it as a work in progress copy of the next version of the model.

Change requests and improvements can get constantly incorporated by the model developers and model maintainers.

And just like code-freeze in case of software development, there could be a content-freeze in the model development cycle, where the next version is baselined and formally released.

CMMI Appraisal Sampling

The second aspect is related to CMMI appraisal sampling.

The sampling now is done using a method that is called as a randomly generated sample (RGS).

In this case, any project can ger selected.

In CMMI V2.0 there is heavy emphasis on business objectives and business performance.

Given that, sampling should also reflect the same line of thinking.

What should happen ideally is that those projects which are critical to business should be a part of the appraisal.

The factors that typically govern “critical to business” are:

• Importance of the customer of the project - this is influenced by both current earned revenue and future projected revenue from that customer
• Size of the project - large projects are more complex and challenging and their success has a proportionately higher impact on the organization's success
• Project in a new vertical or a new domain - such projects can help create huge, sustainable revenue streams in the future
• Strategic value of the project - this would be driven by the view of the executive management in terms of the long-term survivability of the organization

In case the above factors are not being considered in sampling, then the final sample would not be aligned with business priorities.

But in case the above factors are already being considered in sampling, then this is not an issue per se.

And the final sample would still be the same.

That, then, brings up another point.

If the final sample would still be the same in both cases, why to have this new method?

Would it not be better to let the sample be aligned with business priorities and in fact, bring in, or further improve the mechanism to ensure projects that get selected are critical to business?

Why a Clear Understanding of Convergence is Key for Enterprise Survival?

Enterprises comes into existences to address certain basic needs of the society.

However, if an enterprise fails to match the changes in the society, step by step, it will not survive.

What is the key competency that ensures an enterprise will survive?

The answer is convergence.

Beneath the different ideas and trends that become popular in the society at different points in time, there is something more fundamental to the way society functions.

There are certain basic needs of the society that have been like that since ages and will remain so forever.

What are these basic needs?

These basic needs are related to physiological and psychological needs of human beings.

After all society is nothing but human being put together.

The physiological and psychological needs operate at the most fundamental level.

The way to fulfil them have changed over time and will continue to evolve but these needs will never go away.

It is a fact that the ideas and trends that have been used to address the basic physiological and psychological needs have evolved and will continue to do so.

If that be the case, how can an enterprise survive this change?

That is where the principle of convergence kicks in.

What is the meaning of the term convergence?

Convergence means focusing on the fundamental essence of something.

The fundamental essence is nothing but the physiological and psychological needs of human beings.

Since they never change, if an enterprise can link the exact physiological or psychological need behind an idea or a trend, it will prove to be an asset for its survival.

An enterprise which has a clear understanding of convergence of ideas and trends will be willing to not only change if needed to keep up with the change forced upon it but also bring changes to the table.

The above will ensure enterprise survival.

For tomorrow.

And forever.

Busting the Hype around TQM and the Continuum of Enterprise Excellence (EEX)

TQM is a concept that originated in the 1950s in Japan.

However, it has its roots in the American way of looking at things since the founding father of TQM, Deming, was an American.

In the beginning, total quality management or TQM was meant to take care of certain aspects in an enterprise.

Unfortunately, over last several decades, TQM fans have tried to project it as something more than it was meant to be.

That is one of the key reasons behind the problem with TQM’s positioning.

For the fans, the key principles of TQM are like biblical truths.

These principles are, however, not original, or innovative.

They have their basis in the concepts and theories related to general management.

Like there is nothing original or innovative about following a process-based approach, using data for decision-making, etc.

Also, the use of the terms total and quality in TQM is quite misleading.

Total in TQM means all parts of the enterprise and the focus is on how the individual parts support quality of the products and services.

That is a problem since for an enterprise to succeed the various parts need to focus on many other aspects much beyond the quality of the products and services.

Quality in TQM pertains to how well something functions and how every process in every part of the enterprise should work at its optimal best.

That is another problem since it extends the scope of the term quality to mean everything under the sun beyond its core meaning, where quality means quality of design or quality of conformance to the design.

The core need of any enterprise is first to survive and then to grow, organically or otherwise.

The way to achieve the above is quite simple - remain competitive and stay profitable.

For example, Nokia or Kodak were probably doing perfect as far as TQM principles go.

What was missing was the lack of right strategy due to serious misreading of the shifts in the competitive landscape and market dynamics.

At this point, TQM fans will jump and say, "doing that is also a part of TQM".

Well, not really.

That way everything that goes right is due to TQM and everything that does not go right is due to lack of TQM!

That is quite ludicrous.

Achieving enterprise success is hard. 

And sustaining the success achieved is even harder.

The key thing for enterprise success is to focus on enterprise excellence (EEX). 

Achieving and sustaining EEX is inextricably linked to and profoundly dependent on two broad aspects:

• Enterprise Strategy - Setting and calibrating the direction and strategy the enterprise will follow in the near and distant future which includes markets the enterprise will operate in and product/services it will sell
• Enterprise Operations - Adjusting and optimizing the effectiveness and efficiency in the operations of the enterprise at the overall level as well as in its various parts which includes the quality of products/services it will create

It is certainly true that application of TQM is beneficial to ensure quality of products/services.

However, there are many other aspects that can impact enterprise success.

For example, the way the enterprise does cash flow management is very important to ensure its profitability and solvency.

Ask any CEO or CFO and they will tell the same.

But that has nothing to do with TQM.

As a matter of fact, the overall use of TQM is limited to specific aspects of the continuum of EEX ecosystem.

It can be said that TQM is more of an engineering and technical thing that uses lot of general management practices to strengthen itself.

It should, however, not try to become overarching like EEX.

Many enterprises focus on blindly putting TQM in place while missing the larger EEX context.

Focusing on TQM for TQM sake may be a good idea for TQM advisors, TQM consultants, TQM trainers, TQM program in-charges, etc. but not for EEX and certainly not for the enterprise.

Like TQM talks about customer first and primacy of process.

There is a lot that is wrong with that.

Sometimes customers may not be reasonable and fair and need to be dealt with accordingly.

From EEX standpoint, the enterprise may even refuse to continue its association with such customers.

Using standardized processes is fine as far as the routine operational activities and transactional tasks are concerned.

However, for innovations and strategic initiatives there cannot be standardized processes.

From EEX standpoint, for such things the enterprise may employ certain philosophies and principles and not be hung up on using a defined process because there would be none.

Unfortunately, the TQM fans think that TQM is the be all and end all of everything.

That is not a correct view.

Like the other methods and tools, TQM has its place in the continuum of EEX ecosystem and can be effectively leveraged when used in an appropriate manner in the right context.

Quality 5.0 Should Take Quality Beyond the Quality in Quality 4.0

Quality 5.0?

Now what is this Quality 5.0?

And how should Quality 5.0 take Quality beyond the Quality in Quality 4.0?

An earlier post titled What is Quality 4.0? What Does the 4.0 After Quality in Quality 4.0 Signify? dwelt upon the salient aspects of Quality 4.0.

Quality, like any other discipline, should work towards the betterment of the world.

Quality 5.0 should attempt to take Quality a notch higher in the above journey.

Quality 5.0 is still in a formative stage and yet to take its final shape.

Conceptually, however, Quality 5.0 should bring forth certain novel aspects quite clearly and very forcefully.

Beyond systems that behave intelligently, the need of the world is to have systems in place that will act in the right manner, no matter what.

Hence, Quality 5.0 should focus on doing right things than just doing the things right.

For example, a robot can be created with all the AI/ML algorithms to work like a house servant.

The robot is expected to take care of certain needs of the members of the family in whose house it gets deployed.

However, the robot would need more than the AI/ML algorithms to develop empathy when working as a house servant.

Not only that, but such robots should also be made available to those who need it like a physically handicapped person and not only those who can afford it.

Quality 5.0 should go beyond quality of product to its availability to those who have a real need for it.

That way Quality 5.0 will need to imbibe principles of economic equality and not be limited by the principles of economic cost.

Quality 4.0 is supposed to focus on making machines acquire higher level of IQ.

Taking things beyond, Quality 5.0 should focus on making machines acquire higher level of EQ.

It is also important to note that Quality 5.0 will require intervention from the legal authorities and other designated agencies to ensure things are made available based on who needs them the most.

And not who can pay the most!

That is going to be a sea-change in terms of how the world is run.

The objective will be the collective betterment of all living beings and not just human beings.

The ultimate objective will be the betterment of the world around us.

Better for human beings.

And better for all other living beings too.

In a nutshell, Quality 5.0 should help bring sharp focus on three critical aspects:

• Systems develop empathy
• Needs drive availability
• Concern for all living beings

Quality 4.0 will certainly make things better.

Quality 5.0 should help take things much beyond that and make them even better.

What is Quality 4.0? What Does the 4.0 After Quality in Quality 4.0 Signify?

Quality 4.0.

Industry 4.0.

XYZ 4.0.

Put 4.0 after any term and what you finally get is a heady cocktail.

Like all other domains, Quality also seems to be undergoing this transformation.

What is Quality 4.0?

What does the 4.0 after Quality really signify?

4.0 as a concept, in a simple sense, means the use of systems that learn on their own using artificial intelligence (AI) and machine learning (ML) at its foundation.

AI and ML are the hot buzzwords these days.

Talk to any and every Tom, Dick and Harry in the corporate world and after some time into the conversation you will hear AI and ML.

Talk to any school or college student and after some time into the conversation you will hear AI and ML.

What is AI?

What is ML?

Let us first understand these two in simple terms and in a layman’s language.

AI or Artificial Intelligence

• The purpose of AI is to initially replicate and eventually replace the human intelligence being used for decision making while running a process.
• For example, a train can be made to start and stop based on the same criteria a human driver will typically use before making such a decision.
• AI is meant to go beyond the realm of routine decision making to "intelligently" figure out the right decision even if something in the process or environment changes and that too suddenly.
• Suppose the train in the example above is ready to start since all doors are closed, green signal is on and all those standing on the platform are at a safe distance from the train. Also suppose, at that instant and suddenly one of the persons standing on the platform jumps on the tracks right in front of the engine. So how will you make sure the train doesn't get started?
• The way the above will be ensured is where AI can supposedly play a role. The supposedly here is a big SUPPOSEDLY because there are possibly infinitely many possible scenarios like this one.

ML or Machine Learning

• The purpose of ML is to make a system behave "intelligently" without relying upon human intelligence which may be getting used otherwise for decision making while running a process.
• For example, historical data on all train starts can be used to identify patterns, trends, decision trees and heuristics in conjunction with relevant real-time data and information to aid a train system to decide whether it is right and safe to start the train at a given point in time.
• ML sits at the back end of AI and is the thing that makes the system behave "intelligently" and figure out the right decision even if something in the process or environment changes and that too suddenly.
• Suppose the train in the example above is ready to start. Also suppose, at that instant and suddenly one of the persons standing on the platform jumps on the tracks right in front of the engine. ML will use historical data to indicate that the train can get started. It will, however, use real-time data to cause an interruption so that the final decision is right and safe. But what will that take?
• The way the above will be ensured is where ML can play a role and direct the AI module built into a system to make it behave "intelligently".

Note:

• It is fine to say that a system becomes intelligent with AI/ML 
• However, a system does not "become intelligent", rather it starts to "behave "intelligently"
• So, it is better to say that ML induces AI in a system which makes it behave "intelligently".

With that backdrop, let us come back to Quality 4.0.

Quality 4.0

In fact, after having understood AI/ML above, there is nothing left to explain what Quality 4.0 is.

Take Quality.

Inject AI/ML.

What you get is Quality 4.0.

So why so much hype?

Why so much of brouhaha?

There is nothing new here.

In fact, there is nothing new in AI/ML too.

The terms AI/ML and their foundational concepts have been around for decades.

With the advent of computers, automation or digital enablement of systems and processes in all walks of life and business became possible.

And it has been going on since several decades.

The methodologies and technologies to digitally enable or automate a process have evolved and AI/ML is an advanced stage in that journey.

The same applies to the field of Quality.

Processes used or influenced by Quality can be digitally enabled like any other process.

There is no big deal with that.

In some sense, when the automation or digital enablement or digital transformation journey evolves to a very advanced stage and it starts leveraging AI/ML concepts, what you get to is the 4.0.

If what you do is called Quality, then the above would result in Quality 4.0.

That's right.

At the most fundamental level, that’s all there is to Quality 4.0.

How Agile has Turned into a Fulcrum for Selling Organizational and Personal Transformation?

Agile was simply supposed to focus upon and take care of the challenges with the waterfall model for software development.

How much it has really succeeded in that, in a true sense, is still an open debate and is essentially based on which side of the agile camp you are a part of.

However, it needs to be carefully noted and understood that the Waterfall concept is a very fundamental one which talks about solving any business problem including software development through a sequence of logical steps.

These steps typically include:

• Correctly and completely understanding the problem (R for Requirements)
• Selecting approach for the proposed solution (D for Design)
• Implementing the solution as per selected approach (C for Coding)
• Validating that the implemented solution does indeed address the problem (T for Testing).

The above workflow in software parlance is nothing but the software development life cycle (SDLC).

The steps as encapsulated in the term RDCT are nothing but the various phases of the SDLC.

The above principles have always been there.

Right from the very beginning

Software or no software.

In fact, agile is not original or new but is essentially the Waterfall concept re-arranged differently.

Conceptually speaking, in agile, one would execute several, short-duration waterfalls, one after the other.

Reducing release cycle time, or time-boxing, or introducing rituals and practices like backlog, retrospective, daily stand-up, in agile doesn’t anyway change the core of the Waterfall concept.  

Agile was meant to be just another way for developing software.

Just another methodology.

And it should have stayed that way.

Over time, it has purposefully been transformed by interested parties into an organizational and personal transformation tool.

Who are these interested parties?

These are those folks who earn their pay-check as agile trainers, consultants, auditors, etc.

They have created the myth and more than that the funny notion that agile transformation is the only need these days for both organizations as well as individuals.

The idea behind agile transformation and even agile methodology is not really an original one.

Methodologies like scrum and extreme programming did bring certain new rituals and practices.

However, following these new rituals and practices wouldn’t make you agile as also not following them wouldn’t make you not agile.

For understanding and uncovering the reality behind the myth, one needs to understand the broader landscape of philosophies and theories related to general and strategic management at the organization level and personal development and growth at the individual level.

All these philosophies and theories have always professed that “change is the only constant”. 

Change management is important for anyone.

Be it an organization or an individual.

For personal development and growth and change management at the individual-level, one need not look much beyond the ideas narrated and popularized by people like Napoleon Hill, Dale Carnegie, Norman Vincent Peale, et al.

The personal development philosophies and theories are very well defined and widely available since last several decades.

Formally speaking, their origin can be traced back to the 1910 classic book “The Science of Getting Rich” by Wallace Wattles. 

This book propounded that if you make certain changes in your habits and thought processes you will eventually mould yourself into a person worthy of great wealth.

For general and strategic management and change management at the organization-level, one need not look much beyond the ideas such as organizational change management (OCM) and business process management (BPM).

The concepts and practices related to OCM and BPM are very well defined and widely available since last several decades.

In addition, several highly successful CEOs have written books on their own personal experience with organizational transformations.

Here are some examples:

• “My years with General Motors” by Alfred P. Sloan - 1963
• “Talking Straight” by Lee Iacocca - 1988
• “Pour Your Heart into It: How Starbucks Built a Company One Cup at a Time” by Howard Schultz - 1997
• “Business @ the Speed of Thought: Succeeding in the Digital Economy” by Bill Gates - 1999
• “Jack: Straight from the Gut” by “Jack Welch, John A. Byrne, Mike Barnicle - 2001
• “Who Says Elephants Can't Dance? Inside IBM's Historic Turnaround” by Louis V. Gerstner - 2002

Those who are proponents of agile at organization-level use the term “agile transformation”. 

How is that any different from the philosophies and theories related to general and strategic management and change management at the organizational level?

Those who are proponents of agile at individual-level use the term “personal agility”. 

How is that any different from the philosophies and theories related to personal development and growth at the individual level?

It is simply and mostly a copy and paste job.

There is really nothing new.

It should be kept in the mind that coining a new term is not equivalent to coining a new concept.

Using agile for anything and everything is a common practice followed by those who earn their pay-check as agile trainers, consultants, auditors.

They have no choice indeed.

They need to pay their bills.

And for that they need to able to sell their stuff and wares!

For any sales you need a fulcrum.

And agile has turned into and become that fulcrum.

Here are some examples of terms, slogans, catch-words and one-liners which are used by those who earn their livelihood from agile by leveraging agile as the fulcrum to make the sale:

• Personal agility – what about personal development and growth?
• Agile transformation – ever heard of OCM and BPM?
• Remote agility – is working from home or working remotely anything new?
• Distributed agile – how else would you work if not in a distributed model in a globally integrated economy?
• Be agile and stay ahead – was “who moved my cheese” not important earlier?
• The agile way for dummies - what is it about the agile way that was already not there?
• Being agile made easy – why would you want to focus on made easy and not being agile whatever that means?

Nonetheless, the fact of the matter is, agile term is quite popular in certain organizations especially those involved in IT services delivery and software product development.

When one comes to think of it, for both organizations and individuals the focus should always remain on the core issues and concerns.

The core issues and concerns at the individual level are related to personal development and growth and change management.

And the core issues and concerns at the organization level are related to general and strategic management and change management.

Given the above backdrop, it can be argued that a rose is a rose is a rose is a rose.

And calling it with any other name would not have any material effect.

That way, it is fine to say that we will use the term agile transformation.

There is no harm in that.

The problem arises when those who earn their pay-check as agile trainers, consultants, auditors try to build the impression that agile is new, unique, different.

It is not.

Not at all.

Using the term agile or any other term XYZ is alright.

The key thing is this.

Does agile or XYZ help organizations and individuals change for the better?

If yes, then that is exactly what should be.

Names are transient and come and go.

Fundamental concepts and principles remain forever.

Today it is agile transformation.

Tomorrow it will be XYZ transformation.

Today there are those people who earn their pay-check as agile trainers, consultants, auditors.

And tomorrow these same people will earn their pay-check as XYZ trainers, consultants, auditors.

Agile serves as the fulcrum for such people for selling organizational and personal transformation offerings.

However, in the real sense, agile is not the real fulcrum for organizations and individuals.

The real fulcrum is the fact that there are core and fundamental concerns and concepts related to personal development and growth, general and strategic management and change management which will always be there, and which will remain relevant forever.

Why Simple Concepts Win Over Complex Models and Frameworks?

Models and frameworks like TQM, ISO, EFQM, CMMI, Six Sigma are like the same wine in different bottles.

They may try to create the impression of being unique in both their value proposition and orientation but are essentially one and the same.

What they are good at is making simple concepts appear and sound complex.

It need not be that way.

There is a cottage industry of consultants, auditors, trainers, etc. who have a vested interest in promoting and propagating these complex models and frameworks.

Terms and jargons like TQM, ISO, EFQM, CMMI, Six Sigma seem to suggest the person uttering them is some expert.

The reality is far away from the above.

No one can openly and honestly accept that though.

We all need to be hypocrites to maintain the fake decorum.

In many of the conferences on these complex models and frameworks this kind of stupid behaviour is on open display.

There are those venerable folks who are experts in verbal diaorrhea.

They keep on saying many things, unrelated and mostly silly in nature.

These folks are more vulnerable than venerable since they are under pressure due to their hidden need to maintain their standing in such forums.

They somehow end up joining all and every meeting.

And say things like we need to improve humanity, we need to work for the welfare of the society and the country, we need to have this for prosperity or that for prosperity.

You can never be in agreement with their thoughts in a genuine sense but must wear the facade of being respectful and attentive.

And unfortunately, such folks say that same thing again and again and again.

When you clear the clutter and remove the flab wrapped around the Models and frameworks like TQM, ISO, EFQM, CMMI, Six Sigma what emerges is something very simple yet beautiful and powerful.

The simple concepts win over complex models and frameworks.

Any day.

What are these simple concepts and why is it important to understand them accurately?

The answer is this - these are the guiding and the driving forces for any organization that wants to succeed and sustain that success, not just tomorrow or day after but for ever.

The simple and powerful concepts are the heart of how to make an organization successful.

For understanding these, one needs to go back to the basics, the very fundamental elements of business success.

All models and frameworks end up unnecessarily complicating the fundamental elements.

They put too much of dirt and grease to the simple concepts.

The fundamental truth is that an organization needs to fully take care of the interests and needs of its stakeholders.

Nothing more to that and nothing less to that.

Period.

The high-sounding terms and models cannot obfuscate this simple truth.

The simple concepts are as encapsulated below.

As a company you just need to focus on the following simple concepts:

Keep your customers satisfied and if possible, delighted

• Not because you can charge them more money but because you can charge them for more time
• Because they can act as powerful references for you to get more customers

Keep your employees happy and if possible, engaged

• Because they will give their 100% without imposing too many controls on them
• Because they will stay longer with you

Keep your investor's financial interests safe and if possible, make them really rich

• Because they will continue to stay invested and maybe invest even more
• Because other investors will also get interested to place their bets on you

Keep the government agencies content with your level of compliance and corporate ethics and if possible, become a perfect corporate citizen

• Because the authorities will be mindful of your strong reputation when dealing with you
• Because this will attract certain select group of highly successful investors who only invest in ethical companies and once they invest the market capitalization goes up steeply

The above simple concepts are more than enough.

There is no need of the complex models and frameworks like TQM, ISO, EFQM, CMMI, Six Sigma in the real sense.

They can still be used though.

They don't provide any news fundamental concepts but can provide some useful ideas.

They are still important in some sense as they provide work to the cottage industry of consultants, auditors, trainers, etc.

CMMI V2.0 - Some Key Concepts and Terms - Part 3

The following bulleted list provides the links to the earlier post(s) on this blog which talk about certain key concepts and terms in V2.0 as compared to V1.3 that are important from an implementer's point of view.

• CMMI V2.0 - Some Key Concepts and Terms -https://business-process-improvement-blog.blogspot.com/2020/04/cmmi-v20-some-key-concepts-and-terms.html
• CMMI V2.0 - Some Key Concepts and Terms - Part 2 - https://business-process-improvement-blog.blogspot.com/2020/05/cmmi-v20-some-key-concepts-and-terms.html

Here are some more additional key concepts and terms.


Establish approval matrix for key decisions related to process management including process definition, implementation, compliance and improvement

• Such an approval matrix will clearly provide the way for performing process management in the organization with high degree of effectiveness
• It is recommended to revisit and review the approvals peridocially and optimize and fine-tune them for efective and speedier decision-making

Establish approval matrix for key decisions related to project delivery including project management, execution and resource management (people, software and hardware)

• Such an approval matrix will clearly provide the way for performing project delivery to the customers with high degree of effectiveness
• It is recommended to revisit and review the approvals peridocially and optimize and fine-tune them for efective and speedier decision-making

Establish approval matrix for key decisions related to company/site operations including departmental processes like of HR, Admin, IT, Legal, Sales, etc.

• Such an approval matrix will clearly provide the way for managing the operations with high degree of effectiveness (incidentally, if a company is PCMM level 3 or hugher they will already have this in place
• It is recommended to revisit and review the approvals peridocially and optimize and fine-tune them for efective and speedier decision-making

The above provides some additional key concepts and terms in V2.0 as compared to V1.3 that are important from an implementer's point of view.

For any implementer with working knowledge of CMMI V1.3, it would be quite useful to correctly understand and incorporate these and other such key concepts and terms.

CMMI V2.0 - Some Key Concepts and Terms - Part 2

The following bulleted list provides the links to the earlier post(s) on this blog which talk about certain key concepts and terms in V2.0 as compared to V1.3 that are important from an implementer's point of view.

• CMMI V2.0 - Some Key Concepts and Terms - https://business-process-improvement-blog.blogspot.com/2020/04/cmmi-v20-some-key-concepts-and-terms.html

Here are some additional key concepts and terms.

Execute quality assurance using a well-defined approach and plan developed based on historical quality data

• Quality assurance should be executed in a systematic manner using a structured and standardized quality assurance approach and plan
• The quality assurance plan should not only consider future and upcoming process needs but also incorporate results from the analysis of the past data on quality and non-compliance issues

Extend focus of quality assurance beyond verifying compliance to enabling process improvement too

• Quality assurance should continue to be the watchdog on process compliance and continue the focus on compliance to defined processes and procedures.
• In addition, quality assurance should become an enabler of improvement in the quality of the performed processes and resulting work products by focusing more explicitly on identifying and triggering opportunities for process improvement.

Involve subject matter experts (SMEs) also in addition to peer reviewers for identifying work product issues

• Review by SMEs, who possess the appropriate technical knowledge, and not just the peer reviewers enhances the effectiveness of the technical reviews.
• Use of the term SME in addition to the term peer reviewer allows for better handling of the egos, especially of those technical experts who are senior by experience also and not just by expertise.

The above provides some additional key concepts and terms in V2.0 as compared to V1.3 that are important from an implementer's point of view.

For any implementer with working knowledge of CMMI V1.3, it would be quite useful to correctly understand and incorporate these and other such key concepts and terms.

CMMI V2.0 - Some Key Concepts and Terms

An earlier post titled CMMI V2.0 - Some Major Changes and Improvements Over CMMI V1.3 talked about the major changes introduced into the CMMI version 2.0.

Overall the changes are quite useful and improve upon the structure of the framework as well as provide better clarity on certain key principles and concepts.

There are several key concepts and terms in V2.0 as compared to V1.3 that are important from an implementer's point of view.

Here are some of them:

Sustain the focus on continual performance improvement through continual process improvement

• Process improvement is to be employed as a tool to eventually bring in improvements in the performance of the business operations.
• Return on investment of process improvement initiatives should be always on the top of the mind and hence should be measured and closely monitored so as to attain the desired business outcome.

Leverage opportunities in addition to managing risk in the risk management area (this is seemingly a direct lift-off from ISO 9001:2015)

• Risks are those events and factors that act as head-winds and can derail or decelerate the project from meeting its objectives. 
• On the other hand, opportunities are those events and factors that act as tail-winds and can accelerate and keep the project on track so that it can exceed its objectives.

Perform causal analysis right from the start and not only at level 5 as was the case in version 1.3

• Causal analysis need not wait for systems and processes to become highly mature.
• It can and should be done even in an organization which has just started its process improvement journey.

Conduct causal analysis on successes and good happenstances too and not only the failures and problems

• Causal analysis is generally viewed  to be linked with problems and their mitigation.
• However, causal analysis can be equally applied to derive learning from successes and good practices.

Derive effort estimates from explicit size estimates

• At the outset, size needs to be explicitly estimated. In this context, size is viewed as a measure of the quantity of the work to be performed and is regarded as a fundamental attribute of that work.
• Subsequent to that, effort is derived from size estimates and additional considerations like work complexity, team competency, etc.

The above provides just some of the several key concepts and terms in V2.0 as compared to V1.3 that are important from an implementer's point of view.

For any implementer with working knowledge of CMMI V1.3, it would be quite useful to correctly understand and incorporate these and other such key concepts and terms.

Extension to and Augmentation of CMMI Version 2.0

CMMI V2.0 is expected to get extended much beyond the three domains it has conventionally been applied till date - development, services and supplier management (acquisition).

The plan seemingly is to extend CMMI V2.0 by augmenting it with newer domains like workforce management (people), security and safety.

Workforce Management

It is, however, interesting to note that "people" area was already there as part of a separate model called as P-CMM (written with a "dash after "P").

P-CMM had its last release more than a decade earlier in July 2009.

The version was quite incidentally 2.0!

P-CMM never saw much traction and hence never had another release.

In a way, having a separate model for people practices was never a logical thing to do in the first place.

Managing people practices in isolation has no meaning and must be seen as one of the several elements that form part of effective management of work in an organization.

Following people practices will find a place in CMMI V2.0 under the capability area "Managing the Workforce (MWF)":

• Compensation and Rewards
• Staffing and Workforce Management
• Career and Competency Development
• Empowered Work Groups
• Organizational Training

Organizational Training was already there in the first release of CMMI V2.0, and has been a part of CMMI framework for quite a long time.

P-CMM has continued on life-support for many years and CMMI V2.0 will help resuscitate it by subsuming it in a manner that makes sense.

That is why there are just five people practices that will there in CMMI V2.0.

It is actually just four if one were to take out the Organizational Training also.

It is easy to see the right-sizing of P-CMM in CMMI V2.0 from 22 practices to just 4!

The HR folks who used to make a lot of unnecessary hullabaloo, misplaced hype and a big mountain out of the P-CMM mole-hill have also been right-sized along with their pet model.

For more details about P-CMM, read the following post:

• P-CMM or People CMM
• Some Thoughts on PCMM

Security (Management)

Another extension to CMMI V2.0, is the Security domain which has conventionally been associated with ISO 27001, the ISO standard for information security.

The above should be extended further by organizations to the Data Privacy domain though it is not explicitly asked for.

This is crucial given the importance of Data Privacy, which has extended the information security domain to special protection of personal information through regulations such as GDPR.

For more details about Data Privacy, read the following posts:

• EU GDPR (General Data Protection Regulation) - Some Key Points
• Personal Data Privacy Regulations - Some Interesting Corollaries

Following security practices will find a place in CMMI V2.0 under the capability area "Managing Security (MSEC)".

• Managing and Planning Security
• Developing Secure Solutions
• Managing Security Threats and Vulnerabilities
• Selecting and Managing Secure Suppliers
• Planning and Supporting Security in Work

For more details about Information Security, read the following posts:

• Data Privacy and Information Security - How are they different and how are they same? 
• ISO 27001

Safety (Management and Engineering)

Another extension to CMMI V2.0, is the Safety domain which has conventionally been associated with specific safety standards.

In addition, there is a framework known as CMMI + SAFE that was developed to provide a safety add-on the to CMMI-DEV model.

The last version of +SAFE, version 1.2, was released more than a decade back, in March 2007.

Following safety practices will find a place in CMMI V2.0 under the capability area "Managing Safety (MSAF)".

• Communication and Coordination
• Managing and Planning Safety
• Ensuring Safety

For more details about Safety, read the following posts:

• CMMI +SAFE - Safety Extension to CMMI
• Process Framework for Avionics Software

CMMI +SAFE - Safety Extension to CMMI

CMMI +SAFE was developed with the purpose of providing an option to organizations that wanted to extend their CMMI implementation to include safety considerations.

The last version of +SAFE, version 1.2, was released way back in March 2007.

+SAFE, version 1.2 was provided as an add-on for safety over CMMI for Development, version 1.2 and has not been kept current with CMMI V2.0, the latest version of the CMMI model.

It was developed by the Australian Department of Defence and not the US DoD which had funded the development of CMMI models till version 1.3.

The technical report published on +SAFE described how to use this framework as either an independent thread or as an add-on to CMMI implementation in the organization.

Since developing and maintaining safety-critical products require specialized processes, skills, and experiences, +SAFE was intended for guiding the implementation of such practices in an organization.

It was also intended for subsequently appraising an organization's capabilities in managing the development and maintenance of safety-critical products.

+SAFE supplements CMMI-DEV with two additional process areas:

• Safety Management
• Safety Engineering

Key details of the specific goals and specific practices in the above two process areas available in +SAFE are as given below.

Safety Management

This process area pertains to identification and planning for addressing safety requirements and considerations and corresponds to Project Management process areas in CMMI-DEV.

SG 1 Develop Safety Plans
SP 1.1 Determine Regulatory Requirements, Legal Requirements, and Standards
SP 1.2 Establish Safety Criteria
SP 1.3 Establish a Safety Organization Structure for the Project
SP 1.4 Establish a Safety Plan

SG 2 Monitor Safety Incidents
SP 2.1 Monitor and Resolve Safety Incidents

SG 3 Manage Safety-Related Suppliers
SP 3.1 Establish Supplier Agreements That Include Safety Requirements
SP 3.2 Satisfy Supplier Agreements That Include Safety Requirements

Safety Engineering

This process area pertains to execution and monitoring of the plan developed in the "Safety Management" and corresponds to Engineering process areas in CMMI-DEV.

SG 1 Identify Hazards, Accidents, and Sources of Hazards
SP 1.1 Identify Possible Accidents and Sources of Hazards
SP 1.2 Identify Possible Hazards

SG 2 Analyze Hazards and Perform Risk Assessments
SP 2.1 Analyze Hazards and Assess Risk

SG 3 Define and Maintain Safety Requirements
SP 3.1 Determine Safety Requirements
SP 3.2 Determine a Safety Target for Each Safety Requirement
SP 3.3 Allocate Safety Requirements to Components

SG 4 Design for Safety
SP 4.1 Apply Safety Principles
SP 4.2 Collect Safety Assurance Evidence
SP 4.3 Perform Safety Impact Analysis on Changes

SG 5 Support Safety Acceptance
SP 5.1 Establish a Hazard Log
SP 5.2 Develop a Safety Case Argument
SP 5.3 Validate Product Safety for the Intended Operating Role
SP 5.4 Perform Independent Evaluations

+SAFE was designed to cut down the dependence of CMMI appraisals on the need for safety domain expertise with the members of the appraisal team.

This extension was developed for standalone use but can be used in combination model with the primary CMMI implementation track.

There are intentional overlaps with CMMI model content and some safety standards though it is neither meant to be seen as an integral part of the CMMI model nor rely upon any specific safety standards.

Since +SAFE is an extension of the CMMI framework, it adopts the same assumptions, model structure, conventions, and terminology as the CMMI model and is also affected by the general process-area and capability-level interactions inherent in the CMMI model.

Quality Hold or Non-Quality Hold?

At times, a manufacturer is forced to put a product on quality hold owing to some issues getting identified or getting reported on the product from the field.

When the above happens in just a few weeks of the product getting launched, it speaks volumes about the lack of necessary product quality measures before the product is allowed to ship.

This has direct and immediate business impact on the sales figures for the period the product stays on "quality hold".

The term "quality hold" is an interesting one.

It means a product is put on hold due to quality.

Whereas, the product is actually put on hold due to lack of quality or due to non-quality.

It would be better to use the term "non-quality hold" rather than "quality hold".

From a business point of view, quality holds come at a cost.

In addition, there is an impact on the market reputation of the manufacturer.

This has a lot to do with the pressure on manufacturers to design, build and ship new products as well as frequent and continuous product improvements and innovations.

The business pressure leads to short-cuts being taken or crucial aspects getting ignored.

That may result in faster delivery, but at times, not a good one.

Organizations need to carefully assess and balance out the time to market pressure against the need to have good quality of the product that eventually gets shipped.

Quality holds are never a desirable situation for any manufacturer.

In several instances, it is possible that the issues getting identified or getting reported on the product from the field may not lead to any visible product failure in the short run.

However, in case any issue comes to the notice of the manufacturer it has an obligation to act upon it with high degree of urgency.

Hence quality holds.

It would be preferable to never have a quality hold or rather non-quality hold happen.

Business should, at no time, be forced to hold itself from continuing to ship and sell products due to quality hold.

The reason is very simple.

Every quality hold is nothing but essentially a business hold!

ITIL 4 - The 4 Four Dimensions Model and Service Value System

The ITIL 4 framework, the latest version of the ITIL framework, was released in Feb 2019.

The key concept in this model is the concept of services that are delivered by a service system.

So what does a service system contain?

A service system essentially contains the following elements:

• Service relationships (the supply chain through which service is delivered)
• Service offerings which constitutes of:
• Goods
• Access to resources
• Service actions that provide the core, enabling and/or enhancing services,
• Products (refers to the hardware and software used to deliver the service)
• Resources (refers to other elements like people, knowledge repository, etc.

The ITIL 4 framework, broadly speaking, consists of the following key components:

• The Four Dimensions Model
•  Service Value System (SVS)

Here is a schematic representation of the ITIL 4 framework in a nutshell:

The ITIL 4 framework consists of the following key components:

• The Four Dimensions Model
•  Service Value System (SVS)

THE FOUR DIMENSIONS MODEL

The four dimensions include:

• Organizations and people
• Information and Technology
• Partners and suppliers
• Value streams and processes

The above four dimensions represent perspectives which are relevant to the whole SVS, including the Service Value Chain (SVC) and the ITIL Practices.

However, the PESTLE factors, as mentioned below, that are beyond the control of the SVS constrain and influence the four dimensions:

• Political factors
• Economical factors
• Social factors
• Technological factors
• Legal factors
• Environmental factors

The interplay of the four dimensions impacts the creation of products and services for the provisioning of the service offerings for creating value for the service consumers.

ITIL SERVICE VALUE SYSTEM (SVS)

The ITIL Service Value System (SVS) coverts the inputs in the form of Opportunity/demand into outputs in the form of Value.

The core components of the ITIL SVS include:

• ITIL Guiding Principles
• ITIL Service Value Chain (SVC)
• Governance
• Continual Improvement
• ITIL Practices

The Seven ITIL Guiding Principles

• Focus on value
• Start where you are
• Collaborate and promote visibility
• Think and work holistically
• Keep it simple and practical
• Optimize and automate

ITIL Service Value Chain (SVC)

The service value system (SVC) is the central element of the SVS and is essentially the operating model which outlines the key Activities required to facilitate value creation through service provisioning.

The six SVC Activities are:

• Engage
• Plan
• Obtain and Build
• Design and Transition
• Deliver and Support
• Improve

For converting inputs to outputs the SVC Activities use different combinations of ITIL practices.

Governance

This provides the system for directing and controlling the organization and is realized through the following activities:

• Evaluate - Assess the business needs, strategic priorities and current portfolio
• Direct - Decide the strategic direction, future investments, organizational polices
• Monitor - Appraise the performance of organizational outcomes and business benefits

Continual Improvement

Opportunities for continual improvement needs to be explored at all levels of the organization in all functional areas.

The continual improvements can range from strategic to tactical to operational  to the ones which are transaction-based in nature.

The continual improvement model involves use of the following steps:

• What is the Vision? - Align with company mission, business goals and objectives
• Where are we now? - Determine current performance baseline (KPIs and metrics)
• Where do we want to be? - Define measurable targets that need to be achieved
• How do we get there? - Define the improvement plan
• Take action - Execute the improvement plan
• Did we get there? - Evaluate improved performance baseline (KPIs and metrics)
• How do we keep the momentum going? - Put in place measures for ongoing sustenance

The improvement ideas should be logged and tracked to closure using a structured system like a continual improvement register or log.

ITIL Practices

The practices essentially constitute a set of resources designed for performing work.

There are 34 ITIL Practices which are arranged in three broad categories:

•  General Management Practices (14)
• Architecture management
• Continual improvement
• Information security management
• Knowledge management
• Measurement and reporting
• Portfolio management
• Organizational change management
• Project management
• Relationship management
• Risk management
• Financial management
• Strategy management
• Supplier management
• Workforce and talent management

• Service Management Practices (17)
• Availability management
• Business analysis
• Capacity and performance management
• Change control
• Incident management
• IT asset management
• Monitoring and event management
• Problem management
• Release management
• Service catalogue management
• Service configuration management
• Service continuity management
• Service design
• Service desk
• Service level management
• Service request management
• Service validation and testing

• Technical Management Practices (3)
• Deployment management
• Infrastructure and platform management
• Software development and management

CMMI V2.0 - Services View

CMMI 2.0 or version 2.0 came into being with the release of the Development view in March 2018.

This was closely followed by the subsequent release of the Services and Supplier Management views in December 2018.

This post is exclusively focused upon the Services view of CMMI V2.0 model.

It provides high level description of the four practice areas that come under the "Services" category.

• Strategic Service Management (STSM) - what services to provide?
• Service Delivery Management (SDM) - how to ensure delivery of selected services?
• Incident Resolution and Prevention (IRP) - how to ensure smooth service delivery?
• Continuity (CONT) - how to ensure disruption-free service delivery?

 
The above four practice areas are described in a more detailed manner in the following sections of this post.

Strategic Service Management (STSM)

STSM relates to designing, developing and deploying new or upgraded services. It also conceptually relates to decisions regarding downsizing or discontinuing of services that are in operation.

The key point here is ensuring there is deep and strategic connect of the service offerings with the business objectives, needs and directions.

Key elements that need consideration in this practice area include:

• Creating and maintaining a service catalogue that lists down all types of service offerings with different levels of support (like standard, premium)
• An example of this could be a bank offering different facilities/services like ATM, lockers, teller, FD opening/closure, etc.
• Again, there could be different SLAs/levels of the above services based upon customer types like regular. privilege, etc.
• Creating and maintaining the SOP for providing the services with detailed description of the work flow
• Creating and maintaining the SOP for introducing a new or upgraded service and also for downsizing or discontinuing an existing service
• Analyzing the services portfolio to keep it aligned with the business objectives, needs and directions of the organization.
• An example of this could be a bank offering new facilities/services in the branch operating in a specific locality based upon that locality's unique characteristics.
• Again, the bank can discontinue certain services in the branch operating in a specific locality including even shutting down the branch (which essentially means all services get discontinued!)

Service Delivery Management (SDM)

STSM takes care of which services should be offered. SDM takes care of service delivery system to ensure services are delivered as planned.

SDM relates to the provisioning and delivery of the selected services. It also conceptually relates to decisions regarding enhancements, changes and improvements to the services that are in operation.

The key point here is ensuring there is clear operational connect of services with the service catalog and the SOPs for the services that are on offer.

Key elements that need consideration in this practice area include:

• Provide services (which essentially means handle incoming traffic of service requests/tickets) in line with SLAs or service performance contracts and includes services scope, service window (time/availability), SLA commitments, etc.
• Operate and maintain the end-to-end system for service delivery including introducing changes to enhance or improve the parameters related to effectiveness and efficiency.
• Analyze service performance to identify improvements in service delivery like cycle time reduction, response within SLA, resolution with SLA, SLA tightening, etc.
• Evaluate the suitability of service delivery system in terms of its capacity and its actual performance in catering to the incoming traffic of service requests (this would also feed into SSM for the top-level intervention at the service catalog level)

The workflow for handling service requests can follow a workflow similar to what gets used for handling an incident or issue as mentioned in the section below.

Incident Resolution and Prevention (IRP)

SDM takes care of the actual delivery of services on the ground. IRP ensures incidents and issues that  disrupt service delivery are addressed promptly to ensure high availability to the end-user of the services.

IRP relates to identification and resolution of incidents and issues that disrupt or degrade the delivered services and in selected cases investigate the underlying causes to prevent recurrence of certain incidents and issues.

The key point here is ensuring that any disruption of degradation in services is restored and the service operations brought back to normal state at the earliest so that services continue to be delivered in line with the SLA commitments.

Key elements that need consideration in this practice area include:

• Identification of incidents and issues (both in a reactive mode as well as anticipatory/proactive mode) that disrupt or degrade service delivery or may do so
• The definition of incident can be extended beyond issues or problems faced by an end-user to include requests regarding some help or query related to something where the user may have got stuck.
• The incidents, issues and user requests can be logged as service request or problem ticket or service issue or service ticket, etc.
• Logging and tracking the incidents and issues to their resolution and eventual closure
• Resolving incidents and issues in a systematic manner in accordance with the SOP for the same - this SOP should have steps like:
• analyzing the incident or issue
• classifying the incident or issue correctly
• assigning to the right team/personnel
• identifying the fix or workaround needed
• verifying that the proposed fix or workaround will actually resolve the incident or issue
• implementing the proposed fix and pushing that into production
• verifying the fix or workaround is actually working as was thought
• informing the concerned stakeholders and/or the requester that the incident or issue has been resolved
• obtaining concurrence of the requester that the incident or issue has indeed been resolved
• closing the service request or ticket
• Investigating the underlying causes of selected set of incidents or issues and take measures to prevent their recurrence either by eliminating them altogether or minimizing their frequency of occurrence - this is recommended in following situations:
• an incident is occurring very frequently or becomes a pain point for the end-users
• an incident is not occurring very frequently but has significant disruptive or degrading impact on the service delivery system
• an incident is not occurring very frequently but has end-users like the CEO, senior management whose down-time is pretty expensive

Continuity (CONT)

IRP takes care of resolving incidents and issues that disrupt or degrade the services being delivered by a service system.

CONT ensures mitigating measures or controls are put in place to reduce the likelihood of serious disruptions or catastrophic events that have severe impact on the availability or performance of the service system and also the overall business operations.

An example of this could be the outage of the web portal of an e-retailer!

CONT relates to identification and implementation of mitigation measures to avoid the occurrence of serious disruptions or catastrophic events during the operation of the service delivery system.

It also conceptually relates to the complete business operations which essentially means all services being delivered by the business.

This view has direct linkage with the business continuity and disaster recovery plan concept in the ISO 27001 standard as also ISO 22301 (ISO standard exclusively focused on business continuity management).

The key point here is ensuring some kind of FMEA (Failure Modes and Effects Analysis) or FTA (Fault Tree Analysis) is done on the service delivery system (or even the overall business operations) so as to identify and address, in a proactive manner, things that could go wrong.

Key elements that need consideration in this practice area include:

• Identification of the triggers that can lead to serious disruptions or catastrophic events
• Identification of the approaches to mitigate those triggers
• Implementation of the measures and controls in line with the selected approaches for mitigating the likelihood of the triggers
• At times, it may not be possible to influence the likelihood of a serious disruption or catastrophic event so in that case it is advisable to focus on reducing their impact should they happen (an example could be floods in an area where nothing can be done on the likelihood part but a better building design would lessen the impact)
• In addition to mitigation plan, there should be a contingency plan which would state what will be done should any serious disruptions or catastrophic event were to occur
• Preparation of a continuity plan for service operations which should include
• List of functions and services that are essential to ensure continuity of operations
• The sequence of restoration, RPO (recovery point objective) and RTO (recovery time objective)
• Period verification and validation of the continuity plan which should include
• Training of the staff involved in ensuring continuity as well as recovery and restoration after the occurrence of any serious disruption or catastrophic event
• The trained staff should be fully aware of the contingency measures as documented in the continuity plan
• There should be periodic testing of the continuity plan to ensure the plan would "go right" when it needs to be invoked and this is important because it will be a situation of real crisis when it would need to be invoked, if ever

Cyber Security Key Terms - Event, Risk, Incident and Breach

The terms - event, risk, incident and breach - are generally not clearly understood and at times used in a manner which is not appropriate.

So what do these terms mean?

Here is an attempt to define these terms in a very simple language.

Event is any observable occurrence in a system or network. Some events can be conveniently ignored, whereas some would need to be investigated and there are some that would even need some kind of an action. An example of an event would be someone attempting to hack a company's network

Risk refers to the likelihood of a certain event that has the potential to cause some kind of loss or damage. An example of a risk would be data being stolen from a company's network.

Incident is a risk that gets materialized. An example of an incident would be an actual instance of data being stolen from a company's network.

Breach is an incident that violates specific legal requirements. An example of a breach would be an actual instance of data being stolen from a company's network where the breach involves personal information which violates privacy regulations.

Risk-Based Thinking

Risk-based thinking is a management approach that relies upon anticipating the future and adjusting the plans accordingly so as to be better prepared for things to come.

The whole idea behind calling a future anticipated event or happening as a risk is based upon following criteria:

Likelihood

• The occurrence of that event has an associated likelihood. 
• The likelihood could be at different levels such as low, medium, high. 
• So something with high likelihood means that it is very likely to happen.

Impact

• The impact should that event happen has an associated severity. 
• The severity of impact could be at different levels such as low, medium, high. 
• So something with high severity means that it will lead to major consequences.

Risk-based thinking has been made a key and essential element of ISO standards such as 9001:2015 and 27001:2013.

So in the above ISO standards, the purpose of the management system revolves around ensuring risks to the organization's objective are identified and managed.

CMMI V2.0 Practice Areas

CMMI V2.0 is an integrated product suite that comprises of the model itself with three different views currently - Development, Services and Supplier Management.

The architecture of CMMII V2.0 model includes a set of specific Capability Areas that have specific Practice Areas under them.

The Practice Areas in V2.0 are categorized into common practice areas and view-specific practice areas.

 
Common Practice Areas:

1. Requirements Development and Management (RDM)
2. Process Quality Assurance (PQA)
3. Verification and Validation (VV)
4. Peer Reviews(PR)
5. Estimating (EST)
6. Planning (PLAN)
7. Monitor and Control (MC)
8. Risk and Opportunity Management (RSK)
9. Causal Analysis and Resolution (CAR)
10. Decision Analysis and Resolution (DAR)
11. Configuration Management (CM)
12. Process Management (PCM)
13. Process Asset Development (PAD) 
14. Managing Performance and Measurement (MPM)
15. Governance (GOV)
16. Implementation Infrastructure (II)
17.  Organizational Training (OT)  - common area but coming from People view

Development View-specific Practice Areas:

1. Technical Solution (TS)
2. Product Integration (PI)

Services View-specific Practice Areas:

1. Strategic Service Management (STSM)
2. Service Delivery Management (SDM)
3. Incident Resolution and Prevention (IRP)
4. Continuity (CONT)

Supplier Management View-specific Practice Areas:

1. Supplier Source Selection (SSS)
2. Supplier Agreement Management (SAM) 

The model architecture lends a lot of flexibility to the adoption of CMMI V2.0 model by an organization.

In addition, an organization can even create and use a customized view of the model.

In summary, it can be said that the arrangement of Practice Areas in the CMMI V2.0 architecture is a good move.

The CMMI V2.0 architecture should help increase the adoption of CMMI by organizations and more importantly enhance the value organizations derive from the use of CMMI.

CMMI V2.0 - Focus and Key Changes/Additions at PA level

In CMMI V2.0, at the practice area (PA) level, there are some important points that are related to focus in that PA and key changes/additions as compared to V1.3.

A 30,000 feet overview of the key changes/additions is as given below followed by the  PA-wise details of the focus and key changes/additions.

CAUSAL ANALYSIS AND RESOLUTION (CAR)

• Recast from CAR in V1.3 with enhanced scope
• Focus - Ensure bad things never happen again and good things happen again and again
• Key changes/additions:
• Identify causes underlying best practices and not just problems
• Assess quantitatively the benefits versus cost of applying actions identified for addressing a cause in case of a local instance at a broader scale and scope

CONFIGURATION MANAGEMENT (CM)

• Recast from CM in V1.3 with virtually no changes/additions
• Focus - Manage integrity of work products through change control and audits
• Key changes/additions:
• Not much change fundamentally

DECISION ANALYSIS AND RESOLUTION (DAR)

• Recast from DAR in V1.3 with major changes/additions
• Focus - Take high impact decisions in an objective manner
• Key changes/additions:
• Use approval matrix (comes from PCMM)

ESTIMATING (EST)

• New practice area in V2.0
• Recast from the relevant specific practices in PP in V1.3 and promoted one level up from being a practice to a separate practice area in V2.0 with minor changes/additions
• Focus - Estimate size, effort, schedule, cost for developing, delivering or procuring the product or service
• Key changes/additions:
• Use size explicitly to derive effort estimates
• Use a formal method explicitly for estimation
• Use historical data explicitly for estimation

GOVERNANCE (GOV)

• New practice area in V2.0
• Recast from GP 2.1 and GP2.10 in V1.3 with major changes/additions
• Focus - Provide mechanism for senior management to sponsor and govern process and improvement activities in the organization
• Key changes/additions:
• Emphasis is on senior management commitment not only on paper but on ground too (like providing direction, resources, staffing, oversight)
• Use of quantitative analysis for objective decision making by senior management

IMPLEMENTATION INFRASTRUCTURE (II)

• New practice area in V2.0
• Recast from GP 2.2-2.10 and GP3.1 in V1.3 with minor changes/additions
• Focus - Emphasizes on consistent usage and continuous improvement in the processes used in the organization
• Key changes/additions:
• Requires explicit use of organizational processes for performing work
• Ensure agreed processes are assessed not only for adherence but also for effectiveness

MANAGING PERFORMANCE AND MEASUREMENT (MPM)

• New practice area in V2.0
• Recast from an amalgamation of MA and OPP with infusion of QPM practices in V1.3 with major changes/additions
• Focus - Achieve business objective by managing performance using data
• Key changes/additions:
• Take care of data quality (comes from DMM)
• Analyze/mine performance data systematically to proactively identify areas requiring performance improvement

MONITOR AND CONTROL (MC)

• Recast from PMC with infusion of IPM practices in V1.3 with major changes/additions
• Focus - Increase the probability of meeting objectives by detecting early warning signals and addressing them proactively
• Key changes/additions:
• Focus on task completion as a key practice (which makes sense since any project at the end is a series of tasks)
• Monitor the transition of products/services to operations and support (comes from CMMI for Services)
• Manage critical dependencies (merges this IPM practice in V1.3 into MC in V2.0)
• Monitor work environment issues (merges this IPM practice in V1.3 into MC in V2.0)

ORGANIZATIONAL TRAINING (OT)

• Recast from OT in V1.3 with virtually no changes/additions
• Focus - Develop the skills and knowledge of personnel for performing their assigned roles effectively and efficiently
• Key changes/additions:
• Not much change fundamentally

PEER REVIEWS (PR)

• New practice area in V2.0
• Recast from the relevant specific practices in VER in V1.3 and promoted one level up from being a practice to a separate practice area in V2.0 with minor changes/additions
• Focus - Identify and address issues in work-products through reviews by technical reviews or subject matter experts
• Key changes/additions:
• Peer review can be used across the board for any work-product

PLANNING (PLAN)

• Recast from PP with infusion of IPM and QPM practices in V1.3 with major changes/additions
• Focus - Develop plan to elaborate upon what is needed to accomplish the work within the standards and constraints of the organization
• Key changes/additions:
• Focus on identification and assignment of tasks
• Plan is seen as the approach for accomplishing work (PMP always contained the process approach in addition to references to various sub-plans)
• Plan the transition of products/services to operations and support (comes from CMMI for Services)
• Brings into fold IPM practices in V1.3 related to tailoring, use of organizational process assets and measurement repository, critical dependencies and work environment
• Brings into fold QPM practices in V1.3 related to process composition

PROCESS ASSET DEVELOPMENT (PAD)

• Recast from OPD in V1.3 with minor changes/additions
• Focus - Develop and maintain the organizational process assets that are needed to perform the work
• Key changes/additions:
• Talks about not only developing but buying or reusing process assets just like what can be done for technical assets

PROCESS MANAGEMENT (PCM)

• Recast from OPF and OPM in V1.3 with minor changes/additions
• Focus - Continuous improvement of processes and process infrastructure for better performance and for accomplishing business objectives
• Key changes/additions:
• Take care of process issues also in addition to improvement opportunities
• Set performance improvement objectives, they should be traceable to business objectives
• Identify and improve processes that play a significant role in achieving business objectives
• Develop the support system to fix process problems and to improve processes

PROCESS QUALITY ASSURANCE (PQA)

• Recast from PPQA in V1.3 with minor changes/additions
• Focus - Verify adherance to and enable improvement of processes and resulting work products
• Key changes/additions:
• Use quality assurance approach and plan based on historical quality data

PRODUCT INTEGRATION (PI)

• Recast from PI in V1.3 with virtually no change
• Focus - Integrate and deliver the solution that addresses requirements
• Key changes/additions:
• Not much change fundamentally

REQUIREMENTS DEVELOPMENT AND MANAGEMENT (RDM)

• Recast from REQM and RD in V1.3 with minor changes/additions
• Focus - Elicit requirements from customers, ensure common understanding by stakeholders and align requirements, plans, and work products
• Key changes/additions:
• Emphasis on requirements prioritization - mention of prioritized customer requirements and not just customer requirements
• Explicit need for obtaining commitment from project participants for the implementation of the requirements

RISK AND OPPORTUNITY MANAGEMENT (RSK)

• Recast from RSKM in V1.3 with enhanced scope
• Focus - Manage potential risks or opportunities
• Key changes/additions:
• Manage opportunities in addition to risks (comes from ISO 9001:2015)

SUPPLIER AGREEMENT MANAGEMENT (SAM)

• Recast from SAM in V1.3 with minor changes/additions
• Focus - Ensure that the supplier performs in accordance with the agreement, manage supplier relationship
• Key changes/additions:
• Monitor and manage supplier invoices
• Use data to manage supplier performance (comes from CMMI-ACQ)

TECHNICAL SOLUTION (TS)

• Recast from TS in V1.3 with virtually no changes/additions
• Focus - Design and develop solutions, products and services that meet customer requirements
• Key changes/additions:
• Not much change fundamentally

VERIFICATION AND VALIDATION (VV)

• Recast from VER and VAL in V1.3 with virtually no changes/additions
• Focus - Verify that solutions, products and services meet their requirements and validate that they fulfill their intended use in their target environment
• Key changes/additions:
• Not much change fundamentally