Chapter 3

Overview of Project Management Fundamentals

Before discussing in detail the use of project management (PM) to manage Lean projects, it is important to have a good understanding of what the topic is all about. All too often people talk about PM but fail to understand the fundamentals necessary to make it a reality. Good PM requires knowledge and discipline on the subject. Unfortunately, the overall record of projects completing on time, in just about all industries, is less than satisfactory when measured against three common criteria for success: cost, schedule, and quality. What is covered in this chapter, in concert with the basics of Lean in the next chapter, is a game plan for managing Lean projects.

3.1 What Is a Project?

A project is not something that people do routinely. It addresses something that is unique, that is, never having been done before. If it has been done, then it varies significantly due to unique circumstances, such as requirements being different from previous ones. A project also exists for a finite period of time, varying from a few days to a few years, depending on its scale and complexity. Once a project is complete, the entire effort is disbanded or transferred to ongoing operations (refer to Figure 3.1). Hence, a project is a set of activities or tasks performed in a logical sequence to attain a unique result, for example, a new building or a software application, and then it concludes. All projects also consume resources, which include labor, such as people with a specific expertise, and nonlabor, such as time and money.

PM is a discipline to manage projects. It consists of a set of proven concepts, tools, and techniques that enhance the possibility of success, however key stakeholders define it. Stakeholders are people or organizations having a direct or indirect interest in the outcome of a project.

PM requires performing these processes: initiating, planning, organizing, executing, monitoring and controlling, and closing. The scale, complexity, and importance of a project will determine the extent to which these processes are addressed. Although not technically a process, there is one that is performed throughout all the other processes, and that is leading. More on that topic later.

3.2 Stakeholders

As mentioned previously, a stakeholder is a person or organization having a direct or indirect interest in the outcome of a project. The number of stakeholders varies from project to project and from industry to industry. Below is a list of some of the common stakeholders that exist on projects:

• Customers
• Government agencies
• Partners
• Press
• Public at large
• Senior executives
• Shareholders
• Special interest groups
• Suppliers
• Team members
• Users
• Vendors

Often with little or no authority, project managers must also work and communicate with other people involved with their project. They not only have to interact with the team, customer, and steering committee, but they must also act tangentially with a wide category of people in other organizations, including

• Accounting
• Contracts
• Cost engineering
• Employee relations
• Engineering
• Estimating
• Information systems
• Legal
• Operations and maintenance
• Purchasing
• Quality assurance and control
• Records management
• Safety
• Scheduling
• Strategic planning

Stakeholders can play one or more roles on projects. Usually, there are five fundamental roles on a project. These are the sponsor, senior management, customer, project team member, and project manager.

The sponsor is usually a senior manager with single authority to ensure a project is properly supported. The sponsor provides many kinds of support, not all of it financial. He or she can provide political support, resolve issues, and make key decisions. Sometimes the sponsor may be a group of people forming what is known as a steering committee. The project manager may or may not report to the sponsor. Sponsors can be totally involved on a project; or the involvement could be lukewarm at best or it could be nonexistent. Sponsors, too, can change from time to time. Some of the specific responsibilities of a sponsor include organizing and managing the work statement, developing and maintaining relationships with other stakeholders, providing guidance and oversight, making important decisions, and removing key barriers.

Senior management consists of the superiors of the project manager. These are people often in higher management ranks, such as first level or above to all the way up to the C-suite, again depending on the scale, complexity, and visibility of a project. One of the members of senior management usually serves as the sponsor and others attend steering committee meetings. Members of senior management often move around, sometimes making it difficult for the projects to receive stable guidance and support; this situation can be extremely difficult if the sponsor of a project changes too often. Some specific responsibilities of senior management include ensuring their organizations provide the necessary support for the project, making key decisions, and ensuring actions supporting a project align with the goals and objectives of the project.

The customer is the person or organization for which the project is conducted. The customer is, for all practical purposes, the reason for the project in the first place. Whatever the output for the project is, it must eventually go to a customer, whether internally or externally. Defining the customer is not as easy as one would think. For example, a government project that creates a system for use by the public can be a challenge because the public may not be specific enough. It is good to define who or what the customer is for every project, if for no other reason than to understand why a product is being built or service being delivered. Over time, the customer, as well as the requirements, can change. Sometimes, an immediate customer exists but a longer-term one has also been identified. Some of the specific responsibilities of the customer include paying for the product or service being delivered, collaborating with the project manager and the project team, approving interim and final deliverables, providing necessary labor with knowledge and expertise, and defining and communicating requirements.

The project team consists of the people who make it possible to develop a product or deliver a service to the customer. Often, an original core team is established that sets up the initial guidance and plans for the project and then additional members join the team as the project progresses. Some team members support the project full time, whereas others come on board for a short while and then depart. Ideally, a project receives the team members with the requisite skills and knowledge identified in the plan at the right time. Reality, however, may dictate otherwise. In addition, sometimes not all team members perform according to expectations; a common guideline, known as a heuristic, is that 20% of the people produce 80% of the output. The other complication is that turnover of team members on a project is quite common, making it difficult to engender and maintain esprit de corps. Specific responsibilities of the project team include supporting the project manager; applying the requisite skills, knowledge, and expertise; performing as a team; and working with the customer.

The project manager is another major role on a project. This person has overall accountability to complete a project. This is no small responsibility, especially if a project manager has no real authority over team members. It is also a difficult role for the person if she has limited support from the sponsor or senior management. Nonetheless, the project manager is the person held responsible to turn the effort and resources of the project team into a product or service that the customer wants and, therefore, is willing to pay for. The project manager is also the only person who interacts with just about all the other stakeholders. She serves as the hub that all communications funnel through unless, of course, she lacks support from the sponsor or senior management. Some specific responsibilities include establishing effective communication among stakeholders, developing a plan with key stakeholders, ensuring performance according to a performance measurement plan, and motivating the project team.

3.3 Projects, Programs, Portfolios

Some organizations, unfortunately too few, apply project portfolio management, a disciplined approach to view projects as an investment to achieve strategic goals and objectives. Each project, program, and initiative is tracked, evaluated, and managed much like an investment in a financial portfolio. Ideally, a project is considered by senior executives as a good investment; otherwise, when budget cuts arrive, it will likely be one of the first victims.

A portfolio actually consists of projects, programs, and sometimes initiatives, as shown in Figure 3.2. A program is essentially a group of related projects that satisfy one or more strategic goals and objectives. An initiative often consists of one or more programs or one or more large-scale projects that affect an entire enterprise. Hence, the relationship goes as follows: vision, mission, goals, and objectives; operating plans, initiatives, programs, and projects.

The idea is to ensure all projects, programs, and initiatives add value to the company. If they do not, then they should be scrapped. Portfolio management is the tool to ensure that all three are in alignment with the company. Portfolio management uses wide criteria, often determined by an executive steering committee. The criteria may be financial performance but it may be other variables such as schedule performance, technical performance requirements completion, and burndown of deliverables. Under portfolio management, projects, programs, and initiatives are often put into what are known as strategic buckets, such as strategic, operational, and maintenance. Money and other resources are then apportioned and reapportioned regularly to improve performance of a project, much as with an investment portfolio. In some cases, performance may be so inadequate for a project that it is canceled.

3.4 Organizational Location of Projects

Projects can reside in all levels of an organization. The power and visibility of a project depends on its location within a specific structure; it also determines to a large extent how much power and authority a project manager has. There are three fundamental organizational structures where a project may find itself located.

The first is the traditional functional, or stovepipe, organization where a project resides. The company is basically broken into several functional areas, such as marketing, sales, accounting, manufacturing, and engineering. A project may arise in the bowels of one of these functional areas and necessitate the project manager working with a team comprising people from each of the other areas. Obviously, the project manager is going to have little or no control over these people and will need considerable support from his sponsor or senior management to act or make decisions.

The second is the matrix organizational structure. Ideally, the project manager is a member of a PM organization, known as a project management office or PMO, having responsibility to provide PM expertise. Although the people likely report to leadership in a functional area, the project manager has considerable authority to make decisions and to act as they relate to the vision, goals, and objectives of the project. The project manager still needs support from the sponsor and senior management but he can interact with the functional managers regarding the resource. Most of the time, people are supporting multiple projects; sometimes, they are dedicated full time to the project.

The third structure is the projectized or task structure. This structure is the ideal one for a project manager with complete control over resources, labor and nonlabor alike. The project manager has total control over the budget, can negotiate and communicate freely with other stakeholders, and has a dedicated project team. In some cases, a steering team exists to provide some guidance and support, but for the most part the project manager operates the project as an independent business unit.

Realistically, most organizations are a blend of all three structures to one degree or another, especially in medium to large companies. A PM office exists that provides PM expertise, including project manager. Some major projects and programs have their own budget and grant the project manager considerable autonomy. A number of functional organizations, such as finance and information systems, provide resources to the projects and will even have their own internal projects.

3.5 Leading and Six Key Processes

As shown in Figure 3.3, a project manager performs a very critical action and project management processes on a project. Failure to perform any of them at a satisfactory level can result in performance problems for a project.

Leading is the most important action a project manager can take. It is the only one that applies to all the other actions and project management processes on a project. It entails motivating people to achieve the results of a project. Leading is different from managing, which is about doing things right; leading is about doing the right things. For example, PM is about performing the functions such as scheduling, calculating costs, and implementing change management; leading is about working with all kinds of stakeholders, applying effective listening, resolving conflict, raising issues, and other “soft” topics related to intra- and interpersonal skills. There are many types of leadership styles that can be exercised on a project. These range from being autocratic to taking a laissez-faire orientation.

Although the project manager must lead on a full-time basis, in actuality everyone on a project exhibits leadership to one degree or another. Leading entails communicating with and influencing a wide range of stakeholders, confronting issues and problems up front, making timely decisions, collaborating with all stakeholders, and reporting all results, including the good and bad. Ultimately, there is no specific deliverable produced from leading but all deliverables for a project and the final product or service that reflects the quality of leadership exhibited on a project. Leading is instrumental in ensuring that the following project management processes are implemented effectively on any project.

Defining is determining in advance what a project will achieve. This process is extremely important because it essentially formulates the entire purpose of the project. Defining entails drafting a charter, preparing a statement of work, determining requirements, and obtaining buy-in from key stakeholders. The most significant deliverable from defining is the project charter and the statement of work. Both deliverables provide a high-level vision for the project that serves as a basis for performing all subsequent actions and determining success once the project completes.

Planning is determining what activities or tasks are needed to execute the vision of the project, assigning who will perform those activities, and identifying when those activities must start and stop. This process is quite extensive and much effort should be put into it because it serves as a road map for realizing the vision for the project. Actions to perform include defining the scope in greater detail, determining a schedule to complete the work, assigning people to perform the activities, calculating financial requirements, and identifying risks and ways to respond to them. There is a wide range of deliverables produced as a result of this action. These deliverables include a work breakdown structure (WBS), a network diagram, schedules, time and cost estimates, allocating and assigning resources, creating a budget, and performing risk management. Once all these deliverables are produced and bought off by key stakeholders, a performance measurement baseline is established for three areas: cost, schedule, and scope. The performance measurement baseline is used to manage a project and to evaluate its performance. Keep in mind that there is an agreement between two or more stakeholders on expectations about the performance of a project.

Organizing is employing resources efficiently and effectively to manage a project. This action involves establishing the infrastructure for managing a project. It involves activities such as determining tools, documentation requirements, and organizational structure. Some deliverables for this action include a communication management plan, status reports, hardcopy or electronic forms, organization chart, and roles, responsibilities, and authorities. A management plan is often produced to describe how the project will be conducted; depending on the size of the project, it could be one plan or subdivided into multiple management plans.

Executing is the process involving implementing a plan for the project to achieve its goals and objectives. In other words, it involves managing according to the performance measurement baseline that was built under planning. A key activity under this action is change management, which is the policies, processes, and procedures established on a project to detect, analyze, evaluate, and implement changes to all baselines. These changes can be technical or business in nature. Changes can come from many sources, including the project manager, senior management, customer, project team, or an external entity, such as the government. Successful execution depends on controlling the scope by avoiding what is known as scope creep. If unauthorized changes are made to the original scope, then expectations surrounding the performance measurement baseline will be dashed and no matter how good the quality of the deliverables the customer could be dissatisfied. Some significant deliverables produced during this action include a change control log, applying change and configuration management disciplines, revisiting the performance measurement baseline to determine the impact of a change, and closely performing in concert with the following process, monitoring and controlling.

Monitoring and controlling involves assessing how well a project uses its plan and organization to meet its goals and objectives. Some activities include tracking and monitoring performance, collecting and assessing status, and taking an appropriate response. When collecting status keep in mind two important behaviors, persistency and consistency. Being persistent means collecting status from people and organizations without exception. Many times people will resist giving status out of lack of time but mostly out of fear. Seasoned project managers recognize this aspect of human behavior and, it is hoped, deal with it in a positive manner but do not refrain totally from employing a negative approach. They are also consistent in the collection of data and information, avoiding the tendency to take different approaches with different people, with inconsistent results; the assessment ends up comparing apples to oranges. Assuming no problems with persistency and consistency, a key result from monitoring and controlling is variance. Not all projects perform according to their performance measurement baselines; in fact, most do not. The status output will likely show what is known as variance, the difference between what was planned and what actually occurred. If the variance is significant, then the question is whether the variance is negative. If so, what type of corrective action is required or is it even warranted? Is corrective action enough? Could it involve replanning a portion or all of a project?

Closing is the final process. It involves concluding a project efficiently and effectively. Some activities for this process include compiling data and information, conducting reviews, and obtaining buyoffs. Some of the major deliverables for this project are records compilation, financial closeout, contract compliance verification, product verification and validation, process audits, and lessons learned. Quite often, this process is left incomplete on many projects, which is bad because the data and information can avoid legal complications as well as enable project managers of future projects of a similar nature to leverage knowledge and experience from the current one. Some reasons why closing is often neglected are that people who just want to retire from the project, especially if it is a difficult, long, drawn-out affair, are anxious to move on to the next project, and simply because it requires seeking and compiling data and information.

3.6 Project Phases and Project Management Processes

A project consists of phases as opposed to processes (refer to Figure 3.4). Processes are what the project manager performs, such as leading, defining, and executing; phases are discrete periods within a life cycle that require producing a unique set of deliverables, such as a requirements document or software code. Project managers apply the seven processes within each phase and for the overall project.

Consider the following generic example of a project. Call it Project A, which has a mission to develop an accounting system. The life cycle of Project A has four phases: define, design, develop, and deploy. The define phase requires identifying and documenting the requirements; design, building the overall architecture of the accounting system; develop, turning the architectural design into something tangible, such as a software code; and deploy, testing the components and deploying the system into the customer’s environment. These phases can occur concurrently or sequentially, depending on the methodology used to build the accounting system. For purposes of understanding, assume that all phases occur sequentially; that is, one phase completes and then the next one can begin.

The project manager applies the PM processes for the overall project. She leads by taking the initiative to identify all the key stakeholders with the help of the project sponsor. If not developed yet, the project manager drafts the charter and, with the approval of the sponsor, solicits the input from important stakeholders and prepares the document. If the project manager must draft the charter, she will ideally have some prior information, such as a business case, memoranda, reports, studies, and lessons learned to prepare the draft. If not, then the project manager will have to rely totally on input from the stakeholders. The project manager then facilitates, unless the sponsor elects to do so, one or more sessions to come up with a charter.

With the charter complete, the project manager has a core group of people assigned to her to help develop the plans for the project. These plans, depending on the scale, complexity, and visibility of the project, serve as the basis for managing a project. The core team should start, using the charter, to develop a WBS, which serves as the scope for the project but also as a means to develop cost and schedule plans, too.

With the WBS complete, the project manager works with the core team and other stakeholders deemed interested in the project to determine time estimates for each of the activities identified in the lowest level of the WBS. The time estimates are preliminary at this stage and a host of different approaches may be used to make the estimates. The project manager and the core team also determine the resources requirements, which will help to determine the people with the requisite knowledge, expertise, experience, and quantity to perform each activity. In some cases, the project manager and the core team may determine nonlabor needs to perform an activity.

After identifying time estimates and resource requirements, the project manager and the core team can begin to construct a schedule. Again, remember that all this work is still preliminary. The project manager and core team take the lowest-level activities identified in the WBS and logically tie them together, forming a network diagram. Then they apply the estimates to the activities, converting the estimates into durations. Next, they calculate the early start and finish dates followed by the late start and finish dates. The calculation then reveals what is known as the critical path, that is, the activities that cannot slide or there will be a subsequent impact on the critical path. The project manager and the core team will likely have to make several alterations to the schedule to ensure that the work to complete is practical within the time available for completion. The detail schedule provides the basis to develop what are known as a roll-up, or summary, schedule, such as bar charts and milestone charts.

It is at this point in time that costs are prepared for the project. These costs include both labor and nonlabor resources as well as any overhead costs, such as ones related to facilities and training, being apportioned among activities in the project. The costs will determine the budget for the project.

Another important planning exercise for the project is determining the risks. (A risk is something that potentially can occur in the future; an issue is something that already exists.) The project manager and the core team hold a session to conduct risk management. This exercise involves identifying risks, determining their likelihood or probability of occurrence and their impacts, and the potential strategies and actions to take if a risk occurs. Risk management is visited from time to time on the project to determine its validity and reliability under changing circumstances.

Still another important planning output is the communication management plan. The communication management plan enables providing the right information to the right people or organizations at the right time in the right amount. The first prerequisite for putting together a communication management plan is, of course, to identify the primary stakeholders on the project. Using that information the project manager identifies who needs what information and how much, when, where, and why. This plan is often captured in a matrix and is updated periodically because stakeholders and their requirements change from time to time.

With the cost, schedule, and scope defined for the project in the charter, the project manager can now present the plans to the project sponsor or a steering committee to receive buy-in prior to beginning work.

If the sponsor or steering committee approves the plan, the project manager can then, barring no major revisions, create three baselines: one for the scope, one for the costs, and one for the schedule. Any changes to any of them could have a significant impact on the other; therefore, it is important to have all three under configuration management and any changes should proceed through change management prior to implementation.

As the planning comes to completion the project manager along with the project sponsor may start procuring the necessary labor and nonlabor resources. This effort will ensure that the request for people, equipment, supplies, and so on satisfies any lead time requirements to procuring resources before relevant activities start. The lack of available resources can cause a serious delay in progress. These lead times should appear in the schedule to ensure visibility of their impact should the resources fail to arrive on time.

Often occurring concurrently with the planning process during the define phase of the project is putting together a supporting infrastructure that was discussed earlier about the organizing process. During this period, the project manager, in concert with the core team and selected stakeholders, lays the groundwork to manage the project. The deliverables created at this point in time in the life cycle include creating formats for reports and forms to manage the project; preparing an organization chart; defining roles, responsibilities, and authorities; selecting software tools; and preparing one or more documents describing some of the administrative processes for managing a project. Some topics discussed in these documents include configuration management, change management, risk management, scheduling, reporting, quality management, personnel management, procurement management, and communication management. Depending on the scale, complexity, and visibility of the project, these documents can be created as one entire plan with each one being a separate document.

During the design, develop, and deploy phases of the project, the same PM processes may be applied but usually from a revision perspective. All PM deliverables and processes are subject to revision by applying change management. Rarely does a project occur according to plan; circumstances change and problems are uncovered by the team or the customer. However, any change needs to be controlled to ensure that scope creep, the gradual unauthorized expansion of what is expected by the customer, does not become a reality. Scope creep can wreak havoc on a project, eating away at the schedule and budget while simultaneously causing expansion of the scope. The key is to manage change and not let change manage you. The executing process becomes, therefore, the most critical one during the remaining phases.

Many reasons exist as to why people want to circumvent change management. They may want to please the customer. They may not want to wade through the administrative process often associated with change management. They may want to get an unpleasant activity out of the way and make changes without dealing with anyone. Whatever the reason, project managers must insist on using change management to ensure the integrity of the product or service being delivered to the customer and to preserve the performance measurement baseline for accurate reporting.

During the remaining phases, the project manager during the executing process performs monitoring and controlling. This action requires collecting data and information about the technical and business performance of the project. Data and information are used to assess and evaluate performance and then decide to proceed with the status quo, take corrective action, or replan. When collecting data and information, the data and information should be scrubbed for validity and reliability and then used to generate a series of reports regarding performance. These reports usually are identified in the communication management plan and are distributed accordingly.

The closing process is also important. One of the most important deliverables is creating a lessons learned document. This document provides essential information about what went well during the project and the areas needing improvement. It also captures information on recommendations for improvement. The lessons learned document serves many purposes, but two significant ones are that it serves as a debriefing opportunity among stakeholders and that it provides valuable information about the project to stakeholders of future projects of a similar nature. The project managers of future projects can capitalize on what went well and leverage this information and data to avoid problems and overcome challenges. Lessons learned documents can be developed during the end of each phase and compiled at the end. This approach works best for large, lengthy, complex projects because explicit and tacit knowledge contributing to the content of the document may be lost due to forgetfulness by stakeholders or turnover of people.

Of course, closing involves more than preparing a lessons learned document. It also includes concluding contracts, shoring up financial obligations, and archiving data and information. This action is often overlooked because many people are glad the project is complete; it seems anticlimatic; and has a bureaucratic flavor to it. Yet, closing is very important because it helps avoid or prepare for legal complications, eases the effort and pain associated with audits, and provides a useful database for future projects. As with the lessons learned document, these actions can occur during the end of each phase as well as at the end of the project.

3.7 How Much Project Management Is Enough?

Unfortunately, a judgment call is required to answer the above question and it is not solely made by the project manager. He works with the participation of the stakeholders including the sponsor and the team to help make that decision. However, there are some heuristics, or rules of thumb, to consider when making this decision.

Maturity in PM is one heuristic. Have stakeholders had the necessary training and experience to understand the purposes and under what circumstances to use the tools and techniques of PM? Usually the less knowledge and experience of PM, the more difficult it becomes to manage large complex projects. Smaller projects, depending how that is defined within organizations, may require what has been euphemistically defined as PM lite, whereby the requirements for applying PM concepts, tools, and techniques are less robust than for larger ones.

The existence of a PM framework or methodology coupled with supporting processes and systems within an organization is a heuristic. Usually mature organizations have some framework or methodology to manage projects; ones not as mature will likely operate in a less formal manner. If a framework or methodology is available, then use it. If none exists, PM will often be necessary to instill confidence among stakeholders in the project team. However, keep in mind that more is not necessarily better. Too much PM can cause pushback from some stakeholders and will likely require management support. In some environments, project management is viewed as an inhibitor to creativity and productivity. The key is to tailor the concepts, tools, and techniques to the environment.

The visibility of a project is another important heuristic. Regardless of size or complexity, formal PM disciplines are often preferable over less formal ones. The reasons are that executive leadership will have a greater confidence in knowing how well the project is going and will feel more comfortable in the status information they receive. The biggest challenge in this respect is that some executives may find PM too bureaucratic due to a lack of understanding of the topic. They may agree with comments such as the PM is interfering with the “real work” to get done. The danger is that if such an attitude prevails and the project does not meet expectations, the project manager is usually held responsible.

Again, if a project manager and the team have to determine the degree of PM, it is best to err on more, not less, and formal, not informal, application. Then through trial and error review with stakeholders the degree of application can be adjusted to a scale more suitable to the stakeholders.

3.8 Enterprise Project Management

In recent years, public and private organizations have seen the value of applying PM on individual projects of all scales. Increasingly, these organizations have looked at applying PM not on a project-by-project basis but organization-wide. Enterprise project management, or EPM, is the means to do just that.

EPM requires taking a macro view of an enterprise by requiring projects to follow a systematic approach toward ensuring that projects use a common set of tools and techniques, for example, rather than each project operating on its own and being eclectic in application. Some elements of EPM include ensuring that all projects have some business justification, such as furthering the strategic goals of the organization, following a standard approach and toolset and techniques, enhancing employee knowledge and education of the discipline, seeking continuous improvement in applying PM and sharing best practices, and encouraging and sustaining communication among stakeholders.

If a project is large enough, perhaps even at the scale of a program, then it may have a project management office, or PMO. This office supports the project manager by providing PM expertise with a variety of tools and techniques. A PMO is usually staffed with people having experience and expertise in project management and who possess a holistic perspective about the project and PM. The PMO can concentrate solely on one, more, or all of these activities: collecting and reporting status; providing tools and templates; training people; sharing project management expertise; identifying and communicating about best practices; defining roles, responsibilities, and authorities; and applying efficient and effective resource utilization. Depending on the scale of a project, a small one may simply include a PM assistant and a scheduler. On large projects and programs, a PMO may have a staff of five to seven people who include one or more PM assistants, schedulers, facilitators, and project managers. At the more strategic level of an organization, a PMO can exist that provides many services at a high level. Then other project PMOs can cascade that knowledge and expertise down to their respective projects.

3.9 Project Management Is Necessary

PM is absolutely critical to the success of Lean projects. Lean projects suffer from many of the similar problems, challenges, and risks on other kinds of projects when PM is not applied effectively or not applied at all. It is imperative for any project, regardless of industry, to apply the discipline of PM to their Lean projects if they hope to improve their value streams and satisfy customers efficiently and effectively. To achieve that, a project manager needs to exercise the fundamental actions described above for the overall project and within each phase. In some cases, project managers may have to determine and tailor PM on their projects, whereas others may simply follow a standard set of practices identified by a PMO at the project or even enterprise level.