Category: Quality Improvement

Posted on

What is Annex SL in ISO 9001-2015?

Annex SL is a platform upon which all the ISO management system standards rest. Yea, many more are there yet to reach the platform.  Some already took their places, including ISO 9001. With the September 2015 release, ISO 9001 also became a member in this Annex family.

Through this post I’m trying to analyze the change in perspectives/added advantages introduced in the ISO family with the introduction of Annex SL.

Annex SL- An Integrated Management System Approach

It was pretty difficult to manage the parallel show inside an organization with multiple management system standards. And difficult for the auditors too. Even though the standards like ISO 9001, ISO 14001, ISO 27001 have many common elements, there were described and organized differently. Thus it was a cumbersome task for organizations to implement them together. Now the similarities across the standards are framed under a common umbrella and removed the conflicts across the standards. Thus Annex- SL makes the creation of an integrated management system much easier.

Annex SL – A new template for ISO management system standards

Annex SL is written primarily as a guide to who creates new standards. The core of Annex SL consists of 8 clauses and 4 appendices. (Illustrated in the below figure)

It is said that every ISO standards should adhere to the clause structure defined in Annex SL. Hence in fact, with this framework ISO itself got a template to build new standards. To address industry specific needs, additional requirements for discipline specific sectors will be added to this generic framework.

Annex SL – Easier for Users

Annex SL provides an identical structure, terms and common concepts for all ISO management system standards. This will ensure consistency among revised and future management system standards. Hence users will find it easier to read and understand the standards.

Annex SL- Easier for Auditors

Auditors will have a generic set of requirements as a guideline to follow irrespective of the discipline. This will make their job much easier.

 Annex SL – Is it not a cost saver..?

Definitely Yes, It saves pretty much time as well as cost.  It helps to have an integrated management system eliminating the duplication efforts and conflicts within the multiple standards.  Conflicts always call for additional resources. If the conflicts are reduced, rework and in turn resources are reduced. Also it is pretty much clear that the maintenance of an integrated management system is always economical compared to the maintenance of multiple separate management systems.

Annex SL – The business focus

When different management streams are integrated, it becomes easier for the senior management to set their vision mission, goals etc. Also the integration helps the management to streamline the entire business operation.

annex SL

In short, Annex SL is a lot more than just a common framework for Management System Standards. It streamlines the creation of new ISO standard as well as provides an option for integrating multiple management system requirements.

Posted on

In CMMI, have you noticed the evolutionary path for Process Areas? Infact CMMI Maturity Levels are defined as evolutionary stages of process improvement.

An evolutionary process is a process whose stages consist of expanding increments of the defined process.

Watts Humphrey’s Capability Maturity Model (CMM) was published in 1988. According to him organizations mature their processes in stages based on solving process problems in a specific order. Humphrey based his approach on the staged evolution of a system of software development practices within an organization, rather than measuring the maturity of each separate development process independently.

CMMs focus on improving processes in an organization. CMMI describes an evolutionary improvement path for the processes from ad hoc, immature processes to disciplined and mature processes with improved quality and effectiveness.

In some Process Areas the evolutionary path is very evident. It is detailed below.

Evolutionary paths are expected to be one of the new features in CMMI Next Generation

Measurement and Analysis starts at Maturity Level 2 and becomes more quantitative and statistical analysis at High Maturity levels. Even at Maturity level 3 Verification process area and Validation process area demand analysis of peer review data (SP 2.3 in VER) and validation results(SP 2.2 in VAL).

Requirements Management at Maturity level 2 talks about ensuring alignment between project work products and requirements through reviews and all (SP 1.5). Verification process area at Maturity Level 3 supports this process.

Risk Management begins at Maturity Level 2 (Process Area- Project planning SP 2.2 and Project Monitoring and Control SP 1.3) and becomes robust at Maturity Level 3.

Project Planning process area talks about planning for knowledge and skills needed to perform the project. This is aided by the Organizational Training process area in Maturity level 3 by which people can perform their roles effectively and efficiently.

Project Monitoring and Control talks about issue analysis at Maturity level 2 which becomes much more elaborated at ML5 in Causal Analysis and Resolution Process Area

The Process Area Organizational Process Focus is treated as a younger brother of the PA -Organizational Performance Management

Integrated Project Management at maturity Level 3 talks about establishing an integrated and defined process that is tailored from the organization’s set of standard processes. And Quantitative Project Management at Maturity level 4 talks about composing a defined process quantitatively to help the project to achieve the project’s quality and process performance objectives.

The below picture illustrates the Evolutionary path of the mentioned Process Areas

Evolutionary PAs

Posted on

“Walking on water and developing software from a specification are easy if both are frozen.” –  Edward Berard

Baseline means ‘A Line which is the Base’. The word baseline may refer to surveying, typography, budgeting, pharmacology, Configuration Management, calculations etc.

In an IT industry, baseline mainly implies

  • A Configuration Baseline – A configuration of software, hardware or a process that is established and documented as a point of reference
  • A Process Performance Baseline (PPB) – A datum used as the basis for calculation or comparison

Configuration baseline

As and when a work product is created and ready for review, it should be labeled as ‘ready for review v0.9’. (The version number may change based on the project’s strategy). And at the same time the work product should be available in the configuration tool. Once the review, rework and verification are completed the work product is ready for approval. There should be an identified approving authority for each work product. After the approval, the work product is baselined. (The baseline string can be ‘baselined v1.0’). Whenever a change is triggered in the work product, initially an impact analysis is triggered. Impact analysis helps to understand the change in cost, schedule, competency requirements, affected work products etc. The Change Control Board (as defined in the project plan) should approve the change in order to update the work product. After update, the work product undergoes review, approval and baselining process ( If the change is a minor, the review process can be skipped as defined in the project plan). The baseline string can be ‘baselined v1.1’or ‘baselined v2.0’depending on whether the change is a minor or major. All the change requests should be recorded and tracked for future reference.

If there is no configuration management, many people have to work on a work product that is altering. It creates copy-over problem, which causes versions of files to be lost. The number of uncontrolled copies of files makes it difficult to determine where the latest version really exists or not.

A configuration baseline is the configuration of a service, product or infrastructure that has been formally reviewed and approved, that thereafter can be changed only through formal change mechanisms.

Process Performance Baseline

Project data is recorded in the organizational metric repository. And from the data, performance baselines are created, in most cases the center line and upper and lower control limits from a control chart on that process execution. These baselines are used as a benchmark for comparing actual process performance against expected process performance and are revisited over a defined frequency.

These baselines are used

  • In project estimation process
  • While setting Objectives for the project
  • As inputs to the process performance models

Baseline helps to monitor current project performance and also to improve the accuracy of future estimates.

In short

A Configuration baseline shows the current state of a configuration item while a Process Performance Baseline shows the current performance of a process.

 

Posted on

Have you ever wondered about the difference between Acceptance criteria and Requirements?

Have you ever thought why they need to be documented separately?

Requirements and acceptance criteria seem to be the same, but it’s not correct.

Requirements are at a higher level while acceptance criteria at a lower level, more towards the delivery point. Requirements and acceptance criteria would seem to be the same. In an ideal world acceptance criteria may be equivalent to requirements. But in the real world a lot of changes happen during the course of time.

Requirements are what you are supposed to do. Acceptance criteria are agreed upon measures to call a project “done.” Acceptance Criteria are a set of statements, each with a clear pass/fail result. Testability has a close connection with acceptance criteria.

Let us work out a simple example.

I wish to buy a new watch by this month end. It should have a broad silver strap with a round face. Also it needs to be an alarm watch with multiple time zones. Its cost should be less than 100$. And finally it should suit my style. These are my specifications or requirements pertaining to the watch.

Now what are my acceptance criteria? Do I need to consider all of those requirements as acceptance criteria? Or is there anything more that I need to consider while choosing my acceptance criteria?

I define my acceptance criteria as

‘I have to go to a watch store (not online) and purchase the watch. I need it, if and only if I could purchase it before this month end.’

Here, the above stated acceptance criteria are independent of requirements. If I add below more statements to the above, then the acceptance criteria becomes related to requirements.

‘It should have broad silver strap with a round face. There should be a provision to set alarm. It should be possible to alter time zones. And its prize needs to be less than 100$’

So what are the acceptance criteria?

It could vary based on how the user defines it. It is possible for a developer to complete only a few of the requirements, and still meet the acceptance criteria to finish the project. Basically it is a set of agreements which needs to be satisfied for a user to accept the product. These agreements are not static. It varies whenever there is a change in condition. Below are some examples of change in conditions which leads to the change in acceptance criteria over the course of time.

  • Budget changes
  • Requirements change
  • Schedule changes
  • Competency changes

In short, it is not necessary to have all the requirements in acceptance criteria. In some case some requirements (the so called “nice to have” requirements) may be cut down and be considered in next iteration. Sometimes acceptance criteria may be totally independent of requirements.

 

Posted on

Nowadays there are many process improvement techniques and tools around us. It is a different thing whether we use them in the right way or not. Some commonly used models in these days are CMMI, ISO 27001, ISO 9001, ITIL, 6 Sigma etc. When the number of process improvement models and techniques are increasing, the decision of picking the right stuff for the organization becomes really crucial. In addition the choice of order and priority selection may be an aspect which becomes highly important. First of all organization needs to analyze which are their painful areas. Then based on the same, they need to evaluate different models and choose the best fit. Definitely organization decision of selecting a standard could be purely customer driven too.

Once the standard is picked and achieved compliance to it, then many organizations go for formal evaluation by certification bodies. Proper care should be given while selecting the certification agencies too, as there are many. They need to be authenticated agencies. While evaluating several certification bodies it needs to be remembered that the cheapest could be more expensive in the long run if its auditing is below standard.

Posted on

Traceability is the ability to trace the origin. In simple terms a police man identifies thieves by tracing out finger prints or so.. Traceability plays a key role in Requirements Management. It helps to conduct impact assessments when change in requirements happens.  Some unique identifiers are given for each requirement. These requirements are elaborated from the user needs provided by the customer. Thus traceability starts with user needs and then extends to the

Continue reading→

Posted on

 

Tailoring

 

Is this tailoring..?

Definitely not.. tailoring is not a way to escape from a difficult task.

Tailoring enables one to execute the task via an alternate mechanism instead of the usual procedure. Tailoring doent mean to simply skip the current procedure/process. If the process is difficult , then one must find  some other simpler mechanisms to execute the task so that end results are fruitful.

Where is Tailoring mentioned in the CMMI?

CMMI GP 3.1 Establish a defined  Process talks about

Continue reading→

Posted on

Review process is intended to ensure the completeness and correctness of the work products. Merely performing reviews does not meet the full purpose. Reviews must be followed with

Proper correction

The defects need to be fixed and the completion status of reported defects needs to be logged properly. After rework the work product needs to be labelled suitably.

Verification by reviewers after correction

Reviewer needs to ensure the verification of the work product against the reported defects.

 

Root cause analysis of defects

Major or repetitive defects needs to be further analysed to determine the root causes.

 

Taking corrective actions on root causes of defects

Further to root cause analysis, action plans to prevent recurrences of the defects needs to be taken

Review Data Analysis

Review parameters like review speed, review effectiveness etc needs to be analysed and compared against the goal set for those parameters. Further actions needs to be deployed based on the analysis. For more information please refer the post on Review Data Analysis

Making Frequently Committed Defect List (FCDL)

FCDL can be made taking review feedback from the reviewer. And FCDL needs to be continuously updated after each round of review. The key is to learn from faults and consciously avoid repeating them.

Conducting Trainings

Trainings can be triggered to avoid repetition of defects or to improve the depth of review

Communicating the status to stakeholders

Finally, it is important to ensure that the status of review, rework, corrective actions etc. is communicated to all stakeholders.

 

Posted on

Reviews can be analysed based on a number of metrics.  A few of the review metrics are given below

  • Review coverage             : Reviewed Size/Total size
    • For example, if 50 pages out of 100 pages of an artefact are reviewed, then review coverage in percentage is 50 % only. In case 100% review is not possible, the Project Manager or concerned person can identify the critical areas in the work product which need to be mandatorily reviewed.
  • Review Speed                   : Reviewed Size/Total time taken for review
    • For example, if a 1000 Lines Of Code (LOC) is reviewed in 5 hours, then review speed is 200 LOC/Hr.
  • Review Effectiveness    : Defects caught in Review/Total number of defects caught in review and testing
    • For example, if 100 defects were caught in a project including user acceptance testing and 50 of those defects were caught during reviews, then Review Effectiveness will be 50 %
  • Review Defect Density: Defects caught in Review/ Reviewed Size
    • For example, if 100 defects were caught during code review (reviewed LOC =1000), then Review Defect Density will be 0.1 defects/LOC or 100 defects/KLOC

Analysis is not limited to defining and evaluating a metric. From the observed data recommendations must be put forth. Sometimes,

Continue reading→

Posted on

A gap analysis is normally done to identify the gaps/missing in the existing system. The current system is compared to a master standard while doing the gap analysis. A gap analysis reveals gaps in written procedures as well as gaps in practices.

If the organization is already compliant to some older versions of the standard/some other standards, some process and procedures may be there in the organization. So first step is to

Continue reading→