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.

Team Capacity Planning in the Context of Service Delivery and Service Level Management

The services context brings forth some unique and interesting characteristics.

Some of the them are mentioned below:
  • Services may be required to be delivered against an agreed scope in the agreed service window and that too only on demand
  • Some members of the service team will be actively utilized by being engaged in working on open tickets while some of the team members may always remain on stand-by, waiting for the next set of tickets 
Quantity and quality of services delivered is primarily dependent on the team size and competency as well as the volume of tickets, their distribution and nature of work.

In the services context, there are two essential asks:
  • First, ensure service is somehow delivered in line with the agreed scope and the business is somehow kept running and doesn't come to a halt or experience slow down. Service delivery is the key focus area for taking care of this.
  • And second, ensure service is not only somehow delivered but delivered in line with agreed expectations and the business is not only somehow kept running but made to run effectively and efficiently. Service level management is the key focus area for taking care of this. 

Team capacity planning deals with estimating the following:
  • How many team members in all are required for delivering a service?
  • How many shifts are required and how many team members in each shift?
  • How many team members are required on weekdays and on weekends?
  • How many team members are required temporarily to take care of seasonality? When?


Against the above backdrop, where does team capacity planning fit in?

Simply speaking, team capacity planning is finding the required team size at that time.

Required team size is a function of ticket volume, team size and service performance.

The required team size is in some sense is also the optimal team size.

It is important to maintain optimal team size such that the cost is as low as possible and service performance is as high as possible.

Optimal team size can be viewed as the minimum team size which will ensure service performance will meet the service level agreement (SLA).

The core idea is that 1 member less than the optimal team size will adversely impact service performance such that it will not be able to meet the SLA.

Ticket volume, team size and service performance data should be collected and analysed at some selected periodicity like weekly basis or monthly basis.

Ticket volume is simply how many tickets are received.

Team size is simply how many team members are deployed for providing the service.

Service performance is the more intricate one and requires deeper understanding of the following performance parameters:
  • Effort taken to resolve tickets (average as well as its distribution)
  • Calendar time taken to respond to tickets (average as well as its distribution)
  • Calendar time taken to resolve tickets (average as well as its distribution)
  • Comparison of calendar time taken to respond to ticket against the SLA
  • Comparison of calendar time taken to resolve ticket against the SLA (which may be defined priority-wise or some other basis like gold, silver, etc.)
  • Computation of SLA compliance for time to respond
  • Computation of SLA compliance for time to resolve

Given the above, the high-level team capacity planning approach for finding the required team size or optimal team size involves the following steps:
  • Determine the volume of tickets (average as well as its distribution) that is received
  • Compute the adjusted volume of tickets received by the team by considering the variation in the technical nature and complexity of the tickets received 
  • Determine the actual team size (average as well as its distribution) deployed in the team to handle the adjusted volume of tickets received 
  • Compute the adjusted team size by considering the variation in competency of experienced team members versus freshers versus others 
  • Determine the actual service performance of the deployed team in handing the adjusted volume of tickets received 
  • Reconcile the adjusted volume, adjusted team size and actual service performance to see whether adjusted team size is less than required or more 
  • Arrive at the capacity in terms of required team size based on above steps 
    • If the required team size is more than the actual and adjusted team size, then there is a buffer and in case the customer of the service notices that, it can lead to team downsizing 
    • If the required team size is less than the actual and adjusted team size, then there is a deficit and it should be brought intelligently to the attention of the customer of the service for team augmentation 

Reconciliation is the more important and involved step in the approach above and should be done using the following rules of thumb:
  • Total effort available with the team based on adjusted team size and considering leaves, etc. of team members should be more than the total effort required for the team based on adjusted ticket volume and effort taken to resolve one ticket
  • Effort taken to resolve one ticket should be less than effort derived from calendar time taken to resolve one ticket (calendar time multiplied by number of working hours in that calendar duration gives the effort derived from calendar time) 
  • On an average basis, the volume of tickets received in a certain time duration should be less than volume of tickets resolved in the same duration 

For studying the ticket volume and service performance one can start with simple statistical tools like trend of average and standard deviation.

As is required, and as is possible based on competency available, one can explore advanced methods like queuing theory for the above purpose.


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.

Sustained Organizational Success - Looking Beyond Quality and Process

The principles of quality management, as also total quality management, and process improvement, as also process excellence, are truly important for any organization.

The above principles strongly and directly impact the product and service delivery operations of an organization but are still cogs in the wheel as far as sustained organizational success is concerned.

The term "sustained organizational success" is a beautiful concept that can only be understood well when dissected inside out, stretched apart and pinned down throughout the edges.

The first and foremost criterion for success is the organization's ability to remain a "going concern" from financial accounting point of view.

In the most fundamental sense, an organization is a financial system which earns money through certain means and burns money while earning.

Though there are several financial parameters which are important to track and control, the primary secret of staying afloat financially and not become insolvent is to have positive free cash flow.

Profit to an organization is like water to human body.

Human beings can survive without water for certain time but must consume adequate water on an average to stay hydrated and alive.

Similarly, organizations can survive without profit for certain time but must gather adequate profit on an average to stay profitable and afloat.

Human beings need water to stay alive but don't stay alive just for water.

Similarly, organizations need profit to stay afloat but don't stay afloat just for profit.

Where do the principles of quality management and process improvement fit in the big picture as far as the wheel of sustained organizational success is concerned?

They are simply like cogs in the wheel, important but still cogs at the end of it!

Sometimes, this notion is there with some quality and process folks that quality is the answer to all that is ailing organizations.

That is simply not right.

Organizations can run into rough weather on account of issues and challenges in respect of factors beyond just the quality of product and service delivered.

These issues and challenges are generally beyond, much beyond, the principles of quality management and process improvement.

Here are some of the major factors that determine sustained organizational success.

  • Economic environment (both domestic and global)
  • Government regulations (both local and international)
  • Technology innovations (including disruptions and black swan events)
  • Leadership and strategy (competency and character of CXOs)
  • Organizational structure (work assignment based on merit and not loyalty)
  • Financial performance (net income and free cash flow)
  • Operational performance (quality of product and service delivered)
The above very clearly shows the place where quality management and process improvement play their part in the big picture.

And here is the key thing.

Simply designing, developing, delivering and deploying good quality products and services is not good enough to attain sustained organizational success.

For any and every organization the core problem is the one and the same.

How to attain sustained organizational success?

Whatever is the final solution, one thing is quite clear.

One needs to certainly look at the principles of quality management and process improvement to seek a solution.

At the same time, one needs to look beyond, much beyond, quality management and process improvement to get to the right solution to the core problem. 

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.

How Much Value Do Model-based Appraisers and Consultants Add?

The question "how much value do model-based appraisers and consultants really add?" is an interesting one.

In fact, it is quite a fundamental question.

But the more fundamental question is this:

"Do they actually add much value?"

And perhaps the most fundamental questions of all would be:

"Do they actually add any value?"

Most of them do little or no value addition.
Appraiser and Consultant - No Value, No Need

The consultants and appraisers are, at the core, mostly one-trick ponies who regurgitate the same set of nonsense whichever organization they go to.

The work like a pair of clowns who ask dumb questions and expect you to think they are smart.

They re-phrase and paraphrase your questions and ask them back.

That's very irritating, to say the least.

They have some rigid notions about the concepts and terms and refuse to see the underlying logic that governs those concepts and terms.

They have no concrete and specific solutions to offer.

So you can expect them to only say this much:

"We ask questions".

Well, what else would someone do when he or she doesn't know the basic stuff?

They know something is crystal clear.

But they would go on and on and repeatedly raise the same, silly and invalid questions.

And to prove their point, they repeat a falsehood again and again.

In every discussion, they hover around the same set of points like:
  • You must understand the pain points
    • this is a completely nonsensical point 
    • you would start an initiative only when you have a business need, real or perceived
    • no one would allocate budget for an activity if there is no business case for it
  • You must articulate the business problem clearly
    • this is another utterly nonsensical and comical point
    • articulation of a business problem is not a linear thing and is done based on the context and the level of the person it is being communicated to
    • Also business problems may not always be straightforward, number-based statements but may involve complex, subjective issues with multiple dimensions
  • You must have the data for this and for that
    • one big question is why should you collect the data without any thought to the overall burden of collecting that data?
    • ignoring the ROI of data collection is a clear reflection of the ignorance of the consultant and appraiser who suggest get the data for this and for that
    • data should be seen in the context of process and should not be used to blindly infer and conclude anything about the process
  • You only would need to define the right approach for doing this
    • then what are you doing and why are you needed?
    • the consultant and appraiser need to be a part of the solution and not offer arcane and generic and non-implementable suggestions
    • everyone knows the usual stuff and if you can't suggest the specifics then you are good for nothing as a consultant and appraiser
It is interesting to note here that many, if not all, pairs of consultant and appraiser are actually good for nothing.

It is, therefore, very important for an organization to thoroughly evaluate the competency of the consultant and appraiser they are hiring.

You are paying them to be a part of the solution and not to just give you some kind of gyan.

You have to set the context and clear the situation by calling a spade as a spade.

You are paying them.

So you better ask them to listen to you.

You have to manage and drive them.

What if they refuse to get the signal?

There is a very simple answer to that.

Change your consultant and appraiser next time around.

They should not become like a millstone around you neck.

They better add value.

Or you kick them out.

So if there is no value from a consultant and appraiser then there is absolutely no need of such a consultant and appraiser.

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.

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.

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:

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:

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:

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

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.

Why Conferences on Business Process and Improvement May Not be Worth Spending Your Time on?

Most of the conferences on the subject of business process and improvement sound like one and the same.
They try to rehash the same old wine in new bottles but miserably fail at the same.

You have the key note speakers who speak the same stuff in a more flowery language.

They are paid to speak well on anything and everything and most of them do a pretty good job at that.

They are more like paid actors than the believers in business process and improvement philosophies.

Simple, old things are made to sound like new gems of wisdom.

Some of the speakers cover the mechanics of the context for that particular conference.

Suppose the conference is on "How to make your business agile in an ever changing world using XYZ framework?".

So some of the speakers will touch upon the nuts and bolts to do with the XYZ framework.

Some of them may even narrate case studies related to their experience in adopting and using the XYX framework.

And then the funny things start happening.

Almost all of them, invariably, talk of the same set of challenges at the core of their talks and presentations.

The same things that we know since decades and centuries.

The indiscriminate and unconsidered use of certain terms and phrases by most of the speakers has become a part of the SOP for talks at such conferences as it makes the speakers sound knowledgeable and very wise.

Here are some such terms and phrases:
  • Transformation - this is big word which has been around since ages. Radical changes or transformations have been at the root of the how the world around us has evolved since the time of the invention of the wheel.
  • Disruption - doing something out-of-box is not anything new. In any period in the history of human civilization there have many cases of disruption, which one may think of as very commonplace and trivial today.
  • Innovation - doing something in a significantly better or refined way is something that has been going on since times immemorial. These are essentially improvements of a higher order and the world is full of umpteen examples of innovations from the day one a human being has been there on this planet.
  • Disruptive innovation - this is nothing but verbal jugglery and the modern-day management gurus are experts at this. There is not much to understand here if you know what disruption means and what innovations means.
  • Change management - a big phrase indeed. Applied to the context of bringing in any enterprise-wide change in the organization, it is nothing but cultural transformation.
  • Self awareness - again this has been around there since the first human being that lived on the planet. Human beings have the ability to become aware of where they need to improve and can gradually learn and become better at that.
  • Collaboration - another high-sounding term for teamwork. No man or woman is an island and needs to work with others to get things done. Who the hell doesn't know that?
  • Value addition - this has been there and we know that quite well, the term "value for money" tells clearly what this exactly means. When you do something as an organization you expect to make money from that and people pay for it when they see it adding some sort of value.
  • The pace of change in the world is accelerating - we have been hearing this thing in every second article and every second interview and there is nothing new here in any sense. The pace of change will increase as a natural result of the changes before that since there are more things and hence more possibilities for things to change.
  • The new normal now is volatility, uncertainty, complexity and ambiguity - this is the most funny of the statements you will hear since there was no time when this was not happening. Even for those who lived in the stone age, survival was hard and the world was full of  volatility, uncertainty, complexity and ambiguity.
  • You need to own and drive your own career development and growth - when was this not true? Those who have gone to the very top of their careers have usually being propelled by an intense internal desire and passion to reach the top. 
The good part is that at most of the conferences, there is some level of treatment of the context related to the XYZ framework, though it may involve use of some gobbledygook which may have limited relevance for most of those present at the conference.

Not only the above, and to make it even more funny, in the end every talk eventually ends up with the same set of silly conclusions.

All of them bring up the standard list of laundry items and common asks required to make the XYZ framework work.

These items are common across the board, no matter which that XYZ framework is and in fact even if it happens to be any other damn thing you want to get done in an organization.

Here are those common asks:
  • Top leadership commitment
    • This is quite interesting insight from the "key notes". 
    • Is there literally anything that will be allowed to happen in an organization without this
    • For anything to happen in an organization you will need sponsorship, direction, approvals, funds for staffing, competency development and resources.
    • That has been always been true.
  • Organizational culture
    • Another trivial insight related to reporting structure, roles and responsibilities, commitment, accountability, ownership, empowerment, motivation, engagement and blah, blah, blah. 
    • And is this an insight at all, who doesn't really know that this is important? 
    • Culture change is always hard and change management is essentially intertwined with cultural transformation.
  • People receptivity and resistance
    • Another obvious insight that gets thrown at the attendees at the conferences. 
    • Is there anyone in any conference who doesn't know about is? 
    • An organization is a set of people connected through some structure and rules. 
    • This has been always been the case that change in the organization means change in the people working for the organization.
    • In fact, the point above on organizational culture is highly related to this point and the reason for that is people influence the organizational culture as much as the organizational culture influences the people working in that organization
  • Everything starts with the "I"
    • This is another classic point in example for why conferences don't add much real value.
    • Changes always starts with the individual, who doesn't know that?
    • The whole idea of self-awareness and self-development is not at all new.
    • Since ages, thoughts like finding the meaning of life, purpose of life, self-actualization, etc. have very much been there.
Sadly, in many conferences, many times the invited talks by some of the so called "experts" in that XYZ framework dish out exactly the above points.

The language used may be different and more flowery though.

It is all staged or acted out to create the right impact.

There is nothing original about it.

There is nothing really thought- provoking in what you hear from the invited key note speakers.

What you get to see is some colorful picture or table made by the speaker in one of his own books, typically a book you have never heard of.

They re-assemble the old ideas in a newer format and claim to be original thought leaders.

Think about the above.

And also think why conferences on business process and improvement may not be worth spending your time on if you want to learn something new and original.

However, these events are undoubtedly an excellent forum from professional network building point of view.

If you go with the above thought in  my your mind, you will not be disappointed.

For better network building, it is also a good idea to keep on asking couple of questions when you attend a conference so that you get noticed.

Better still, become part of a panel discussion, or take up a speaker slot, if it comes by.

And the best, the icing on the cake, is to become a key note speaker for delivering an invited talk.

And why is that the best?

First, you get the chance to dish out and peddle your stuff.

You need to speak about the same age-old and universal principles but in your own language,

And you would need to learn to use the flowery method of delivering a talk so that you also sound like an exert.

After all, those who have paid to attend the conference deserve some bang from the bucks they have spent on the conference fees.

Also the side benefit, you will need to start writing a book.

This would essentially mean you should be able to re-assemble the old ideas in a newer format and claim to be an original thought leader like others of the ilk.

Say that emphatically that you are working on a book when you give your talk.

You don't have to finish it though.

Don't worry, no one is going to check with you about the book after wards.

And yes, the book should include some colorful picture or table.

The other good thing is you will be paid for the talk, not for the book though.

So are conferences on business process and improvement worth spending your time on if you want to learn something new and original?

Think about the that when the next conference on business process and improvement comes up.

That will help.

Going is not a bad idea, but be clear what is it that you want to get out of it.

ROI of Agile Transformation

Agile transformation has become a catch word since last couple of years.

Like so many things that have come and gone, this is like the latest fashion in the town.

Is agile transformation about driving the adoption of a newer method such as Scrum, XP, SAFe, etc. by an organization?

Or is it something which is above and beyond and involves changes in the mindset required to make an organization truly agile?

The dictionary meaning of the term agile is quite interesting.

Agile means "to be able to move quickly and easily".

"Quickly" means the time required to do something is, relatively speaking, on the lower side.

"Easily" means the effort required to do something is, relatively speaking, on the lower side.

So Agile means quick and easy.

This is a simple but very good definition of the term agile.

Even when agile as a method was not there, agile as an English word always existed.

When you say something needs to be "quick and easy" it is a good thing to have.

Over time, obviously, people created agile methods with their associated rituals like scrum, etc.

Agile transformation needs to look at above and beyond the method-driven approach.

Given the above, we now agree that any organization needs to be quick and easy.

And consequently agile.

This needs a foundation level shift in the way the organization is structured and run.

The top man needs to adopt an agile-based thinking.

The top man needs to drive "quick and easy" aspect into the organizational strategy and operations.

Agile transformation is not a technical subject.

The simplistic and popular views prevalent on agile are not right in this context:
  • Agile is better than waterfall (one can leverage any method including waterfall in a truly agile environment)
  • Agile is fragile (the failure points in Agile like design refactoring which can render the system-level architecture less than optimal can be better handled using the right method)
  • Agile is for delivery function only (agile as a method can be useful for any function but agile as a mindset is most certainly useful for any function)
  • Agile is the cure for all ills (there is no silver bullet, agile certainly is not one and there will never be one even in the distant future)
Agile transformation as mindset change is definitely crucial for companies and organizations in the present times where change has truly become the constant.


So is agile a good thing to do?

What is the ROI of agile transformation?

ROI has two components - return and investment.

What is the return from agile mindset?

There are several benefits an organization can derive from agile mindset.

Here are some of the important ones:
  • The organization will have elaborate plans but will revisit and align the plans to keep them synchronized at all times with the changes in the environment.
  • The organization will look for ways to empower its workforce at all levels to take important decisions without too many layers of approvals.
  • The organization will have such policies in place that facilitate the various teams and their members to constantly improve their activities and operations to make them more "quick and easy".
  • The organization will have the right structure in place based on meritocracy and competency without consideration to  loyalty and longevity.
And what are the investments required for agile transformation?

There are several expenses an organization has to incur for instilling agile mindset.

Here are some of the important ones:
  • Setting up a dedicated core team to lead the agile transformation
  • Training of top management, core team and others on the agile way of thinking
  • Review and revision to the existing policies and procedures to align them with the concept of "quick and easy"
  • Up-gradation of internal tools to improve the agile factor
The expenses and investments are really no different from what one would incur for running any organization-level change management initiative.

Any agile transformation is nothing but an organization-level change management initiative.

So are the returns from agile transformation commensurate with the investments made?

Is the ROI promising enough?

Yes and no.

Yes, if there is real mindset and cultural change at a deep level.

No, if the change happens but stays at the method-level and is at the surface only.

Many organization-level change management initiatives do not deliver to their promise as they fail to bring in true cultural change.

Culture is hard to change.

And in fact, culture is the only thing that needs to be changed, in any organization-level change management initiative.

ROI calculation for agile transformation is done in a manner similar to what is used for any organization-level change management initiative.

As someone said culture has strategy for breakfast.

The ROI is good if the culture changes.

Culture changes happen if they happen first and for keeps at the top management level.

Top management in many companies is expert at giving lip-service.

They would show as if they genuinely care but scratch the surface and there is only dirt and dust underneath.

They need to let things go, which is very hard if not impossible.

ROI for any organization-level change management initiative depends upon them.

Similarly, ROI for agile transformation also depends upon them.

There is a simple magical trick to get the ROI from agile transformation.

The magical trick involves just one thing.

The top management needs to change first.

Unless these folks change, no change happens for real.

And unless these folks change, there is no ROI of agile transformation.