Chapter 6

Lean Project Management Using the PDCA Cycle

The PDCA (plan, do, check, act) cycle has been around for several decades and remains a popular tool to improve quality. It also serves as an excellent road map for performing Lean in an enterprise both as an overall framework and also as a specific tool to improve a process, procedure, or operation. This chapter presents the PDCA cycle from the perspective of the former. In some places, PDSA rather than PDCA is used, meaning plan, do, study, act.

6.1 PDCA Cycle and Project Management Basics

Perhaps the biggest strength of the PDCA cycle is its simplicity. Plan is determining the problem or issue to resolve and then building a road map to resolve it. Do is executing the plan. Check is measuring performance to determine if progress is meeting expectations. Act is analyzing the findings and making improvements. This cycle continues until a state of perfection is reached or when key stakeholders are satisfied with the results, thereby enabling pursuit of continuous improvement (shown in Figure 6.1).

Leading and all the project management processes apply to a Lean project using the PDCA cycle. They are applicable for the entire project and within each phase. At the overall project level the processes have a broad perspective. For example, a charter and high-level plans contain content at a summary or strategic perspective. At the phase level, the processes may amplify in greater detail the applicable content at the overall project level or, if necessary, be modified for the particular context in which a phase finds itself.

6.2 Goals

Adopting the PDCA cycle has three fundamental goals. One is to provide a high-level framework for managing a Lean project. The four phases of plan, do, check, and act provide a simple structure that flows naturally and easily and offers sufficient flexibility for adapting to the environment. Two is to improve the quality of decisions regarding project performance. The simple transition from one phase to the next with reviews interspersed throughout and especially at the end of each phase increases the odds for success. Finally, it is to reduce the variability in outcomes in pursuit of satisfying the customer. The entire PDCA cycle, starting with the first phase, plan, focuses on satisfying the customer by solving a problem or issue related to Lean, for example, waste. All subsequent phases are predicated on what is identified during the Plan phase.

6.3 Benefits

Many benefits are attributed to using the PDCA cycle as a framework to manage a Lean project.

Easier and faster than DMAIC. The PDCA cycle, in comparison with the DMAIC life cycle, is much easier for people to handle. As noted earlier, DMAIC stands for define, measure, analyze, improve, and control. One reason for being easier and faster is that the DMAIC really is a combination of Six Sigma and Lean which requires considerable data collection and mathematical calculations not necessarily required under the PDCA cycle. However, keep in mind that the PDCA cycle does not preclude the use of considerable data collection and mathematical calculations; it’s just that extensive data collection and mathematical calculations are not often associated with it to the extent of DMAIC. The PDCA cycle works best in an environment where speed is necessary to solve a problem or issue.

Familiarity. The PDCA cycle has been around for quite some time. Employees with some background in quality improvement are likely familiar with it to a certain degree. It was used extensively in the 1980s during the Total Quality Management, or TQM, Movement and when W. Edwards Deming was becoming a household name. The DMAIC cycle reflects a combination of Lean and Six Sigma in which the latter has received considerable press but its understanding is not as widespread.

Iterative. One of the redeeming values of the PDCA cycle is its iterative nature. It can be used to address a problem or issue and then require stepwise refinement as a project repeatedly progresses through the cycle. This iteration continues until key stakeholders reach a level of satisfaction that the problem or issue has been addressed. Kaizen is the fundamental principle behind the PDCA cycle that emphasizes the pursuit of perfection through continuous improvement. The number of iterations, of course, depends on the scale and complexity of the Lean project.

Less mathematical. For some people, perhaps for a good number of them, mathematics can be intimidating. Lean projects applying the PDCA cycle de-emphasize, not preclude, using mathematics, such as probability statistics, to come up with solutions to problems or issues. In fact, Lean projects using the PDCA cycle can involve little or no mathematics and still have meaningful results. Naturally, mathematics can make persuasion for changes easier and can demonstrate the value of one recommendation over another. However, not all recommendations require math. Keep in mind that if mathematics is necessary, it is important that the data are cleansed so as to avoid working with incorrect or useless data that are converted into information and ultimately used to make a decision. Hence, bad data equal bad information and potentially bad decisions. Also, make sure that everyone involved on the project team has a rudimentary understanding of statistics, such as mean, medium, mode, and standard deviation.

Shorter learning curve. Because the PDCA cycle requires less mathematics than the DMAIC life cycle people can pick up the concepts fairly easily. People can, with little training, understand the basics and then move forward in identifying, recommending, and making changes. This short learning curve, due to its conceptual simplicity, makes it ideal to apply Lean quickly, efficiently, and effectively. The training for the PDCA cycle is fairly straightforward and the knowledge transferable within a short period of time.

Applicable to all environments. One of the clear benefits of the PDCA cycle is its applicability to different industries. A Lean project in any environment can quickly apply the PDCA cycle. An insurance company can just as easily apply it in an office environment as well as a manufacturer of heavy machinery in its production facility. DMAIC is mainly applicable to the manufacturing environment albeit it can be used in other environments, too; DMAIC often requires a much greater understanding and rigor than the PDCA cycle which outside the manufacturing environment may be unnecessary.

Less time and effort to apply. This benefit ties closely with the PDCA cycle requiring a shorter learning curve and being less mathematical. The very simplicity of the PDCA cycle is easier to understand and apply than DMAIC and, as such, requires less time and effort to complete a Lean project, although it depends greatly on the complexity and length of the Lean project. The concepts behind the PDCA cycle are very comprehensible and easily applicable and, hence, its popularity over the DMAIC life cycle.

6.4 Challenges

Despite its benefits, the PDCA cycle has its challenges.

Repeating the cycle. Projects by their very nature require a short life. Once the solution is implemented, a project is over. Using the PDCA cycle, however, requires using the cycle at least several times to ensure that a solution to a problem or issue is thorough, meaning it addresses the root cause and does so according to specific criteria. The tendency of some projects is to end and declare victory without much follow-up. Applying the PDCA cycle often requires a willingness to ensure that goals and objectives are met and done so effectively. The planning for such a project may require planning several iterations to ensure success.

Introducing bias. Because the PDCA cycle does not necessarily require mathematics to determine the cause and solution of a problem or issue, it can allow the opportunity for bias to affect people’s judgment. This bias may come from individuals, peers, or superiors. The key, of course, is having the ability to determine whether bias is influencing judgment, to call it out, and to offset its influence. There are a number of tools and techniques to offset this bias. The first step, however, is at least to recognize that the potential for bias might be, or is, present.

Failing to question assumptions. Assumptions are closely intertwined with bias. Assumptions are accepted as facts until proven otherwise. The failure to question assumptions can lead to reliance on erroneous facts which, in turn, leads to ineffective decision making. Assumptions may not necessarily introduce bias if a person is willing to question them to ascertain relevancy or correctness and to then make changes accordingly. As with introducing bias, there are some ways to challenge them. The first step is a willingness to revisit assumptions.

Not relying on facts and data. As noted before, Alan Mullaly, formerly of Boeing and Ford, once said in several meetings with this author attending, that the facts and data will set you free. Once facts and data are collected and converted into information, the reality is that they set a person free from bias, erroneous assumptions, and just plain prejudices when conducting Lean projects. When using the PDCA cycle, collecting facts and data and converting both into information is the best route to freedom. Unfortunately, many times adopting the PDCA cycle is an excuse to avoid collecting facts and data and simply doing a preliminary or cursory review to determine a solution to a problem or issue. Just because a project adopts the PDCA cycle does not mean facts and data are unnecessary; it simply means a Lean project may not have to emphasize their collection and use. Sometimes the review of a current value stream can result in developing one that just at face value is more logical, efficient, and effective in reducing waste and satisfying the customer.

Taking shortcuts. Because the PDCA life cycle does not involve the rigor of DMAIC, the danger is that people on a Lean project will take shortcuts; that is, they will not perform one of the phases as thoroughly as the others or may even skip one. For example, the define phase may not be sufficiently articulated to define the real problem or issue but rather simply treat the symptoms. Or, the do or act phases are shortchanged because certain key stakeholders for a Lean project feel that it is unnecessary and too time consuming to plan anything; the pressure may be too intense and hence the do and check are not well thought out. Succumbing to such pressure can result in implementing a solution to a problem or issue that, quite frankly, ends up being ineffective or serves as a short-term fix. A good project plan is an effective way to deal with this challenge.

Not involving key stakeholders. Following the PDCA cycle may prove so easy or occur so quickly that key stakeholders may be overlooked or simply ignored until the Lean project comes up with one or more recommendations. It is not uncommon for Lean projects to whiz through a PDCA cycle without engaging key stakeholders partially or throughout the life cycle. The key to overcoming this challenge is to engage stakeholders during each of the phases, especially at the end of each one, such as in the form of a check point review or frequent status review meetings.

6.5 Case Study

From a high-level perspective, the following case study is about applying PM processes throughout a PDCA life cycle and within each one of the phases.

The International Event Planning Company (IEPC) is a global holding that plans conferences, workshops, and other events. It consists of multiple divisions, one of which is the International Training Company Services (ITCS) with its headquarters located in Seattle, Washington. The company has a workforce of over 3,000 people and generates total revenues of about $3 billion per year. Its primary mission is to provide a wide array of training services to public and private companies around the world. These training services include, but are not limited to, defining, designing, developing, and deploying business management and technical training at all levels for private and public institutions. It also delivers certification training on management and information technology topics.

ITCS has a president who sits on the board of directors for IEPC. ITCS consists of four divisions, each led by a senior executive vice president and supporting business units. The four divisions are the:

• Instructional Definition and Design Division, with the overall mission to perform customer training needs assessments and to prepare training proposals
• Instructional Development Division, with the overall mission to prepare training materials
• Instructional Sales and Marketing Division, with the overall mission to solicit and maintain business opportunities as well as to provide customer support services
• Instructional Delivery Division, with the overall mission to provide training to affiliate customers

The two supporting business units that serve the entire company:

• Shared Services Group, with the overall mission to profit support services to each of the divisions, such as Information Technology and finance and accounting expertise
• Enterprise Services Group, with the overall mission to support senior executive leadership of ITCS

Together, all four divisions provide an entire package of services to affiliates across the globe. Each affiliate must use the services provided by the divisions. This requirement has caused a severe strain between the ITCS training company and most of its affiliates because of the increasing breakdown of communication and coordination among everyone in definition, design, development, and deployment of resources. Many affiliates find themselves sandwiched between the ITCS home office and their customers when services go awry.

Although ITCS has its corporate staff in Seattle, it has affiliate offices located across the globe. These affiliate offices are profit centers, responsible for their own profit and loss within the company, but they remain legally part of ITCS. Each affiliate has a liaison unit from the home office in Seattle that develops and delivers training to customers for each affiliate but reports, from a matrix perspective, to a sales and marketing manager located in:

• Beijing, China
• Cairo, Egypt
• George Town, Cayman Islands
• Johannesburg, South Africa
• London, England
• Los Angeles, United States
• Miami, United States
• New Delhi, India
• New York, United States
• Rome, Italy
• Santiago, Chile
• Seattle, United States
• Tokyo, Japan
• Washington, DC, United States

Over the past decade, ITCS has acquired a number of training and development companies located across the globe. Although these acquisitions have increased the expertise of the staff and enabled gaining access to markets where it originally had no presence, the result has been a complex organization structure and processes that led to a deteriorating quality of services delivered to the customers who, in this case, are the local presidents of each of the affiliates. As a result, several affiliates have experienced a sharp decline in cash flow and profitability along with ITCS. For example, the processes to define, design, develop, and deploy training, whether online or in the classroom, have deteriorated according to feedback from many of the affiliate offices. Recently, the affiliate in Santiago, Chile, legally severed its relationship with ITCS, becoming a “broker” in procuring training and development from different companies. The result was an immediate sharp decline in ITCS market share in South America.

The reasons behind this decline in performance are well known. As mentioned earlier, ITCS has become a maze of processes due to acquisitions, the processes to define, design, develop, and deploy education and training. Training and development that frequently occur fail to meet expectations set by the sales and marketing division. Instruction often partially meets the requirements of the attendees at in-house and public seminars and workshops. The material, such as handbooks, delivered to the instructors is often incomplete or has mismatching content, resulting in different versions being delivered to attendees at the same training session. In fact, some materials don’t arrive at the training site in time for the seminar or workshop. Some instructors are not well versed about the topic that they teach and instructors are changed at the last minute despite customers having received assurance that the person mentioned will teach. Some seminars and workshops have been cancelled without prior notice to the attendees. These, and many other, problems have risen in number, too frequently, causing a strained relationship with affiliates and public and private customers alike. Consequently, profitability and market share are declining at a rapid rate.

The president, Wanda McFarland, appointed a steering committee to determine whether a true need exists for a project to identify and address the issues and concerns that many affiliates have expressed. The committee was to determine, first of all, whether a project was warranted based upon the results of a business case. The committee consisted of the vice presidents of each of the divisions plus shared services group and enterprise services. Here are the members:

• Nancy Wixman, vice president, definition and design
• Donna Fritolo, vice president, development division
• Jesus Marchiano, vice president, sales and marketing division
• David Kleinstein, vice president, delivery division
• Mary Rotoro, vice president, shared services group
• Sandy Alexander, vice president, enterprise services

The steering committee then performed the work necessary to determine whether to proceed with the project. Based upon its calculations and data and information provided by the shared services group, the steering committee agreed that a Lean project was necessary. The president then decided to be the executive sponsor for the project and directed the steering committee, chaired by Mary Rotoro, to prepare a charter, which was eventually approved.

The steering committee reviewed a select group of potential project managers and chose Harold Fitzwater from enterprise services to lead and manage the project. The steering committee then required each of its members to provide a core team member to support the project on a full-time basis. The members were:

• David Packart (definition and design)
• Inata Ditma (development division)
• Steve Posner (sales and marketing division)
• Cindy Sanderforder (delivery division)
• Mary McMartini (shared services group)
• Howard McCasel (enterprise services)

Fitzwater then held an offsite meeting with the project team. The team reviewed the business case and charter and then drafted these deliverables:

• Communication management plan
• Data repository structure and content
• Kaizen workshop preparation
• Organization chart
• Procedures and workflows on managing the project
• Roles, accountabilities, and authorities (RAAs)
• Selection of software tools
• Statement of work (SOW)

Fitzwater and the team also thought it was important to identify the stakeholders and their degree of influence on the project. The idea of customer seemed too vague and required greater refinement. Knowing exactly who the customer was would make it easier to define the criteria for success as well as identify meaningful requirements. Otherwise, the project team might do considerable work that, ultimately, would be of no value to whoever the customer might be. This stakeholder analysis was critical, too, because some customers might be more influential or important than others.

The stakeholder analysis was also important for identifying individuals and organizations who would need to participate more fully on the project team. Without their input, feedback, pushback, or resistance might arise from any work or recommendation affecting them.

The team agreed to criteria for identifying stakeholders. The criteria contained several elements: power, influence, degree of involvement, approval responsibilities, and position. This information was then captured in a log. The team used the log to identify future team members as well as participants in the upcoming kaizen workshop. The team also developed a set of rules for interacting with one another at meetings. These rules centered on two topics: meetings and consensus building.

With regard to meetings, the team established the following rules:

• Afford everyone the opportunity to speak.
• Clean the meeting room after every session.
• Come prepared.
• Distribute handouts prior to the meeting within a sufficient timeframe.
• Keep within the timeframe allotted to use the room.
• Provide and adhere to an agenda.
• Set up audiovisual equipment before the meeting begins.
• Silence electronic devices, preferably by turning them off if not needed for a meeting.
• Use active listening.

With regard to consensus building, the team adopted the following rules:

• Keep in mind the concept of UAS, meaning understanding, acceptance, and support.
• Focus on facts and data, not personality or physical attributes.
• If discord arises, apply timeout techniques, such as using a “parking lot” to record issues, problems, concerns, and the like to revisit later.
• If necessary, bring a topic to a vote for resolution by using approaches such as Nominal Group Technique (NGT) or the Delphi Technique.
• Keep the “big picture” in the forefront of meeting attendees.

Fitzwater, along with the core team, conducted a self-assessment of the level of understanding and knowledge about Lean. They decided that they were woefully lacking about the subject. Consequently, he budgeted time and money for everyone on the core team and other selected stakeholders to obtain training in Lean and related subjects, for example, PM. He decided, with the concurrence of the project sponsor, to have people attend on Lean. He then selected a person on the team to serve as a Lean focal point whereby that person shared knowledge about Lean with stakeholders not on the core team. This person was also responsible for keeping people abreast of interesting topics related to Lean, such as sending out articles or Web links on Lean concepts and techniques.

If only one person could attend a Lean seminar or workshop, that individual would perform what is known as cascade training. He or she would train others on the topic covered in the seminar or workshop. If anyone attended a Lean conference, he asked that the person prepare a trip report that everyone could read, whether in hard- or softcopy format, or attend a presentation.

Fitzwater set up a project office. The office consisted of three part-time employees from enterprise services: a planner, responsible for scheduling; an office administrator, for tasks such as taking minutes and preparing correspondence; and a data administrator, for collecting and verifying data and information before being incorporated in reports. Their services are also available to each of the subteams.

He then presented the deliverables to the steering committee for review. After a few suggestions for improvement, the steering committee approved the deliverables. Fitzwater then scheduled a kaizen workshop with the help of all the core team members.

The project team then determined requirements for the workshop. It decided that the workshop would be offsite and defined its goals, agenda, and roles and responsibilities. The team also decided that it would bring on board a scribe and a Lean expert to run the workshop.

Below are the topics listed in the agenda:

• Introductory remarks
• Charter review
• Current state and issues
• Future state and kaizens (improvements)
• Ideal state
• High-level RAM
• High-level milestone chart
• Lessons leaned
• Help needed
• Next steps
• Closing remarks

Taking the results of the kaizen workshop, which identified 25 kaizens, the team grouped them into these categories:

• Training needs analysis and design
• Development
• Sales and marketing
• Delivery
• Support

Within each category, each kaizen was assigned a priority: low (1 point), medium (2), high (3), and critical (4) as well as difficulty: low (1 point), medium (2), high (3), and critical (4). The two values of priority and difficulty were multiplied for each kaizen to determine the level of importance. Each kaizen was assigned eventually by the applicable subteam described in the next few paragraphs.

Fitzwater, based upon feedback from the executive sponsor, decided to establish subteams within the project, each with a team lead and representatives from each of the other subteams.

The PDCA cycle would follow what it called an evolutionary or agile release of the final work. Essentially, this approach meant that the first phase, plan, of the PDCA would proceed through stepwise refinement until all teams felt comfortable with the results. A gate review was headed and then the project could proceed into the second phase, do, and continue until desired results were achieved. The third phase, check, would do likewise, and then through the final phase, act.

Each subteam had the responsibility to develop a complete plan to address the problems and issues subsumed under their respective category; all content of the subteams’ plans had to comply with the requirements identified at the project level. Using the output of the kaizen workshop, each subteam was responsible for creating a charter, SOW, WBS, schedule, risk assessment, and responsibility assignment matrices as well as provide weekly status during the overall project review meetings. The status report had to follow a standard format to ensure consistency of reporting which covered cost, schedule, risks, and quality metrics as well as an overall assessment for each project. Whenever any subteam fell behind expectations, they were expected to provide solutions to improve performance to recover or keep pace with expected performance. The weekly status report contained this information:

• Critical issues
• Help needed
• List of names, to include subteam leader and team members
• Performance metrics and assessments related to
  • Purpose of project with a short one- or two-sentence description
  • Quality
  • Risk
  • Schedule
  • Cost
• Weekly look-ahead

With the input from all key stakeholders, Fitzwater updated the plans for the overall project. This included updating the schedule, risk assessment, responsibility assignment matrices, charter, SOW, and project procedures. Naturally, any significant changes had to go before the steering committee for eventual approval.

With the aid of key stakeholders involved in the project, Fitzwater developed a high-level milestone chart which showed the major events that have to occur on the project. Phase gates were established at the end of each phase of the PDCA cycle and were reflected in the schedule; these phase gates served as check points to determine if the overall project should progress on to the next phase. At a phase gate meeting, each team presented its results as well as identified touch points with the other categories. Ultimately, each subteam presented its reviews and findings in a presentation at the phase gate review and sought approval to proceed to the next phase.

Additionally, Fitzwater and the core team members agreed upon an online repository to store data, information, and documentation for access and review by relevant stakeholders. This allowed members of one subteam, for example, to see and use the output of other subteams. This capability was especially important for capitalizing on the work of the other teams to preclude wasting time and effort.

Fitzwater consolidated the reports into one summary report, which he submitted to the executive sponsor and all the other members of the steering committee. The format, content, and distribution of the individual subteams and the overall project were all described in the communications management plan.

Before proceeding to the next relevant PDCA phase, the overall project plan and a summary of the subteams’ plans were presented before the steering committee for review and approval. The steering committee granted its approval with some suggested minor changes that were made. All material was stored in the repository.

With the defining and planning PM processes completed, the entire project was ready to begin the executing PM process both at the project and subteam levels. Fitzwater and the executive sponsor decided that a kickoff meeting was necessary just prior to the execution of the project. This kickoff meeting had all the core team members present. There were several reasons to hold the kickoff meeting. One, it provided an opportunity for all key stakeholders to assemble at an offsite location to communicate and share knowledge and information with each other. Two, it provided Fitzwater with a venue to identify and address any major concerns up front so they could be dealt with as early as possible. Three, it afforded the opportunity to identify and prepare to act upon any potential showstoppers. Four, it provided a way to build esprit de corps early on among key stakeholders. Finally, it provided stakeholders with the opportunity to develop and understand the overall vision for the project. Here is the agenda for the kickoff meeting:

• Introductions
• Project review:
  • Charter
  • Statement of work
  • Cost
  • Schedule
  • Quality
  • Risk assessment
  • Roles and responsibilities
  • Critical issues
  • Project procedures
• Subteam reviews:
  • Statement of work
  • Cost
  • Schedule
  • Quality
  • Risk assessment
  • Roles and responsibilities
  • Critical issues
  • Project procedures
  • Help needed
  • Round robin
• Next steps

After the kickoff meeting, the project began the executing PM process. Each subteam had its own kickoff meeting and a series of working sessions to further define its purpose and approach for all the phases of the PDCA life cycle. Then, the subteam executed its responsibilities for the first phase of the PDCA cycle, plan. The subteam placed special emphasis on understanding each kaizen, defining exactly the problem or issue, and comprehending the criteria for success. Much of this information was acquired during the kaizen workshop; however, now was the time to identify exactly what to address. Each team reviewed the current and future state diagrams.

During executing, each team conducted its internal weekly review prior to the overall weekly one. The subteam leader would collect status and, with the help of a staff member, enter the values collected into a software PM application. The subteam leader then took the information generated and conducted an internal team review every Tuesday before preparing the final report to the project manager and eventually to the steering committee. The report, along with the others, was reviewed at the project performance review every Thursday morning. Fitzwater would then take the information from the project review meeting, compile it, and give a summary presentation to the steering committee. All of this reporting, of course, was documented in the communications management plan.

To ensure reliable status derived from monitoring and controlling, Fitzwater was persistent and consistent when collecting status for the project. All team members were to collect status using the same approach and he insisted that all percent completes were derived based upon the remaining duration. All team members were also expected to collect data approximately at the same time and in the same format. No exception. He also made sure that all team members followed the same format in their report to him. This consistency and persistency resulted in reliable status reporting on cost, schedule, and quality performance. If status showed a significant slide in the performance metrics, he expected the project manager to have some proposals to improve performance so that actual progression would once again match planned progression by the next performance review.

As the planning phase came to a close, each of the subteams verified the completion of all activities as well as all deliverables meeting the criteria established by the customer.

Additionally, each subteam held a lessons learned session at the end of the phase. The session discussed what went well, what areas needed attention, and recommendations for improvement. As with all other project information, the lessons learned were stored in the project repository.

Fitzwater also, prior to the gate review, conducted a lessons learned session for the entire project. The focus was on the project at large and also included a review of the lessons learned from the subteams to ascertain which insights were common to them all. Like the lessons learned for each subteam, these lessons learned were placed in the repository. The lessons learned session consisted of representatives from each of the subteams, the project sponsor, and selected key stakeholders.

With the plan phase of the PDCA cycle tentatively complete, the gate review was held. The purpose of the meeting was to determine whether to proceed to the next phase of the PDCA life cycle, do. All performance metrics were reviewed for accuracy as well as to address any quality issues that may have been overlooked. The steering committee determined that all expectations had been made and the project was granted permission to proceed to the next phase.

During the plan phase of the PDCA cycle, each subteam conducted a risk assessment regarding the applicable kaizens that they were assigned. Each risk was captured in a five-by-five chart that reflected both its likelihood of occurrence and impact on the project. The likelihood and impact were multiplied to derive a risk rating and that score was the value plotted in the chart. For each risk, a risk owner was assigned to monitor whether the risk was about to be, or had been, realized. Each risk deemed having a medium or high score had to have a risk strategy to address it and a corresponding action to implement the strategy. Risks that were assessed as having an impact beyond the purview of a subteam were elevated to the overall project risk assessment.

Also, once in a while a subteam during this phase was faced with whether to change the scope or to request a revision to the schedule that would affect the overall project timeline. The subteam had to submit a change request to the change board at the project level. The change board consisted of key stakeholders from each of the subteams and various members of the steering committee as well as selected individuals from the affiliates and from among a pool of subject matter experts. A committee of the change board did an impact analysis for each change request. The change board then decided whether to approve or disapprove the request for change.

At the conclusion of the plan phase, the project team and all subteams conducted the closing PM process. Each subteam conducted a lessons learned session. It also verified requirements and validated deliverables with the customer. The schedule was closed and a final status report completed for the phase and submitted to Fitzwater.

All the PM processes were employed by the subteams the same way during each phase of the PDCA life cycle according to project procedures. Only the content was different for all the PM deliverables produced by each subteam. Of course, each phase had its own set of deliverables to remove waste.

After Fitzwater gave his final report, the steering committee project declared the project a success for version 1. The project had completed all top priority kaizens and met customer expectations. Waste and cycle time had been reduced and untimely and unprepared delivery of seminars and workshops was becoming history. The project sponsor along with supporting signatures from the steering committee members provided all team members with letters of recognition and cash awards. An offsite party was held. One week later, the project team began work on the next release: addressing the kaizens of medium importance.

6.6 Final Insights

Lean projects employing the PDCA life cycle still require employing the PM processes on a project. These processes apply to the overall project; they can also apply, as we’ve seen in this case, during each phase of the PDCA life cycle. The degree of rigor depends on the size and complexity of a project. The decision as to what extent to apply these processes is also not a unilateral decision by the project manager; it is a collaborative decision, involving all key stakeholders. The key to success for Lean projects using the PDCA life cycle is to understand the context and then determine, in concert with other stakeholders, the degree to apply processes.

6.7 Getting Started Checklist