How to overcome project failures

Even if a project has been a complete write-off – or conversely, a total success – there are always lessons to be learnt from the experience. Taking the time to reflect, and training yourself to think critically will help you overcome project failures and work towards future successes. Here we uncover the actionable steps you can take on the ‘road to recovery’ following a project failure.

Ask tough questions (of yourself)

What could I have done differently? This is the biggest question you can ask yourself following a project failure. Don’t underestimate how beneficial carving out the time to reflect on previous projects can be. Think about how you handled each stage, particularly the challenges, and speculate on what you could do better next time.

Critical thinking and problem solving go hand in hand, so before you start a new project look back on previous ones and be critical about their success. Did everything run smoothly? Were the solutions you came up with the best ones in hindsight? Work through the project systematically and reflect on areas of strength and weakness. Armed with this knowledge you will be better equipped for future problem solving as part of your next project.

Reflect on your skills...

Whilst being tough on yourself, question whether you have the full skillset your job requires. This is particularly relevant if you have worked your way up through the ranks quickly. Training and continually upskilling are key for confidently tackling the challenges of your daily work. Take a critical look at whether you are equipped with the tools to respond effectively to issues that arise and find solutions. And if there are pitfalls, such as a lack of process knowledge or technical understanding, remedy these with training. While you’re at it, take a look at your team’s skills too. Investing in their professional development and your own can help to avoid future project failures.

...And on your soft skills

It is said that in the project management profession, your performance is measured by the performance of others. Rather than let that intimidate you, allow it to inspire your practices. Soft skills are hugely significant in project management, so take a moment to evaluate yours. Leadership, for one, is paramount as effective team leadership can make or break a project. Your attitudes, commitment, honesty and communication skills all factor into this and are pivotal in your team’s performance. Reflect on whether these are the best they can be, and if not, brush up! Emotional intelligence and social skills come naturally to some, but for others they need to be nurtured.

Be more responsive

Traditional methodologies within project management put a lot of emphasis on thorough planning and scheduling. Though this may have worked in the past it is not always scalable to today’s evermore complex projects, and so PMs are moving towards a more hybrid approach. By combining your current framework with agile practices, you can be far more responsive when facing hurdles during a project. Agile working allows you to adapt your original plans with carefully considered strategies, whilst always moving towards your end goal. What’s more, using modern tools and technologies to your advantage can go a long way to preempting challenges ahead. Be responsive by first uncovering how to analyse data and flag any warning signs in advance. These indicators will allow you to react effectively and in a timely manner.

Know when to ask for help

There will be occasions where a project’s shortcomings are a challenge too far. Perhaps in order to fulfill a project’s potential you need support from above, in the form of finances or resources. Whatever the hurdle, prepare for the occasions where you need to ask for help by forging strong relationships with your seniors.

Upper management are as invested in a project’s success as you are, if not more so, so they can be a valuable, and an often untapped resource. Whilst you may be reluctant to bother your seniors with issues, by putting in the groundwork ahead of time you can make sure you’re on a good footing. This can go a long way in preventing management from viewing you negatively when asking for help. For example, when signing off a project be sure to report to your seniors not only the successes, but the failures you had to overcome in order to achieve your positive end result. This way, they get the full picture and can identify areas of improvement.

Going forward

When you are intensely committed to making a project work, as most project managers are, it is easy to let failures be all-encompassing. However, learning to recognise when change is needed will help you overcome project failures, preempt and deal with them ahead of time. By being more responsive, improving your leadership methods, building a support network, and upskilling, you will be able to identify solutions to any issue a project throws your way. Remember that everyone is still learning.

Continue reading

Failure Fuels Better Results from Lean

Colleagues at a Lean conference I attended supported this claim, claiming greater than 90 percent failure rates in their experiences. I do not have the data to support this anecdotal “data,” but these numbers beg the question: Why? If true, this failure rate for Lean initiatives would seem discouraging. Or is it?

Failure Is Good

Have you heard the phrase, “fail often, fail early, fail forward”? Failure is not a subject that you should fear; failure should be embraced. You should seek out failure to learn and improve. However, for many organizations, when their first “failure” happens or when Lean initiatives call for harder work than anticipated, they quit and blame the failure on Lean. Organizations may be quick to move on to the next flavor of the month after just a quick exploration of Lean. This creates a frustrated and discouraged workforce. Sustainment only happens when organizations are truly committed to true and lasting change – a relentless pursuit of cultural transformation.

What can you learn from the idea that more than 90 percent of Lean implementations fail?

Leadership Is Everything

I have worked with many organizations from nonprofit to government to manufacturing and ranging from small businesses to billion-dollar corporations. Leadership has been the key component to sustainment or collapse of their Lean initiatives. It is imperative that an organization develop its leaders to embrace the idea of being a learning organization supported by an enabling operating system. Every leader in the organization must be committed. Cultural transformation is hard. Humans can be difficult. There are many obstacles you will face in your Lean journey, but when you are committed to success, you don’t let anything stand in your way!

A Gallup Study found that 50 percent of people who leave their jobs do so to get away from bad leaders. Seventy percent of employees are not engaged at work. Gallup also found that 51 percent of managers not only are not engaged but 14 percent are actively disengaged!1

For Lean initiatives to be sustained, you need a different leadership system, a different management system, than what was in place before Lean. If you don’t deploy a different leadership system, your initiatives will fall apart. If you manage the same way – with the same meetings and same metrics – you will get the same behaviors and results instead of the improved results you are seeking. Unless you change the way you manage, Lean initiatives will not be sustained.

Be a Servant Leader

As a Marine, I attended survival, evasion, resistance and escape (SERE) survival training – it’s an advanced code of conduct course. All military personnel get their initial code-of-conduct instruction during basic training, where they are taught an American service member’s legal responsibility if captured by enemy forces. SERE goes beyond that; it starts with survival. It was in SERE training that a young captain showed me what it means to be a servant leader.

After many days of limited rations, the enemy forced all the officers to eat first. As the rest of us stood in line waiting for our small bowl of soup, the enemy officers kicked over the serving table and all the remaining soup spilled onto the ground. The young captain and a few other officers were the only individuals who had already received their bowl of soup. Without hesitation, the captain ordered the other officers to disperse their soup among the rest of the group. He was first to share. I would have followed that man to the ends of the earth. What an amazing example he gave me of a true servant leader.

A great Lean leader is also a servant leader (see table below). They choose others before themselves. They are humble, listen and build trust. They see conflict and are quick to resolve it. A Lean leader never abuses their authority. They encourage collaboration, trust and empowerment.

Servant Leadership Checklist
Is self-aware	Has foresight	Collaborates
Is humble	Has foresight	Is trusting
Has integrity	Doesn’t abuse authority	Coaches
Is result-oriented	Has intellectual authority	Resolves conflict

You may already have some or many of these qualities. But how do you become a great Lean leader?

Lean Leadership Development

Dr. Jeff Liker’s Lean Leadership Development Model (as described in The Toyota Way to Lean Leadership) will help you break through development plateaus and create a sustainable future for Lean thinking in your enterprise. (See figure below.) When leaders adopt this model as their “system,” their way of managing, amazing things begin to happen.

Lean Leadership Development

1. Commit to self-development. There are a few steps to managing your personal self-development following the plan-do-check-act (PDCA) model.

1.1 Create a vision for where you want to be in the future. This will become your true north. Every decision should then be aligned with this true north. Most of us find it easier to motivate ourselves to learn and improve if you have a purpose in doing so. Your personal vision will give you a clear idea of where you want to be in a few months or years – and why you want to be there. It’s a crucial part of developing this purpose.

1.2 Plan your personal development journey. Once you are clear about where you want to be, you can start planning how to get there. Who do you need to meet? What books or podcasts should you listen to? What mentors do you need to reach out to and on what topics? Drawing up a personal development plan is not essential, but it does make the planning process more realistic. I usually create a one-year plan with 90-day PDCA cycles.

1.3 Carry out your plan. Don’t wait to get started. You can adjust as needed. It is often a good idea to keep a record of your personal development. This is done in the check phase. By writing down key developments in your learning and development as and when they occur, you will be able to reflect on your successes later. Regular review of your personal development plans and activities will ensure that you learn from what you have done.

1.4 Act on your result. It will also ensure that your activities continue to move you toward your goals, and that your goals or vision remain relevant to you.

2. Coach and develop others. The Center for Creative Leadership gave us five areas to assess ourselves as effective leaders developing others.

2.1 Relationships. How well do you establish boundaries and build trust? This cannot be done from your desk. You need to go to the gemba – go to where your team members are and spend time with them. Ask them to show you how they do their job. Show genuine interest in their work and in their personal lives.

2.2 Assessment. Do you skillfully help others to gain self-awareness and insight? Your team should see you and hear from you daily. You should set up a regular cadence of positive and constructive feedback for your team members. A good leader doesn’t just tell. Engage your team members with strategic questions that can help them discover opportunities for improvement themselves and then be sure to give them credit.

2.3 Challenge. Do you effectively challenge the thinking and assumptions of others? You must be careful with this one because you don’t want your team to think you are micromanaging them. Their learning will come through their own mistakes. Allow them to experiment, but challenge strategically with good questions.

2.4 Support. Do you listen well? Do you understand things from your team members perspective?

2.5 Results. Do you help your team members set meaningful goals, hold them accountable and help remove any roadblocks they may have for successes?

3. Support standard work. Leader standard work is a tool that defines what a leader must do to ensure a successful day. It ensures process integrity. The best way to build and sustain a continuous improvement culture is incremental. Daily accountability is key! By following your own daily standard work, you will begin to solve problems quickly, creatively and permanently. Collaboration will become a regular occurrence as your coaching and developing of others becomes a regular habit. Personal productivity and time management are important to assure complete success at the end of each day. Your leader standard work can help with this.

4. Create vision and align goals. There is a certain level of stability within your team and your processes that is necessary to create vision and align goals throughout your organization. Once that stability is reached, it is time to move ahead with your vision and get alignment with goals. People perform best when they have a purpose. When they understand not just what to do, but why it’s important. It is best to know your team well enough to create a shared vision.

The Traits of a Lean Leader

Change leader John Hamalian wrote about six traits of a Lean leader.2 In an organization committed to cultural transformation, leaders need to be intentional to develop these traits within themselves.

1 and 2. Embrace the journey and relentlessly pursue perfection. As previously stated, Lean needs to be accepted and embraced by the organization and every single leader. Lean needs to be the way you do work. It’s not a tool or a step toward something else. Continuous improvement is a never-ending journey toward perfection. You’ve heard of organizations that started their Lean journey just to quit when the going got tough. Your journey toward perfection will not be easy. Thomas Edison once said, “Opportunity is missed by most people because it is dressed in overalls and looks like hard work.”

Lean expert and FastCap CEO Paul Akers is a relentless, maniacal cheerleader for Lean. He arrives at the office and talks to everyone, asking them to show their improvements. He creates videos of every Kaizen and shows them to the whole company at the daily huddle. Paul celebrates every improvement, no matter how small, every day. He may be more excited about the improvement than the person who’s made it! How many presidents/CEOs are willing to make that commitment? Not many. It takes hard work and a total embrace of the journey.

3. Be a fanatic about customer focus. Having a relentless focus on the customer is the path to sustained growth and profitability for any organization. This fanatical customer focus must become everyone’s responsibility, not just the leaders. The customer is the only reason you have a job. If customers are not your focus, then you might as well go home because you are not needed. Every employee must understand what they need to do to maintain and add value to both internal and external/end customers.

4. Champion simplicity. The biggest reason so many leaders fail to maintain a robust, workable Lean system is their desire for complexity. This desire seems to be human nature. You begin simply enough, but then you add more levels of complexity until eventually you have a system that takes far too long to maintain. To avoid that cumbersomeness, you must keep things as simple as possible.

When I was serving in the Marine Corps, I was taught a valuable lesson about communicating strategy to all levels of an organization. The lesson has come to be known as “Napoleon’s Corporal.” Napoleon recognized how vital it was to have an enlisted soldier in the planning process. While creating their battle plans and war strategies, Napoleon made sure there was a corporal in the room. Once finished, he would ask the corporal if he completely understood the plan. If he said, “Yes, sir!” Napoleon would carry out the plan knowing it could be cascaded down to the ground troops, who would understand it well enough to execute it. If the corporal was unclear, then the group would continue working on the plan until the corporal understood it.

Another concept used in the military is KISS, or keep it simple, stupid. When communicating expectations to our teams, they need to be communicated in a manner that everyone can understand.

5 and 6. Live the Gemba and be authentic, upstanding and respectful. The auto manufacturer Nummi, a partnership between Toyota and GM, yielded extraordinary results based on these leadership traits. The two companies selected GM’s plant in Fremont, California, for Nummi’s location, which was considered to have “the worst workforce in the automobile industry” by United Auto Workers. Sex, drugs, alcohol and gambling were all rampant on the job. Despite this, Toyota developed a culture of engaged problem solvers.

The Fremont workers went to Japan for a full immersion in Toyota’s Production System (TPS). The traditional way of managing employees in the United States was top-down and usually done from the office. This was quite different than in Japan, where the leaders embraced a gemba style of leadership and respected the expertise of those closest to the value-add work. In a traditional management system, employees are told about decisions after they are made and are expected to just do what they are told. This coercive type of system does not provide respect to employees.

At Nummi, after the full immersion in TPS, the employees were empowered to make decisions, although sometimes within boundaries. Standard work provided a baseline and starting point for consistency. Employees measured their results based on a known expectation and they were cross trained to move wherever the greatest need was. Leaders were placed at the gemba, where the value-add work was being done, so they could ask questions and help to remove roadblocks, problem solve, mentor and coach.

Continue reading

Next Move: Should You Study PRINCE2 or ITIL?

IT professionals are often looking for methods to expand their skill sets, with project and service management qualifications commonly the best approaches.

Of course, several options can make choosing the right program hard.

ITIL and PRINCE2

Information Technology Infrastructure Library (ITIL) and PRojects IN Controlled Environments (PRINCE2) are a couple of the most popular qualifications and recognized by organizations around the world.

This is for a good reason, too, as they're able to offer a framework that can be applied to nearly any project, whether it is implementing a new IT installation or even something like organizing a conference.

ITIL is the most recognized framework for IT service management and is a set of 'best practices' for managing IT services within an organization. ITIL can be used to improve effectiveness, quality, and cost management continually, and is now being used for more than merely IT-based projects.

PRINCE2, on the other hand, is intended to manage projects and improve performance where required. Its focus is centered more on process-based methodology and giving detailed direction on achieving successful projects.

How PRINCE2 and ITIL Can be Used Together?

Though they can be used individually, both qualifications are used well together. For example, if a business is trying to implement ITIL across the organization, it is essentially becoming a 'project.' PRINCE2 can then be used to manage the whole management process. By using the methodologies studied during the qualification process, efficient ITIL integration is assured.

Read: ITIL Vs PRINCE2 Certification - Choose Better One

Knowing how both can be used to work together can assist businesses and IT professionals, and secure projects are completed smoothly.

The Qualification Process

Once the benefits of both are known, and IT professionals have narrowed down the one that best suits their needs, it is time to assess the qualification process. It is essential to undertake comprehensive courses that offer the smoothest progression.

Below, the qualification method for both PRINCE2 and ITIL will be explained. Understanding how the process works before starting education can make each stage easier to get.

The Qualification Process for PRINCE2

PRINCE2 offers several courses for IT professionals, each taking place over several days and offering different educational opportunities. The starting point is the practitioner certificate, which can be used by professionals to master the PRINCE2 structure. It is useful for those studying to become a consultant or even a trainer.

PRINCE2 Foundation Certification:

This offers a fundamental understanding of the framework and is suitable for those who require an understanding of the project management methodology. This is a course ideal for team leaders or those contemplating moving into the project management field.

PRINCE2 Practitioner Certification:

This stage is intended for those who have made the foundation certificate but want to upgrade to a practitioner level the scene features how theory can be put into practice.

The Qualification Process for ITIL

• ITIL has several courses that can be utilized called 'Lifecycle modules.' These focus on a range of various areas and are quite comprehensive.

• Freestanding qualifications are also available, such as one that provides a business and management level opinion of the ITIL focus lifecycle. It also deals with how it might be made to enhance IT service provision within an organization.

• IT professionals need to consider the use of these qualifications and how they offer lasting career benefits. While they do give distinct variations in terms of both the qualification process and where they can be used, they are also able to be used together.

• In today’s highly aggressive marketplace, both ITIL and PRINCE2 can be a powerful combination for organizations that need to maintain their corporate dynamism.

• Whether an organization is setting up a foreign location or developing something new in-house, following the ITIL framework, along with a robust project management structure, will do spectacles for the business.

• According to AXELOS, PRINCE2 (PRojects IN Controlled Environments) is a soft method that guides organizations in the essentials for running a successful project regardless of project type or scale. PRINCE2 can be tailored to satisfy your organization or industry-specific requirement.

• ITIL (Information Technology Infrastructure Library) is a generally-accepted IT service management strategy in organizations across the globe. The ITIL framework is formed from best practices followed by both public and particular sectors all over the world.

• The best practices in ITIL are based on expert advice and inputs of ITIL users and consolidate the latest thinking with sound, practical guidance. ITIL has, hence, increased in importance as a methodology that delivers actual business outcomes for enterprises.

How ITIL and PRINCE2 Complement Each Other?

The ITIL framework discusses many of the limitations of IT by providing a service-oriented framework that fits the business requirements of the customer.

Read: Difference Between ITIL and PRINCE2 Certification

But, for the ITIL framework to be performed, which is a project in itself, a specific project management methodology in PRINCE2 must be applied as well to ensure a higher degree of success. PRINCE2 and ITIL organization complement each other in several ways:

Consistent Business Justification:

The best benefit that PRINCE2 takes to the table is the principle of continued business justification and constant center on the business case throughout the project. This assures the project does not change course from its primary objective at any point in time.

Management by Stages:

Breaking large chunks of work to sizeable pieces will aid in handling a project more efficiently. Every requirement will be analyzed and signed off from the right stakeholders. With PRINCE2 methodology, it provides an accurate view of what can be done and when it can be done.

Careful Risk Management:

Because ITIL demands to change not only the IT department but also the rest of the organization, ITIL implementations require an impeccable project management structure.

Anything less and the application is at severe risk. With its careful risk management processes defined in the risk theme, PRINCE2 serves to address all possible threats in the project.

Risk management is also a component of the ITIL framework. Hence they complement any other well. The emphasis on identifying and evaluating risks helps the stakeholders to make educated decisions as part of ITIL change management.

During the Commencement of a Project:

The ITIL best practices in Service Design and Service Strategy have a clear project order which forms a basis for building PRINCE2’s project management structure. Everything from field, success, and different criteria, are identified and approved by senior management. This saves a lot of time in lighting up a project.

Quality and Cost:

The ITIL framework helps PRINCE2 to concentrate on the bigger picture. It is imperative to balance both cost and quality in ITIL, which helps in making correct decisions for quality improvement, which adheres towards the larger view.

The stress on quality also fits in with the PRINCE2 framework, where the quality theme develops on aspects such as Project Product Description, Product Description, Quality Register, Quality Management Strategy, among others.

Plugging the PRINCE2 Gap:

The ITIL framework implementation helps in ‘benefits realization,’ which happens only after the project is finished. PRINCE2 has no part in this, as the project management structure mandates the completion of the project successfully. But, the ITIL framework helps to realize the advantages when the implementation is done, and it can fine-tune it when there is a change after the project is completed.

Managing several constraints such as time, price, and the scope of business are all superimposed on a framework of meeting quality requirements. This forms the foundation of project management and meeting customer-defined needs, availability, reliability, capability, and cost-effectiveness of business services offered along with increasing responsiveness in managing change from the heart of ITIL.

Summing-Up

PRINCE2, with its project management structure and the ITIL structure with its best practices together, deliver an aggressive advantage for an organization.

Continue reading

People Complexity Can Require a Special Roadmap

Despite the awareness that the standard Six Sigma DMAIC (Define, Measure, Analyze, Improve, Control) toolkit can be applied to process problems in so-called transactional environments as well as manufacturing – improvements to existing processes do not always involve just tweaking of “settings” in the process. This is because processes in transactional environments contain lots of what have come to be called people complexity, as opposed to manufacturing problems which often have a high technical complexity.

What is meant by people complexity? High people complexity problems are typified by change environments that involve multiple stakeholders with conflicting and/or competing needs. In manufacturing, extreme people complexity scenarios rarely come into play once the technical solution has been proven rationally. But, in transactional environments, this is not so simple.

Mixed Problems in Transactional Six Sigma

Transactional Six Sigma issues are often mixed problems with mid- to high-technical complexity, and almost always have high people complexity. Processes in transactional environments tend to have three important characteristics.

1. Transactional processes cut across multiple functions, and consequently:

◉ Sometimes competing and conflicting priorities of these functions come into play.

◉ Existing power politics that may exist between the leaders of these functions become entangled with the improvement effort.

◉ Ownership of the entire end-to-end value stream may not exist formally within the organization structure.

◉ Nobody has the final say on whether something goes or not.

2. Transactional processes are often “invisible” because there is no shop floor line, and consequently:

◉ Perceptions of what constitutes the process may be unclear.

◉ People only see their part of the process and sometimes may not even be aware of the other parts.

◉ The lack of a process view of work means readily available data is not present.

◉ Collecting data can become an exercise in influence (if handled correctly) and power politics (if handled badly).

3. Transactional processes have intangible products (in the form of services or completed transactions), and consequently:

◉ People and people-related factors influencing perceived product quality are typically significant, and improving these people factors are normally not just a function of tweaking of settings but cultural change.

◉ Most of the people working within value streams rarely see a completed product because the product is largely a function of the customer’s entire interaction with the organization (and only the customer sees the whole).

Because of the lack of a process view of work, improvement actions are almost always targeted at local optimization (improvement projects are functionally scoped). Global optimization across the entire value stream is unheard of in some transactional organizations and those that attempt it have typically found it very difficult to do.

This is largely because people complexity is much lower when the project is scoped within functions. However, the sum of local optimization does not lead to global optimization. Paradoxically, for global optimization to occur, it is sometimes necessary for some parts of the system to be sub-optimized.

Managing the People Side of Improvement

The Lean Six Sigma DMAIC toolkit is excellent for solving technical complexity problems. However, the current Six Sigma core training curriculum barely mentions the people side of improvement and is sorely lacking in tools designed to optimize people-centered problems.

The classic approach to managing the people side of change follows a patient/doctor model, also known as the “sickness model.” Often an expert consultant is brought into an organization that is experiencing people complexity issues to diagnose the root causes. Then medication in the form of a change intervention is proposed and, if approved, implemented under the expert guidance of the consultant. This model has largely failed. Indeed, an early champion of this approach, Marvin Weisbord (who wrote the definitive text on it, called Organizational Diagnosis) has since rejected it and is now the leading champion of what he calls third wave consulting.

Figure 1: Progress of Solving People Complexity Issues

Third wave change management is based on four practical guidelines:

1. Assess (and harness) the potential for action: This means moving away from diagnosis toward assessing and exploiting existing readiness for change. (Factors are committed leadership, good improvement opportunities and energized people with passion).

2. Get the whole system into the room: This means getting all of the stakeholders (including, in some cases, customers and suppliers) into the same meeting to work on joint tasks to optimize the larger system.

3. Focus on the future: This does not mean denial of current reality. Rather, it means that by focusing more of the group’s energy on what could be (vision) tends to yield more positive outcomes than being stuck in current reality.

4. Structure tasks that people can do for themselves: The underlying principle here is that in high people complexity environments, people are more likely to implement improvements that they have a hand in developing. Involvement breeds commitment and passion, which in turn breeds success.

Need for an Integrated Roadmap

What is needed in a high technical and people complexity change environment is an integrated DMAIC/change management roadmap (Figure 2). The model suggested here is designed based on the third wave principles. Significantly, DMAIC is just one of the 12 steps in the model and occurs late in the plan, once the organization is ready for globally optimized change.

Figure 2: 12 Steps of Integrated DMAIC/Change Management Model

The table below shows a snapshot of the kinds of tools that are employed in the three phases of change.

Continue reading

Six Sigma Tools Still Fit in Projects Lacking Data

In organizations struggling through the early phases of Six Sigma implementation, practitioners often find themselves doing projects with little or no data. Sometimes they can begin collecting the needed data, which causes delays in the project. In other situations, where past information is critical to understanding the evolution of the project, but the data is not recoverable, practitioners can poll experts in the process and use those opinions as data. In the worst of situations, there is just no way to gather any data at all for baseline calculations or analyses. This could occur when all experts are unavailable because of layoffs or job changes.

Many would say that the Lean Six Sigma process cannot be used in these cases. After all, Six Sigma is based on data. However, there are many good reasons for practitioners to use the methodology, tools and approaches of Lean Six Sigma, even if they have no data.

Why Use the Lean Six Sigma Process?

The Lean Six Sigma process provides an excellent framework for projects. Some specific benefits:

◉ It provides a structured roadmap to eliminate the two-step process most organizations use, which consists of problem and solution. Six Sigma forces practitioners to define, plan, analyze, develop solutions, pilot changes and sustain results. This drives project management thinking.

◉ Many of the tools characterized by Six Sigma are just as valuable in any project. For example, the failure mode and effects analysis (FMEA) is useful in several ways in most projects:

1. To characterize the current, as-is process

2. To predict issues in the proposed process prior to implementation

3. To characterize the final process that is put in place

◉ Measurement systems are normally created that can be used by management on the project involved as well as other organizational needs.

Looking at the DMAIC (Define, Measure, Analyze, Improve, Control) phases in detail shows how the use of the Six Sigma processes and tools can benefit practitioners, even in the absence of data.

Define Phase

Nearly all of the tools in Define can be utilized without data:

◉ The project charter is a great way to identify the business case, the problem, potential goals and team members’ roles and responsibilities.

◉ The critical-to-quality matrix and tree can focus on those areas important to the customer.

◉ The high-level process map (SIPOC) gives a good view of the process, the project’s scope and boundaries. It forces practitioners to think process rather than solutions.

◉ Other Define templates can be used to assess readiness for change and stakeholder support.

Obviously, in the absence of data, the problem and goals will be qualitative in nature, but practitioners should be able to begin their quest for improvement.

Measure Phase

The following Lean Six Sigma approaches can be utilized in Measure without data:

1. The detailed process map can help with understanding the process. It also can give ideas as to where particular measures can be captured and even suggest the nature of the metrics.

2. In the absence of any historical data, a value stream analysis can be performed from the detailed process map using recently collected data and expert opinions and observations. Any Six Sigma project focused on cycle time improvement can benefit from this effort, but even those projects focusing on other areas can add value via this analysis.

3. The operational definitions can still be defined here, although they may be qualitative. Practitioners can set the stage for data collection and measurement through any quantitative definitions needed.

4. At this point, practitioners can perform an initial FMEA to document the current, as-is process weaknesses.

5. The fishbone diagram and other methods can be used to identify and prioritize possible x’s. In most cases, practitioners can begin collecting the needed data now by implementing a data collection plan.

6. Once the data collection plan is implemented, it is possible to perform a measurement system analysis (MSA) on the newly collected data.

By this time, the no-data project may have converted to a more typical Six Sigma project, an practitioners can continue with normal deliverables, such as the baselines, process capability/sigma level calculations and financial analyses.

Analyze Phase

While Analyze is most heavily impacted by lack of data, practitioners can still take advantage of Six Sigma thinking if they do not yet have data. Two major outputs of this phase are 1) the vital few x’s and 2) root causes. The methods and procedures associated with these deliverables can be used without much data. The key difficulty, at this point, is the inability to graphically or statistically prove any hypotheses. The best that practitioners can do may be to give impressions and observations of process stakeholders, participants and experts.

Improve Phase

Here, practitioners can develop solutions, assess risk, use a selection matrix and select solutions for trial. This will not be very precise in the absence of data, and will likely make solutions more global rather than specific, but it may still add significant value. Any cost benefit analysis may be at a high level. Obviously, any data collected during pilot activities can be well utilized. But practitioners will often have difficulty meeting the power and sample size standards to close the Improve phase.

Control Phase

Given the data collected during the earlier phases, it will be possible to work the Control deliverables as usual due to especially from the pilot activities in Improve. If practitioners are not able to prove their results graphically and/or statistically at this time, they may have to determine project closure from the process participants, owners and experts. While making decisions in this way is not desirable, it may be the only alternative.

Continue reading

Standard Work: What It Is and Measures of Success

Many companies have jumped on the Lean/continuous improvement bandwagon since the 1990s. Most have failed to sustain the changes. Even many of those that have achieved some level of success have failed to achieve true standardized work.

For the sake of convenience, in this article standard work and standardized work will be interchangeable, although my mentor taught me that the two are different practices.

Standard Work Requires Cooperative Effort

I was sitting among approximately 50 peers at a large Lean-focused conference. The topic of discussion was standardized work. I sat and listened to human resources (HR) managers, industrial engineers, process engineers, production managers and team leaders discuss how they have had limited success implementing standard work. Each shared how important it was to capture how the job is done before the tribal knowledge associated with longevity disappears from their companies. Each shared how difficult it can be to get the more experienced operators to adjust to standard work.

As I listened over the next hour, I discovered that many in the room seemed to have a different view of the process than I was taught. Some mentioned training within industry (TWI – the foundation for Toyota’s standardized work process), but even then, the advice was to train others to follow their standard work. I had to break my silence.

My mentors were from Toyota, although I have never worked for Toyota. I shared what they taught me. The primary idea of standardized work is that it is an agreement between leaders and those who perform the task (usually operators, but they can also be customer service specialists, HR generalists, engineers, etc.) developed through a cooperative effort. It is not something certain people develop, then “distribute” to those doing the work. It is not something someone off the floor creates, then uses TWI to train those doing the work.

Several others agreed. It generated some discussion as we walked out of the room to the next session. It was then that I realized it amazes me how wrong we are doing standard work, even in the Lean community.

I chalk this up to too many people who were improperly trained who are now training others. So, let’s take a closer look at standardized work.

Definition of Standard Work

Standardized work is the safest, easiest and most waste-free way of doing a job that we currently know. It is developed and owned by operators, team leaders and supervisors working together. It provides a baseline for future improvements. It is highly flexible, able to change through Kaizen and to meet takt time as it may change. It is working smarter – not harder or faster.

Standardized work is not work instructions developed by industrial engineers, focused on standard efficiency and moderately inflexible due to ties to cost accounting. Nor is it a work standard – a guideline for quality and/or safety, developed by quality, safety or design engineers, and extremely inflexible due to industry quality or safety standards.

Three Elements of Standard Work

Standardized work consists of the following three elements.

1. Takt time. This is simply how often a part is needed to be produced based on customer requirement. It is calculated as: TA (time available, excluding breaks, usually expressed in seconds) divided by [K]T ([K]ustomer take – forgive the spelling – simply the customer demand expressed in units). The result is time needed per piece.

2. Work sequence. This is the main element, and so often the only element that organizations determine when developing standard work. It can be defined as the specific order in which an operator (or operators) performs the steps of the process for one part. The goal is to be able to separate the worker from the machine and provide flexibility to share steps or change workload to meet changing demand.

3. Standard work in process. SWIP, as it is often referred to, is the minimum amount of parts on the line that will allow the operator to flow product effectively. It has a calculation to determine appropriate quantity. The calculation is: (lead-time of a process) divided by (takt time). This calculation works both for internal and external processes. However, when determining external processes, I highly recommend adding a buffer, or “safety stock,” to the SWIP calculation.

Five Components of Standard Work

The main element of standard work is work sequence. That simple element has five key components.

1. Content. Standardized work is highly defined work. The first step is to define the content. What are the steps needed to complete a product or service? Initially, these steps may be vague or broad. The goal is continuous improvement of the standard, so it is okay to start vague or broad.

2. Sequence. This is the meat of the second element. Now that the steps have been determined, what is the current best sequence to perform those steps? This ensures all operators are performing the process in a similar manner – the cornerstone for both standardization and improvement of the standard.

3. Timing. Timing is a critical component of standardized work. It is required for operators to be able to run self-diagnostics and seek help on their own. It drives respect for people in this manner. It also provides the leader with a means to perform leader Kamishibai (visual controls) on the process.

4. Location. Location defines where the work is done. This is important when an organization’s standard work becomes more defined. It denotes which steps in the process are done where. Thus, when demand changes and the tasks (or content) are separated between two or more operators rather than a single operator, it is clear where each operator conducts that task.

5. Outcome. Outcome defines the expected quality of the product, in the safest manner, within the expected amount of total time to complete one piece.

Success Measures of Standard Work

Standardized work is successful when:

◉ It drives the organization to Kaizen. A mentor always told me if your standardized work hasn’t changed in three to six months, it isn’t standardized work – you should always be striving to improve. As the current best way, it allows an organization to capture small changes between operators, so all can learn and benefit. In this way, it helps capture that tribal knowledge that so many people seem to struggle to capture.

◉ It functions as a diagnostic device. Having standardized work allows operators to analyze their work, identifying which steps they are not able to perform at the current standard. This gives them the opportunity to ask for help rather than waiting to be disciplined for poor performance after the fact. It also allows leaders to review the process in real time, observing operators as they conduct tasks (part of leader standardized work). When they vary from the documented process, leaders can determine if their process is more effective (thus driving Kaizen) or less effective (driving coaching opportunities).

◉ It functions to drive out waste and eliminate problems. It gives everyone a chance to see the waste in the process. Many times, as we create standard work, I hear individuals say, “I never realized I walked that much” or “Wow, I use a combination wrench, not the air ratchet.” Without a standard, everyone performs the task differently, making problem-solving difficult. As Taiichi Ohno, the founder of the Toyota Production System said: Without standards, there can be no Kaizen.

When Lean is a focus on reducing people or adding work (without the elimination of waste) or is focused too heavily on manufacturing (meaning no enterprise focus), the transformation will fail. Will some improvements be made? Absolutely! Will they be sustained or, more importantly, continuously improved upon? Absolutely not!

Every action has an equal and opposite reaction. It is a simple theory. The difficulty lies in understanding the reaction, preparing for the reaction and working with the reaction. Failure to understand the relationship a Lean transformation has with the entire business will cause an unexpected, and unwanted, reaction.

Continue reading

Case Study: Defection Prevention for Software Development

Organizations face many problems that impede rapid development of software systems critical to their operations and growth. The challenge in any software product development lies in minimizing the number of defects. Occurrence of defects is the greatest contributor to significant increases in product costs due to correction and rework time. Most defects are caused by process failures rather than human failures. Identifying and correcting process defects will prevent many product defects from recurring.

This article will present various tools and techniques for use in creating a defect prevention (DP) strategy that, when introduced at all stages of a software life cycle, can reduce the time and resources necessary to develop high quality systems. Specifically, how implementing a model-based strategy to reduce requirement defects, development rework and manual test development efforts will lead to significant achievements in cost reduction and total productivity.

Defect Prevention

DP is a strategy applied to the software development life cycle that identifies root causes of defects and prevents them from recurring. It is the essence of total quality management (TQM). DP, identified by the Software Engineering Institute as a level 5 Key Process Area (KPA) in the Capability Maturity Model (CMM), involves analyzing defects encountered in the past and specifying checkpoints and actions to prevent the occurrence of similar defects in the future. In general, DP activities are a mechanism for propagating the knowledge of lessons learned between projects.

Mature IT organizations have an established software process to carry out their responsibilities. This process is enhanced when DP methodologies are implemented to improve quality and productivity and reduce development costs. Figure 1 clearly depicts that identifying defects late in the game is costly.

Figure 1: Software Defect Rate Of Discovery Versus Time

A model for an enhanced software process, including a DP strategy, is presented in Figure 2. Adopting a DP methodology will allow the organization to provide its clients with a product that is “of high quality and bug free.”

Figure 2: Defect Prevention Strategy for Software Development Process

On a macro level defects can be classified and filtered as depicted in Figure 3.

Figure 3: Filter or Whirlpool Diagram for Software Defects

Features of Defect Prevention

Management must be committed to following a written policy for defect prevention at both the organization and project level. The policy should contain long-term plans for funding, resources and the implementation of DP activities across the organization including within management, to improve software processes and products. Once in place, a review of results provides identification of effective activities and lessons learned to further improve the organization’s success in applying a DP strategy.

To assist in the successful implementation of a DP strategy, members of the software-engineering group and other software-related groups should receive training to perform their DP activities. Training should include software quality assurance, configuration management and document support, and focus on DP and statistical methods (e.g., cause/effect diagrams and pareto analysis).

Creation of an action plan plays a key role in the implementation process. At the beginning of a software task, the members of the team meet to prepare for the task and related DP activities. A kick-off meeting is held to familiarize members of the team with details of the implementation process. Included in the meeting is information related to the software process, standards, procedures, methods and tools applicable to the task, with an emphasis on recent changes; inputs required and available for the task; expected outputs; and methods for evaluation of outputs and of adherence to the software process. A list of common errors and recommended preventive actions are also introduced along with team assignments, a task schedule and project goals.

Periodic reviews are conducted by each of the teams assigned to coordinate DP activities. During the reviews, action items are identified and priorities set based on a causal analysis that determines the:

◉ Causes of defects

◉ Implications of not addressing the defects

◉ Cost to implement process improvements to prevent the defects

◉ Expected impact on software quality

A pareto analysis is helpful in setting priorities and provides direction for assignment of action items or reassignment to other teams, making changes to activities and documenting rationale for decisions.

Additional DP activities involve reviewing results of defect prevention experiments and taking actions to incorporate the results of successful experiments into the rest of the project or organization, as appropriate. Examples of defect prevention experiments include using a temporarily modified process or a new tool.

Data Documentation and Measurement

Defect prevention data are documented in a centralized repository and tracked across the DP teams, providing details of the defects and resulting action plan proposals. The status of action items is also documented along with time and cost estimates associated with correcting the defect, and the expected cost of not correcting it. Process improvement proposals as defined in the project and targeted for the organization’s standard software process are documented as well. In addition, methods are established to communicate progress to all impacted parties on a regular basis.

The DP teams oversee the work product in a “managed and controlled” environment with changes incorporated in a controlled manner. If a greater degree of regulation is desired, teams can invoke the full discipline of configuration management, as is described in the Software Configuration Management key process area. Measurements are made and used to determine the status of DP activities. Examples include the costs mentioned above; the number of action items proposed, open and completed; the number of defects injected in each stage, and the overall number of defects.

Verifying Implementation

The organization’s activities for defect prevention are reviewed with senior management on a periodic basis to provide awareness of and insight into, software process activities at an appropriate level of abstraction and in a timely manner. The time between reviews should meet the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available. Management reviews include major defect and action categories and the frequency of distribution across those categories; significant actions taken to address major defect categories; and a summary of proposed, open and completed action items.

In addition, management should review the effectiveness of DP activities, the savings attributable to the activities, and their actual and projected cost. Once the effectiveness of the activities are verified, it is important for the team to ensure that significant efforts and successes in preventing defects are recognized.

Case Study

A case study of a real time scenario is discussed below along with statistics derived from the analysis.

The Reference Line

As a first step, a “defect analysis of past projects” was performed to create a reference line for the PIE. As many as 1,336 defects were analyzed from the baseline project (TETRA Released) and two other projects to increase statistical significance. A detailed root cause analysis was performed on all defects and the Beizer Taxonomy1 was used as the “classification vehicle.” Analysis was done for five development phases: Requirement Specifications, Architectural Design, Detailed Design, Coding and System Test Case Preparation. Based on this analysis, specific DP solutions were determined for each of the phases.

The Beizer Taxonomy included ten major categories, each of which was divided into three levels, resulting in a four-digit number which specifies unique defects. The ten top level categories were:

0xxx Planning

1xxx Requirements and Features

2xxx Functionality as Implemented

3xxx Structural Bugs

4xxx Data

5xxx Implementation

6xxx Integration

7xxx Real-Time and Operating System

8xxx Test Definition or Execution Bugs

9xxx Other

The causes of the defects as determined by the engineers doing the classification, fell into four major categories: communication, education, oversight and transcription.

In creating the reference line, detailed interviews with 24 software engineers took place. The interviews allowed a full understanding of the reason for each defect, classification of the cause and an understanding of defect prevention activities. This data mining was performed on all defects, resulting in a series of classification tables and a pareto analysis of the most common problems. The results of the pareto analysis according to the Beizer Taxonomy top level categories are presented below with the breakdown in descending order.

◉ Requirements and Features (1xxx) 47.0%

◉ Functionality as Implemented (2xxx) 13.5%

◉ Structural Bugs (3xxx) 9.3%

◉ Implementation (5xxx) 8.3%

◉ Data (4xxx) 6.9%

◉ Integration (6xxx) 5.7%

◉ Real time and Operating system (7xxx) 4.9%

◉ Test definition or Execution bug (8xxx) 4.3%

Within each development phase in the baseline project, the defects were further classified based on the Beizer Taxonomy. For example, in the Requirement Specifications phase, the second level breakdown of the main defects occurred as follows:

◉ Requirement completeness (13xx) 37.5%

◉ Requirement presentation (15xx) 34.7%

◉ Requirement changes (16xx) 11.2%

◉ Requirement incorrect (11xx) 8.7%

The third level breakdown of the main requirement completeness defect was:

◉ Incomplete requirements (131x) 73.4%

◉ Missing, unspecified requirements (132x) 11.2%

◉ Overly generalized requirements (134x) 4.6%

The same type of data analysis was performed for each development phase selected for the PIE. The next step was to identify a toolset of phase-specific improvement activities, based on the root cause analysis, that would prevent defects from recurring in the next release. Highest priority was given to the most common defect types. Extensive training and phase kickoff meetings were held to empower the development team to integrate DP activities into the existing process. The development team then applied the improvement activities determined in the analysis phase to the development phases, and ongoing defect recordings and measurements were performed.

The final step was to compare the numbers and types of TETRA Release 2 defects with those of the reference line. The effectiveness of the prevention toolset was measured in the quantity and types of defects found in the second release of the project. The effective prevention actions could then be integrated into the OSSP to improve quality and cycle time for all the projects in MCIL. The impact on the OSSP, including changes to review guidelines and changes to the phase kickoffs, are considered part of the PIE results.

Expected Outcomes

Expected outcomes from the project consisted of a framework for establishing a DP program in a software development environment and alist of improvement actions the TETRA project development group would take to prevent defects, including:

◉ A method to number the requirements in the SRS document

◉ A writing strategy procedure to reduce ambiguities in the Requirement Specification phase

◉ A utility to support/implement the writing strategy

◉ An improved software requirement specifications (SRS) template

◉ A formalized context diagram/feature interface chart for the Requirement and Design phases

◉ Improved review checklists for all development lifecycle phases

◉ Causal analysis procedures and meeting guidelines

◉ Improved kickoff meeting templates and guidelines for all phases of the development process

◉ A testing strategy

An additional expected outcome was the improved quality of the TETRA product, including:

◉ A decrease in the overall number of defects found in the various development phases

◉ A shift in the distribution of defects, by phases

◉ Lower development costs

◉ Shorter cycle times

Implementation of Improved Actions

At the beginning of the project, kickoff meetings were held for each phase, where the importance of DP and causal analysis were explained and emphasized and improvement actions for the specific phase were presented and discussed. The actions, as suggested by the PIE team, were generally well received by the TETRA development engineers and managers. Techniques such as improved review checklists were applied immediately after the kickoff at formal peer reviews.

In each progressive phase, engineers became more adept at recording the defects using distributed defect tracking systems and at performing causal analysis. They became more open minded about reporting and recording their own defects, understanding the importance of a systematic tracking approach to the quality of the product and the process.

Many TETRA engineers expressed satisfaction with the causal analysis process and kickoff meetings, which made them feel better equipped to prevent defects and improved their general attitude towards the software process.

Both technical and business staffs considered the PIE a positive process, which provided an advantage in creating better quality products, and reducing cycle time of the development process. As such, the TETRA development group adopted several changes to its processes to accommodate the DP environment.

Internal dissemination outside of the TETRA development group, will begin with a presentation of the DP method to the Software Engineering Process Group (SEPG), the owner of MCIL’s OSSP. This group will analyze results of the PIE project and update the OSSP accordingly. The SEPG will also be responsible for deploying the new process and training the other development groups. This will occur through a series of technical meetings with engineers and managers, who interact with DP activities, the PIE and the updated OSSP.

Results

As a result of the project, the overall number of defects in TETRA Release 2 has decreased by 60 percent as compared to the number of defects detected in TETRA Release 1 (the reference line project). In part, this is attributed to the fact that Release 2 is a continuation project and not an initial project as was Release 1, and that later releases usually have fewer defects due to more cohesive teams, greater familiarity with the application domain, experience and fewer undefined issues. Based on numbers from other MCIL projects, we estimate that half of the defect decrease can be attributed to the implementation of the PIE. A breakdown of defects by phase of origin shows the following results.

Table 1: Breakdown of Defects by Phase

The absolute reduction in defects, which relates to the % Improvement shown in the above table, can be observed in the following figure.

Figure 4: Reduction of Defects by Phase

The obvious observation is that a higher percentage of the defects migrated to later phases of the development process: from Requirement Specifications, Preliminary Design and Detailed Design, to Coding. In TETRA Release 1, 76.5 percent of the defects are in the Requirement and Design phases and only 23.4 percent are in Coding, while in TETRA Release 2, 45.5 percent of the defects are in Requirement and Design and 54.5 percent are in Coding. This implies that the DP methods employed in the early phases of development were very effective.

The % Improvement column shows the improvement within each development phase with respect to the absolute number of defects. This is a different view of the improvement in the number of defects, partially attributable to the improvement actions.

Another comparison was made in respect to the Cause category with the following results.

Table 2: Breakdown of Defects by Cause

The observation here is that the differences are not significant. The largest bulk of the defects are caused by human errors.

Lessons Learned

There are several key lessons learned from this PIE project.

1. Although DP is considered an SEI/CMM Level-5 KPA, we found that a strong Level-3 organization, with a DP infrastructure, can build an effective DP process, and obtain excellent results.

2. The primary cause of defects as classified by the development team is oversight, or human error (almost 75 percent). Our experience shows that the term “oversight” is too broad and should be broken down somewhat, probably based on the Beizer classifications of those defects, which were categorized as “oversight.”

3. The timing of the phase kickoff meetings is critical. A phase kickoff should be planned early and performed as close as possible to the beginning of the phase.

4. In order for the DP process to be effective, the software teams need in-depth training and initial support in using the taxonomy and performing the root cause analysis.

5. A tool to input the classification of defects according to the Beizer Taxonomy is essential. An automatic tool is needed to analyze the defects and to obtain statistical results. The current vehicle used for input of cause analysis and defect classification is deficient. A better interface is needed, as well as a mechanism for adding new categories to the Beizer Taxonomy. Standardized statistical analysis reports are needed for use by all projects for ongoing DP and process improvement.

Acknowledgements

Sincere thanks to my entire team for their continuous support in transferring their knowledge and time in making this happen.

Continue reading