Chapter 5
Lean and Project Management Processes
Projects have a greater likelihood of success if project management (PM) tools, disciplines, concepts, and principles are applied; they have a lesser chance of success without PM. To leverage the gains from applying PM requires taking a structured rather than haphazard approach. The way to do that is to apply PM processes.
5.1 Key Concepts
Before discussing the PM processes, however, it is important to set the stage with some concepts that should be considered before any process is implemented.
Define the Lean problem, or issue, as clearly as possible. This definition sets the stage for all subsequent phases and the activities within them. If the definition is vague then the danger of not coming up with one or more solutions that satisfy the customer arises or scope creep becomes such a problem that it results in gold plating, that is, giving the customer more than what is necessary, which, in turn, affects the budget and schedule and may even degrade the quality of the results. Additionally, not defining the issue or problem may result in a project plan that proves unrealistic later in the cycle. Finally, a good definition of the problem or issue will make managing and leading the project much easier.
Avoid being overly ambitious. If a Lean project employs a life cycle for the first time, pick a problem or issue that will not over- or underwhelm people. The problem or issue should be on a scale that presents sufficient challenge and that has a likelihood of success. The best approach is to develop a model or prototype for the potential solution and build upon its progress throughout the life cycle to assess the results. If the model or prototype demonstrates value, then consider expanding the project to develop a full solution to the problem or issue in question. The key is to demonstrate success and to minimize the opportunity for failure. All the key stakeholders gain, by not only learning about Lean and its tools and techniques, but also by having a good opportunity to ascertain if the scale of the issue or problem is appropriate for the project.
Solicit and maintain customer involvement. In the end, a Lean project is about the customer, regardless of whether using the PDCA or DMAIC life cycle. Involving and maintaining customer involvement increases the likelihood of success. After all, the purpose of a Lean project is customer satisfaction by eliminating waste. In many other projects, the customer ceases to become the reason for existence and the project goes off in a different direction. The surest way to keep that focus is to consistently and persistently engage and inform the customer during each phase of a Lean project.
Take a multifunctional approach. Very few Lean projects involve just one discipline, such as engineering or information technology. More often than not, they involve multiple disciplines working together throughout a Lean project. Although each one provides a unique perspective, they seek consensus on both the problem, or issue, and the approach to address it. Stakeholders from each of the various disciplines provide useful insights as well as learn to see problems, or issues, and potential solutions from different perspectives. Any differences are resolved through agreement or consensus by the project manager encouraging each stakeholder to remember what is in the best interests of the customer.
Identify all relevant quality tools and techniques regardless of life cycle. The life cycle of a Lean project is conceptually at a high enough level to allow using a wide range of quality tools and techniques to improve the value stream. Force field analyses, fishbone diagrams, scatter plots, statistical process control, Pareto charts, trend charts, and much more can be applied throughout the life cycle of a Lean project. Even the simplicity of the PDCA cycle does not mean using a limited set of tools and techniques. It does mean, however, being creative and judicious in their application.
Consistently apply the phases of the Lean life cycle. Be sure to follow all phases in the life cycle of a Lean project. Be sure to follow the sequence again and again, if necessary, but do not skip any of the phases. Consistently applying the phases produces steady results because each iteration, if there is more than one, builds upon its predecessor. Skipping over one phase will invariably affect the quality of the output from subsequent phases. If the life cycle repeats itself, it may also weaken the final results of the project.
Involve key stakeholders throughout a Lean project. Getting and keeping stakeholders engaged is absolutely critical throughout a Lean project. Through engagement comes emotional involvement and commitment. When engagement occurs and is sustained, good teaming arises and people are willing to share their knowledge and insights. It also helps in satisfying expectations. The challenge, of course, is sustaining involvement, especially if the life cycle of a project occurs over a lengthy time period.
Determine the degree of PM to apply. Too much PM can hinder the performance of a Lean project. Too little PM will not provide the necessary direction and road map to lead a team to success. The key is to provide the right amount of PM and to do that by working with key stakeholders to determine the extent of project management to employ. Some Lean projects, whether using the PDCA or DMAIC life cycles, may require what is referred to in some circles as PM lite, meaning that the degree of PM provides just enough direction and discipline. Others, especially if the scale is much greater, may require a greater degree of PM. The best approach is to obtain consensus from the project sponsor or steering committee, the customer, and the project team.
Recognize the people side. It is easy to get lost in the mechanics of managing a Lean project. The tools and techniques of statistical analysis and value stream mapping, for instance, can prove quite stimulating mentally. However, a Lean project involves people, and the results can affect the way they do business and, even though it does not intentionally do so, sometimes results in a loss of livelihood. The project manager always needs to keep the people side of the project in the forefront of his or her mind. Whether using the PDCA or DMAIC life cycle, people inside and outside a project’s domain may be affected and can have a positive or negative impact on the performance of the Lean project. Identifying, communicating, and working with stakeholders are key responsibilities the project manager and the entire team need to understand and appreciate.
Train stakeholders. Often overlooked, training is important for people to participate in a Lean project. This training should include using tools, techniques, and concepts for both PM and process improvement. Through training, stakeholders use a common language; become more proficient in applying tools, techniques, and concepts; increase the opportunity for engagement; and enhance their skills and knowledge for use on future Lean projects. To leverage these benefits, training should occur as early as possible. One final point about training: it is a continuous process. Training occurs throughout the PDCA or DMAIC life cycle and people learn from experience as well as from the classroom, so to speak. “Experiential learning” serves as a means for moving a project forward, not backward, by recognizing what works and what does not work. The iterative characteristic of a Lean project allows for leveraging such experience.
Monitor performance throughout the Lean life cycle. The project should be monitored in several areas. One area is PM, which entails determining how well the project is performing according to the project baseline. The other area is process improvement, which entails looking, from a customer satisfaction perspective, at how well waste is being reduced or eliminated. What the two areas have in common is variation, that is, the difference between what is planned and what is actually occurring. Throughout the life cycle of a Lean project, attention is paid to identifying variation and determining its degree of significance. In some cases, the variation may be small, requiring little, if any, remedial action by the project team. In other cases, the variation may be significant enough that it requires taking a whole new approach, whether from a PM or process improvement perspective.
5.2 Overview of Project Management Processes
There are six PM processes that are applicable to every project; what varies from project to project is their degree of application. These processes can be employed on Lean projects, too. These processes are defining, planning, organizing, executing, monitoring and controlling, and closing.
Defining is determining in advance the vision for the project. Organizing involves putting together the support infrastructure for the project. Planning is coming up with a road map to achieve the vision for the project. Executing is implementing the plans efficiently and effectively. Monitoring and controlling is determining how well a project is achieving the vision and whether any corrective actions are necessary. Closing is concluding a project.
All six processes work together to complete a project, whether Lean or some other type. Generally, defining comes first followed concurrently by organizing and planning which are, in turn, followed by two other concurrent processes, executing and monitoring and controlling. Monitoring and controlling is followed by closing.
All processes occur for managing the entire life cycle of a Lean project. Within each phase, the same processes may occur for a phase. Take the following example for a PDCA project. The overall management of the project will have its own set of the PM processes to manage the entire life cycle. The plan phase of the PDCA cycle may also have its own PM processes; however, this application will depend on the scale and complexity of the project and also for the phase. The same concept applies to Lean projects using the DMAIC project, too.
Sometimes a seventh process is adopted that runs concurrently with all six other processes. Technically, it is not a process but serves as an effective enabler of the other processes. This process, if it can be accepted as one, is leading; and without it the other processes may not be as effective in their application. Leading is essentially motivating people to meet or exceed expectations by doing what is right for the project. Without leading, a project manager is simply managing, that is, going through the motions, so to speak, to apply the processes. With leading, the project manager applies the processes according to what is required rather than simply going through the motions. In other words, leading involves doing the right things and not just doing things right.
5.3 Relationship to Lean
PM processes should work in concert with the PDCA and DMAIC life cycles (refer to Figure 5.1). They should mutually support one another. PM processes deal with managing the work of the project; the phases in a Lean life cycle are doing the technical work. Both must work together to develop a product or service that meets customer satisfaction. Good PM, without good technical output, will likely result in an unhappy customer; poor PM and good technical output will likely have the same result.
As mentioned earlier, PM processes occur not only for the entire project; they also occur for each phase of a Lean life cycle. This depends, of course, on the size and complexity of the project. If the size and complexity warrant it, not only do the six processes apply for the entire PDCA project, but also to each of the phases of the life cycle. In other words, defining, organizing, planning, executing, monitoring and controlling, and closing can also be applied. The same is true for the do, check, and act phases of the life cycle. Again, the same pattern exists for DMAIC projects.
5.4 Benefits
The six PM processes offer several benefits.
Provides a structure for managing work. As a project grows in size and complexity so does the magnitude of work. A certain threshold exists whereby the lack of an adequate structure to complete a Lean project can result in difficulty in keeping a project under control and focusing on the vision. It becomes akin to dropping a multicolored bag of marbles on the floor and the contents scattering about. A similar situation can exist on a Lean project. For example, a multidisciplinary team can find its actions scattered about with some areas making progress while others fall behind. The goal is to harness this energy in a way that achieves the vision with the least amount of cost, effort, and waste. PM processes enable doing so by defining up front, providing a road map, establishing a supporting infrastructure, implementing the plan, collecting status, assessing performance, taking any necessary corrective actions, and bringing all work to a successful conclusion.
Focuses on results. PM processes all play a significant role in focusing on results simply because all subsequent planning and behaviors are directed toward achieving the vision, goals, and objectives. With the vision squarely in the minds of the key stakeholders, all decisions and actions are evaluated from the perspective of achieving it. If a change arises to any significant elements of a project, for example, charter or performance measurement baseline, stakeholders apply change management to assess the impact on achieving the vision. In some cases, the vision may need to change and the focus is on the revised revision; all subsequent decisions and actions are changed accordingly, which includes applying all PM processes.
Sets and manages expectations. Defining plays an important role in realizing this benefit. Defining provides an overall vision for a project, ideally replete with goals, objectives, and a scope. This definition occurs in concert with the key stakeholders, including, and perhaps most important, with the customer. All subsequent processes and technical efforts rely upon the vision, goals, objectives, and scope to deliver what the customer wants. Any changes, of course, must undergo change management to determine the impact on the vision, goals, objectives, and scope and to make adjustments accordingly, as a way to reset expectations.
Enables more effective and efficient use of resources. These resources cover labor and nonlabor, for example, time and money. Thanks to the output of the defining process, all subsequent phases entail using and assessing resources to maintain focus. Resources are employed with the purpose of achieving the vision, goals, and objectives. Additionally, during planning, techniques such as resource leveling and smoothing are employed to reduce inefficient and ineffective assignment of resources. During planning and executing, schedule compression techniques, such as fast tracking, can also be employed to accomplish similar results. Without these processes, resources, from energy to people, are wasted which can only result in customer dissatisfaction.
Encourages greater participation and ownership. Key stakeholder involvement is absolutely essential for the success of any project, let alone a Lean one. It becomes critical to share thoughts, ideas, information, data, and experiences among all stakeholders that everyone can leverage. It also becomes critical to share knowledge about areas that did not go well but, just as important, the negative risks that could arise and the positive risks that can potentially be realized. Through greater participation and ownership, resistance lessens because stakeholders who are engaged are less reluctant to criticize and reject something they had participated in creating or performing. Greater participation and ownership is achieved by involving key stakeholders when developing PM deliverables and practices. During planning, for example, key stakeholder involvement when developing a schedule can go a long way to achieve acceptance of the dates within it.
Encourages better communication. If ranked, in some respects, communication is the most important of all benefits. A failure in communication is a project heading for failure. Communication plays an instrumental role in defining by identifying, obtaining agreement or consensus, and informing all stakeholders about the vision, goals, and objectives for the project. It also plays an important role when preparing and distributing plans during planning, as well as establishing a supporting infrastructure during organizing. Communication is instrumental, too, while executing a project and monitoring and controlling to ensure that the project stays focused on its vision, goals, and objectives. It also plays a key role in closing to verify and validate that requirements have been met. As for leading, communicating is critical to motivate people to engage and perform at, or beyond, expectations. According to some institutions, project managers communicate 90% of their time. PM processes help them do that.
Engenders greater accountability. Each of the processes enables greater accountability on projects. Each process requires certain stakeholders to participate when developing deliverables. For example, to complete a charter for the defining process, the participation of key stakeholders, such as the executive sponsor and the customer, is necessary. The document also delineates roles and responsibilities at a high level. Planning also requires identifying roles and responsibilities in much greater detail when developing plans. Executing and monitoring and controlling, of course, help to ensure greater accountability when collecting and assessing status.
Provides an audit trail. For people who fear auditors, this one may not seem to be a benefit. Yet it is an important one. All of the PM processes require some form of documentation, whether in hard- or softcopy format. For example, defining requires creating a charter and a statement of work; organizing, such as forms and reports; planning, such as the work breakdown structure and schedules; executing, such as change management procedures and process, and revisions to the vision, goals, objectives, and requirements; monitoring and controlling, such as forms to capture status dates; and closing, such as a letter of acceptance from the customer. These documents, whether in electronic or hardcopy format, can be used to evaluate how well a project has been managed and led. It also can provide data and information in situations when litigious concerns arise.
5.5 Challenges
As do all other projects, a Lean project faces challenges when applying PM processes.
Resistance toward PM. Despite evidence to the contrary, some stakeholders resist applying PM processes. This resistance may be overt, such as a lack of willingness to follow any PM plan, or with subterfuge, such as deliberately not providing timely accurate information. Resistance is often due to fear. It could be fear of losing independence. It could be fear of looking negative. It could be fear of losing one’s position or job. It could be fear of being held accountable. Whatever the reason, this resistance can make it difficult to implement PM or to do so effectively. It is imperative that project managers seek the participation and engagement of stakeholders who may exhibit such perspectives, if for no other reason than to encourage ownership in the processes. It also may provide them the opportunity to suggest improvements when applying the process to enhance acceptance. Of course, some stakeholders may exhibit so much resistance that it may require elevating the issue to members of an executive steering committee, senior executive management, or an executive sponsor.
Not receiving enough training on the processes. Many people think they know PM and the relevant processes but when quizzed about the subject they display their ignorance. For example, some people think that a simple “to do” list is planning when in reality it serves no purpose from a time and resource utilization perspective. Other people think that merely beginning a project by simply talking with some stakeholders is enough to formulate a vision for a project; oftentimes that approach is woefully inadequate, leading to serious communication and expectations problems later on during the project life cycle. Others think PM involves simply putting out fires, running from one crisis to the next, when in reality they are functioning as an expeditor and not as a project manager. Without training on PM processes, such scenarios are all too commonplace and often assure project failure, not success. Training serves to increase people’s awareness, knowledge, and expertise in PM processes, when performed adequately and in a timely manner. To preclude causing a host of future problems, this training should occur as early as possible in the life cycle of a project.
Not enough discipline and patience by stakeholders. Applying PM processes requires discipline and patience, both of which are few and far between in a business age that requires producing faster, better, and cheaper. The pressure can be immense for getting a product “out the door” and applying these processes with little or no forethought before proceeding. Lean projects are no different and, in fact, the more competitive the environment, the greater the pressure to not implement these processes effectively on a Lean project. Yet, key stakeholders need to sometimes call time out to think about what is occurring and to ascertain where the project is taking everyone. PM processes enable both to occur which requires discipline and patience. Naturally, applying the processes does not necessarily mean that all activity on a project must stop; however, it does require some discipline and patience from time to time to stop, look, and listen for at least a short while. Many projects, Lean and others, often move forward like a herd of buffalo over a cliff, generating a lot of energy and output that the customer does not want or desire. Repeat: key stakeholders need to exercise the necessary willpower to apply PM processes.
Viewing PM processes as “administrivia.” Many people, especially people in highly technical fields, often see PM processes as nonproductive and burdensome. At best, they view it as a necessary evil and like all evils they are best to avoid for the most part. Not surprisingly, many stakeholders will work to circumvent the structure and discipline associated with PM processes. This behavior often persists even in the face of the great gains that have been attributed to applying PM processes. Key stakeholders need to insist up front that people take these processes seriously. This support needs to come not only from the top down but also from the bottom up, meaning that the stakeholders at all levels need to participate in determining the degree to which these processes are implemented and to adhere to that agreement.
Lacking sponsorship or support from senior management. The reality is that the tone often starts at the top. If senior leadership simply talks the talk but does not walk the talk for PM processes, then implementation will not occur, and if it does, then it will be tepid at best. Executive and senior management need to proclaim their support for applying PM disciplines. They must demonstrate this support by expecting all projects, Lean or otherwise, to apply PM processes consistently and effectively. Frequently, Lean projects face the temptation to circumvent PM processes, either because some stakeholders feel that a process takes up too much time from getting the “real” work done or that the customer wants team members to deliver the product or service quickly and does not understand the implications of yielding to this pressure. The trouble with the latter is that the customer often gets shell-shocked over the costs associated with the rework, that the final product or service does not meet requirements, or that the project completion date continues to slide.
Not facing problems beneath the waterline. Unfortunately, not all problems are visible to stakeholders on a project. Many problems are like an iceberg floating in the Arctic; most of the iceberg floats under the surface of the water. These problems often arise at the worst possible time and may not become apparent early on from defining to closing. For example, the simple act of drafting a charter and encouraging discussion will bring forth problems whether people like the topics or not. The earlier such problems arise, the easier they are to address, especially less tangible ones such as political considerations and indecisiveness. Some stakeholders resist applying the PM processes to avoid conflict or to maintain the advantage or edge over other stakeholders.
5.6 Getting Started
The following processes entail applying all the tools, techniques, and concepts discussed in the chapter on PM. Depending on the scale and visibility of a Lean project, the following should be addressed, differing only by a matter of degree.
5.7 Defining Process
This process requires developing a project charter and statement of work for the overall project. The first deliverable should be a project charter that serves as an agreement among a limited number of key stakeholders, shown in Figure 5.2. The charter covers several topics and is restricted to two to three pages. The following topics are covered at a high level.
Background and summary. This section describes key information about the reasons for the Lean project. For example, it might describe the circumstances leading up to the problem or issue being addressed. It may also discuss the impact it has on the customer as well as on internal operations for providing services or a product. In addition, it provides a high-level statement about the purpose of a project.
Goals and objectives. A goal is a broad statement of intent, such as “to provide customer satisfaction.” A goal, however, lacks specificity. An objective provides that missing specificity to achieve a goal, such as “to reduce the number of customer returns by 17% within two months.” An objective can support multiple goals identified in a charter.
Key stakeholders. A key stakeholder is a person or organization having an interest in the outcome of your project. Key stakeholders often include a project sponsor or a steering committee; either one, or both, can provide oversight and resolve issues beyond what the project manager or the project team can handle. The sponsor or a representative of the steering committee prepares the charter. As often happens, however, the project manager may inherit the responsibility to prepare the charter.
Scope. The scope describes the boundaries of a project. This section describes the purview of a project. For example, instead of addressing a complex process or operation, it may describe a subset of an overall process or operation. This section also may describe what the project does not address, thereby identifying the exact scope via falsification.
Constraints. A constraint is something that limits options on a project. A constraint may be a limited number of available resources or having existing operations taking precedence over a project. Constraints often center on time, money, or other resources; however, sometimes these may include other topics, such as regulatory compliance.
Framework or methodology. How the project will be approached is described here. For example, it might include a methodology for approaching a project. From the perspective, it might describe the PDCA or DMAIC life cycle and some of the major deliverables resulting from each phase. It may also describe a specific approach used to produce each deliverable. This section focuses on identifying and describing briefly the framework or methodology used for both PM and process improvement.
Significant milestones. A milestone is an event that consumes no time or resources. The number of milestones presented should be limited to preclude producing a detailed schedule. Some examples of milestones include the beginning and end of a project as well as the end of each phase in the life cycle of a Lean project.
Major assumptions. It is important to capture assumptions up front and to revisit them periodically throughout the life cycle of a Lean project. Assumptions are treated as facts until proven otherwise, and they can have a big influence on the direction and approach for a project. An example of an assumption is dedicated continuous participation by the customer throughout the life cycle. Revisiting this assumption might involve periodically assessing how well this participation is occurring and its impact on a project.
Risks. These are something, such as an event, that potentially may occur in the future. It is important to identify, even based on a limited amount of knowledge what could potentially affect the performance of a project. Risk can be either positive, known as an opportunity, or negative, known as a threat. Often the focus is on threats. By identifying threats up front, especially the heavy hitters, the project can institute strategies to minimize or eliminate the impact if they occur. An example of a threat for a Lean project, for example, is a major stakeholder refusing to share information. An example of an opportunity might be leveraging improvements in a process for use in a project.
Major responsibilities. Delineating responsibilities occurs at a high level. The purpose is to help clarify who does what. Often this might be a listing known as RAAs (roles, accountabilities, and authorities). For example, this section might specify the need to involve the customer in each of the phases of the life cycle of a Lean project and the types of general decisions to make at discrete points in time.
Acceptance criteria. The charter provides a high-level listing of the criteria that the team must meet to complete a project successfully. These criteria often encompass both business and technical needs. An example of a business criterion is reducing overhead costs for a process by 33% or reducing cycle time by 20%. An example of a technical criterion is reducing weight of a deliverable by 25%.
References. This section cites internal and external documents and online sources to name a few. An example of an internal procedure is following specific steps to receive project approval of a Lean project costing more than one million dollars. An example of an external source is legal documentation specifying a specific procedure to follow that can constrain options for process improvement.
5.8 Statement of Work
Frequently, but not necessarily, a statement of work (SOW) is appended to a charter.
Note
In some companies, a charter and a SOW have the same meaning; but for purposes here, these are treated as two distinctly separate deliverables.
The SOW essentially provides a more in-depth description of the work to perform on a project (refer to Figure 5.3). When complete, it serves as a basis for performing another action, planning. It also helps to define, in greater detail, what is and is not in scope.
The SOW covers several topics, some of which leverage from the contents of the project charter.
Overview. This section summarizes background information that has led to a Lean project. It usually provides a greater technical description of the work involved to solve the problem or to address an issue. Greater emphasis is placed on defining the issue or problem that has led to a Lean project, as well as the relevant consequences of not doing anything.
Scope. It is important to describe carefully the scope of work that a Lean project will address. This scope will identify all or part of a process. The scope should describe the overall boundaries or parameters of the scope and its components and their relationships among one another. Also important is to identify subprocesses or procedures that are not part of a project. An example might be a critical financial process that is defined further into subprocesses, such as an accounts receivable process and accounts payable process.
Goals and objectives. The goals and objectives in the charter are further defined in greater detail, which will be used to plan the project. These goals and objectives are predicated on having a well-defined scope of work. Business and technical goals and objectives are all recorded.
Success criteria. The criteria serve as a means to determine whether the goals and objectives have been achieved both from verification and validation perspectives. Verification means that the solution complies with specific qualitative requirements. Validation means that the solution is found acceptable to the customer. An example of verification might be compliance with the Health Insurance Portability and Accountability Act (HIPAA). An example of validation might be reducing customer rejections of products by 33%.
Product or service description. This section describes in considerable detail the product or service to deliver to the customer. It usually describes the major functions or components and any performance needs or wants. It also describes how the different functions or components interact to meet the acceptance criteria defined by a customer. This section may describe in a narrative format, graphic format, or a combination of both. An example of a product or service description might show, in detail, the functions or components and their relationship with one another for a new accounts payable process and what performance needs or wants to satisfy.
Assumptions. The assumptions described in the charter are discussed in further detail in this section. Specifically, it describes the impact of assumptions on producing a product or service for a customer if they are not met, either from a business or technical perspective. An example of an assumption is that the customer provides a liaison to ensure that the requirements for a new accounts payable process are clearly articulated to the Lean project team.
Risks. This section discusses the business and technical risks that might affect a Lean project. Taken from the charter, the impact of each risk is assessed on the technical quality of the product or service being delivered. These risks may be opportunities or threats. An example of a threat might be a customer not providing the requirements needed to improve an accounts payable process.
With the charter and the SOW in place, the next step in a Lean project is to identify the requirements. Capturing the requirements involves identifying the needs and wants of the customer within the confines of the scope. In some cases, the requirements may be identified first and then the SOW. Regardless, the requirements provide the data and information necessary to begin work on improving an existing process. To a large extent, these requirements will likely be more clearly articulated during what is known as a kaizen workshop. However, a preliminary collection of requirements whether in narrative or graphic format can serve as aids during the kaizen workshop which occurs, for example, during the define phase of the PDCA cycle. These requirements will often be compiled from a host of sources, from existing documentation, data and information compilation, and interviews. The compilation should be well organized and approved by key stakeholders when presented at the kaizen workshop.
5.9 Organizing
This process involves putting in place the support infrastructure for a project, existing as a significant part of a project office. Below is a description of the deliverables often put in place for a Lean project to apply the PDCA life cycle, also shown in Figure 5.4.
Roles, accountabilities, and authorities. More commonly known as RAAs, this deliverable describes the contributions of each different job category on a project. A generic title for all roles, such as a business process analyst, the general responsibilities for each one, and the power to make decisions under specific circumstances populates an RAA. The RAA serves as a guideline for assigning responsibilities, embedded in a responsibility assignment matrix, or RAM. The RAA covers all key stakeholders participating on a project.
Team organization. One of the other initial deliverables in the organizing process is to produce an organization chart. This chart will likely be incomplete until the planning process is complete. However, the organization chart can show the roles and reporting relationships among the actual members of a team and the generic positions that will eventually be filled. As people come on board their names populate the chart. The organization chart should reflect the steering committee, project sponsor, the project manager, team members, customer representatives, and other key stakeholders.
Forms and reports. Documentation, either in hard- or softcopy format, is important for many reasons. It serves as a repository of data and information that can be accessible throughout a Lean project. It serves as an audit trail to ascertain the source of problems, conduct performance reviews, or satisfy audit and legal requirements for evidence. Forms and reports are two ways to fulfill these needs. Forms capture the data and reports reflect conversion to information. When a project closes, these documents are then compiled and archived. Forms and reports prove their value by being defined up front and applied as soon as a Lean project begins. The key is to have forms and reports that are useful to stakeholders and do not waste time and other resources, especially on a Lean project.
Procedures and work flows. The project should have procedures describing the overall process for managing a Lean project. In some places these are called management plans. Regardless of the name, they describe what is needed to ensure that stakeholders follow common processes. These procedures often cover a wide range of topics on managing a project. They may vary in degree of formality and content. In some cases there may be a separate procedure for each topic; in other cases, only one procedure is necessary because the project is small enough. Common topics include change management, risk management, scheduling, issues management, resource management, communications, procurement management, and software tool application. Naturally, these procedures should be accessible to everyone.
Project manual. This PM deliverable is often overlooked. It contains a wealth of information that stakeholders can reference during the life cycle of a project. It contains a contact listing of key stakeholders, procedures, descriptions of forms and reports, communication management plan, status reporting requirements, RAAs, organization chart, and any other information deemed important to stakeholders. Every stakeholder should have a hardcopy but this may prove difficult to maintain. In today’s technological environment, the manual can be stored online and everyone, using a common toolset, can access its contents.
Communication plan. This deliverable can be as simple as an electronic spreadsheet. It describes which stakeholders receive specific information as well as what meetings they should attend. Additional information might include agendas for meetings, contact information, and who receives what reports and the specific information contained within. The whole idea is to provide the right people with the right information in the right amount at the right time. Communication is absolutely critical for project success, whether for a Lean one or some other one. The communication management plan should be revisited throughout the life cycle of a Lean project inasmuch as stakeholders often change and the ones who remain may also have changing requirements.
Software tools. A Lean project has to be careful in selecting the right software tools. Some scheduling tools may prove too cumbersome for the scale and complexity of a project. Lean projects applying the PDCA life cycle often require less sophisticated software tools than ones following the DMAIC life cycle. A small Lean project can easily get stymied by a scheduling tool that requires considerable expertise to use and poses a challenge for interpreting the output. In some cases a simple spreadsheet and presentation software might suffice. The key is to use technology that supports, not drives, a project.
Project library. Like the project manual, this deliverable can be either in hardcopy or electronic format. This library serves as a repository of information that people can reference throughout the life cycle of a Lean project. The content may include technical documentation, reports, presentations, drawings, regulations, company policies and procedures, and any other content deemed useful for a project. Again, everyone should have the tools to access the content of the library to access it electronically.
5.10 Planning
Planning involves coming up with a road map to achieve the vision of a project as defined in the charter, SOW, and requirements. Several PM deliverables are produced during planning for the overall project (refer to Figure 5.5). The plans are further broken into greater detail for each phase in the PDCA cycle.
Work Breakdown Structure. Also known as the WBS, this deliverable becomes the ultimate scoping document for a Lean project. It is developed in a top-down perspective and shows the major phases of a project and the corresponding deliverables within each phase. The WBS serves as the hub to build the entire remaining planning deliverables, enable managing change, and tracking and monitoring performance. The WBS can be expanded for each phase during the life cycle of a Lean project.
Risk assessment. Some preliminary risks are usually identified in the project charter and they provide a good basis to conduct a comprehensive risk assessment. However, now that project managers know more about their projects, they can engage more stakeholders in developing a comprehensive risk assessment. Using the SOW and WBS, too, they can determine with some confidence the risks that their projects could face. This risk assessment, in the end, provides a listing of risks as well as their priorities and impacts. For each significant risk, project managers identify strategic responses for dealing with each one. The results of the risk assessment provide invaluable data and information to make time and cost estimates as well as to determine the logic in a schedule.
Resource assignments. With the WBS built, the next PM deliverable is to assign responsibilities to activities for members of a project team. This action entails developing a high-level responsibility assignment matrix. A RAM is based upon the roles, accountabilities, and authorities defined during the organization process described earlier. The RAM at this point is useful to identify who provides time and cost estimates during the planning of each phase in the Lean project life cycle.
Schedule. This diagram shows the logical relationships of the elements within a WBS at the detail or work package level. The content can be rolled up into a milestone chart or bar chart. The contents of these schedules can also be expanded further for each of the phases if the entire project cannot be scheduled in detail up front This expansion will enable creating a network diagram that shows the relationships among work package levels and their activities within the WBS. Some milestones may have already been defined in the charter.
Budget. At this point in time, the budget was likely identified in the charter. The reliability of the estimate is questionable because the work has not been fully planned. As the planning becomes more refined during the entire life cycle of the project, a more reliable estimate of the budget may be made by stakeholders.
With the WBS, resource assignments, and the schedule done, the project budget can be finalized at a certain confidence level to form part of a performance measurement baseline.
5.11 Executing Process
During this process, the PM tools, techniques, and deliverables discussed in the previous sections are now applied. Two parts to this process exist: adhering to the PM processes and deliverables to begin improving a business or technical process (refer to Figure 5.6).
Operate according to plan. It is during this phase that implementing the project plan occurs. The relevant stakeholders should understand their responsibilities and the PM processes, procedures, and practices to follow. They should know what to do, when to do it, have an idea, and how to do the procedures. They also know the criteria for user acceptance. They should be very knowledgeable about the vision, goals, and objectives of the project. The charter should have captured much of this information as well as the statement of work, the WBS, and the proposed schedule.
Other actions can begin occurring during this phase of the Lean life cycle and throughout all the phases of the PDCA cycle. These actions include acquiring additional resources; capturing data and information; communicating with key stakeholders; complying with change management procedures; working with suppliers, vendors, consultants, and contractors; and managing and leading people.
Acquiring additional resources. Initially, a project starts off with a core team. The core team lays the groundwork to apply project management and produce deliverables. This team then determines at what point to bring in additional labor. As these resources arrive according to the plan, they may need to revisit estimates to accommodate their level of knowledge and expertise to perform any necessary activities. These activities are then applied while improving a process. For nonlabor resources, the core team accounts for any relevant lead times to ensure availability according to the schedule. If unavailable, then the team anticipates what contingency plans to invoke.
Capturing data and information. During all phases of a Lean project, data are captured, especially on the project performance and the deliverables produced. Data are converted into information for stakeholders as described in a communication management plan. All data are scrubbed before being converted into information to avoid tarnishing the quality of the latter. As stakeholders change, the content of the communication management plan is changed to reflect the changing needs and wants of new stakeholders. Naturally, the revised communication management plan is made available to all stakeholders.
Communicating with key stakeholders. This one is closely allied with capturing data and information. The only real difference is ensuring that stakeholders receive the right information in the right amount in the right format at the right time. Nothing can kill credibility with reports more than giving people too much data and information and their having to decipher the content. The communication management plan captures such information requirements, and all reports should adhere to the requirements captured in the communications management plan. Data and information can be provided both on a regular and ad hoc basis.
Another part of communicating with stakeholders is listening. A good communicator listens as well as talks. By listening, project managers can learn a good amount about what is occurring on their projects; they can hear what they need to hear, not what they want to hear. This feedback then allows project managers to make effective decisions as well as determine the source of a problem. They can then take appropriate corrective action. This activity requires listening to individuals and groups alike to gather a good perspective about where the project has been, where it is, and where it is going in the near and distant future.
Working with suppliers, vendors, consultants, and contractors. This action may or may not be relevant simply because many times process improvement projects occur in-house. However, external stakeholders may be brought on board due to their experience, knowledge, and expertise. Project managers need to work closely with these stakeholders because their actions and decisions may affect the final results when executing and completing a project. They can also influence the morale and esprit de corps of permanent stakeholders. A common occurrence is that sometimes external stakeholders participating on a Lean project generate suspicion among the rank and file, especially when the latter perceive that their positions are threatened. The tension can become quite intense under such circumstances, making it difficult for a project manager to manage and lead a project.
Adhering to change management. Change will occur and the longer the life cycle of a project the greater the opportunity for it to arise. Change can come from a variety of sources, including the government, the customer, or a team member. The key is to have a disciplined approach for addressing change to a process, product, and baseline. This means following an approach described in a change management plan. Changes should be assessed according to priority and impact and then handled accordingly, such as approving and scheduling it for implementation.
At all times, the project manager should make every effort to stop any attempt to subvert change management. Otherwise, scope creep can occur. Scope creep is the gradual expansion of the original vision for a project; it can dash customer and other key stakeholder expectations related to cost, schedule, and quality. Lean projects applying the PDCA cycle can help to keep scope in check by following a repetitive cycle.
Managing and leading a project. As mentioned earlier, managing a project is doing things right, that is, following what is expected in terms of procedures and practices. Building a WBS and a schedule are expected deliverables for managing a project. Leading a project is different; it is doing the right things. It requires making decisions that are not always popular but are necessary to further progress or deal with a negative conflict that no one wants to admit exists despite having deleterious effects on team performance. On Lean projects, whether employing the PDCA or DMAIC cycle, people issues often become very difficult. There are several reasons but the most common one is that process improvement generates fear because some people perceive that they might lose something of value, such as status, power, money, or a combination of all three. Whatever the reason, a project manager with good leadership skills must address problems early on, not later; otherwise, their impact will become apparent at the most inopportune times in a project life cycle, such as during the delivery of a product or service. In the end, it can, and more often than not, affect customer satisfaction.
Also important to leading is maintaining esprit de corps and morale on an individual and team level. Project managers need to identify and apply ways to keep team members motivated to progress through not just one phase of a Lean project but also through an entire life cycle. This responsibility becomes quite difficult in the face of negative conflict and setbacks that invariably accompany all projects. Lean ones using the PDCA life cycle are especially challenging in this regard because of the sometimes “porous” nature of these projects, meaning they use less rigor than the ones employing the DMAIC life cycle. The PDCA life cycle can be heavily oriented toward conflict if findings are mainly anecdotal and the recommendations rest upon subjective assessments. Sometimes this conflict can arise in a manner that appears irreconcilable and yet project managers must do their best to resolve such conflicts to conclude successfully.
Revisiting the risk assessment. Through all phases of the PDCA life cycle, project managers and other key stakeholders need to revisit the risks for their projects. This review includes risks, priorities, impacts, and strategies to ascertain relevancy and importance as well as the adequacy of planned and actual responses. Most projects happen in dynamic environments that present a changing list of risks and their attributes, for example, priority and impact. The assessment will likely also result in impacts on estimates on performing specific activities in a schedule which, in turn, require revisiting. After reassessing risks, the results should be communicated to key stakeholders.
Reviewing the quality of output. This activity is much more difficult than what many people think, especially with Lean projects. The ultimate arbiter is the customer because anything that does not achieve its goals is considered waste. Communicating with the customer and obtaining its engagement are two important ways to increase the likelihood to improve quality because of ongoing feedback. Additionally, quality is in the processes (not to be confused with the business process under review) involved when performing each phase of the Lean life cycle. Furthermore, quality is fulfilling what the customer wants, not exceeding expectations which only lead to scope creep. The fundamental challenge is that quality really is in the eye of the beholder, meaning in this case the customer, on Lean projects. This circumstance involves a subjective assessment by the customer, especially if the PDCA life cycle is employed.
5.12 Monitoring and Controlling
The monitoring and controlling of a Lean project occurs concurrently with executing. This PM process is analogous to a doctor checking the symptoms of a patient to determine health status and then deciding what action to take. Communication, as with other process groups is critical; however, it is absolutely essential if projects are to progress as planned and, if not, recognizing that a problem or issue exists and determining what action or actions are necessary to proceed according to plan in the future. Monitoring and controlling involves several actions to take in this regard. These actions are following PM procedures, collecting metrics, comparing planned and actual performance, analyzing and evaluating performance, taking remedial action, controlling procurements, and applying change management (as shown in Figure 5.7).
Following PM procedures. Following PM procedures is especially important during monitoring and controlling when collecting data and information about the performance of a Lean project. By following the procedures developed in the organizing process group, project managers can feel confident about their feedback. Obtaining this feedback is, however, easier said than done, especially when executing a project. People may be focusing so much on their technical responsibilities, for example, that they may find collecting status as interfering with “real” work. Project managers need to be persistent and consistent when collecting facts and data about project performance. Being persistent requires using whatever means to collect status from stakeholders. Being persistent is not, as already mentioned, always popular; this is especially the case when some stakeholders fail to fulfill their responsibilities. Being consistent is collecting the necessary facts and data at regular intervals and in a format commonly known and understood by everyone. This, too, is not always popular among stakeholders if they feel that they have “higher” priorities. Still, it is important to execute relevant procedures developed during the organizing process group; otherwise, the result will likely be an incomplete and inaccurate assessment of project status. Unreliable status then creates a credibility gap not just in the reports but also with the project manager.
Following procedures using the PDCA cycle is frequently a challenge. The reason is that PM lite is often applied, meaning that PM is applied at a relatively high level. It is true that the rigor advocated by some professional associations for office-type environments can result in overkill and can actually be counterproductive. The procedures for collecting facts and data on performance are often at a high level and do not demand the rigor that is often associated with DMAIC projects. The tendency is simply to go with personal subjective assessments and mental estimates of percent complete without much regard to the reliability of these data and information. Procedures, too, are not often consistently followed due to the simplicity of the PDCA cycle. For small PDCA projects, this approach may suffice; but for medium to large projects PM lite may simply be a prescription to generate meaningless reports and, ultimately, result in project failure.
Generating metrics. Having the right data allows project managers to have reliable information to determine how well their projects are progressing. Without reliable facts and data project managers will likely make decisions that could have a negative impact on their project. It is important, therefore, to have the right measures in place that will generate the right information to make the right decisions. If any data are tainted the chances increase that the information will become suspect.
It is imperative, therefore, to provide sufficient measures that generate useful metrics. From a PM perspective, these metrics center on the performance measurement baseline, consisting of cost, schedule, and scope criteria. The keys to successful metrics are twofold. They tell a true story about the performance of a project, and they indicate whether corrective action is necessary. The former action is to determine what measures are required to generate the desired metrics. These measures should have meaning to stakeholders and should not be done simply to collect data to generate information that ultimately has no meaning to anyone. More is not better in this regard and, quite frankly, may be counterproductive. To do that requires ensuring that the data are reliable, meaning scrubbing them to remove inaccuracies and inconsistencies. Once scrubbing is complete, the latter action is to generate information in the form of metrics that are easy to understand, useful to the recipient, and that enable an accurate understanding of what was, is, and will be happening on a project. The information is presented in a format that satisfies the stakeholders who receive it; both stakeholders and content should be identified in the communication management plan.
For PDCA projects, these measures are often at a high level albeit not necessarily so. The level of depth regarding metrics depends on the size, visibility, and complexity of a project. It also depends on the stakeholders who will receive the output. The higher a project manager reports up the chain of command, it is best to produce summary metrics; the lower the chain of command the more detail is better as long as the content is relevant to the stakeholder doing the work.
When data is collected at a high level, the “alarm bells” should always be present, especially on PDCA projects. The tendency is to accept very subjective assessments that are riddled with ambiguity. As a heuristic, meaning a rule of thumb, it is better to strive for objectivity through numerical measures than accepting a subjective assessment. If subjective assessments are all that are available, as is often the case associated with PM lite, project managers must be prepared to question the responses when requesting data to ascertain reliability if they hope to assess the performance measurement baseline meaningfully. For instance, simple percent completes that are not based upon measurements are notoriously inaccurate, such as the perennial, “I am 95% complete.” Skepticism is critical.
Comparing planned and actual performance. With reliable data and useful information, project managers can compare what is supposed to happen with what has actually happened and will happen if current levels of performance occur in the future. The idea here is to ascertain whether the project is progressing according to the plan agreed upon by all the key stakeholders. The metrics, which include cost, schedule, and scope data, should indicate whether progress is proceeding as expected. Whether for cost or schedule, for example, the differences between planned and actual may be different and the significance determined by the degree or magnitude of the variance, that is, the difference between planned and actual. In some cases, the variance may naturally recover before the next reporting period; in other cases, corrective action may be necessary to make appropriate changes. And, if that does not help, replanning, in whole or part, may have to occur.
For projects using the PDCA, comparing planned with actual performance is very difficult because PM lite is often applied, meaning the lack of rigor in tracking performance necessitates receiving more feedback from the people doing the work, which is good but too subjective. Project managers need to discuss and cross-check extensively to ensure that the data used for comparing planned versus actual performance are accurate and complete. Otherwise, the results will likely be unreliable and, therefore, provide little value to key stakeholders.
After comparing the planned and actual performance, project managers and other key stakeholders have to make a decision to continue with the current level of performance or take some remedial action, which is doing something that aligns actual performance with planned performance or replans the remainder of the project. The decision to replan should not be taken lightly because it requires slowing the momentum of a project and may consume resources and extend the timeline available for completion.
In many environments applying the PDCA cycle, a tendency exists not to develop cost and schedule baselines. Instead, the planned baselines get status but the dates continually move, leading to one slide after another. No baseline equals no discipline and makes it difficult to determine whether the performance metrics for a project will be met. If no performance measurement baseline exists, the impact of a failure to perform is difficult to determine and assess. The project manager will have to collect status continually in a reactive manner, reflected in constant revisions.
Applying change management. During monitoring and controlling, the metrics may reveal that a project is not progressing as expected. The cause could be due to one or more factors, such as an unrealistic schedule, an unanticipated technical problem, lack of information, or a change in managerial direction, and significant corrective action may be required. Regardless of the type or degree of change, what is meant by “significant” should be defined by the PM plan or procedures. Usually a significant change involves some alteration to the performance measurement baseline, which includes cost, schedule, and scope. The corrective action under such conditions necessitates submitting the proposed action for approval or disapproval via integrated change control.
Because many Lean projects applying the PDCA cycle tend to embrace PM lite, a performance measurement baseline is often opaque at best, thereby making it extremely difficult to ascertain the cause for making a change and determining its impact. Under this circumstance, it behooves project managers to obtain a review and approval or disapproval from the project sponsor or steering committee. If the Lean project is substantial in terms of scope, for example, a formal change board may exist and the impact of a significant corrective action can then be assessed and subsequently approved or disapproved.
5.13 Closing
Closing is often the most overlooked process group in project management. More often than not, stakeholders are just happy the project is over, especially if it was extremely grueling. Nonetheless, there are some significant activities to conduct when closing a project. These are closing contracts, compiling and archiving data and information, verifying and validating the product or service, delivering the project or service to the customer, and conducting a lessons learned (shown in Figure 5.8).
Obtaining acceptance of the product or service. Upon completing a product or service for delivery, the customer must obviously review the output. The customer ensures that the product or service satisfies the requirements, such as the ones delineated in the statement of work. Sometimes, a requirements or specifications document provides greater detail than what appears in the SOW. Regardless, something equivalent to acceptance testing is conducted with the customer to ensure satisfaction with the product or service. Often this satisfaction must occur in two areas: the functional and performance requirements as defined by the customer and compliance with certain standards, such as one dealing with industry standards or the law. Sometimes, before acceptance testing occurs, the Lean team conducts its own tests to verify that requirements and standards have been met and, if so, then acceptance testing occurs.
For Lean projects applying the PDCA cycle, validating and verifying requirements and standards are often quite simple. The final assessment and decision rest with the customer. If the customer feels satisfied with the product or service, the project is over. The downside with Lean projects applying this principle is that the customer may never express its satisfaction and the project keeps going on and on with seemingly no end in sight.
Closing contracts. As a phase or project comes to a conclusion and the work has been found acceptable to the customer, all contractual obligations with vendors, suppliers, contractors, and consultants must come to an end. This action requires reviewing the terms and conditions to ascertain whether all obligations are complete on both sides. If the customer is satisfied, it makes little sense to keep the contract open; doing so will only add costs.
The challenge with Lean projects using the PDCA cycle is that it may take many additional iterations through a cycle before a contract with a vendor, supplier, consultant, or contractor can come to a close due to the life cycle’s iterative nature. Still, every effort is made to close contracts when work is complete. This requires project managers and other stakeholders to watch costs closely when obtaining support from external parties.
Compiling and archiving data and information. If the customer is satisfied with the product or service, the project manager can start gathering data and information about the project. The data and information can be hard- and softcopies of documents and may include data stored in spreadsheets or repositories; correspondence, such as emails, financial agreements, accounts payable, and accounts receivable documentation; schedules; burndown and burnup charts; PM documentation; and other pertinent material. These data and information are indexed and archived for easy access. It should be accessible to project managers and other project professionals who will be involved with Lean projects of a similar nature. It should also be accessible to auditors to ascertain how PM and Lean were executed during the project. Finally, it should be accessible to lawyers and other legal experts if litigation should arise over any process improvements made that resulted in injuries to an internal or external stakeholder.
For Lean projects using the PDCA cycle, compiling and archiving data and information are not an issue. There is often plenty of material to handle. In fact, the challenge will be what information to exclude when compiling and archiving. The decision on what to include and exclude is often done by the project manager and project sponsor. Criteria for making such decisions are based upon the purpose and scope of a Lean project, the material used to determine improvements in a business process, any material used to make decisions to proceed with the project, and any material that significantly relates to the performance management baseline.
Conducting a lessons learned session. No project should conclude without a lessons learned session and a document that captures the feedback during that session. In fact, it is best to have a lessons learned session at the conclusion of each phase so that no feedback is lost due to turnover or memory loss. For example, a lessons learned session might be conducted right after completing each phase of a PDCA project. Once the project is complete, the lessons learned from each phase are compiled into one document.
What goes into a lessons learned document? A lessons learned consists of four sections. The first section provides background information about the project; it should be a high-level overview because more details reside in other project documentation, such as the charter. The second section describes what went well during the project and some of the contributing factors to the outcome; it may even identify some best practices. The third section describes what did not go so well and some contributing factors for the outcome. The fourth section describes any recommendations for improvement applicable to future projects of a similar nature.
5.14 Final Insights
PM processes are applicable and provide value to Lean projects. The data and findings by professional institutes and other organizations verify their effectiveness and their contributions to the efficiency of projects across all industries. Lean projects can especially benefit from PM processes because they provide a structure to manage the work performed regardless of whether applying the PDCA or DMAIC life cycle.