Friday, 9 September 2016

Kaizen, Lean and Six Sigma

What is Kaizen?

Kaizen is a Japanese word for “Change for the better” or it is also referred to as “Continuous Improvement”. So it is a journey and not a destination, it is a mindset as opposed to being a specific tool. It is a culture that needs to changed & adopted by the organizations. It uses personal creativity and ingenuity to identify problems and then develop and implement ideas to solve those problems. Kaizen philosophy says that everything can be improved and everything can perform better or more efficiently. It helps to identify 3 MU’s – Muda (wastes), Mura (variation/ inconsistency) and Muri (strain/ burden on people & machines).

Kaizen is the practice of continuous improvement. Kaizen was originally introduced to the West by Masaaki Imai in his book Kaizen: The Key to Japan’s Competitive Success in 1986. Today kaizen is recognized worldwide as an important pillar of an organization’s long-term competitive strategy. Kaizen is continuous improvement that is based on certain guiding principles:

·         Good processes bring good results

·         Go see for yourself to grasp the current situation

·         Speak with data, manage by facts

·         Take action to contain and correct root causes of problems

·         Work as a team

·         Kaizen is everybody’s business

·         And much more!

One of the most notable features of kaizen is that big results come from many small changes accumulated over time. However this has been misunderstood to mean that kaizen equals small changes. In fact, kaizen means everyone involved in making improvements. While the majority of changes may be small, the greatest impact may be kaizens that are led by senior management as transformational projects, or by cross-functional teams as kaizen events.

What is Lean

Lean is opposite to fat and it often focuses on removal of ‘wastes’ sometimes referred to as ‘muda’ in Japanese. Operations that fail to create value for the end customer are deemed “wasteful.”

Although the basic lean model was introduced more than 100 years ago, it has continued to evolve over time, from Henry Ford’s continuous assembly lines for the Ford Model T, to the concept of interchangeable parts used by Eli Whitney and Samuel Colt, to the Toyota Production System. These concepts, in addition to a multitude of others, have come together to formulate what we know today as lean manufacturing.

What is Six Sigma

It is a set of tools and strategies to limit defects and variability/ in consistency, also referred to as “Mura” in business processes. Its two project methodologies – DMAIC (define, measure, analyse, improve, control) and DMADV (define, measure, analyse, design, verify) are based on Deming’s Plan-Do-Check-Act cycle. The team leverages advanced statistical techniques such as pareto charts and root cause analysis to reach quantified value targets.

The roots of Six Sigma as a measurement standard can be traced back to Carl Friedrich Gauss (1777-1855) who introduced the concept of the normal curve. Six Sigma as a measurement standard in product variation can be traced back to the 1920’s when Walter Shewhart showed that three sigma from the mean is the point where a process requires correction. Many measurement standards (Cpk, Zero Defects, etc.) later came on the scene but credit for coining the term “Six Sigma” goes to a Motorola engineer named Bill Smith. (Incidentally, “Six Sigma” is a federally registered trademark of Motorola).


Kaizen looks to improve all aspects of a business through standardizing processes, increasing efficiency and eliminating waste by involving everyone while Six Sigma focuses more on improving the quality of the final product by finding and eliminating causes of defects, whether by variances (Sigma is a mathematical term that measures a process' deviation from perfection) in the business process or in manufacturing and Lean focus on elimination of ‘wastes’in order to improve process speed and quality through reduction of process wastes

The most important fact however is that one is not better than the other - you need, can benefit from the use of, and should be using all. The bottom line is don’t waste lots of time and money trying to put ways of thinking and improving in place as these concepts/ tools are designed to save time and money. The ultimate goal will be Operational Excellence for Business Excellence and the spirit should be to improve, to change the paradigms, to change the culture, to change the current set of habits, etc. 

Wednesday, 3 August 2016

Project Portfolio Management

Project portfolio management (PPM) refers to a process used by project managers and project management organizations (PMO’s) to analyze the potential return on a doing a project. By organizing and consolidating every piece of data regarding proposed and current projects, project portfolio managers provide forecasting and business analysis for companies looking to invest in new projects.

Project Portfolio Management with Kanban - LeanKit

Project portfolio management gives organizations and managers the ability to see the big picture.

  • Executives – know what project managers to reach.
  • Project managers – easy access to team members.
  • Team Members – improved communication with leadership and other teammates.
  • Stakeholders – kept in the loop with reliable and consistent feedback.

Take Informed Risks

Taking risks is an inherent part of business. However, when taking a risk it is important to remember, the bigger the risk does not always equal the bigger reward. Risk vs. reward all boils down to smart decision making.

Understand Risks, Reap Bigger Rewards

The project portfolio management process helps companies predict the outcome and plan for projects that will offer the best results. It highlights questions such as:

  • Do I have the resources/budgets available to take on this new project?
  • Is there a similar project in my portfolio I can use to model after this one?
  • What current projects might act as a barrier to completing this project?
  • Are the stakeholder’s expectations realistic? Where can we compromise?
  • Does this project help reach our overall objectives as an organization?

Project portfolio management helps companies break down every detail of a proposed project – budgets, resources, tasks, timelines and goals. Using in-depth analysis of proposed projects, weighed against current projects, a company can define what risks offer the most rewards.

Using key indicators that illustrate costs versus returns, organizations are able to determine whether a project should go forward. This allows for the creation of fluid and replicable workflows that ensure efficiency and optimal team performance.

Mitigating Risks

By using PPM, project managers and PMOs have a global view of each project. When every element of a project is presented as whole, problems can be predicted before they ever occur.

The PPM process gives organizations the foresight to identify potential risks and put the necessary measures in place. This helps a company proactively manage risks, allowing teams to realistically estimate potential delays and put into place measures to prevent or mitigate those risks, should they prove to be unavoidable. Risk mitigation can entail:

  • Aligning each proposed project with overall organizational goals
  • Providing measurable data used to weigh risks against rewards
  • Determining potential bottlenecks and design flaws at more than one level
  • Reconciling team bandwidth with the amount of work needing to be done

Project Portfolio Management vs. Project Management

At the most basic level, PPM and project management differ by number of projects. Project management looks to focus on an individual project’s road to completion, whereas project portfolio management takes into consideration every project or potential project and its viability to meeting overall business goals.

A smarter approach views project portfolio management as the process which lays the foundation for more efficient project management.

Here are a few ways in which project portfolio management helps support the fundamentals of project management.

  • Avoids project management disasters by pointing out good projects versus bad projects, the ROI and the projected value the project might have to the organization
  • Offers a clear path to prioritization that allows project managers to create flexible timetables
  • Lists what team members and project managers are available
  • Helps assign monetary value to a project, making project budgets firm

Effective PPM helps project management become an easier road to travel. When used in tangent, they are invaluable to a organization.

Project portfolio management lays down a methodology used to predict potential problems, review progress towards operational goals, manage budgets and stakeholder concerns. Allowing project managers to then follow up with precision execution.

See the Big Picture

Project portfolio management gives companies a “bird’s eye” view of upcoming, current and past projects. By seeing the big picture of how a proposed project will fit into the goals and objectives of the organization, companies can make better decisions on what projects to choose and what initiatives will create the most return.

Tools for Project Portfolio Management

Project portfolio management helps leadership plan projects and predict outcomes. To effectively plan, PMO’s use project portfolio management tools such as project portfolio management software, scenario analysis tools and good old-fashioned spreadsheets, in addition to other software tools used by project managers.

Though there are many types of project portfolio management tools, the best ones:

  • Accommodate project portfolio management at the enterprise level
  • Offer user-friendly interfaces and functionality
  • Deliver enhanced online features for remote collaboration and communication
  • Provide robust reporting and analytics

Outlined are a few of the benefits that come with using project portfolio management software.

Easy to Use Enterprise Project Portfolio Management Software

Enterprise means one resource with multiple functionalities that can be used across the entire business spectrum.

Most PPM tools are created as enterprise software, decreasing the reliance on multiple applications that can increase overhead and confuse workflows. As an enterprise solution, this usually means you do not have to be an Information Technology whiz to figure how they work. These tools incorporate simple functionality like the “drag and drop” and do their best to organize information in ways that seem intuitive to most users.

Centralized Communication Hub

Often businesses and organizations who take on multiple projects have employees and team members working remotely. When you have various team members working from multiple locations, effective communication can be difficult.

The best PPM tools are accessible online, eliminating communication barriers.

When communication is streamlined through one central hub you can:

  • Connect and coordinate with all team members and provide real-time status updates
  • Track, share and store data, files and feedback
  • Answer questions and solve problems faster
  • Quickly and easily mine data that can be shared with stakeholders

A Step Ahead with Better Reporting

A good PPM tool should offer robust reporting options. Report data provides executives and managers perspective that allows them to predict what projects may require excessive resources by highlighting active projects or circumstances that may act as impediments to organizational goals.

PPM reporting tools also allow companies to actively monitor every facet of the organization’s current and potential projects, including budgeting, forecasting and risk/reward analysis.

Individual project budgets may go over, but effective use of PPM tools may help a company see the potential impacts to other projects and determine whether going forward with a project that is already over budget will pose a problem in terms of multiplied financial overages in other areas. When projects fall behind, leadership has the ability to stifle the potential ripple effect using project portfolio management techniques.

Reporting makes for factual and informed project portfolio management that in turn helps set expectations within the company regarding what projects should, and should not, go forward.

Thursday, 7 July 2016

Process Maturity

Let´s take a look at the concept of process maturity, which shows until what extent a process is manageable and predictable. 

There are five levels of business process maturity:

  • Level 1: Initial – business processes are inconsistent and are not coordinated.
  • Level 2: Managed – business processes are defined, but different procedures are used for similar tasks, making work badly coordinated.
  • Level 3: Standardized – standard processes are synthesized from best practices, and guidelines are provided to support different business needs.
  • Level 4: Predictable – detailed measures of the processes and their outputs are collected, analyzed and controlled. Process performance is measured throughout the workflow so that process outcomes can be predicted.
  • Level 5: Innovating – processes are continuously improved.

Every new level makes a company more able to meet competition, timely react to market requirements and wisely use its resources. Fully describing and specifying the processes can take the company to Level 3 at the most. It is possible to go from Level 3 and higher only if the workflow (business processes, document management and so on) is automated. 

According to the Deming cycle (Plan-Do-Check-Act), the simplest model for process improvement consists of four steps:


Deming cycle in business process management

  • Plan – define the objectives and processes that are necessary to deliver the expected result; plan the work aimed at accomplishing the process goals and satisfying the customer; schedule resources.
  • Do – implement the plan.
  • Check – collect information and study the actual result comparing it to KPIs; look for deviations, analyze them and find their causes.
  • Act – implement the improved solution, correct deviations; modify the plan and resource scheduling.

Let us sum it all up. 

BPMN allows you to model an executable process. The main concept of an executable process is as follows: first, you draw the diagram, and then the process is executed according to the diagram. Processes described with BPMN and automated in BPM systems are manageable from the moment they are modeled to the moment they are executed, allowing for constant improvement.

fig 1 700

Friday, 17 June 2016

Stakeholder Analysis

To identify the stakeholders, ask yourself whose help you need to develop, release, and provide the product. The answer to this question will be specific to your product and company. For a commercial product, the group is likely to include representatives from marketing, sales, support, and management. But it might also comprise legal, finance, and human resources. For an in-house product, your stakeholders may be operations, the affected business units, and management.

Analyse the Stakeholders

Once you have identified the stakeholders, take the next step and analyse them to understand how you should engage with them. This focuses your efforts, generates the desired buy-in,  and allows you to spend your time wisely.

A common stakeholder analysis technique is the power-interest grid, which was originally published by Colin Eden and Fran Ackermann in their book Making Strategy. As its name suggests, the grid assesses the stakeholders by taking into account their power and their interest. The grid assumes that stakeholders take a low or high interest in your product and that they have low or high power. A stakeholder is typically interested in the product if it noticeably affects the individual. Someone has a high power if the person can influence the product decisions, for instance, if or when a feature is implemented.

Taking into account low and high power and interest results in four quadrants and stakeholder groups, players, subjects, context setters, and crowd, as the following picture shows.


Each stakeholder group on the grid above requires a different level of engagement, as I explain below.

Collaborate with the Players

Stakeholders with high interest and high power are called players. These individuals are important partners for you as the product manager or product owner. You should therefore collaborate with them closely, for instance, by inviting them to product strategy and roadmapping workshops and sprint review meetings. Aim to secure their buy-in, leverage their ideas and knowledge, and establish a close and trustful relationship with them.

Additionally, ensure that the individuals are involved with the product on a continued basis to avoid loss of knowledge and hand-offs. It is undesirable, for instance, that the marketing group sends a new representative every time a strategy workshop or review meeting takes place. Instead, one marketer should represent the group on a continued basis.

Bear in mind that collaboration requires leadership. You should be open and collaborative but decisive at the same time. Aim to build consensus with the players but don’t shy away from difficult conversations. Don’t settle for the smallest common denominator and have the courage to make a decision if no agreement can be achieved.

Involve the Subjects

Subjects are individuals with high interest but low power. They feel affected by the product and are keen to influence it but they can’t veto or change decisions. Subjects can make great allies who can help you secure understanding and buy-in for your product. Keep them engaged and involve them on a regular basis, for instance, by inviting them to sprint review meetings and encouraging them to share their feedback.

But don’t make the mistake to say yes to every idea and request subjects raise. Use the product strategy and roadmap to assess if an idea is helpful or not. If in doubt, consider running a brief and cheap experiment to find out if adding a feature would be beneficial, for example.

Consult the Context Setters

People with low interest but high power are called context setters or referees. They affect the product’s context but they take little interest in the product itself. An example is the person in charge of the development group: If the individual does not help staff the development team properly, then the success of the product may be at risk.

Make sure that the context setters feel that their opinions, concerns, and ideas are heard and understood. Regularly consult them, for instance, by having one-on-one meetings. This ensures that their ideas and concerns are heard and it helps avoid nasty surprises. Don’t let the context setters intimidate you and don’t allow them to dictate decisions. Be strong and have the courage to say no even if faced with a powerful and pushy stakeholder.

Inform the Crowd

The crowd are stakeholders with low interest and low power. As they are not very interested in your product and don’t have the power to influence product decisions, it’s usually sufficient to keep the individuals informed, for instance, by giving them access to the product’s wiki web or by sending out a status report to update them on important developments.


The following table summarises my recommendations on how to engage with the four different stakeholder groups.

Stakeholder GroupEngagement LevelEngagement FrequencySample Engagement Techniques
PlayersCollaborateOnce per sprintCollaborative workshops including strategy and roadmap workshops, sprint review meetings
SubjectsInvolveMonthlySprint review meetings
Context SettersConsultQuarterlyOne-on-one meetings
CrowdInformQuarterlyStatus reports

Thursday, 12 May 2016

Project Managers in Enterprise Agile

Recently, I was engaged in a lively conversation about enterprise agile transformations and the topic turned to Project Management Offices (PMOs) and, specifically, Project Managers (PMs). The gentleman I was speaking with said that in ideal agile, there is “no need for Project Managers”. His argument was that they are replaced by Product Owners, Delivery Teams, ScrumMasters, and/or Functional Managers.

At first glance, there may appear to be merit to his statements. Let’s look at some of the evidence:

  • In most agile methodologies and frameworks, there is no Project Manager role. In fact, there might not be projects at all.
  • No need to build teams around a project – teams are stable and work is brought to the team.
  • No need to manage scope and build detailed GANTT charts – that is done by Product Owners through a well-defined, prioritized backlog.
  • No need to gather individual estimates – that is done by the teams progressively.
  • No need to gather individual progress status – that is done through working, tested software and burning down work.

So was the gentleman correct? I contend that he was not, especially as you start to scale agile in larger organizations. In fact, in my experience, buy-in and alignment of the PMO and Project Managers could make or break your transformation.

I will not deny that the traditional role and responsibilities of a Project Manager changes and may be distributed in agile, however, the skills and experience PMs bring to the table are extremely valuable.

Effective Project Managers have good organization and communication skills. They are well versed in risk and dependency management. They understand ways to manage time, cost, and scope. They know the organization and how to remove impediments.

So what becomes of Project management in an enterprise agile world? There are many roles a traditional Project Manager can play. One such role is as a Portfolio Manager on a Portfolio Team.

Portfolio TeamThe Portfolio Team is responsible for setting the vision and strategy, deciding on initiatives in which to invest, and ensuring value is aligned with business strategies. The Portfolio Manager helps make sure that the team has everything it needs to function effectively. This goes beyond just scheduling recurring meetings. The Portfolio Manager can act as a servant leader, removing impediments, measuring progress, and enabling the team to make decisions on the portfolio.

The Portfolio Manager is the facilitator for the team. They help keep the team accountable to adhering to processes and working agreements, as well as ensuring the team operates efficiently.

Product Owner TeamAnother role could be that of a Program Manager on a Product Owner team. As an organization scales, it becomes difficult to manage dependencies and risks. It becomes overwhelming for a Product Owner to provide clarity of the backlog to their delivery teams.

By forming a team around a Product Owner, many individuals can lend support and capacity to the Product Owner, providing delivery teams that backlog clarity. A vital part of that team is the Program Manager. They help to clear impediments, manage dependencies and risks, hold the team accountable to providing all the things necessary to ensure the delivery teams are never starved of requirements. They can also serve as an escalation point for blocks and issues that cannot be resolved within the delivery teams.

Other areas and roles a traditional Project Manager could serve or grow into include Release Manager, ScrumMaster, Community or Practice Lead, Product Owner, or Internal Coach. I tell Project Managers to really think about their long term career goals and be proactive in pursuing those areas of interest.

The biggest lesson I try to impart is how to be a servant leader. Changing your mindset from directing to serving can be difficult. But, in an Agile world, servant leadership is what is needed to be truly successful. Enabling others to be successful, will make the organization and the individual successful. When the teams win, everyone wins.

I encourage Project Managers to seek opportunities where they can help the organization and the transformation. With a Project Management background and a servant leader mindset, PMs can grow into incredibly effective agents of change.

Tuesday, 10 May 2016

Overview of process analysis

Quite often, when process work enters the analysis phase, there is either a fair bit of confusion or (perhaps more typical) a lot of running forward with no direction.  At this point in a project, the effort of gathering process information is finished and people are eager to move on to the next phase of fixing/improving the process or redesigning it.  However, they know they "should" do some analysis first.  Sadly, the very approach that created problems in the process may be used at this point to analyze the problems, e.g., fire-fighting, checking the box, or "the way we've always done it" (whatever that is).  This is really unfortunate.  The highest Return On Investment (ROI) from a process improvement effort will be generated by excellent analysis.  Really good analysis of a process will uncover the real problems instead of the symptoms, the perceived problems, or the personal pain points.  Improving/changing a process based on the symptoms or pain points results in sub-optimization and frequently produces negative, unintended consequences.

For example, I recently sat in on a presentation by a group whose project objective was to solve the problem of not knowing who, how, or where to contact the staff in the event of an emergency situation (such as a hurricane in the Gulf).  They put together a very good presentation on their solution, which included compiling all the necessary information so that it would be readily available in the future.  That's a great idea, right?  Not really.  They missed the fundamental problem.  The real problem was that the assessment process that was supposed to ensure that there was a process in place when an "event" occurred to contact people was completely inadequate.  Otherwise, the problem would never have been a problem.  With their solution, they now have a contract list, but the next time an "event" occurs, if the people are different or their numbers have changed or the person responsible for actually doing the contacting is different or...  they will still have the same problem.  Had they done a proper job of analysis, they would have realized where the real problem was.  And by fixing that core problem they would have helped not only their own area of the business but several others as well since this safety assessment is an integral part of almost everything in their business.

Understanding the various analysis techniques won't necessarily fix this kind of problem, but it does provide a well-stocked tool kit to pull from when planning the analysis of current business processes.  This in turn results in higher quality, with more accurate and valuable results.

There are a multitude of analysis techniques that can be applied to business processes in an effort to determine what problems need to be addressed.  This article provides a brief overview of the most common and useful techniques.  Many of the techniques are referred to by different names in the various disciplines of process analysis.  The most common/generic names will be used although it should be noted that many of these techniques are also used in Continuous Improvement, Lean, and Six Sigma efforts but have acquired different names even though the techniques remain the same.  This can cause confusion for people who are new to process and process analysis efforts and it can create the impression that the Lean and Six Sigma concepts are new ideas.  In fact, the techniques in both disciples have been in existence and have been used by analysts for many years prior to the Lean and Six Sigma 'branding'.  A mapping of the original or most common name to the Lean or Six Sigma names will not be part of this article but will be included in follow-up articles that go into more detail.

 Focus on the "Right" Things 

Often, just deciding on what to analyze creates a frustrating dilemma.  It's so easy to be distracted by the identified pain points and symptoms, making it very difficult to step back and view the information objectively.  There are no "silver bullets" for this but the following concepts should help.

  • First, address those things related to the KPIs, Goals, Objectives, and CSF for the project.  If these haven't been defined, define them: 
    • Start with the basics — problems in the process and performance targets for the process often drive which type of analysis technique is used. 
  • Remember that gap analysis drives much of the time spent in analysis. 

  • Ask yourself, who, what, where, when, how, and why (5 times). 

  • When choosing the approach and focus, some useful questions to ask are: 
    • Is the flow correct effective, efficient, and adaptable? 
    • Are there a lot of defects in the process? 
    • Is there an overabundance of frustration? 
    • Is there an excessive number of reviews and/or approvals? 
    • Is anyone in control/accountable?
    • Are there any metrics or defined levels of acceptable outcomes?
    • Is there a "standard" way of working?
    • Are there appropriate controls in the process? 
    • Are the activities/tasks/steps really necessary? 
    • When the "unexpected" occurs, does it create a "train wreck"?

There are other questions, but hopefully this list will get you started and will help generate ideas for other appropriate questions to ask.

Process Analysis Techniques

There are a multitude of techniques that can be used to analyze processes.  This is part of the problem — too many choices.  It has been my experience over that last twenty years that there are five techniques that should be used every time.  Beyond that, the answers to the questions in the previous section, as well as common sense, help determine if other techniques will be necessary or useful.

Critical (5) Analysis Techniques

The critical five techniques are:

  1. Gap Analysis
  2. Value-Added Analysis
  3. Root Cause Analysis
  4. Observation
  5. Examining the Experience

The first three can be done in facilitated sessions.

Other Analysis Techniques

Other useful and frequently-used techniques include:

  • Critical Path Analysis 
  • Scenarios 
  • Customer Requirements Analysis 
  • Matrices Analysis 
  • Correlation Matrix 
  • Pareto Analysis 
  • Process Constraint Analysis 
  • Cultural Factor Analysis 
  • Customer Focus Groups 
  • Supplier Feedback 
  • Comparisons to Documented Procedures
  • Role Playing

The Critical (5) Analysis Techniques

  Gap Analysis — Utilizing all Process/Activity Information 

Gap analysis is one of the most useful types of analysis.  However, if complete information about the process isn't available to conduct this analysis then most of the value it should provide will be lost.  The complete information about process includes inputs, guides, outputs, and enablers.  This is not a new concept, although many people haven't seen it or haven't seen it in a long time.  It is part of the oldest modeling technique.  Definitions of each component follow.

Input:  something that is consumed by or transformed by an activity/process. 

Guide:  something that determines why, how, or when an activity/process occurs but is not consumed.

Output:  something that is produced by or results from an activity/process.

Enabler:  something (person, facility, system, tools, equipment, asset, or other resource) utilized to perform the activity/process.

When analyzing gaps in the process from an input/output perspective, it is useful to consider the following items:  


  • Sequence of activities 
  • Linear activities 
  • Missing connections between activities 
  • Feedback Loops 
  • Unnecessary Reports 
  • Handoffs 
    • To/from wrong interface 
    • Wrong format 
    • Timing 
    • Phantom-handoff that don't really exist but are assumed to exist 
  • Direct interface with the customer 
  • Activities performed redundantly in different parts of the organization 


  • Restrictive policies & guidelines 
  • Activities with experience as the only guide 
  • Assumed policies 
  • Lack of training, education, and/or knowledge/experience 
  • Inappropriate or no measurements 
  • Steps controlling others 
  • No consistent process 

Guides are the source for the greatest opportunity for improvement; therefore they should be carefully analyzed for:

  1. Legitimacy 
  2. Accuracy 
  3. Relevancy 
  4. Appropriateness 
  5. Value to the Customer/Business 


  • Inadequate use of technology 
    • Using an adding machine with Excel 
    • Using a dictionary with Word 
    • Creating Spreadsheets to analyze Enterprise Data 
    • Creating Access Data Bases to store and update Enterprise Data 
  • Lack of technology 
  • Environmental or Facilities Issues 
  • Human Performance Technology (HPT) 
    • Lack of training, education, and/or knowledge/experience 
    • Focuses on analyzing and improving human performance, on job design, training, motivation, and management system

  Value-Added Analysis 

Value-added analysis is a detailed examination of every activity/task in a process to determine if it supports/contributes to customers'/stakeholders' requirements or needs.  To add value, a process/activity must produce an output that creates value for the customer, and the completion of the activity must be required to create that output.  The objective is to optimize the value-added steps and to minimize or eliminate non-value-added steps.  It is worthwhile for the team to identify the non-value-added actions as early in the analysis as possible. 

The decision tree shown here depicts a very basic approach for the initial evaluation of the "Outputs from Activities."  Each activity should be evaluated for its true value to the process.  This technique can be used as a starting point in a facilitated session with the business.

Depending upon the discipline for "process improvement" that is being followed or implemented, the titles assigned to the three categories of value-add are:

  • Real Value-Added (RVA) — refers to activities that are essential to the process in order to meet the customers' expectations. 

  • Business Value-Added (BVA) [Necessary Non-Value Added] — refers to activities essential to conducting business, such as policy and regulation compliance, that add cost to the process but do not add value from the customer's perspective. 

  • Non Value-Added (NVA) — refers to activities that neither add value to the process from the customer's perspective nor are required to conduct business, such as storage, movement, rework, or approvals. 

When evaluating the potential for value, activities are classified into the four phases of a typical process life cycle:  Plan, Execute, Review, and Adapt.  Furthermore, Plan can be broken down into planning (VA) and preparation (NVA) activities.  Execute can be broken down into execution (VA), storage (NVA), movement (NVA), and handling (NVA).  Review can be broken down into prevention (VA) and control (NVA).  Adapt can be broken down into prevention (VA) and processing defects and waste (NVA).

The Planning part of Plan and the Execution activities in Execute normally are considered value-add activities based on these definitions:

  • Planning:  the preparation of a detailed method that is formulated prior to execution, for doing or making something.  (The objective of planning is to reduce the chance of error and to minimize rework.) 

  • Execution:  the transformation of information; the output of information; the delivery of a service that directly meets a stakeholder's needs.  

The verbs in the table below describe activities that are normally considered value-added. 

Utilizing the concept of the process life cycle to evaluate value, the verbs used in the activity naming convention are the focal point.  This method examines the verbs that should be part of the verb-noun naming convention.  There are many verbs that indicate a strong potential for an activity to be non-value added from both the customer and business point of view.

As a key to identifying non-value-added actions, the following is a sample list of verbs or actions that are normally considered to be non-value-added.  This is a valuable method for creating the "top suspect" list.  This list can be used to ask more detailed questions, if necessary, regarding who, what, where, when, how, and why (5 times).


To change something to make it fit, conform, or suitable for use.


To give consent to someone or something as being good or satisfactory.


To set something apart from something else or mark it for a specific purpose.


To alter, substitute, or replace something with something else.


To put something in its proper order.


To gather things together for some purpose.


To make an imitation of an original thing.


To carry something and leave it at the proper place or places.


To give something out, scatter, or spread it out.


To take someone or something out; remove it or get rid of it.


To speed something up or make the progress easier.


To arrange something in order for future reference or to put it in its proper place or order.


To look at something carefully or examine it critically in order to detect flaws or errors.


To put someone or something into or on something else.


To keep something in good condition, position, or repair.


To determine or estimate the dimensions of something by the use of a standard.


To check on or regulate the performance of someone or something.


To change the place or position of something by pushing, carrying, or pulling it from one place or position to another.


To make arguments, ideas, texts, or accounts of something consistent and compatible with something else.


To put something back in good condition after damage or decay.


To express a wish or desire for something in a polite or formal way.


To bring, send, carry or put something back.


To examine or inspect something formally.


To read something over carefully and to correct, improve, or update it where necessary.


To choose or pick something from among several alternatives.

Sets up

To prepare something for future use.


To stop something on its journey through a process and hold it in a particular place.


To bring something up to date or make it conform to the most recent facts, methods, or ideas.


To test or check the accuracy or correctness of something through investigation, comparison with a standard, or reference to the facts.

Waits for

To stop and wait for someone or something to catch up.

  Root Cause Analysis 

Root Cause Analysis:

  • Is used to perform a thorough analysis of a process in order define a problem; 
  • Uses brainstorming to identify all possible causes and potential effects and impacts on customers/stakeholders; 
  • Pinpoints main cause and identify key contributors until the "real" cause of the problem is identified. 

This technique uses what is commonly called a "fishbone diagram," Ishikawa diagram, or "cause and effect diagram."  This diagram relates all possible causes to specific effects.  Finding the real root cause of an identified problem is not a science but rather a technique that repeatedly asks why things are the way they are.

In conducting root cause analysis, examine the following areas related to a process:

  • People
  • Materials
  • Equipment
  • Environment
  • Methods
  • Guides

Root Cause Analysis-Cause and Effect

Another technique often used to determine the "real" root cause is a Cause and Effect Matrix (or Table).  This technique identifies the potential cause or scenario where a problem occurs then records the most likely effects of that scenario for analysis.  For example:


  Observation — Observing the Process ... "In Person" 

One very important (but rarely applied) analysis technique is that of "observing the process."  This must be done in person.  As workers and workplaces have become more decentralized and many teams work in different locations, this has become very difficult to do, but that doesn't reduce the importance and value of the technique.  Nothing is as enlightening as actually seeing the work done.  More often than not, when people simply talk about how they perform their work, the description is more of a "should be" than it is a true representation of how the work is actually done.  Observing people at work confirms whether there is an accurate understanding of the current As-Is process.  

In a perfect world, it is best to see the work under various scenarios.  The list below represents various scenarios or approaches for seeing and understanding the "real" process activities.

  • Multiple scenarios from 'on-track' to 'train wreck'
  • Be the transaction:  Become an order (or other inanimate object) and get processed, step-by-step. 
  • Act as if you are a customer under different situations. 
  • Find the pain. 
  • Experience the delays and frustration. 
  • Walk around:  Shadow. 
  • Compare the perspectives captured from various individuals. 
  • Note discrepancies for further analysis. 
  • Validate the metrics. 
  • Notice the office environment outside of the project scope. 
  • Non-Value Added activities that have not been identified through facilitation or interviews are often readily apparent when observed. 
  • Find the low-hanging fruit everyone walks on every day. 

  Examining the Experience 

Quite often the quickest way to reach a destination is not via the most obvious path.

All organizations have experienced and competent staff.  These individuals (who typically have 15+ years of experience) are a wealth of knowledge for a process analyst.  Their knowledge and experience is an integral part of why the business runs smoothly, even when the unexpected occurs.  These are the individuals who know how to expedite a six-week activity and make it happen in two days.  They intuitively know all of the non-value added activities and the policies, traditions, or culture that drives them.  A complete and accurate analysis of process is never complete without input from this group.


The analysis phase is often the phase where the focus of the improvement effort is lost as the goals and objectives are forgotten and the assumed problems are addressed and solved without due consideration given to whether these are the real problems.  Or it can be the phase that is given the least attention due the fact the initially-identified problems are the only problems to be solved and little or no actual analysis is done.  Yet, the analysis phase has the potential to provide the highest ROI of all the phases.  That includes the To-Be or redesign phase because if the real problems are not identified then the To-Be work may (unintentionally) actually design the same problems back into the processes.

© Copyright 2012 Gateway to Process Improvement LtdWebsite design by Toolkit Websites