Chapter 9: Lean Project Planning

Introduction to Lean Planning

Planning is defining the steps and the resources required to achieve a desired outcome.

The lean project itself is a plan to create net value for the customer and the other stakeholders. Lean planning is not a separate phase of the project cycle, but takes place in each phase, as part of the PDCA cycles. In terms of the flow of value, the project plan is a design of the project value stream.

The primary purpose of lean project planning is to enable the achievement of project objectives by informing decision making and defining the means and actions. Planning reduces uncertainty, establishes trust and facilitates a reliable flow of value. Plans are means of transparency, collaboration, alignment, direction and coordination.

Planning is often seen as the dividing line between traditional project management and Agile. But there is nothing wrong with considering project management as plan-driven. Regarding planning, the difference between the “traditional plan-driven” and the “agile-driven” project management isn’t the presence or absence of a plan. The major difference is that traditional planning is more “predictive” than adaptive, while Lean-Agile planning is more adaptive rather than predictive, and it’s generally more intense. “Predictive” planning tries to plan the unknowable, which is both wasteful in itself and causes waste. Adaptive planning plans how to make unknowable knowable and thus effectively increases predictability.

Each lean project plan is a combination of a plan to execute and a plan to experiment and validate. A plan to execute can work for what’s known, while a plan to experiment and validate should aim at acquiring knowledge and reducing risk of what’s unknown. The right proportion between the two depends on the specific circumstances, but the mental setting of the team should be that each project is a hypothesis that they need to prove empirically.

Lean acknowledges that results are not completely knowable in advance, and planning must be adaptive. The value of a plan is perishable and may change because of:

• New knowledge gained about customer value, stakeholders’ expectations, requirements, deliverables, creation process, technologies, project team, risks and assumptions
• Empirical evidence about team’s productivity
• Stakeholder feedback on deliverables increments
• Changes in project environment
• Revised estimates and forecast of project’s net benefit
• Any discoveries and new information that affect the project

Re-planning shouldn’t aim to bring the project back to the baseline plan but needs to be informed by project objectives and the Conditions of Satisfaction.

Some major differences between traditional and lean project planning are summarized in the table below.

In the following sections, we’ll define the principles of lean project planning.

Planning and plans are necessary for the people involved in projects. That's why, to define the planning principles, we need to look at how projects work from a social point of view.

It’s often said that for a project to be successful, a common goal must unite project participants. That’s true, but it would be simplistic to presume that this common goal should be to create value for the customer. In fact, for a project to be successful, each actor must profit from it, and thus the actors become each other's customers.

The benefit that everyone wants to receive is expressed in expectations to be realized both through their own actions and through the actions of others. People seek to secure the actions of others by gaining their commitment [1]. The actors engage in conversation, discussions and negotiations that result in a network of agreements (NOA) between them. These are formal and informal, conscious and unconscious arrangements.

In these agreements, rights take the form of expectations and obligations take the form of voluntary commitments to undertake certain actions or provide something. In doing so, the expectations of one party become the commitments of the other party and vice versa. Each actor becomes part of different bilateral and multilateral agreements, in which they play both the role of a customer (through expectations) and the role of a performer (through commitments).

The network of agreements is a system that evolves, and we must balance it to ensure coordinated actions between the parties and project success. The following is required for the balance:

• Harmony between the interests of all parties involved and collaborative behavior; relational agreements that prevent local optimization (relational contracts)
• Shared understanding and alignment – clear, realistic and acceptable expectations and commitments that others understand well
• Trust between the participants that the commitments will be fulfilled
• Correspondence between all expectations and all commitments (to meet expectations with commitments and commitments to match expectations)
• Common understanding of the uncertainties associated with the realization of expectations and commitments
• Common agreement and understanding of the decision-making principles in the project
• Continuous evolution and rebalancing of the system

As the balanced NOA includes both the ends and the means of the project in their entirety, hence the first principle of lean project planning is as follows (numbering of principles is only for convenience and doesn’t show their relative importance):

Only through the NOA can we do something meaningful in a project. Project plans that are not part of the NOA bring disharmony. It follows that every plan in the project must become part of the NOA. The plan should be a tool for meeting expectations by making and realizing commitments. Therefore, the plan should be an agreement. Making commitment doesn’t imply that the probability of its fulfillment is 100% percent (although this should be one’s idealistic aspiration). The probability varies for specific plans and circumstances, but the parties must understand and accept it. Here we come to the second principle:

Viable agreements require high trust between the parties. Trust depends on building positive and open relationships, and on adhering to commitments based on reliable planning. Because of the great importance of trust, we have a specific principle for it:

The NOA is a dynamic system that is constantly changing and needs rebalancing. Sources of change can be:

• Subjective (internally-motivated) change in the expectations or commitments of the stakeholders
• New information, knowledge or circumstances that affect expectations or commitments or actors’ ability to realize them
• Feedback on project performance and the agreed improvement actions

The dynamic rebalancing of the evolving NOA system is an act of adaptive and continuous planning. We can achieve continuity through periodic planning on a cadence, complemented by ad hoc, on-demand planning, as the unbalancing does not happen in periodic steps.

So far, we have defined five principles of lean project planning. Let's continue with other perspectives on planning to look for more principles.

PDCA Cycle and Planning

In the Initiation-Planning-Execution-Closing cycle of traditional project management, the important component of learning and improvement is missing. Thus, planning itself is also not subject to systematic improvement.

In lean project management, we should view planning as part of the Plan-Do-Check-Act (PDCA) cycle through which we realize the project objectives.

• Plan: planning how to carry out the planning process
• Do: performing planning
• Check: checking the quality of planning
• Act/Adjust: learning and improvement of the four planning processes (plan planning, do planning, check planning, adjust planning)

This is an example of continuous improvement of planning [2]:

• Determine the percentage of completed activities from the total number of planned activities over a given period (Percent Plan Complete – PPC). PPC measures plan reliability.
• Identify causes for noncompletion.
•  Act – remove the causes to improve planning and aim to increase PPC.

Here is how we can improve plan value and reliability:

• Perform continuous estimating and planning
• Assess the plan’s value and reliability on a cadence
• Actively remove constraints to the workflow to improve plan reliability
• Learn and adapt to improve plan value and reliability

The project plan must ensure that we achieve the best outcome within the existing constraints. Constraints are set by external circumstances, third parties, the customer or other stakeholders. Let's look at how constraints affect planning and how to set constraints which are under the direct control of the customer and the project team.

There can be many constraints in a project, but the common ones are time, cost, scope and, to some extent, quality. For some types of projects, regulations and location are also very important.

Besides the legal factors, probably the only constraint that we should consider fixed by default is the minimum required profitability of the project. Without achieving it, the project makes little sense. Conditions of Satisfaction follow next, but they are negotiable.

Traditional project management assumes that, through proper upfront planning, we can precisely define the project scope and we may not need to change it. In turn, the fixed scope makes it possible to assess and fix time and cost within tight tolerances. It turns out, however, that projects can rarely be completed within a fixed scope, time and cost. Instead of over-constraining, we need flexibility in one or more of these variables.

Fixing scope

We can define project scope as the configuration of project deliverables with their features, functions and relationships. As the primary consideration for the scope is benefit and cost, it should be quite normal that it varies to improve the outcome.

Typically, we can achieve project objectives through an unlimited number of alternative scope configurations. Fixing one of all possible configurations means that we consider it to be complete and the best one at the outset of the project. This is equivalent to accepting that a hypothesis needs no proof or deciding with incomplete information. Therefore, we don't recommend fixing the scope. Instead, we might consider certain range limits of scope, based on experience with similar projects.

The progressive detailing, narrowing, prioritizing and improving of the scope begins with the choice of project approach, goes through different stages as, for example, a choice of design option, and goes on until the very end of the project.

Fixing scope often results in including items that are not absolutely necessary. A better solution might be to leave open the possibility to prioritize scope items within the other project constraints. The Minimum Viable Project (and the Minimum Viable Scope respectively) is also a good approach to prevent fixing a scope that is too large.

Fixing time

From a practical point of view, we will always have some kind of time limit. Projects don't go on indefinitely.

Apart from regulatory requirements, the primary rationale for limiting time should be the cost of time.

Another aim for fixing time along with cost might be to ensure that we complete high-value work by a fixed date when we correctly prioritize scope items.    

A third reason for fixing time might be to foster innovation, when we set a stretch goal for cycle time improvement.

Fixing costs

We must always consider the total life cycle costs of the project and the expected benefit-cost ratio. From a customer’s perspective, operation, maintenance and business costs are expected to be financed from the revenue, and a constraint usually applies to investment costs. The limits depend on the customer’s available funds (there is always some limitation) and the amount they are prepared to invest (the target cost).

When the customer sets a target cost, the project team should aim to optimize the configuration of scope, time, quality and recurrent costs to maximize the return. Therefore, constraining the costs is a valid approach, unless the target cost doesn’t accomplish a minimum viable project.

Setting the target cost below the industry benchmark to spur innovation might also be considered.

Planning Items

Planning items provide guidance for executing the project. The project scope is translated into planning items such as milestones, stages, iterations, user stories, features and tasks, and dependencies between them. In turn, the planning items drive resource requirements and cost and time estimates that provide feedback for refining the scope (see more about estimating).

Milestones are the backbone of the overall project schedule. These are events that mark significant stages in the project's progress and facilitate flow – key decisions, deliverables, handoffs, and coordination and integration points that release subsequent major stages of work.

Milestones aggregate individual activities and are more reliable than them, as they pool variability from independent sources.

The project team’s common understanding of these key events informs the project's conceptual plan.

Stages are common building blocks of the non-iterative evolutionary life cycle. Stage planning is the first (macro) level of detailing the plan in terms of the local (stage level) milestones, tasks, dependencies, sequence, and priorities. The next level of increasing detail could be the regular look-ahead planning that also emphasizes making tasks ready for execution and removing constraints.

Iterations

These are the key components of the iterative life cycle. Iteration is a time-boxed PDCA work cycle aimed at creating an increment of project assets that can be absorbed into the customer’s value stream. If absorbed, we expect the increment to improve the capability of the value stream which would generate incremental value.

Features and Stories

Features and stories are product backlog items used in iterative development.

Features are higher-level product attributes which can be decomposed to become user stories – small slices of user functionality described from an end-user perspective. Upon completion, the user stories selected for the iteration add value to the product increment. When user stories are clear, self-contained, with limited dependencies and achievable within a single iteration, they can be a very effective means for planning and executing work.

We can use a completed user story as a proxy measure of generated customer value, and thus it’s a more relevant planning item than tasks. The actual value will depend on whether the customer will use the feature and whether this will bring the expected positive effects.

Tasks are the lower level and most detailed items of planning. They can give the most precise guidance for performing the work. Completing tasks doesn’t create value in itself, and we must pay special attention to task relevance.

We need to plan four types of project tasks:

1) Creation tasks

These are the workflow tasks for creating project assets, which include value-added tasks of transforming inputs into outputs, and non-value-added tasks such as inspection and transportation.

2) Absorption tasks

By absorption, we mean fully integrating the assets created by the project into the customer’s value stream. By using "absorption", we emphasize the need for the project assets to gradually become an integral and natural part of the value stream, creating an improved whole.

The absorption activities have to start at the beginning of the project and continue until its end. We should not plan them as a major effort at the end (or after the end) of the project.

Absorption tasks need to be planned and performed by the integrated project team, including the development team and the customer value stream team.

The change in the value stream begins with the creation of a vision of a new reality, according to which value stream team members change their mindset and mentally transform their way of working. In this way, absorption begins mentally, even before the actual asset creation has begun.

Then, before the team completes the assets, the material absorption activities may include, for example:

• Training and educating value stream team members
• Developing operating procedures
• Preparing infrastructure, equipment, premises and other aspects of the production, operating and support environment
• Hiring and onboarding people
• User testing

The aim is that when the assets are completed, all conditions for their integration are met and all obstacles are removed.

When the assets are created, the absorption continues with testing in a production environment (or equivalent), including beta testing, until all problems are eliminated and the value stream is effectively improved.

3) Preparatory tasks

These are the tasks to make the creation and absorption tasks ready for execution.

For instance, for the execution of a construction task, at least seven prerequisites (or conditions) are needed [3]:

• Construction design
• Components and materials
• Workers
• Equipment
• Space
• Connecting works (prerequisite activities)
• External physical conditions

Typical prerequisites are clarity of work requirements, availability of resources and information, prerequisite work, approvals and decisions. Absorption readiness and capacity of customer value stream are specific prerequisites for absorption tasks. The preparatory tasks provide the conditions for executing creation and absorption tasks by removing constraints.

The make-ready process transforms work that SHOULD be done into work that CAN be done. [4]

4) Management tasks

These are the planning, organizing, leading and controlling tasks, related to the plan-do-check-act loops of creation management, flow management and value generation management.

This brings us to the next principle:

Plans to execute or to experiment should pursue a reliable project workflow. Workflow reliability affects cycle time, quality and cost of projects. Quality and cycle time affect cost and benefits. Thus, workflow reliability affects project success.

Reliable workflow needs a reliable plan. A reliable plan is one that is executed with minimal deviation. 100% reliability is difficult to achieve as no plan is perfect and there is no theoretically perfect plan, but such must be the idealistic goal of continuously improving planning reliability.

Besides team planning skills and the quality of planning, plan reliability depends on several factors:

• Planning horizon
• Level of detail
• Project and process uncertainty
• Make-ready process
• Pull or Push planning

Figure 9.1: Project Plan Reliability

The reliability of the plan decreases as the planning horizon expands and details increase. Therefore, we must balance the detail with time. In Reinertsen's words, “the most powerful way to reduce variability in forecasts is to shorten our planning horizons” [5].

Besides the uncertainty of the project as a whole, the reliability of the plan is affected by the nature of the workflow processes. It might be easier to plan to execute than to plan to experiment. Often, we can plan execution processes (e.g., construction) more reliably than exploratory and generative processes (e.g., design).

Successful project performance requires a certain level of detail of the plan, which we need to balance with the planning horizon. We must balance the greater project and process uncertainty with a further shortening of the planning horizon – up to the extremity of continuous planning.

We achieve balancing with multi-level, just-in-time planning, where we combine the shortening of the planning horizon with increasing detail and vice versa.

A proactive make-ready process is crucial, to remove impediments and to prepare sound (execution-ready) assignments that can become a part of lowest-level plans.

Pull planning increases reliability as it helps to make commitment plans only for assignments ready for execution, and the team has the capacity to perform.

The output of the planning at each level is the design of the process of creation and absorption with increasing detail, including work methods, workflow steps, dependencies, human capabilities and effort, equipment, tools, materials, prerequisites, assumptions and risks.

We already included pull planning in the third principle, and this is what the wording of the eighth principle looks like:

Let’s look at specific models of multi-level planning.

Agile planning has five levels: two portfolio level - Product Vision and Roadmap and three project level plans - Release Plan, Iteration Plan and Daily Plan.

• The Release Plan is a long-term plan that sets the general framework of scope (which products or features will be delivered), time (the delivery schedule) and cost. The plan items are features and user stories which the team estimates in story points or ideal time. The team organizes the release plan in iterations to which they add user stories.
• Iteration planning refines and adjusts the iteration components of the Release Plan.  The planning items of the Iteration Plan are the user stories that the team commits to for the upcoming iteration. The team calculates their capacity for the iteration, reviews, refines and estimates the stories from the team backlog, elaborates acceptance criteria and selects prioritized stories for the iteration backlog until they run out of capacity. Iteration planning may involve breaking down user stories into specific tasks.
• The Daily Plan is a refinement and adjustment of the Iteration Plan. At the daily coordination and planning meetings, each team member reports what they did yesterday, what they’ll do today, and what obstacles are hindering the progress. Team members work together to remove blockers and impediments.

As we can see, this model balances the planning horizon with the level of detail and ensures effective pull and commitment by the team. It may be useful to have a greater focus on making user stories/tasks ready for execution and on proactively removing obstacles in advance.

The lean construction model of planning has also three levels: Initial Planning, Lookahead Planning and Commitment Planning [6]:

• The Initial Planning pushes completions and deliveries onto the project through the project budget and schedule it produces (what should be done).
• Lookahead Planning details and adjusts initial schedules and budgets matching resource demand and supply (what can be done). The activities in the lookahead schedule are screened to start a make-ready process to prepare sound (execution-ready) assignments. The output of this process is a buffer (a backlog) of sound assignments, from which to pull assignments for the commitment plans. The typical time horizon of the lookahead planning is 4-6 weeks. When multiple teams are involved, lookahead planning helps to coordinate them by planning and handling their dependencies.
• When resources are actually received and prerequisites are completed, the Commitment Planning establishes what will be done (the commitment). Most often, the commitment plan is a weekly work plan and its assignments must meet the criteria for soundness, sizing, and sequence. The commitment plan is a foundation for continuous improvement. To improve productivity and increase workflow reliability, after the team completes the plan, they calculate a Percent Plan Complete (PPC) as a ratio between the number of completed assignments and the total number of assignments for each week. Reasons for noncompletion are identified and acted upon and the aim is to increase the quality of planning as measured by PPC.
• The three levels of planning are complemented by Methods Planning, which specifies the methods of doing the work with an increasing detail at each subsequent level of planning.

The gap between what should be and what will be done shows that we can implement the principles of commitment and pull planning to the greatest extent at the lowest level of planning, when the people closest to the work plan for the imminent future.

Planning and control are interrelated and meaningless without each other. Planning sets goals and the course of action to achieve them and control ensures that goals are achieved. Control provides feedback to planning so we can adjust it. Therefore, we must plan with control in mind.

Unlike the thermostat model, lean project control is not just about monitoring progress against the plan, identifying variations and applying corrective action as needed.

The lean control system [7] aims to “cause events to conform to plan, or to identify as early as practical the need for replanning” (Ballard) in sharp contrast to the traditional project control that tries to bring the performance back to the plan, following after-the-fact detection of variances. [8]

Lauri Koskela proposes five principles of a lean control system [9] [10]:

1. To minimize the work in suboptimal conditions, the assignments should be sound with regard to meeting all prerequisites for their completion.
2. Percent Plan Complete (PPC) is used to measure and monitor the realization of assignments. The focus is on plan realization to reduce the risk of variability propagation to downstream steps.
3. Causes for noncompletion are systematically investigated and removed and thus continuous improvement is realized.
4. A buffer of sound tasks is maintained for each team, to avoid lost production due to starvation, or reduced productivity due to suboptimal conditions.
5. The prerequisites of upcoming assignments are actively made ready in lookahead planning to ensure that all the prerequisites are available and to avoid accumulating a buffer inventory that is too large.

Although designed for construction, these principles can be a good basis for creating a lean control system for a wide range of projects.

We can summarize the relationship between planning and control with the ninth principle of planning.

Customers pull value, says the popular lean principle.

The ultimate customer (or the customer avatar in a startup project) pulls a project that will generate net value. The pull is the basis for defining the main project variables, such as expected benefits and costs, lead time, scope and quality.

This pull, however, rarely works automatically like in a supermarket where customers can pull any product sold there. It works when there is an agreement between the customer and the project team (actually, a customer-performer agreement within the integrated project team). When we consider all people expecting to benefit from the project, we can say that the project is pulled by the network of customer-performer agreements between the stakeholders.

“The next process is your customer.”
- Kaoru Ishikawa

Within the team, there are similar customer-performer arrangements between the upstream and the downstream sub-teams. The sub-teams responsible for the downstream processes (process customers) pull the work from the upstream processes.

Note, however, that the workflow isn’t strictly unidirectional and the work and information move back and forth with the process customer and the performer exchanging roles.

As in rugby, the team goes the distance “as a unit, passing the ball back and forth” [11].

Figure 9.2: Customer Pull and Customer-Performer Agreements [12]

The team needs to understand the value for the end customer and they have to agree about expectations and delivery. Then, the team plans backwards how to create the value.

The process customer sets requirements and expectations for the upstream process (pull), which are subject to negotiations with the performer. Negotiations result in an agreement and commitment from the performer. The commitment must be also an act of pulling from the work backlog because the performer should commit only to meaningful work that will be done. That is, only to sound assignments (i.e., meeting all prerequisites for their completion) that don’t exceed performer’s capacity and whose completion is expected by the downstream process customer.

When the performer completes the agreed work and delivers the outcome to the process customer, new work is released that can be completed to satisfy the pull by the next downstream process. The current customer becomes a performer for the next process customer. A Work in Progress limit will prevent pushing work down the process.

The role of the process customer is to:

• set their requirements and expectations
• negotiate the work to be completed with the performer
• collaborate and help the performer
• provide continuous feedback on the completed work
• check and accept the work
• work with the performer and other team members to identify causes for noncompletion and for other issues and act on them

The performer should:

• understand customer’s requirements, expectations and conditions of satisfaction
• negotiate the work to be completed with the process customer and commit only to sound and required assignments within performer’s capacity (the required work that will be done)
• complete the work as agreed and seek continuous feedback from the customer
• deliver the outcome and if necessary, rework until the customer is satisfied (until the conditions of satisfaction are fulfilled)
• work with the process customer and other team members to identify causes for noncompletion and for other issues and act on them

The customer-performer relationships should not become a means of alienating team members. They must be only an aspect of the continuous collaboration between the members of the integrated team which has collective accountability for the outcome. This collaboration requires intensive, open and, as far as possible, informal, synchronous and face-to-face communication. Formal hand-overs should be minimized.

Push Planning

When work is set up on forecast rather than on actual demand, this is a "push" method. It aims to ensure completion of work based upon top-down planning and an order from an authority. Resources and information are released according to plan, regardless of whether the downstream process is ready to use them. [13]

Traditionally, the plan is prepared by a small group of people, then sent for feedback to the team. Feedback is usually limited to the scope of work of the team member or sub-team. Then the plan is finalized, and the team is expected to follow it. Regardless of whether such a plan is made with backwards scheduling, it’s still a push plan.

Push planning assumes that once a sound and detailed project plan is prepared, it could be dispatched to the team and this will ensure its implementation. The plan is considered a commitment. If deviations are detected, corrective measures may be applied, so that performance meets the plan. If the plan is found to be inadequate, it can be revised and a new baseline can be created to push further work. Implementing the push plan is driven by the actual activities of the first and the next performers, and often the plan gets quickly outdated.

This planning often uses complicated scheduling tools and seeks to anticipate all the details at the outset of the project, including start and end dates, relationships and lag times, to name a few. But push planning is used with multilevel planning, too. Although this improves the reliability of the lower levels of planning, the plan is still about what should be done and the team is expected to follow it, no matter what the state of the system is.

Push plans often lack team buy-in and ownership and support silo mentality.

If work is released and performed when the system is ready to use it, this is a "pull" method. The customer signals that the work is needed and pulls it from the performer. [14]

Effective pull planning itself involves several factors that improve reliability.

The pull planning organizes activities based on the needs of the downstream steps and takes into account what the state of the system is:

• if the process customer needs and is ready to use the outcome of the work
• what are their conditions of satisfaction with the work
• whether all conditions to perform the work are fulfilled/constraints are removed
• if the resource demand for the work matches the supply

Pull planning works best when the team is actively working to achieve the desired state of the system. Thus, effective pull planning facilitates lean control that causes performance to conform to plan and ensures early detection of any need for replanning.

We can assess the state of the system with greater accuracy for a shorter future period. Therefore, in multi-level planning, the ability to use pull increases as the implementation period approaches. For instance, the lookahead plan as described above is a pull plan, but the weekly pull plan is the one by which the team makes a firm commitment.

Pull planning is a collaborative effort of the integrated team across the value stream, including those closest to the work. It breaks silos and ensures plan ownership.

When used effectively, pull planning increases the project’s net value by:

• creating what’s valued with the expected quality
• improving team productivity as the tasks are performed in correct sequence and the constraints to their completion are proactively being removed 
• improving plan predictability as the commitment is made in front of the other team members and accounts for the customer expectations, soundness of the tasks and the work capacity 
• eliminating non-value-added steps, optimizing workflow and shortening cycle time
•  facilitating lean control and continuous improvement

Lean project planning differs from the traditional planning in that it:

• Considers the project plan a design of the means, resources, and actions to create net value for project stakeholders
• Applies learning and adapting mindset
• Shifts the focus from upfront to just-in-time planning and planning is adaptive and evolutionary
• Requirements are progressively elaborated and the deliverables are evolving
• Uses the plan baseline to measure plan reliability, but project performance measurement is value-driven
• Is highly visible and transparent, collaborative and decentralized
• Decouples estimates and commitments
• Is based on customer pull

Use the following principles for lean project planning guidance:

1. Creating agreements between project participants is a planning process, and the evolving network of agreements is the ultimate project plan.
2. Turn all project plans into viable agreements with acknowledged uncertainty.
3. Sound plans require decentralized, collaborative, consensual pull planning with active involvement of the people closest to work.
4. Planning and plans must build trust.
5. Plan adaptively and continuously.
6. Continuously improve planning.
7. Plan creation, absorption, preparatory and management tasks.
8. Perform multi-level, just-in-time planning and proactive make-ready process to improve planning reliability.
9. Plan with lean control in mind.

_______________

[1] We prefer to use commitment rather than promise, because it implies a dedication to act, not just a declaration or assurance. 

[2] Ballard, Glenn (2000). The Last Planner System of production control, PhD thesis, University of Birmingham, Birmingham, UK 

[3] Koskela, Lauri (1999). “Management of Production in Construction: A Theoretical View”. Proceedings of the 7th Annual Conference of the International Group for Lean Construction, University of California, Berkeley, CA

[4] Ballard, Glenn (2000). The Last Planner System of production control, PhD thesis, University of Birmingham, Birmingham, UK

[5] Reinertsen, Donald G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing 

[6] Ballard, Glenn and Howell, Gregory (1998). “Shielding Production: An Essential Step in Production Control.” Journal of Construction Engineering and Management, Vol. 124 No. 1, American Society of Civil Engineers, New York

[7] This lean control system can be considered an extension of the lean construction planning model described above.

[8] Ballard, Glenn (2000). The Last Planner System of production control, PhD thesis, University of Birmingham, Birmingham, UK

[9] Koskela talks about production control in construction as he views construction as a production system, but in our opinion, the principles can be generalized for lean project control.

[10] Koskela, Lauri (1999). “Management of Production in Construction: A Theoretical View”. Proceedings of the 7th Annual Conference of the International Group for Lean Construction, University of California, Berkeley, CA

[11] Takeuchi, H; Nonaka, I (1986). "The New New Product Development Game". Harvard Business Review (January): hbr.org/1986/01/the-new-new-product-development-game (last accessed 2022-10-20)

[12] Here's what Nigel Thurlow had to say about this figure in a LinkedIn comment on July 30, 2024: "Imagine mapping this with Team Topologies of UnFix type team structures. That could be fun and useful."

[13] Lean Construction Institute, Glossary: https://leanconstruction.org/pages/learning/education/glossary/#p (last accessed 2022-10-20)

[14] Ibid. (last accessed 2022-10-20)