Agile and Fr(agile)

Imagine you are a building contractor and a person wanting to build a house comes to you. He tells you he has a piece of land on which he wants to build a house but he doesn't know what kind of house he wants. What approach would you take?

Approach A (Agile):
  • You get your team to start digging the ground from next day 
  • You are told by the person who wants that house (your customer) what he really wants on a daily basis (almost) 
  • You don't know how many floor and rooms your customer wants until he himself knows and chooses to tell you 
  • You are ready to re-do the brickwork as many times as the customer suggests changing the size and location of the rooms 
  • You team meets every morning and discusses what they did yesterday and what they need to do that day
  • Your team works without any blueprint but talks very often 
  • You start building a wall and stop when the customer and team members feel it looks wide enough
    Approach B (Traditional or Waterfall): 
    • You make sure the requirements are known to a reasonable extent before starting the digging 
    • You work with the customer to crystallize the requirements to a finer degree as the construction progresses You agree on the structure and overall design such as the number of floors and rooms 
    • You are flexible but in a disciplined way, changes are welcome but done based on techno-commercial feasibility analysis which becomes more and more formal as the number of walls and rooms increases 
    • You meet as and when required (and periodically as well if it makes sense) but the discussion is not only on yesterday and today but also what is needed to deliver the house to the customer as committed while ensuring your margins remain intact 
    • Your team talks and also refers to critical guiding documents like the blueprint, electrical wiring layout, etc. You know the exact width of a wall before the first brick is laid
    Approach A versus Approach B - Is Agile Really Better than Waterfall? Or is Waterfall Model, Original and Forever?
      If you are a contractor you will most likely prefer approach B. The first approach is what would be an agile approach. It may work perfectly well but the change dynamics will make every day a challenge. This approach has an inherent fragility where it is difficult to predict what kind of house will emerge finally. It is possible the customer gets his dream house but that will depend on nothing going fundamentally wrong until the very end. At the same time the contractor may not be able to protect the profit margins because of too many change cycles. The second approach is what would be a traditional approach. Here the customer needs to know a great deal about what his dream house is going to be like and in case he was not right in his assessment of what a dream house means for him may end up not getting it. In this case the contractor may be very well able to protect the target profit margins.

      Now consider what would you prefer if you are the customer? But obviously approach A. Isn't it interesting? As a customer you'd want maximum bang for your bucks and you'd love to get every change in your mind implemented till the last day at no additional charge. Besides, no one can blame you for not thinking hard through your requirements in the beginning because in this kind of agile approach you not supposed to do that.

      Using Waterfall and Agile Together or Using Whichever Seems More Appropriate

      Agreed there are situations where the final solution emerges through experimentation with alternative approaches (especially in emerging technologies where the behaviors are still not fully understood). In such cases being agile during the solution building process has its merit. However, even in such scenarios at some point in time the solution needs to be pinned down and taken to its conclusion. The fragility in such situations is a natural outcome of not understanding how a particular approach will work but needs to be frozen nonetheless to deliver the final solution.

      Agile though fragile has its own advantages. The closeness between the two words agile and fragile is an interesting co-incidence. For any new technology though the initial work may happen using approach A there has to be a constant attempt to migrate to the approach B so that predictability and profitability is assured. This is crucial in a business context. For research, academic, first of its type, prototyping kind of work approach A (agile method) is probably a right choice however the inherent fragility in this approach has commercial implications and needs to be frozen to move towards the approach B (traditional method).

      P.S.:

      The adoption of agile methods in software development is considered to be a kind of revolt against the heavy, plan-driven, waterfall-like methods and models. It is clear however that these two approaches complement each other. If you are sure go traditional, if not go agile but try to be sure rather than not.

      Waterfall Model, Original and Forever

      The not so positive perceptions which have been created around the waterfall model have probably to do more with the lack of understanding among the software professionals than anything else. It is interesting to note that every model and methodology which has been proposed has always been defined against the backdrop of waterfall model - either as its derivative (like V-model, incremental, iterative, etc.) or as an alternative (like agile, etc.).

      It is also interesting to note that the description of these 'new' and supposedly better models and methodologies has been around how they have managed to address the shortcomings of the waterfall model. The above discussion seems to have reached a new height with the advent of the agile methodology in the last decade (the agile manifesto came into being in 2001).

      Agile has been proposed as an alternative to the supposedly 'heavy' waterfall model. Lot of discussion has been about how agile will eventually replace waterfall. In all this discussion the key message seems to have got lost somewhere.
      • The first and the most fundamental question is "why is software required in the business context"? Is it for the creative satisfaction of the software developer or serving a business need of the software user? It can be safely assumed that is is always the latter that any CEO will agree to and for very obvious reasons. This basic understanding clearly implies that a software project is meant to deliver business value to its customers.
      • The second question is "can we ever develop perfect software"? Ideally one would want that to happen but based on pragmatic considerations this is like being able to count till infinity. It follows from here that some bugs will remain and more importantly the customers will be willing to tolerate it subject to considerations of applicable laws and regulations, safety, reliability, availability, functionality and value for dollar spent to procure and use it.
      Combining the above two aspects one would arrive at the conclusion that software is for a customer and its value should be as defined by the customer. The software must operate as it should and in case it doesn't and fails it must fail safely. And this is a fair expectation from not only software but any product or service which is there in the market.

      Would one be happy if the meal offered on the flight is cold and stale? or worse the pilot informs that the fuel tank has been leaking and the plane is going to crash? The answer to both is no, however the second no is much more serious case.

      Drawing analogy to the software domain would one be happy if while working on a document the software freezes and one has to reboot the machine and looses few lines of data? or worse while making an online payment one's credit card details are stolen? Again the answer is no with the second no being more serious than the first one.

      Waterfall should be looked at as a concept that promotes efficiency. The essence of waterfall is zero rework. Once a phase is complete it never gets revisited and that means no rework, which means higher efficiency. Waterfall concept assumes that the most efficient way to do software is to do it right first time.

      Living up to pure waterfall approach is extremely difficult as human mind hasn't evolved to the level where the intended system behavior can be understood perfectly at the start (as this involves two subjective factors - humans talking/writing/reading in a language like English which is not based on scientific principles) or the exact on-field behavior of a system at the architecture and design stage predicted with absolute certainty. And then there are natural reasons like new technology, new regulations, new concepts, new thoughts etc. which might trigger changes to the original system requirements and design.

      Use of a pure waterfall approach was never the case even in the past. Even in the so called waterfall projects design changes to take care of issues and defects observed in end-stage testing is not an unheard phenomenon. The preparation of a list of "known issues" that usually gets bundled as part of the software package for release is a very common practice. The firefighting projects pass through at release time is also a common occurrence.

      These examples demonstrate that a pure waterfall was never and can never be followed. No one would, however, disagree with improving the way software gets developed and the constant attempts to reduce the cycles of rework and minimize the list of "known issues".

      Taking this one step ahead, use of iterative, incremental, spiral and agile can be seen as essentially doing waterfall in short and repetitive cycles with overlapping and parallel phases and activities, as the case may be. Especially in respect of agile one must consider the answers to some key questions:
      • Is agile an original concept? not really. It is not fundamentally different from the decades old concepts of incremental, iterative, spiral development
      • Is agile valid from a scientific or conceptual standpoint? not really. The agile manifesto tends to view software development work as an art and not science. Even conceptually it seems to encourage rework over solid understanding of the customer's need and the proposed solution right at the start (evolution in understanding can't be considered as an excuse for not applying scientific methods at the start to gain as much understanding as possible in a cost-effective and pragmatic manner)
      • Is agile the proverbial silver bullet? not really. Every model and methodology has its pros and cons. However, the ultimate acid test for any model is the business value it helps to create for the end customers. One may use use different model at different stages of the project as is the most appropriate.
      • Is agile 'the model' the software industry was waiting for? not really. It is one of the many models that have come up in the last and newer ones that will emerge in the future
      Agile is essentially about recognizing the importance of convenience and flexibility while developing software. The whole idea in agile revolves around doing what is really needed and accepting that many factors are not in control or need to be evolved (due to the limitation of human mind, time and money constraints, etc.).

      These assumptions are no doubt very real but may end up becoming an excuse for complacency or not pushing the envelop. At the same time, the need to work better and better every time would mean certain discipline is exercised to ensure revisits and consequent reworks are minimized in line with the waterfall concept. What is probably the need of the hour is to have a hybrid approach that combines the best of various models varying the flavors as the customers want it.

      The concept behind waterfall is going to remain relevant and important forever. The waterfall model is the original one and must be adapted in whichever way it might be, with a new name if that helps improve software development (agile or whatever).

        Major Changes in CMMI Version 1.3

        The version 1.3 of CMMI was released by SEI in Nov 2010. As compared to the previous version of CMMI (version 1.2) some of the major changes in version 1.3 are as listed below:
        • The three models - development, services and acquisition - have now been harmonized. There are 16 core process areas that are common to all three
        • The process areas across the three CMMI models are now categorized only under one of the following - Process Management, Support, Project Management, Engineering, Service Establishment and Delivery, Acquisition
        • In accordance with the concept of having any process area appear under the same category in all three the Requirements Management area has been moved to Project Management from Engineering
        • The articulation of goals and practices in maturity level 4 and 5 areas have been refined in line with industry best practices for improving the conceptual clarity and reducing inconsistencies in their interpretation
        • The process area OID (Organizational Innovation and Deployment) has been renamed to OPM (Organizational Performance Management) to better reflect the business value of improvement activities
        • A new goal requiring clear linkage between business objectives and process performance goals has been added to the OPM process area
        • The generic goals 4 and 5 have been removed from the model for reducing the confusion in the interpretation of high maturity concepts (high maturity process areas versus high maturity goals)
        • The generic goal/practices elaborations from the process area-wise chapters have been consolidated into a single chapter
        • The IPPD practices in OPD and IPM process areas in version 1.2 which were related to integrated teaming have been replaced by a non-optional practice each (related to teaming) in OPD and IPM
        • Practices of the Engineering process areas have been refined in line with new developments in the area of software engineering (for example guidance has been added at appropriate places for agile methodology, there is increased focus on non-functional requirements)
        • The coverage of training has been broadened to include methods beyond instructor-led classroom  session such as self-study, on the job training, mentoring, online training
        • A sub-practice for performing causal analysis has been added to the practice of IPM related to managing the project using the integrated plan
        • The coverage of milestone reviews has been elaborated to include project start-up and close-out
        • The term "typical work product" has been changed to "example work product"
        • The term “work products, measures, and documented experiences” has been changed to “process-related experiences.”

        CMMI High Maturity

        CMMI high maturity has gained a lot of importance over the last few years, and in a true sense this time around.

        Not only that, achieving CMMI high maturity has become tougher also in the the last couple of years as explained in the post Is Achieving CMMI High Maturity Tougher Now?.

        This is also clearly is evident if one were to analyze the trend of CMMI level 5 appraisals as explained in the post Trend of CMMI High Maturity Appraisals.

        Achieving CMMI High Maturity is certainly a true indicator of the effectiveness of the software project delivery and project management practices employed by an organization.



        And the days when almost all organizations directly attempted and achieved CMMI high maturity rating (eaither maturity level 4 or 5) are hopefully behind us.

        One of the reasons for CMMI High Maturity gaining renewed importance appears to be the changes introduced to CMMI in the version 1.2 release.

        CMMI High Maturity represents the highest order of achievement in the journey of an organization that adopts and implements CMMI.

        Adopting CMMI high maturity practices is assumed to be tough as there's an apparent feeling that there Demystifying and Understanding CMMI High Maturity is not an easy task.

        This, however, is more of a myth than anything.

        Reaching high maturity in business is no mean achievement and should be based on strategic considerations as the cost and efforts involved with it are enormous.

        The returns from becoming high maturity would justify the investments provided the achievement of CMMI high maturity is based on changes to the organization's DNA.

        CMMI High Maturity and Six Sigma, adopted together can deliver significant benefits over the adoption of either framework in isolation.

        Some pertinent questions and aspects that arise during any discussion on CMMI high maturity are as follows:
        Clear understanding of the answers to the questions above is the key in ensuring the right type of implementation of CMMI high maturity practices by an organization.

        And despite widely availability of literature that provides clarity on implementation of high maturity practices, these are still a neglected lot.

        This is explained in much more detail in the following post elsewhere on this blog - Why Are CMMI High Maturity Practices So Very Much Neglected Despite Being So Very Powerful?

        Business of Process Improvement and Assessment

        Increased uncertainty in the marketplace, quantum and frequency of changes in the business climate, ever increasing competition, demanding customers, vocal employees and always-under-pressure executive management has led to organizations focus more and more on improving how they work. What business an organization does is important along with how it doesthe business . The 'what' part relates to product and product innovation whereas the 'how' part relates to process and process maturity improvement and assessment.

        ISO 9001, ISO 27001, CMMI, ISO 14001, Six Sigma are but a few commonly known terms when one thinks of the frameworks and models which have emerged in the last few decades to cater to the needs of organizations for process maturity improvement and assessment.

        The rise of the plethora of process frameworks has also given rise to the phenomenon of businesses getting established to cater to the market needs around this.

        One would come across companies which are into advisory, consulting, training, assessment, third party certification, etc. around these frameworks. There's also another trend where suchcompanies offer services where an organizations can outsource its process and certification requirements to them. Such companies can be collectively labeled as "Quality/Process Consultants" for lack of a better term.

        The need to engage "Quality/Process Consultants" for assessment and third party certification can't be wished away due to the requirement of independence for such activities. So this will continue to be there.

        The need to engage "Quality/Process Consultants" for advisory, consulting, training, etc. can't be wished away completely. This is a way for an organization to inject the emerging and latest improvement concepts and methodologies into the organization. Organizations should set-up internal quality/process department to internally fulfill this need to the extent possible and as required selectively bring in external experts to supplement or enhance the internal expertise.

        The need to engage "Quality/Process Consultants" for outsourcing process and certification to them is not really a strategic idea. The way an organization treats its core products ("What") as strategic similarly it should treat its core processes ("How") as strategic. Selective outsourcing of not-strategic products and processes is fine but needs to be done after thorough evaluation of their strategic impact both in short- and long-term.

        The above would apply to medium- and large-sized organizations. What about small-sized organizations? Small-sized organizations can start with outsourcing process and certification activities to "Quality/Process Consultants" but should eventually set-up internal quality/process department to gain strategic advantage. In fact, small-sized organizations should view engaging "Quality/Process Consultants" at the start as the first step towards creating internal capabilities in respect of process and process maturity improvement and assessment.

        Using IPM and SAM

        IPM (Integrated Project Management) and SAM (Supplier Agreement Management) both are process areas of CMMI.

        The applicability or otherwise of SAM and handling it within the ambit of IPM (remember SAM is the only PA allowed for exclusion in CMMI-DEV v1.2) depends on the nature of relationship between the primary project team and extended team. It is governed in a broad sense by the following criteria:
        • Is the effort of the supplier managed by the project on a day to day basis - it doesn't matter where the supplier is physically located (if yes, IPM would be more appropriate)
        • Is the working of the supplier bound by a assignment-specific contract/agreement (SAM would be more appropriate) or by a master contract/agreement (IPM would be more appropriate)
        • Is the supplier working in a staff augmentation mode (IPM would be more appropriate) or working independently to deliver parts of the project that will be integrated with the final product after suitable acceptance checks have been performed by the project (SAM would be more appropriate)

        How is IPM related to PP, PMC and RSKM

        IPM (Integrated Project Management), PP (Project Planning), PMC (Project Monitoring and Control) and RSKM (Risk Management) are process areas in of CMMI which are meant for effective project management. IPM builds upon PP, PMC and RKSM but is not intended to duplicate them in any manner. The term "Project Management" in IPM may be confusing as it refers to "managing the project as per an integrated and defined process" rather than "just managing".

        IPM basically brings in the concept of organization-level maturity as compared to project-level maturity by requiring that the processes defined for a specific project are "tailored out of" the organization's standards processes. CMMI is meant to create, sustain and improve the process maturity from the organizational perspective and IPM assumes that projects will come and go but organizational process maturity would stay. This is what puts "defined" into managing the project.

        IPM also adds another dimension of stakeholder management which is important for managing the relationships a project team has with interfacing entities - other teams, management, customers, suppliers, etc. The idea is to manage the various sub-plans which describe the involvement of various stakeholders in the project and also manage the dependencies and relationships with the stakeholders for project success. This is what puts "integrated" into managing the project.

        DAR and TS in CMMI

        DAR (Decision Analysis and Resolution) and TS (Technical Solution) are process areas in CMMI. DAR is employed by TS for making a selection amongst the competing alternative solutions. However, DAR application is not limited to TS and can be used for any of the other 21 PAs. In a nutshell, TS is meant for engineering work whereas DAR is meant for formal decision making (not limited to engineering only but extending to other areas as well)

        DMADV (DFSS) versus DMAIC

        DMADV (Define, Measure, Analyze, Design, Validate), also known as DFSS (Design for Six Sigma), is used to design and develop new products and processes. DMADV/DFSS is also used to re-engineer or improve existing products or processes where the re-engineering or improvement is generally of a significant nature/quantum. This can be contrasted with DMAIC (Define Measure Analyze Improve and Control) which is used to re-engineer or improve existing products or processes where the re-engineering or improvement is generally of a minor nature/quantum.

        It can be easily seen that both DMADV/DFSS and DMAIC are same until the "Analyze" step. This means that any Six Sigma project shouldn't start as DMADV/DFSS or DMAIC but should be identified as one during the "Analyze" step when the results of the analysis of actual performance are available. If the actual performance is lesser but very close to the target performance, DMAIC should be used and if the actual performance is lesser but far away from the target performance DMADV/DFSS should be used.

        Using DMADV/DFSS for all new product development is not a cost-effective strategy when a DMAIC project will be enough to improve the product to satisfy the customer requirmenets. There are many instances when DMADV/DFSS can lead to over-design and hence development of solutions which may work but are not cost-effective for its intended customers.

        Process Framework for Avionics Software

        Avionics software ought to be zero-defect.

        And zero-defect actually means ZERO as in 0.

        For development and maintenance of avionics software following process standards/frameworks are generally used:

        DO 178B

        • DO stands for Document Order
        • DO 178B provides practices which are required for development and certification of all software which are embedded in an aircraft

        +SAFE

        • +SAFE is an extension of CMMI (Capability Maturity Model Integration)
        • +SAFE extends CMMI by adding two process areas:
          • Safety Management
          • Safety Engineering

        Verification versus Validation

        Verification means:
        1. Doing the thing right (climbing the chosen ladder in the right way!)
        2. Ensuring throughout the project life cycle that the activities in the various SDLC phases are performed in accordance to their specified requirements.
        3. Some of the suggested ways to achieve this are:
        - create work-products of a phase in strict accordance to the specifications (for example coding as per detailed design specifications)
        - perform peer reviews of work-products generated from a phase before transitioning to the next phase
        - use pre-defined engineering standards for requirements, design, coding, etc.

        Validation means:
        1. Doing the right thing (choosing the right ladder to climb!)
        2. Ensuring throughout the project life cycle that the product will work as intended in the actual operating conditions.
        3. Some of the suggested ways to achieve this are:
        - perform validation of customer requirements in the beginning and UAT in the end
        - involve the end-user(s) throughout to make sure the final product will work as intended

        Continual versus Continuous Process Improvement

        Continuous Process Improvement (CPI) means an ongoing focus on trying to improve incessantly - in small and big ways. CPI is strategic and philosophical in nature.

        However, in a real sense improvement is continual rather than continuous. Continual means gradual progress with intervals of rest in between. Basically, every phase of improvement should be followed by a phase of sustenance (for holding on and stabilizing the improvement). In that sense improvement is really not continuous but continual.

        Process Tailoring, Process Deviation, Process Exception, Approval and Waiver

        Generally, an organization has a set of standard processes in the form of a QMS (Quality Management System) or a Process Asset Library (PAL).

        The entire organization is expected to adhere to the standard processes or SOPs as defined in the QMS or the PAL.

        However, standard processes may need some tweaking, some small and some big too, when put into use by the projects.

        The tweaking may range from pre-approved process tailoring to process deviations and exceptions requiring approvals and waivers, as depicted in the figure below.

        Process Tailoring

        Tailoring means selecting and customizing the selected standard processes in a pre-defined manner as per the “Tailoring Guidelines”.

        It is recommended that tailoring requires approval at the level of a process group team member or no approval at all.

        The approval in this scenario can be clubbed with the approval of the overall project plan.

        Process Deviation

        Deviation means modifying the standard processes beyond what is allowed to be tailored (as specified in the “Tailoring Guidelines”).

        It is recommended that deviation cases are analyzed thoroughly at the level of a process group team member for their potential future impact on project delivery.

        And finally, escalated upwards at the level of the process group head and delivery head for them to review and approve.

        Approval in such cases should strictly be through and in the form of a formal waiver.

        Process Exception

        Exception means providing complete exemption from following a standard process.

        It is recommended that exception cases are analyzed very thoroughly (much more thoroughly than the deviation cases) at the level of a process group team member for their potential future impact on project delivery.

        They should then be escalated upwards at the level of the process group head and delivery head for them to review.

        And finally, escalated further upwards at the level of the business head for her to review and approve.

        Approval in such cases should strictly be through and in the form of a formal waiver.

        CMMI Certification

        Use of the term CMMI Certification is actually not correct, going by strict technical considerations. Due to the huge popularity of ISO Certifications, however, the term CMMI Certification has also come into popular use.

        Instead of CMMI Certification, it is recommended to use the right term – CMMI Appraisal.

        Appraisal means investigating an organization’s processes and practices to evaluate its strengths and weaknesses against a reference model. CMMI Appraisals are performed using SCAMPI (Standard CMMI Appraisal Method for Process Improvement).

        Note- Searching for the string ‘CMMI Certification’ in Google returns a long list of search results which shows how popular the term ‘CMMI Certification’ is.

        Certifications for Improvement Professionals

        From Software Certifications:
        *CASQ - Certified Associate in Software Quality
        *CSQA - Certified Software Quality Analyst
        *CSPE - Certified Software Process Engineer
        *CQSPE - Certified Quantitative Software Process Engineer
        *CMSQ - Certified Manager of Software Quality

        From ASQ Certifications:
        *CMQ/OE - Certified Manager of Quality/Organizational Excellence
        *CQA - Certified Quality Auditor
        *CQE - Certified Quality Engineer
        *CQIA - Certified Quality Improvement Associate
        *CQPA - Certified Quality Process Analyst
        *CSQE - Certified Software Quality Engineer

        How Metrics Evolves from Level 2 to 5 in CMMI?

        Metrics and measurement is core to making CMMI a framework whose benefits can be viewed in quantitative terms and not just qualitative terms. Metrics and measurement relies on data collection and analysis to aid in fact-based decision making. The decisions made are not only for managing business execution but also for improving continually.

        At Maturity Level 2 (ML2), the PA MA (Measurement and Analysis) brings in quantitative focus. The main role of metrics and measurement at ML2 is to set the system for data collection and analysis. Here the key aspect is the management of project using data. The other aspect is to create a management dashboard which captures the primary project parameters related to schedule, cost and quality. In addition, additional parameters of interest can be included.

        At ML3, the need is to perform activities in the various projects and areas of organization consistently. The PA MA is evolved in terms of consistency of its application. For metrics and measurement this translates into bringing stability and consistency in data collection and analysis across the organization. This makes comparison across projects meaningful and thus improves project management maturity. There is also emphasis at ML3 on using historical data from past projects - consistency in data collection and analysis makes this possible and useful.

        At ML4, the focus is on bringing higher rigour into analysis through the application of statistical methods like SPC, Anova to manage the projects much more effectively. In addition, predictive management gains importance - this allows issues to be proactively identified and addressed to better satisfy the specified project success goals. This is effected through the PA QPM (Quantitative Project Management).

        At ML5, the focus shifts from management dimension to improvement dimension. Analysis is meant to unravel ways to continually improve the processes. At the same time, metrics and measurement is used to address existing and anticipated issues and problems in a preventive mode. The idea is to establish system which prevents the recurrence (or if possible even the first time occurrence) of issues and problems.

        Does CMMI-DEV apply only to Software?

        Absolutely no... this is a myth whose origin lies in the manner in which CMMI-DEV has evolved (from SW-CMM). The CMMI-DEV framework provides an effective and efficient approach for the development and maintenance of complete systems (which consist of both hardware and software) and not just software.

        Statistics

        Statistics means both the following:
        1. Data and analysis results
        2. Data analysis methods

        Statistics provides a scientific approach to understand, analyze and change the world around us. It is a fact that we can't change anything for better unless we know what it is and statistics helps us in this!

        Statistical Tools - Simple

        Pareto Analysis
        Determine relative priority or importance of available alternatives

        Run Chart or Trend Chart
        Understand the behavior of a process over time

        Mean or Average
        Most likely value of a process parameter

        Median
        Middle-most value

        Mode
        Value that occurs most of the time

        Statistical Tools - Advanced

        Statistical Process Control (SPC)
        Adoption of Control Charts theory to monitoring and control of business processes

        Statistical Data Analysis

        Use of Statistics in the form of various Statistical Tools and Techniques have found a useful place in almost all business organizations for different types of analysis.

        Statistical Data Analysis techniques can be broadly categorized as:

        Statistical Tools - Simple
        Statistical Tools - Advanced This categorization is based on the relative difficulty one would face in applying a tool and technique and doesn't imply anything about the underlying theoretical concepts.

        How to Perform Statistical Data Analysis

        Statistical Data Analysis can be performed using various Software Applications such as MS-Excel, MINITAB, SPSS, SAS, etc.

        From a general purpose angle, MS-Excel offers enough feature to perform basic statistical analysis easily. MS-Excel can also be used in a limited way to perform certain types of advanced statistical analysis. In addition, many MS-Excel Add-ins are available which when plugged to MS-Excel can be used to perform most of the advanced statistical analysis.

        Useful Utilities which provide Sample Examples or can be used as Templates for performing certain types of basic and advanced statistical analysis are also available on this site.

        Quality Assurance

        Quality Assurance or QA is meant to obtain an understanding of the level of compliance or adherence to the defined processes and standards. Quality Assurance generally means one or more of the activities listed below:
        • Process or Quality Audits 
        • QA Reviews 
        • Internal Audits
        Most of the business excellence models contain requirements related to the Quality Assurance function as is described below:

        CMMI – the Process Area PPQA (Process and Product Quality Assurance) elaborates the requirements for Quality Assurance. A key requirement is that assurance must provide “Objective Evaluation” of defined processes and standards. The “Objective Evaluation” can be ensured by assigning an independent role to perform criteria-based assurance activities by using a checklist. In addition, CMMI ensures that all Process Areas are subjected to “Objective Evaluation” by positioning the QA intervention as a generic practice.

        ISO 9001 – the Section on “Internal Audits” elaborates the requirements for Quality Assurance. A key requirement is that assurance should be independent so that “no one audits his or her own work”.

        ISO 27001 – same as ISO 9001, the Section on “Internal Audits” elaborates the requirements for Quality Assurance. A key requirement is that assurance should be independent so that “no one audits his or her own work”.

        DO178B – the Section on “Software Quality Assurance Process or SQA Process” elaborates the requirements (or objectives) for Quality Assurance. A key requirement is that SQA role must be independent of the project. As this standard deals with Safety Critical Software, assurance is highly rigorous and even process deviations and project document changes are subjected to stringent configuration control.

        Defining Business Processes

        Business Processes can be defined in the following ways:
        • Detailed text description taking into consideration the elements of business processes as described in Business Processes
        • Graphical representation in the form of a flow chart or swim lane chart – also called as Process Flow Diagram
        • Combination of the above two representations Business Processes should be created based on a well-defined standard Process Definition Template and should include a Process Flow Diagram.
        How to Define Effective Processes? Process Definition can be effective if following points are kept in mind:
        • The activities are defined to the right level of granularity (both over-description and under-description must be avoided)
        • The sequence of activities is correct (there are times when the defined sequence may not get followed in practice but the process definition should describe the most logical sequence)
        • The referencing to processes, templates from an activity is appropriate (dangling processes and templates should be linked or removed)
        • The activities in a process cover the defined scope of the purpose (activities described as part of a process should be exactly as per the define scope – neither an activity more nor an activity less than the defined scope.)
        • For each declared input, one or more activities of the process should either use or refer to it
        • For each declared output, one or more activities of a process should either generate or update it
        • For flexibility, the exit criteria can be defined as two-staged criteria – one for complete exit and another for conditional exit

        Deploying Business Processes

        Deployment of business processes means that while performing the assigned business activities, the personnel involved make use of the defined processes. True deployment of a business process means the defined processes are used under all circumstances. True deployment also means that a business process has become an integral part of the organization’s DNA.

        How to Effectively Deploy Business Process? Effective deployment of business processes assumes that the following key challenges are managed well:

        Lack of involvement and support from people
        People claim to be too busy with “Business As Usual” with no bandwidth available for getting involved in activities such as process compliance, process improvement that are not regarded as “real” work!

        Lack of real management commitment
        Many leaders and managers advocate use of standardized business processes but champion them only at a superficial level. There are talks that demonstrate strong commitment to using defined process processes but at the first sight of an organizational crisis the “good” practices get sidelined – this kind of behavior implies that “good” practices are only for “good times” and cascades through the organization in no time and stays that way for good.

        Too much emphasis on process compliance so that even poorly defined processes get ingrained into the organization
        Just like good practices, avoidable practices also tend to stick to the organizational DNA. Organizations must watch out for absolute process compliance even when theprocesses are not effectively defined. All incidents of lack of absolute process compliance should be evaluated first for “gaps” in the defined processes before they are addressed for “gaps” in process deployment.

        Inadequate or missing tool support
        Deploying business processes using automated tools and templates greatly increases the deployment effectiveness in terms of the intensity, consistency and depth. However, usage of automated tools and templates without stabilizing the process to some degree must be avoided. There could be cases where the business process is standardized across the industry and the process deployment is done using a tool right at the beginning.

        Data and Document Management

        Effective management of business information (data and documents) is mandatory for organizations that wish to adopt certification standards and assessment frameworks.

        In order to successfully “demonstrate” compliance to the stated and implied requirements of the adopted standard or framework, certain kind of data and documents are required to be made available.

        In addition to the above, the data and documents created, obtained, used and stored by a business are important information assets that have significant influence on the overall effectiveness and efficiency of the business operations.

        Data and Document Management includes the following activities within its scope:
        1. Establishing the need for creating certain data or document
        2. Creating the data or document from scratch or updating existing data or document
        3. Trashing or destroying
        4. Storing and securing
        5. Managing access
        6. Archiving
        7. Change control
        8. Base-lining and version control

        Data and Documents could be of the following types:
        1. Strategy and Roadmap – Business Plan, Implementation Roadmap, Certification Strategy, Sales and Marketing Analysis, etc.
        2. Plans – Project Management Plan, Risk Management Plan, etc.
        3. Standards – Coding Standards, Surface Treatment Standards, etc.
        4. Technical Specifications – Software Design, Engineering Drawing, Version Information, etc.
        5. Data Stored in Tools and Templates – Records in Employee Database, Raw Data in Data Collection Sheet, etc.
        6. Communications and Reports – Weekly Status Reports, E-mail Approvals, etc.
        7. Management Reports – MIS Dashboards, Executive Briefing

        Data and Document could be in any of the following formats:
        1. Proprietary formats such a MS-Excel, MS-Word, PDF, etc.
        2. Image formats such as JPEG, TIFF, etc.
        3. (Generally) Unstructured formats such as e-mails, scans of handwritten notes/drawings, etc.
        4. Web-accessible formats such as XML, SOAP, etc.
        5. As records in Relational Database (SQL Server, Oracle, etc.)
        6. As objects in Object-Oriented Database

        Business Processes

        Why Business Processes are Critical for any Organization? Effective deployment of well-defined business processes offers the following key advantages:
        • Repeatability of business outcomes achieved through use of a proven method or approach to handle common business activities.
        • Higher synergy amongst the various business activities through alignment and tight integration of the business processes.
        • Consistency in operations through reduced dependency of business activities on people and more dependency on standard processes and procedures.
        What is a Business Process? As business process is defined as and constitutes the following elements:
        a.a set of activities
        b.that are integrated in a thoughtful sequence
        c.with the purpose of achieving specified business outcome(s).

        In addition, the description of a business process may also include the following elements:
        a.declaration of roles that will perform the various activities of the process
        b.the pre-requisites to start the process (inputs and entry criteria)
        c.the pre-requisites to end the process (outputs and exit criteria)
        d.scope of the business process in terms of the major activities included as part of the process description and also the conditions under which the business process will be used
        e.the interfacing or supporting processes, procedures, guidelines, formats, tools and templates that will be used for performing  the business process

        Defining or establishing business process is an important aspect of Business Process Management (BPM).
        The term “Quality Process” is in use in many organizations to mean the processes that are defined as part of implementing quality management and process improvement program. This term “Quality Process” is a misnomer and dilutes the criticality and effectiveness of the effort spent by an organization on defining business process. Every process used by a business organization should be treated as a “Business Process”. Even the so-called “Quality Process” is nothing but a “Business Process”. In fact all the functional processes for example, HR Process, Admin Process should also be regarded as business process.

        Why Every Process in an Organization is a Business Process? The argument for calling all processed deployed and employed by business organizations as “Business Process” is based on the following factors:
        An organization should not spend effort on defining any process that doesn’t have a business value – Direct, Indirect or Remote. All processes must have a clearly identified supplier and customer – internal or external as the case may be All processes must have a traceable link to earning of revenue or incurrence of expenses.

        How to Categorize Business Processes? All processes must be categorized as one of the three types:

        Direct Business Value
        Those that require incurrence of expenses but are linked to the earning of revenue in a direct manner. These are the core processes that relate to make and sell activities.
        For example, in a car manufacturing company, the process for technical activities related to car body design, engine assembly, etc. needs expenses to be incurred with the expectation of earning direct revenue when a customer purchases a car.

        Indirect Business Value
        Those that require incurrence of expenses but are linked to earning of revenue only in an indirect manner.
        For example, in a car manufacturing company, process improvement activities performed by an organization (such as Defect Prevention Program, Adoption of any Business Excellence Models, etc.) needs expenses to be incurred but lead to better quality products and services and higher efficiencies in business operations which translates into more market wins and lesser costs on internal non-conformances.

        Remote Business Value
        Those that require incurrence of expenses but are linked to earning of revenue only in a remote manner.
        For Example – the “Performance Appraisal Process” is “incurrence of expenses only” process. It is however quite critical to attract, develop and retain talent in the organization.

        Business Process Management

        Business Process Management or BPM is a useful business excellence concept that provides methods and approaches to handle Business Processes in an organization – from cradle to grave. Business Processes are everything that an organization uses to carry out the various activities that are required to run the business – from delivering products to hiring people, from launching new products to shutting down!

        The two distinct stages that constitute business process management are:

        Defining Business Processes

        All activities that a business performs are business processes. Sometimes, activities may start getting performed without a defined process existing. In such cases, process definition must be formalized at the earliest.

        Defining Processes includes all of the following:
        1. Writing processes
        2. Incorporating process usage feedback and process improvement opportunities into the defined set of processes through
        a.Adding new processes
        b.Updating existing processes
        c.Deleting/archiving processes
        3. Publishing the processes
        4. Sending out relevant communications to relevant stakeholders as a pre-requisite to Deploying Business Processes

        Deploying Business Processes

        Business processes deliver their true value if and only if deployed effectively. And as “the proof of the pudding lies in its eating”, changes felt necessary during deployment should get fed back into the process description.

        Deploying Processes would include all of the following:
        1. Training and mentoring on processes
        2. Usage of processes in performing business activities
        3. Gathering process usage feedback
        4. Identifying process improvement opportunities
        5. Providing process usage feedback and process improvement opportunities to the Defining Business Processes stage

        Business Process Improvement

        Business Process Improvement or BPI is the constant analysis of the Business Process to determine opportunities for improvement. For succeeding in business, it is important to try to get better at what one is doing, improving bit by bit, every day.

        Here are the typical steps in improving business processes:

        1. Collect data and analyze the data to understand how is the process behaving w.r.t. the expected results. Even if the process is behaving in accordance with the expectations, improvement opportunities can still be identified.

        2. Investigate the causes (preferably root causes) to understand the process behavior

        3. Determine factors that influence the process behavior. Conduct what if analysis to find how change to certain factors can improve the process performance

        4. Articulate the action items and set the ball rolling

        Non Conformances

        Non-Conformance or NCs represent process gaps and are a direct indicator of the weaknesses that exist in the implementation of a business excellence model.

        The end-objective of an organizational program for the implementation of a business excellence model is two-fold:
        1. Minimize the first time occurrence of NCs, at least the ones that are severe or major in nature
        2. Prevent the second and subsequent recurrence of NCs, at least the ones that are severe or major in nature

        NCs are a way for an organization to view how well the processes and practices have got ingrained into the organization's DNA.

        Implementation Steps

        Implementation of any organizational initiative such as CMMI, ISO 9001, ISO 27001, et al would make use of a well-defined Implementation Roadmap from a technical perspective. In addition, the Implementation would also require managing the other aspects associated with an organizational initiative of such a size and complexity like cultural changes, people buy-in, management funding, external consultants, program schedules, etc.

        List of recommended steps for CMMI or ISO or any other Program's Implementation are as follows:
        1. Evaluate business need for the improvement program
        2. Obtain executive management's buy-in and funding
        3. Conduct awareness campaign - this will continue till organizational awareness reaches a reasonable level. The campaign may use techniques such as quiz, poster sessions, e-mail communications, inclusion of program updates inmanagement and team meetings.
        3. Prepare detailed plan - the plan would detail out program milestones and activities, effort estimates, resource requirements, people and teams, task assignments, schedule, consultant and lead appraiser negotiation, etc.
        4. Initiate the Implementation Roadmap - this will continue till the end
        5. Revise the detailed plan based on Gap Analysis findings
        6. Perform program management - schedule monitoring and corrective act ions, issue management, risk management, people management, Organizational Change Management
        7. Manage involvement of external consultants and Lead Appraiser - external visits scheduling and co-ordination, processing of payments, etc.
        8. Coordinate training - scheduling and conducting of training identified to be imparted
        9. Provide status updates to management and other stakeholders - discussions on the Improvement Program's progress must be included in all management and team status meetings

        The above Implementation Steps along with the Implementation Roadmap would ensure successful completion of the Improvement Program. However, one must watch out for Implementation Challenges - risks, issues and challenges that can either delay the program or in the worst case lead to its total failure.

        Implementation Challenges

        During the implementation of business excellence frameworks such as CMMI, ISO 9001, ISO 27001, etc. an organization would come across many challenges, risks and issues. The primary reason for these challenges is that these improvement programs are typically long drawn - lasting for several months or years. And such a long duration presents its own dynamics in terms of organizational churn like change in people, change in policies and procedures, change inbusiness climate, change in business imperatives for the organization, etc.

        List of typical implementation challenges:

        • Change in organization’s leadership team and executive sponsors
        • Dilution in the involvement and commitment of executive management
        • Attrition of key personnel involvement with the implementation of the improvement program
        • Organizational culture and workplace politics
        • Lack of ready availability of required competencies in the organization
        • Decline in business growth and profitability
        • Shifting in the organization's corporate and business strategy
        • Non-availability of adequate funds at the appropriate time
        • Cultural barriers due to mental blocks - necessitates extensive and rigorous application of Organizational Change Management strategies
        • Diversion of attention due to fire-fighting required from time to time
        • Initiation, in parallel, of another program or programs in the organization

        Implementation Basics

        Implementation of any improvement model requires, at least, the following:
        1. Program Management of the implementation initiative
        2. Organizational Change Management for obtaining budget, resource, time, support of key stakeholders
        3. Technical understanding of the model requirements

        Program and Organizational Change Management are needed for any initiative in the organization and hence their generic understanding is essential.

        From the model perspective, the key point to note is that audits and assessments by external agencies rely on implementation evidence. Hence focus on what artifacts need to be created for the various model requirements and expectations is a must.

        Closure of Gaps or NCs

        Closure of Gaps or NCs (Non-Conformances) is required to remove the identified weaknesses in Process Implementation. These gaps would be mostly related to process implementation. However, gaps related to process definition are also quite common.

        Too many process definition gaps is not a good sign and it is generally considered to be a good practice to close all process definition gaps first, followed by sufficient time and effort on process implementation (the deployment of defined processes as standard practices across the organization).

        Only thereafter, an organization should consider the conduct of internal audits and external audits. Internal audits may still be fine if conducted at an earlier stage but external audits due to the cost involved should definitely not be conducted prematurely.

        Gaps or NCs in the process (Pg) arise when the observed process (Po) as evident in its practice differs from the defined process (Pd).

        Or, Pg = Po - Pd

        Closure of Gaps or NCs in the process (Pg) can be done using the following strategy.

        (1). Make Po = Pd so that Pg = 0;
        Which means start following the defined process henceforth

        (2). Make Pd = Po so that Pg = 0;
        Which means re-define the process to be in line with the practice, this may require process tailoring or process waiver

        (3). Take waiver on the NC (or obtain NC Waiver or -Pg);
        Which means the gap would continue to exist but will be considered as waived off (so that Pg + (-Pg) = 0)

        With approach (1) it will be fine when it comes to the external auditors. However, with approach (2) and (3) there are associated risks. It would be prudent to take professional or expert opinion on (2) and (3) to reduce any anticipated risks during the external audit.

        TS 16949

        TS 16949 (or ISO/TS 16949) is the Technical Specification for the Automotive industry. This Technical Specification should be referred to along side the ISO 9001 standard for designing and developing the Quality Management System.

        TS 16949 provides requirements for the design, development, production and installation and service of automotive products and components. This standard is applicable to the entire automotive supply chain.

        FDA CFR 21 Part 11

        FDA 21 CFR Part 11 applies to companies which need to operate under the purview of FDA regulation, like Pharmaceutical and Biotech Companies, Medical Equipment Manufacturers.

        CFR21 Part 11 defines the criteria which need to be fulfilled for electronic records and electronic signatures to be considered trustworthy, reliable and legally equivalent to paper records and signatures.

        The standard applies to those companies (FDA-regulated) who want to store their records in electronic format. It specifies the guidelines and rules for storing, copying, setting access and permissions, audit logging and tracking, and managing change and version control of the electronic records and electronic signatures.

        An electronic record is defined as as any combination of text, images, data, audio, video or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system.

        DO178B

        DO178B is a certification standard for avionics software.

        DO178B defines the requirements for airborne software and due to the high risk involved is quite stringent.

        Organizations which already have CMMI implementation can look at DO 178B to strengthen their basic management, engineering and support practices.

        CMMI offers an extension called as +SAFE that can be used by organizations which are already CMMI to extend their CMMI Program to bring in higher rigor.

        CMMI for Services

        The main application of CMMI for Services (CMMI-SVC) is for service management. In some sense, this is patterned in a way which is similar to another service management model, ITIL. However, whereas ITIL is supposed to be focused on IT Service Management, CMMI-SVC is applicable to service management in a wide sense.

        Service management usually means designing, deploying and provisioning services to the customers. Service has a wide meaning which encompasses activities like opening a bank account to booking an air ticket to having dinner served in a restaurant.

        Even for those organizations which develop and maintain products (using CMMI-DEV maybe), CMMI-SVC is useful for managing service performance in case of certain activities like resolving customer complaints, time to repair any fault in the product, etc.

        CMMI-DEV Implementation

        Process area wise sumamry of "suggested" artifacts for CMMI-DEV implementation is given below.:

        Project Planning (PP)

        Suggested Process
        Project Planning Process with activities for Plan Preparation, Plan Review and Plan Approval

        Suggested Templates / Format / Checklist
        Program/Project Management Plan (PMP) Template with following sections - Scope, Staffing, Staff Induction and Exit, Competency Assessment, Training, Hiring, Contractor Engagement, Risk Management, Data Management, etc.
        Role-Responsibility-Resource Mapping Matrix Template
        Competency Assessment Template
        Training Plan and Tracker Template
        Estimation Template - Size, Complexity, Effort, Schedule, Cost

        Project Monitoring and Control (PMC)


        Suggested Process
        Project Monitoring and Control Process Project Status Report Format

        Suggested Templates / Format / Checklist
        Action Item Tracker Template
        Commitment Plan and Tracker Template
        Project Performance Dashboard Template
        Issue Log Template - can be clubbed with Action Item Tracker Template

        CMMI for Development

        CMMI for Development or CMMI-DEV is the most well-known and adopted CMMI framework. The main application of this framework is for the development and maintenance of engineering activities - be it mechanical engineering, software engineering or systems engineering.

        Due to origin of the CMMI frameworks in the software industry, there is a misconception amongst non-software organizations that CMMI is not applicable to them. However, the truth is that CMMI-DEV is equally applicable to mechanical engineering as it is to software engineering.

        The key practices of a CMMI-DEV Implementation can be summarized in the following categories:
        1. Program/Project Management - planning, monitoring, risk management etc,
        2. Engineering - requirements, design, implementation, release, etc.
        3. Process Improvement - process changes, improvement suggestions, etc.

        CMMI framework offers a way to make the above consistent and effective through the various specific and generic goals and practices.

        CMMI for Acquisition

        The main application of CMMI for Acquisition (CMMI-ACQ) is for the acquisition of sub-systems or product components from suppliers, integrating them with in-house sub-systems or product components to build the final system or product which is shipped to the customer.

        CMMI-ACQ offers a way to organizations which rely (heavily) on suppliers to create high-quality and reliable products for their end-customers. In today's corporate ecosystem outsourcing is a reality and CMMI-ACQ can play a crucial role in governing suppliers.

        Even for those organizations which develop and maintain products (using CMMI-DEV maybe), CMMI-ACQ is useful for managing the overall product development cycle by effectively managing the suppliers.

        CMMI High Maturity and Six Sigma

        The goals, practices and informative material that constitute the description of CMMI High Maturity – Maturity Level 4 and 5 Process Areas of the CMMI Framework – espouse and expect the usage of Statistical Data Analysis for understanding, controlling and improving processes.

        The Six Sigma methodology also relies heavily on the application of Statistical Data Analysis. In fact, a closer look at Six Sigma makes it look like a natural ally of CMMI High Maturity. Six Sigma can be dove-tailed with CMMI not only to drive CMMI High Maturity but also to make it penetrate the skin of an organization and impact its DNA.

        In a nutshell, both CMMI High Maturity and Six Sigma are about the following, and strictly in quantitative terms:
        • Setting up the performance target that an organization wants to achieve – goal setting
        • Determining, at the end, the process outcome that the organization actually achieved – process monitoring and control
        • Determining progressively, at intermediate stages, the process outcome that the organization is likely to achieve in the next stage and finally at the end – prediction model
        • Improving process outcome by understanding and treating the underlying causes that influence process performance – root cause analysis
        • Achieving breakthrough jump in process outcome by ideating and adopting innovations – breakthrough innovation

        TQM

        TQM or Total Quality Management, is a holistic way to manage quality and process improvement in organizations. The idea of managing quality in a holistic manner is quite a powerful one as quality cannot be integrated into an organization's DNA without all the constituent elements buying into it and internalizing it.

        All the major business excellence frameworks currently used, in one way or the other contain TQM concepts such as:
        1. Management sponsorship, commitment and involvement
        2. Employee involvement

        Six Sigma

        What is Six Sigma?

        Six Sigma is a problem solving methodology, which employs statistical rigour to identify, drive and demonstrate process improvements. In Six Sigma, an improvement can claim to be so only if it is based on data and numbers.

        Six Sigma has come to be regarded as a magical tool in the field of Business Process Management (BPM) and is being extensively used across diverse sectors of the economy.

        Six Sigma originated at Motorola but gained immense popularity in the business world after it was successfully deployed at GE. Most of the large-sized business organizations of today have adoptedSix Sigma in some form or other as part of the larger Business Excellence Framework.

        Most of the Business Excellence Models like CMMI, ISO 9001, MBNQA require the adoption and emphasize the application of quantitative rigour (using Statistical Tools and Techniques) to improving business processes.

        Applying Six Sigma to Business

        The typical usage of Six Sigma has primarily been in solving two of the most common business problem faced by all business organizations:

        Achieving breakthrough improvements in existing business products and processes
        Designing and developing innovative products and processes Achieving breakthrough improvements in existing business products and processes

        Organizations in the current business climate have no choice but to improve on their products and services on an almost daily basis. As these products and services result from the business processes deployed by these organizations, persistent focus on Continual Business Process Improvement (CBPI) is but mandatory.

        CBPI ensures that an organization can sustain its competitive edge by being able to offer the same products and services that its competitors are offering in the marketplace but at a cheaper rate, faster cycle-time or better value-proposition.

        Six Sigma offers the DMAIC (Define Measure Analyze Improve Control) as a problem solving methodology for addressing the above business need.

        Designing and developing innovative products and processes

        Organizations also need to be on constant lookout for newer product and service offerings to its customer base for sustaining and growing sales volume and revenue.

        Newer or innovative product and service offerings could mean one or more of the following:
        1.Products that serve the “needs” of the customers. For example, people need food hence creating novel food varieties (using Genetic Engineering, for example) would fit into this category
        2.Products that serve the “wants” of the customers. People want cakes and pastries hence baking cakes using ingredients that have never been used for baking cakes would fit into this category
        3.Products that are either served, or booked / dispatched via a different format. People want pizzas and offering pizzas through home delivery mode or ordering over Internet would fit into this category (the core product or service would generally remain unchanged)

        Six Sigma offers DFSS (Design For Six Sigma) or DMADV (Define Measure Analyze Design Validate) for addressing the above business need.

        SA 8000

        SA 8000 is a standard governing social accountability of organizations. It provides guidelines for ensuring decent working conditions to the employees of a company but also the employees of its suppliers.

        SA 8000 was developed and is overseen by Social Accountability International (SAI). Detailed guidance for implementing SA 8000 and auditing the Social Accountability System (SAS) are available on SAI's website.

        SAI has contracted with Social Accountability Accreditation Services (SAAS), which is a global accreditation agency that licenses and oversees auditing organizations to award certification to employers that comply with SA8000.

        OHSAS 18001

        OHSAS 18001 is intended to ensure safe and secure work environment. OHSAS implementation by business or other enterprises also ensures that they would be in compliance with certain requirements related to Occupational Health from the two world bodies - the International Labour Organization (ILO) and the World Health Organization (WHO).

        Organizations typically define an OHSMS (Occupational Health and Safety Management System) as the primary vehicle to institutionalize policies and practices related for providing safe and securework environment to the employees and visitors, both inside and around its facilities. An effective implementation of OHSAS 18001 will generally also make use of ISO 9001 and ISO 14001 standards.

        MBNQA

        MBNQA stands for Malcolm Balridge National Quality Award. MBNQA is not about how to become better at doing business, it's rather about what characteristics you would display if you are a successful business. Malcolm Balridge, as it is also commonly known as, provides key characteristics of successful organizations.

        The characteristics of MBNQA can be divided into two categories:
        1. Those that pertain to "Means" of doing business. This category includes factors like human capital management, process management, etc. which denote the means to business success.

        2. Those that pertain to "End" of doing business. This category includes business results which represents business success or failure, as the case may be.

        The award is based on a 1000 point score system. The biggest strength of MBNQA is probably a strong focus on Business Results.

        MBNQA Scoring System

        1000 Point - TOTAL

        120 Points - Category 1: Leadership

        70 Points - Item 1.1: Senior Leadership
        50 Points - Item 1.2: Governance and Societal Responsibilities

        85 Points - Category 2: Strategic Planning

        40 Points - Item 2.1: Strategy Development
        45 Points - Item 2.2: Strategy Deployment

        85 Points - Category 3: Customer Focus

        40 Points - Item 3.1: Customer Engagement
        45 Points - Item 3.2: Voice of Customer

        90 Points - Category 4: Measurement, Analysis, and Knowledge Management

        45 Points - Item 4.1: Measurement, Analysis, and Improvement of Organizational Performance
        45 Points - Item 4.2: Management of Information, Knowledge, and Information Technology

        85 Points - Category 5: Workforce Focus

        45 Points - Item 5.1: Workforce Engagement
        40 Points - Item 5.2: Workforce Environment

        85 Points - Category 6: Process Management

        35 Points - Item 6.1: Work Systems
        50 Points - Item 6.2: Work Processes

        450 Points - Category 7: Results

        100 Points - Item 7.1: Product Outcomes
        70 Points - Item 7.2: Customer-focused Outcomes
        70 Points - Item 7.3: Financial and Market Outcomes
        70 Points - Item 7.4: Workforce-focused Outcomes
        70 Points - Item 7.4: Process Effectiveness Outcomes
        70 Points - Item 7.5: Leadership Outcomes

        Lean Six Sigma

        Lean Six Sigma (LSS), is the application of Lean philosophy to Six Sigma programs to bring in added focus on work-flow optimization (by reducing "wastes" in a process).

        LSS combines the best of both the excellence frameworks - Lean and Six Sigma - to offer a complete package for driving process improvement.

        -Reducing process variation (higher product quality)
        -Optimizing process flow (reduced cycle time)

        In a generic sense, Six Sigma can be extended to address the areas that are targeted by Lean. Six Sigma can easily address problem that involve reducing delivery time (process average) and improving the delivery consistency (process variation).Lean, however, adds certain tools and techniques that make the Six Sigma tool-set richer and more powerful.

        Lean

        Lean or Lean Manufacturing has its roots in Toyota Production System. The key concepts and methods of Lean are as listed below:

        1. 7 Types of Waste - Focus on reducing waste in the form of inventory, changeovers, unnecessary activities, idling, etc.

        2. Value Stream Mapping - Optimize process work flow through redesign to eliminate or reduce non-valued added activities

        3. Quick Changeover (SMED = Single Minute Exchange of Die) - Reduce idle time during man, machine or material changes that happen during the execution of a process

        4. Poka-yoke (Mistake Proofing) - Design products and processes in such a way that errors are curtailed or prevented from occurring in the first place

        5. Kaizen (Continual Process Improvement) - Be on the look out for opportunities for process improvement on an ongoing basis

        6. 5S - Organize and arrange the work-place and work-aids to increase the actual productive time spent during working

        7. 3M - Focus on reducing wastes and inefficiencies in the process

        8. JIT (Just in Time) - Make inputs for performing activities available as close to the point of start as possible (zero inventory)

        9. Kanban (Card System) - Order only when required and as late as possible. Kanban is a pull-type order system for inventory management which supports JIT implementation quite effectively

        ITIL

        ITIL (IT Infrastructure Library) is also known as ITSM (IT Service Management). In fact, there is an ISO standard around it, ISO 20000.

        ITIL or ITSM is about conceptualizing, designing, developing, operationalizing and continually improving IT service offerings to the target users (internal or external). Though ITIL is meant for IT services primarily, in a conceptual sense it can be applied to non-IT services as well.

        ISO 9004

        ISO 9004 is concerned with providing guidance to organizations as they adopt and mature a quality management system. The quality management system is typically established, used and improved in accordance with ISO 9001 (probably the most widely adopted ISO standard).

        Unlike the ISO 9001 standard, however, ISO 9004 is not meant for third-party certification, regulatory or contractual use. However, it is similar to ISO 9001 in terms of its applicability since any type of organization, regardless of size, type and activity can put ISO 9004 to use. Although ISO 9004 complements the ISO 9001 standards and vice-versa, it can also be used independently. It is also not be be construed as a guide for implementing ISO 9001.

        ISO 9004 strengthens the process and improvement program of an organization. It enables an organization to institutionalize the ISO 9001 and other good practices for sustained success in its business operations and continual performance improvement, amidst today's complex business environment.

        ISO 9001

        ISO 9001 is probably the most well-known and most widely adopted business excellence model. As a framework, ISO 9001 is quite generic in nature and hence offers high degree of flexibility in its implementation.

        ISO 9001 Certification has come to be accepted as a pre-requisite for business organizations, especially the SMEs (Small and Medium Enterprises), to qualify for competing in the marketplace. The vendor qualification process in most of the organizations considersISO 9001 Certification status of the competing vendors for deciding on awarding the contract.

        From an internal perspective, business organizations can benefit greatly by adopting and aligning their business model with the ISO 9001 framework.

        For organizations interested in adopting ISO 9001 the fist natural question is - "How to implement ISO 9001?". ISO 9001 should be adopted and implemented as per a structured and systematic Implementation Roadmap. Such an approach ensures an effective and sustainable ISO 9001 Implementation. The exact Implementation Steps an organization must follow depend on other factors as well, such as business context, organizational culture, existing process maturity, business need for implementingISO 9001, etc. The MR Role in ISO Implementation and Certification is a crucial enabler for success with the ISO program.

        ISO 27001

        As "IT" or Information Technology has gained in importance amongst business organizations so has the importance of the "I" or Information in "IT". Creating, storing, securing, and most importantly making use of the information at the right time for the right purpose is a weapon that business organizations possess today for delivering the right business outcomes.

        ISO 27001 steps in to make this happen by providing a generic framework for developing and running an Information Security Management System for use by a business organization.

        ISO 27001 Certification is now recognized as a bold statement about how seriously a business organization treats data and information. In a world where outsourcing has become a reality in doing business, ensuring confidentiality, integrity and availability of data is of utmost criticality.

        From an internal perspective, business organizations can benefit greatly by adopting and aligning their information security management strategy with the ISO 27001 framework.

        For organizations interested in adopting ISO 27001 the fist natural question is - "How to implement ISO 27001?". ISO 27001 should be adopted and implemented as per a structured and systematic Implementation Roadmap. Such an approach ensures an effective and sustainable ISO 27001 Implementation. The exact Implementation Steps an organization must follow depend on other factors as well, such as business context, organizational culture, existing process maturity, business need for implementing ISO 27001, etc.

        ISO 14001

        ISO 14001 is a framework for designing, developing and deploying a management system for managing the environmental impact of the operations of a business organization.

        Companies typically establish an EMS (Environment Management System) as the primary vehicle for deploying ISO 14001 requirements. An EMS enables the organization to:
        1. set objectives on parameters which indicate impact on the environment
        2. monitor and control the environmental impact of its operations in line with the objectives
        3. improve the mechanism to reduce the impact on environment
        4. and lastly, demonstrate compliance to ISO 14001 requirements

        An effective implementation of ISO 14001 will generally make use of ISO 9001 as the basic framework on top of which EMS gets deployed.

        It's increasingly becoming crucial for business enterprises to adopt and practice sustainable business practices. Tighter government regulations and ever-vigilant media ensures that companies don't harm the planet in their pursuit of ever-higher profits.

        Many companies have adopted "Go Green" campaigns for educating their employees on eco-friendly practices. In addition, many companies have started investing heavily in "Green Technologies".

        EFQM

        EFQM (European Foundation for Quality Management) is a business excellence framework used by companies across the European Union. It can be compared with MBNQA which is used by companies in the USA.

        The EFQM Excellence Model has 9 elements - 5 "Enablers" and 4 "Results". The 'Enablers' mean what an organization must do and the 'Results' mean what an organization must achieve. Based on where an organization stands against these 9 elements or criteria, the capability and performance of an organization can be characterized.

        The key premise of EFQM is that the "Results" are caused by the "Enablers" and the "Enablers" improve continually based on the feedback received from the "Results" achieved. The 9 elements are given below:

        Enablers
        1. Leadership
        2. People
        3. Policy and Strategy
        4. Partnerships and Resources
        5. Processes

        Results
        6. Key Performance Results
        7. People Results
        8. Customer Results
        9. Society Results

        DMAIC

        For six sigma proponents, DMAIC is like a message from the messiah!

        DMAIC stands for Define, Measure, Analyze, Improve and Control.

        DMAIC offers an approach and associated tools and techniques for:
        • systematically determining the current business value created by a process
        • setting realistic targets on the expected higher business value
        • and then driving changes to the process in delivering the higher value.
        A typical roadmap for applying DMAIC Six Sigma to solve a business problem is as follows:

        DEFINE
        • State the business problem (pain point or improvement opportunity). Example: 
          • CEO - “we have lost two customers last month, and if I remember correctly we lost one the month before as well”
        • Identify the business process or processes that majorly contribute to the business problem. Example: 
          • VP Sales - "our suppliers are delaying on their commitments… our supplier monitoring process is ineffective in dealing with this issue, and our supplier selection process is not rigorous enough”

        MEASURE
        • Apply quantitative rigour to select the business processes to be considered for change or improvement. Example: 
          • VP Quality - "on analysis performed by the Six Sigma Black Belt, our supplier monitoring process has emerged as something we got to fix”
        • Quantify the business problem in terms of the characteristics of the selected business processes. Example: 
          • Six Sigma Black Belt - "the average %Schedule Slippage of our suppliers is close to 8%, but the “worst performing” 5 out of the 20 suppliers have an average %Schedule Slippage of 15%”

        ANALYZE
        • Apply Six Sigma tools and techniques to determine the factors influencing the behavior of the selected business processes. 
        • And then determine the possible changes and improvements to these business processes so that they behave in a desired manner. Example: 
          • Six Sigma Black Belt -"study of the 5 suppliers has shown that the common problem area is poor demand forecasting and inventory management by these suppliers, this can be easily taken care of by deploying appropriate statistical methods”

        IMPROVE
        • Bring about the changes or improvements to the selected business processes. Example:
          • VP Quality - "selected suppliers have been asked to improve their demand forecasting and inventory management method, also they have been trained by the Six Sigma Black Belt on some of the statistical tools they can use” 

        CONTROL
        • Ensure the improved process performs as desired Example: 
          • VP Quality - "in the last two month since we brought the issue of demand forecasting and inventory management with some of the suppliers and helped them in fixing it, we haven't missed any date!
          • VP Sales - "our customers are happy with timely deliveries"
          • CEO - "good going, well... we have won back some of the old customers and are also having discussions with come new customers".

        DFSS

        DFSS (Design for Six Sigma) or DMADV offers an approach and associated tools and techniques for systematically determining innovative ideas related to new product design and development or breakthrough ideas related to upgrading or re-engineering existing product design.

        DFSS is important in designing and developing robust and innovative products which would satisfy the customer's requirements and achieve business success for the organization.

        CMMI

        CMMI as a process model or framework is about Business Excellence and not just about Capability and Maturity. What makes CMMI truly a global framework for business excellence is that it has been adopted by organizations of different types across the world. CMMI can be used to initiate the setting up of a business excellence framework in an organization and in case the organization already has a business excellence framework, CMMI can be easily integrated with it to improve its business impact. CMMI stands for Capability Maturity Model Integration. CMMI is a powerful framework for business excellence owing to its highly effective and integrated approach to process management, product management and project management.

        The evolution of CMMI has its roots in the "Software Crisis" that plagued the development and maintenance of software-based systems in the earlier days. The concept of modeling capability of software processes in terms of 5 maturity levels is what CMMI (or CMM earlier) offered to the software companies as a solution for the "Software Crisis". The five maturity level idea was not really a new concept as it was actually based on the Organizational Maturity Grid proposed earlier by Phil Crosby.

        Though CMMI has its history in the SW-CMM (CMM for Software) it has now evolved into a business excellence framework which can be applied and implemented in different contexts:

        System/product development and maintenance - CMMI-DEV or CMMI for Development
        Acquisition of sub-systems or product components from suppliers - CMMI-ACQ or CMMI for Acquisition
        Service management - CMMI-SVC or CMMI for Services

        When the phrase CMMI Implementation is used it usually refers to adopting CMMI-DEV which has its origin in SW-CMM and SECM (Systems Engineering Capability Model). The I in CMMI stands for integration which means a systems approach to engineering - considering both hardware andsoftware. Of course, it can still be applied and implemented to pure software development and maintenance. It is undoubtedly the most used framework in the IT companies though it can be adopted equally easily by non-IT organizations also.

        It's a fact of modern day business that all systems and products are gradually becoming "softwarized". From the automobile we drive, to the cellphone we use, to the aircraft we fly in, all have a lot ofsoftware residing within them. The difference between pure software and pure hardware is getting eroded with each passing day and hence the need of the hour is to look at business processes and business excellence from a systems perspective. In this context, CMMI fits in very well.

        The use of CMMI for Business Excellence has resulted in mixed results as far as better financial performance (in terms of higher revenues and/or lower operating expenses) is concerned. We must remember that CMMI is just one of the many elements that impact thefinancial performance. At the same time, financial performance is not a true indicator of business success. Continued business success, year after year and quarter after quarter, depends on the robustness of the overall strategic and operational model of a business organization.

        For organizations interested in adopting CMMI the fist natural question is - "How to implement CMMI?". CMMI can be implemented by following a systematic and structured approach for extracting the full benefit. CMMI adoption using a well-defined Implementation Roadmap ensures successful adoption and continued sustenance of CMMI in an organization. The exact Implementation Steps an organization must follow depend on other factors as well, such as business context, organizational culture, existing process maturity, business need for implementing CMMI, etc.

        Beyond the mere implementation of the practices and sub-practices required by the CMMI framework, the real value of CMMI lies in going for the bulls-eye - achieving CMMI High Maturity. CMMI High Maturity has gained importance in the recent years as it was being realized that most of the CMMI Appraised organizations have failed to derive the real value from their CMMI Implementation. The primary reason for this is also obvious - in the race for achieving a numerical maturity level status, many of the finer aspects and concepts of CMMI were not given a rightful consideration they deserved.

        Agile

        Agile methodology emerged as an alternative to CMMI and other "heavy" frameworks. The perception of "heavy" evolved due to the excessive (or supposedly excessive) volume of processes and documents that are needed to demonstrate compliance to the "heavy" frameworks. The evolution of Agile can be traced back to Lean or Lean Manufacturing methodology that is commonly used in manufacturing companies.

        Though Agile came from the software industry, it can be applied equally effectively to non-software product development also. Generically speaking, process agility is important for companies in all sectors of the economy.

        Agile relies on continuous development, integration and testing to ensure software development is done according to an adaptive approach. Interaction between the developers, testers and customers is encouraged to ensure fast-paced development.

        Agile is effective in the development of products which use emerging technologies or provide "novel" features as they involve lot of research and analysis to finalize the product features and low-level implementation details. On the other hand, the typical commercialproduct development prefers predictable and speedy execution and hence relies on` proven methodologies and technologies. In such cases CMMI-driven approach may be a better choice.

        In the recent years, attempts have been made to evolve a combined and integrated approach to apply both agile and CMMI together. Supplanting Agile concepts on a CMMI implementation is an effective way to reduce the burden associated withproduct development.