Model-based Improvement

Improvement in a business context means
  • Increase in effectiveness (achieving the specified business results)
  • Increase in efficiency (effectiveness with minimal resource utilization)
Improvement programs can be broadly classified as
  • Model-based such as ISO 9001, Six Sigma, ISO/IEC 27001, CMMI, etc.
  • Tool-based such as development of MIS automation, intranet portal, project management tool, sales forecasting tool, etc.
  • Campaign-based such as brand awareness drive, all employee communication, corporate road shows etc.
  • Innovation-based such as new product research and development, unique service offerings, etc.
Advantages of model-based improvement
  • Readily available structured framework to initiate, achieve and sustain improvement
  • Accelerated improvement as model encapsulates proven best practices
  • High acceptance among customers owing to external validation of internal systems and processes
Approach for model-based improvement




Roadmap for third-party assessment

 
Key critical success factors
  • Management Support - Sponsorship, commitment and involvement
  • Program Management - Costing & budgeting, Planning and control, Risk assessment and management
  • Resource management - Competence development of internal resources

Business Value of MBNQA, EFQM, CMMI, ISO, et al

The primary purpose and motive of any commercial organization is to capture and grow revenues and generate as high profit margins as possible by reducing the cost of doing business. It is a fact that every dollar spent reduces the revenue and ultimately the profit margin, so it follows from there that dollars need to be spent to generate additional revenues.

In this context, what should be the characteristics of a highly mature organization? Such an organization should be able to demonstrate business value through:
  • Sustained and ever-increasing revenues from continuous product/service innovations driven on the strength of solid business processes for engineering products/services and management of engineering activities
  • Optimized cost of business operations from ongoing improvements to business processes for higher effective efficiency
So do frameworks such as MBNQA, EFQM, CMMI, ISO, et al have any business value? Yes and no.

Yes, if the practices offered by the frameworks are adopted to bring in real improvements, resources are committed and utilized with complete seriousness and management is involved throughout and allows sufficient time for the returns to materialize. This can benefit in both ways – external recognition will improve chances to earn increased revenue from new customers, internal improvements will improve chances of retaining existing customers.

No, if the organization wants external recognition only for being able to attract new customers. In this case revenue growth may be experienced by adding new customers whereas at the same time revenues from existing customers may decline. Remember, existing customers will continue and give more business depending on their satisfaction with products/services actually delivered. It is also to be assumed that there is no strategic shift in their business approach such as change in business priorities where further investments on the products/services being procured is stopped or there are operational issues such as budgetary constraints.

The moot point still remains – do frameworks such as MBNQA, EFQM, CMMI, ISO, et al add business value? The answer is indeed an emphatic yes and since that is so, it means the frameworks offer practices which can make business processes both effective and efficient. There is enough empirical evidence in support of the above conclusion.

Also. these frameworks do not assume a linear view of the world that customers know what they want very precisely and want it with best quality, at the cheapest cost and delivered fast. Remember your customer is a supplier to its customer and knows these are conflicting objectives and the best solution is necessarily not the best but the optimal – which is dynamic and changes as per the situation.

What this means is that process should adapt to business requirements and dynamically scale up and scale down as the need be. Of course, there will be some holy cows – processes that can never be challenged no matter what (these are the one which are directly derived from and related to the organization’s core values). 

Adopted withe above dynamism in mind, MBNQA, EFQM, CMMI, ISO, et al bring immense business value. As someone said, Judo techniques are always good but the way they get used may differ and so will the outcome. One person can use them to kill another person and end up getting imprisoned whereas another person can use them to beat another person and end up becoming the World Judo Champion!

What Companies Want?

Companies are meant for doing business. And doing business means money.

So what companies want? What companies say what they want is not what they really want. What they actually mean by what they want is different from what they say they want.

The following table explains the above clearly. What they actually mean what they want is always to do with money - hard dollars.

 

Data Management Maturity (DMM) Model from CMMI Institute

The Data Management Maturity (DMM) Model was unveiled in May 2014 and released in August 2014.

This is a model that was developed by and is maintained by the CMMI Institute.

The CMMI Institute is well know for its CMMI family of models (CMMI for Development, Services and Acquisition) .

DMM model is intended to help business organizations improve their data management practices across the board.

Data management is an area that needs high level of attention by any organization as the organization's strategy and direction is increasingly becoming dependent on data.

The major challenge there is the sheer amount of data that is getting generated on a daily basis, the world over.

This also leads the way towards what can be called as digital junk.

Digital junk is all the useless data that is getting generated along with the useful ones.

In addition to the sheer volume, determining what data is useful and then making it available in the right processed format to the right user at the right time is very crucial for correct decision making by the executives involved with a business problem in an organization.

Data generation is not only internal within the organization but also outside as well.

Lot of outside data is also useful when making a decision.

Big data, data analytics, data warehousing and mining, business intelligence are some of the terms that indicate towards the need of a framework for data management.

The model contains specific process areas grouped by categories.

It can be implemented and assessed either across the entire organization or a selected business unit based on customer, geography or product/service.

The DMM Model has the following major categories:
  • Data Management Strategy
  • Data Governance
  • Data Quality
  • Data Operations
  • Platform & Architecture
  • Supporting Processes
Data quality is the bedrock of any management system to derive the right set of actions.

So deep focus on data quality is of paramount importance.

Data quality category has the following process areas:
  • Data Quality Strategy
  • Data Profiling
  • Data Quality Assessment
  • Data Cleansing 
Process areas under Data Management Strategy category:
  • Data Management Strategy
  • Communications
  • Data Management Function
  • Business Case
  • Funding
Process areas under Data Governance category:
  • Governance Management
  • Business Glossary
  • Metadata Management
Process areas under Data Operations category:
  • Data Requirements Definition
  • Data Life-cycle Management
  • Provider Management
Process areas under Platform & Architecture category:
  • Architectural Approach
  • Architectural Standards
  • Data Management Platform
  • Data Integration
  • Historical Data, Archiving and Retention
Process areas under Supporting Processes category:
  • Measurement and Analysis
  • Process Management
  • Process Quality Assurance
  • Risk Management
  • Configuration Management

Payment Card Industry Data Security Standard (PCI DSS)

The Payment Card Industry Data Security Standard (PCI DSS) is a standard maintained and promoted by the PCI Security Standards Council.

This is an important standard that is related to securing payment cards and cardholder data. This standard is useful for vendors involved in creating securing payment solutions. It is also useful for the merchants and financial institutions that process card payments worldwide.

PCI DSS iss also applicable to any entity that stores, processes or transmits cardholder data (CHD) and/or sensitive authentication data (SAD).

The Requirements and Security Assessment Procedures, Version 3.1, released in April 2015 of this standard provides the list of necessary practices.

The practices are spread across and pertain to the following areas:

Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data
Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need to know
Requirement 8: Identify and authenticate access to system components
Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes.

Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security for all personnel

Appendix A:  Additional PCI DSS Requirements for Shared Hosting Providers 
Requirement A.1: Shared hosting providers must protect the cardholder data environment

Appendix B: Compensating Controls
Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other, or compensating, controls. 

ISO 9001:2015 - 2015 Revision of the ISO 9001 Standard

ISO 9001:2015 was released on 23 September 2015. For the official communication of IS0 9001:2015 release visit the link http://www.iso.org/iso/home/news_index/news_archive/news.htm?refid=Ref2002.

ISO 9001:2015 marks a significant milestone in the journey of the ISO family of standards. Starting with ISO 27001:2013, the  ISO family of standards are being aligned with a standard structure (known as the High-Level Structure). This is very useful for those organizations that comply to more than one of the ISO standards.

In addition to bringing better integration across various standards the new structure improves upon consistency in understanding and implementing the basic principles that constitute a good management system. The most famous of these principles is the PDCA (Plan-Do-Check-Act) or Deming or Shewhart cycle which deeply embedded in the ISO standards.

ISO 9001:2015 also brings in the risk-based approach. This is quite similar to the concept of Enterprise Risk Management (ERM). Viewed logically from a pure business perspective the management systems in any organization essentially have a sole purpose - how to reduce surprises and disruptions to the business?

This aspect is also covered as part of the business continuity management (BCM) strategy of the organization. In some sense, ERM and BCM are trying to solve the same business problem, the difference being in their orientation. BCM talks about how to ensure continuity in case a disruption occurs whereas ERM talks about how not to let disruptions occur in the first place.

The above concept finds explicit recognition in ISO 9001:2015 now. It is interesting to note that similar to ERM the scope of ISO 9001:2015 can be extended beyond the traditional areas of the core operations and its management.

The risks to an organization can be from multiple and varied sources as listed below. Risk originating from core operations and its management.is just one of the sources:
  • Core operations and management
  • Government rules and regulations
  • CSR and good corporate citizen duties and responsibilities
  • Employee rights and safety
  • Customer rights and obligations
  • Financial and liquidity position
  • Management actions and constraints
ISO 9001:2015 provides a comprehensive framework for risk-based approach to doing business. This allows the focus to shift to managing performance through managing processes.

Processes stay an important part of the ISO 9001:2015 standard. However, the flexibility in terms of documentation has gone up a few notches higher by introducing the phrase documented information.

On ground, however, this has already been happening. Information in the form of emails and accessible over the screen of information/IT applications has for very long been considered a valid document. The idea is that the data/information should be visible and verifiable, which is clearly met in such a situation.

When it comes to software development and other organizations that are using the CMMI framework, any level 3 or higher implementation would have risk management framework already in place. The focus in CMMI is on project-level risk but it can be easily extended to identify and manage risks to the business at the organization-level.

For those organizations that have ISO 27001:2013 implementation in place, risk management would already be happening on risks to information assets. This concept can be extended further with necessary adaptations to include risks to the business itself at the organization-level.

For those organizations that are already ISO 901:2008 certified, the changes required on the ground would be few and far. Some of the changes are as follows:
  • Revisit Quality Policy to include a reference to risk-based approach
  • Revisit and update Quality Manual by adding a section for risk management both at department-level (which would include departments beyond the core operations and its management) to be manged by the department heads as well as at the organization-level to be managed by the head of the organization.
  • Quality Manual may also be restructured in line with the High-Level Structure. This is optional though as long as the Quality Manual covers the ground fully.
  • Create or modify existing processes in line with the changes to the Quality Manual
So what is the level of effort required to transition to ISO 9001:2015? In summary, here is the level of effort required to transition to ISO 9001:2015:
  • If only ISO 9001:2008, then lot of effort
  • If the above and also ISO 27001:2013. some effort
  • If the above and also CMMI maturity level 3 and higher, minimal level of effort

Process Simplification through Process Flow Charting Tools

There is this perception in many organizations that their processes are very heavy. The process or SOP library is typically a web-based portal with multiple process documents and other artifacts put together in some kind of a structure. The sheer number of process documents and artifacts can give rise to the feeling that "processes are very heavy".

One reason for the above is that in most organizations processes are captured in the form of a text mostly as a word document. This leads to some of the following challenges cropping up as a result:
  • Defined processes are not easy to understand. Text-based processes cannot capture the various decision paths neatly.
  • Defined processes are not interlinked. It is hard to link sections across multiple documents.
  • Activities to be performed by a role do not come out clearly. It is scattered across multiple process documents.
  • Defined processes cannot be viewed at different levels of granularity. Capturing different levels of granularity makes the process documents heavy.
With flow charts it is very simple to:
  • Understand the process flow
  • Interlink various processes cutting across departments
  • Generate responsibilities of a role at the click of a button
  • View process at different levels of granularity, again at the click of a button
Process flow charting tools can thus be used as a powerful tool for process simplification. The first step in process simplification is to map out the process clearly. This would facilitate the identification of the steps that can be cut down or optimized or moved in the work flow.

As it is pretty straightforward to change a process flow chart if an organization uses a process flow charting tool, coming out with the simplified process is so very simple!

Using CMMI to Achieve Business Results

CMMI is truly a wonderful process model and its integration with Agile and Lean can accentuate it to enable exponentially higher business outcomes for organizations.

However, an organization needs to focus on all the four elements of strategy, people, process and technology to reap the real business benefits.

Many organizations seem to carry this belief that a process model be it CMMI, Agile or Lean by itself is good enough and fail to realize the significance of the other three elements.

And when they fail to achieve business outcomes the tendency is to question the value of the process model rather than failure of the leadership of the organization in envisioning the right strategy, building the needed competency and culture, and establishing the right set of tools and infrastructure.

Inability of an organization to achieve business results is more of a function of lack of leadership vision and non-provisioning of required resources to employ a process model effectively rather than the process model by itself.

Audits and Project Success

Project success depends on several mechanisms which form part of the overall governance framework.

The mechanisms include management reviews like proposal reviews, project status reviews, program status reviews, top management reviews and process audits.

In addition to the above management reviews, there needs to be rigorous technical reviews of requirements, design, implementation, verification & validation, delivery and installation.

Audits are but one of the several mechanisms for an organization to make sure things go right. Some organizations think that audits can solve all their problems.

Its like thinking that more testing will help improve product quality.

However, the focus should be on improving how things get done right the first time rather than how to better find whether they got done right.

In the case of software, quality of the software depends on the quality of the code and not how well it got tested.

Testing cannot inject quality it can only enable quality by identifying issues and defects before it gets shipped to the customer.

It would, in fact, add to the eventual cost of the software and someone has to pay for it.

CMMI Next Gen

CMMI for development, version 1.3 was released in the year 2010, towards the end of that year to be more precise (sometime in October/November 2010, to be even more precise).

Like the ISO standards which are revised every 8-10 years, CMMI models also undergo revision periodically and the process for the latest revision has already been initiated. It is being referred to as CMMI Next Gen or CMMI Next Generation.
As a side information, it is useful to note that the revision to 2008 version of ISO 9001 standard is due and is interestingly enough slated for release sometime this month - September 2015!

As is the convention it will be called as ISO 9001:2015. The technical committee entrusted with the 2015 revision has claimed many significant changes.

However, many people believe that these are mere paper changes and will not lead to significant changes in the implementation on the ground.

And that is how it should be. The standard is based on fundamental principles of quality management as propounded by Shewhart, Deming and Juran which remain unchanged.

These principles apply to CMMI as well.

Coming back to CMMI, the CMMI models (development, service and acquistion) and the appraisal method (called with a complex sounding term SCAMPI A) can undoubtedly be improved.

Following aspects related to CMMI need a closer and deeper investigation as CMMI Next Gen gets crystallized:
  • There is no area that focuses on customer management. There are areas related to internal management and partner/supplier management, however, the most important stakeholder, the customer, for which work is performed doesn't get the kind of focus it should.
  • The appraisal duration is on the higher side which leads to excessive strain on the organization. First, getting appraisal team members for a long duration is not easy. Second, logistics challenges tend to be huge. And third, the cost of appraisal becomes high.
  • Appraisal team involves internal employees which is not efficient. The internal members have a narrow view and understanding of the practices and it is not clear how significant their contributions are given the lead appraiser would eventually have his way. The reason for this is that the lead appraiser has a better understanding or at least this can be assumed to be so in most cases.
  • Use of the term "high maturity" in CMMI model is not appropriate. Use of control charts, regression, design of experiments, etc. are common practices in a manufacturing context and there is really nothing "high maturity" about it.
  • In fact, applicability of statistical techniques especially control charts and modeling in CMMI needs to be validated much more rigorously. Software processes owing to their high dependence on human factor tend to have high outcome volatility. An example to illustrate this is that the quality of same code written by a developer would be different on different days as also the quality of same code written by two developers would be different.
  • CMMI level 5 is really nothing but six sigma and it would be appropriate to label it so. Use of the term OPM makes it sound more complicated than it actually ought to be.
  • Explicit referencing of existing tools and methods like six sigma and TQM is the right way to go. Explicit linkages to these should be part of CMMI model. For example CAR is nothing but RCA and Fishbone/Ishikawa diagram which is a TQM method known much before CMMI came into existence. Similarly, QPM is nothing but statistical monitoring and control, again a decades old concept.
  • Lead appraisers for CMMI need to have formal education/training in decades old concepts from TQM, lean six sigma, etc. Many lead appraisers don't have clear understanding of statistical theory and hence use approach for level 4 and level 5 practices that are not scientifically validated.
CMMI Next Gen provides a good opportunity to further improve CMMI framework. The key is to recognize and articulate how it can fit into the overall business excellence framework of an organization.

Another aspect worth pondering about is how it can be promoted as a framework that can help organizations that are not just doing software. Legacy has ordained CMMI to remain limited to software companies and CMMI Next Gen should focus perhaps on breaking this barrier more than anything else.

CMM/CMMI Development Timeline

1979 - Quality Management Maturity Grid Philip Crosby, "Quality is Free"

1985 - IBM Maturity Grid
R.A. Radice, J.T. Harding, et al, "A Programming Process Study", IBM Systems Journal, Vol. 24, No.2, 1985.

1987 - Maturity Questionnaire
W.S. Humphrey, "Characterizing the Software Process: A Maturity Framework", Software Engineering Institute, CMU/SEI-87-TR-11, DTIC Number ADA182895, June 1987.
W.S. Humphrey and W.L. Sweet, "A Method for Assessing the Software Engineering Capability of Contractors", Software Engineering Institute, CMU/SEI-87-TR-23, DTIC Number ADA187320, September 1987.

1989 - Capability Maturity Model
Watts Humphrey, "Managing the Software Process", Addison-Wesley, Reading, MA, 1989.

1991 - SW-CMM, v1.0

1993 - SW-CMM, v1.1

2002 - CMMI, v1.1

2006 - CMMI, v1.2

2010 - CMMI, v1.3

20XX - CMMI Next Gen

Six Sigma Development Timeline

1733 - normal curve developed as an approximation to binomial distribution by Abraham de Moivre

1783 - normal curve used to describe the distribution of errors by Pierre-Simon Laplace

1809 - normal curve used to analyze astronomical data by Carl Friedrich Gauss

1924 - statistical process control launched for quality improvement by Walter A. Shewhart

1984 - internal quality research report in Motorola on the correlation between how well a product did in its field life and how much rework had been required during the manufacturing process by Bill Smith

1985 - development of a four-stage problem-solving approach: Measure, Analyze, Improve, Control (MAIC) by Mikel Harry

1987 - six sigma launched in Motorola by Bob Galvin

1991 - six sigma launched in Allied Signal by Lawrence Bossidy

1995 - six sigma launched in General Electric by Jack Welch

ISO 9001 Development Timeline

WWII -  Inspectors and “quality system requirements” for suppliers (Ministry of Defense, UK)The Government placed inspectors in weapons factories in an attempt to solve the problem of bombs going off in the factories. To become a supplier to the Government a company had to document the procedure for making the product, have the procedure inspected by the inspector and ensure the procedures were followed.

1959 - MIL-Q-9858a (US Military)

1968 - AvP92 (British Ministry of Technology which handled defense materiel procurement)

1969 - AQAP (NATO quality management specifications)

1973 - DEF STAN 05/21 (Ministry of Defence, US)

1979 - BS5750 (British Standards Institution)

1987 - ISO 9001:1987 (ISO)

1994 - ISO 9001:1994 (ISO)

2000 - ISO 9001:2000 (ISO)

2008 - ISO 9001:2008 (ISO)

2015 - ISO 9001:2015 (ISO)

Agile Development Timeline

1986 - "approach similar to rugby" for commercial new product development Takeuchi, H. and I. Nonaka, "The New Product Development Game", Harvard Business Review, 1986 (January-February).

1991 - use of the term Scrum (term of rugby) for the "approach" DeGrace and Stahl, “Wicked Problems , Righteous Solutions”

1993 - Scrum used at Easel Corporation by Jeff Sutherland

1995 - Scrum paper presented by Jeff Sutherland and Ken Schawaber in OOPSLA'1995

1996 - XP used at Chrysler by Kent Beck

2001 - Agile manifesto signed by 17 original signatories