Skip to main content
Business LibreTexts

1.1: Project Management Foundations- Principles and Practices

  • Page ID
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)

    Nothing endures but change.
    Heraclitus, 535 – 475 BC



    After reading this chapter, you will be able to

    • Define terms related to project management
    • Discuss two essential qualities of good project managers
    • Explain the difference between geometric and living order
    • Define “project outcome,” “project success,” and “sustainability” in the context of a project’s full life cycle
    • Identify four roles of a project manager
    • Provide a basic introduction to Lean, including the six principles of Lean
    • Explain fundamentals of Agile software development, including sprints and product stories

    The Big Ideas in this Lesson

    • Living order thinking recognizes that a system of things is always in the process of remaking itself, and that a system is always—at some level—in a state of uncertainty. In project management, this suggests that projects happen in dynamic environments, and that unexpected events should be considered part of the project’s life cycle. It is fundamentally adaptive.
    • Project managers traditionally idealize the more prescriptive geometric order, in which one stage necessarily leads to the next stage. It is an essential component of project management, but when relied on exclusively, geometric order thinking can lead to inefficient and ineffective results.
    • Lean thinking focuses on eliminating waste. In project management, Lean thinking provides a way to focus on the customer’s definition of value, which is the only definition that matters.

    1.1 Technical Project Management in the Modern World

    For a complete summary of the latest statistics on project management, see the Project Management Institute’s annual Pulse of the Profession report. You can read the 2018 version of the report here: PMI Pulse of the Profession 2018

    Projects are by definition ephemeral—they come and go, depending on an organization’s needs, and eventually come to a close. According to the Cambridge English Dictionary, a project is “a piece of planned work or activity that is completed over a period of time and intended to achieve a particular aim ” (2018). The fleeting nature of projects means that organizations with less than optimal project management proficiency often fail to develop systematic processes for managing them. Once a project is completed, everyone moves on, gearing up for the next, with barely a backward glance at what did and didn’t work in the old project. In other words, these organizations lack a coherent approach to project management—“the application of processes, methods, knowledge, skills, and experience to achieve the project objectives” (Association for Project Management n.d.). This lack of a systematic approach is especially problematic in technical fields, leading to an extremely high rate of failure for technical projects across many industries.

    A quick web search on the success rate for technical projects offers some eye-opening facts and figures. Depending on which study you read, projects fail at rates between 20 and 80 percent. And throwing more money at the problem doesn’t help. Indeed, the higher a project’s budget, the more likely it is to fail (Mieritz 2012). One study found that IT projects with budgets over $15 million are project management fiascos: “On average, large IT projects run 45 percent over budget and 7 percent over time” (Bloch, Blumberg and Laartz 2012). The verdict is even more sobering for industrial megaprojects—that is for industrial projects costing over $1 billion. According to Edward W. Merrow, “The oil and gas production sector fares the worst; 78 percent of megaprojects in this industrial sector are classified as failures” (2011, 49).

    How can organizations find their way out of this morass? By creating a culture of systematic, professional project management that values the skills discussed throughout this book. Research consistently shows that organizations that implement technical project management techniques and processes reap a rich reward in project successes. This book focuses on developing an approach to technical project management that is flexible, adaptable, and open to new learning. It provides many practical suggestions but does not go into specific methods in detail. For guidance on the nuts and bolts of project management see Project Management: The Managerial Process, by Erik W. Larson and Clifford Gray.

    This 2.5-minute video from the Project Management Institute describes the advantages reaped by a financial institution that created a formal Project Management Office (PMO) to manage all of its IT projects:


    A YouTube element has been excluded from this version of the text. You can view it online here:

    2015 PMO of the Year Award Winner – Navy Federal Credit Union

    1.2 Be a Hedgehog and a Fox

    Living Order, Some History

    Although Henri Bergson was the first thinker to use the term “living order,” the idea that life is a continual process of unpredictable change has ancient roots. The fragments that remain of the work of the pre-Socratic Greek philosopher, Heraclitus, provide profound insights into this idea. He famously reduced the ever-changing nature of the universe to this simple saying: “No man ever steps in the same river twice.” According to Heraclitus, nature is in a constant state of change. Indeed, change is the only constant a human can rely on. Religious thinkers have long recognized that change in our lives is inevitable and unavoidable. For instance, the idea of impermanence is a key component of Buddhism. The Bible, in Ecclesiastes 9:11 points out the futility of striving against the inevitable:

    Again I saw that under the sun the race is not to the swift, nor the battle to the strong, nor bread to the wise, nor riches to the intelligent, nor favor to those with knowledge, but time and chance overtake them all.

    As the scientific revolution took hold in Western thought, this understanding of living order went underground, only to reemerge in the work of early twentieth-century thinkers and artists like Bergson, in reaction to World War I and widespread industrialism.

    In his book Mastering the Leadership Role in Project Management: Practices that Deliver Remarkable Results, Alexander Laufer explains two essential qualities of a project manager, drawing on the hedgehog and the fox metaphor made famous by the philosopher Isaiah Berlin:

    The fox is a cunning and creative creature, able to devise a myriad of complex strategies for sneak attacks upon the hedgehog. The hedgehog is a painfully slow creature with a very simple daily agenda: searching for food and maintaining his home. Every day the fox waits for the hedgehog while planning to attack him. When the hedgehog senses the danger, he reacts in the same simple, but powerful, way every day: he rolls up into a perfect little ball with a sphere of sharp spikes pointing outward in all directions. Then the fox retreats while starting to plan his new line of attack for the next day. (Laufer 2012, 220)

    The advantage of the fox is that his complex understanding of the world allows him to try out many possibilities, adapting strategies and tactics in response to the current situation. Hedgehogs have one grand strategy that allows them to simplify all experience into “a single overall concept that unifies and guides everything they do.” As you will see in Lesson 2, where we discuss organizational strategy, the hedgehog approach is preferable when it comes to making long-term decisions about an organization’s future. But when it comes to project management, both strategies are powerful, and both can be effective, depending on your situation. Laufer argues that successful managers “behave both like hedgehogs and foxes, though they place the hedgehog in the driver’s seat.”

    Throughout this course, we will take a foxlike approach to technical project management by keeping an open mind and exploring the many lines of attack available in a particular project. But we will also place a hedgehog-like emphasis on a few basic principles—in particular the basic principles of Lean project management. At the same time, all our discussions will be informed by the distinction between the two fundamental approaches to project management: the traditional, or geometric-order approach, and the more adaptable, living-order approach.

    1.3 Two Types of Order: Living and Geometric

    In his 1907 book Creative Evolution, the French philosopher Henri Bergson investigated the nature of human creativity and its relation to order. According to Bergson, by “order” we generally mean a mechanistic, predetermined, linear relationship between things. Event A leads to Event B; Event B leads to Event C; Event C leads to Event D; and so on, with no possibility of variation or adaptation. We also tend to consider creativity as something that arises only in a state of disorder—that is, when no type of order is evident. The free-thinking artist is a stereotype founded in this way of thinking. But Bergson argued that the disorder we associate with creativity is really just a different type of order (222-224).

    Again, we turn to Alexander Laufer, who has drawn some powerful insights on project management from Bergson’s work, which he summarizes as follows:

    Bergson claimed that there is no such thing as disorder, but rather two sorts of order: geometric and living order. While in ”geometric order” Bergson related to the traditional concept of order, in ”living order” he referred to phenomena such as the creativity of an individual, a work of art, or the mess in my office. (2012, 214)

    Throughout this book we will examine and compare geometric order to living order, with a goal of developing a creative, realistic, functional approach to project management.

    Qualities of Living and Geometric Order

    In project management, geometric order aligns with traditional managerial thinking. This concept of order is associated with predictable relationships between the stages of development, such as the relationships shown in Figure 1-1, with one stage necessarily leading to the next.

    Figure 1-1: Geometric order is predictable, with one stage leading to the next

    Project managers traditionally idealize such an orderly project progression. Indeed, it is the driving force behind the process-oriented approach to project management that organizations such as the Project Management Institute tend to focus on. It is an essential component of project management, and inexperienced project managers should start by mastering a geometric approach to their work. However, when relied on exclusively, geometric order thinking can lead to inefficient and ineffective results.

    By contrast, living order thinking recognizes that a system of things is always in the process of remaking itself, and that a system is always—at some level—in a state of uncertainty. In project management, this suggests that projects happen in dynamic environments, and that unexpected events should be considered part of a complex project’s life cycle. This is something that experienced project managers learn over time. But even inexperienced project managers can try to incorporate an understanding of living order into their work.

    Figure 1-2 illustrates the characteristics of living and geometric order. Keep in mind that a project can have qualities of both.

    Figure 1-2: Characteristics of living order and geometric order

    You might be called on to use geometric order methods in one situation and living order methods in another. For example, preparing a weather forecast on a typical day in San Diego, where the weather varies little from day to day, is a geometric order task. By contrast, preparing a weather forecast for the coast of Florida with a hurricane expected to hit shore five days in the future is a living order project. Often the planning stage occurs in living order. Then, as you begin to learn more about the project and what to expect, execution proceeds in geometric order. But when something unexpected happens, you could suddenly be plunged back into living order. You have to be prepared to move back and forth among geometric and living order techniques, adapting to the situation as necessary.

    Traditional project management processes are founded on the presumption that a project can be planned down to the smallest detail, and that after the planning phase is complete, the project manager’s job is to execute the project according to that plan, without surprises. The reality of the modern world is quite different. In his 1991 book, Managing as a Performing Art: New Ideas for a World of Chaotic Change Permanent, Peter Vaill argued that today’s organizations actually operate in a state of “permanent white water.” Alexander Laufer describes Vaill’s argument as follows:

    In using the “permanent white water” metaphor, Vaill calls our attention to the fact that the external environment of contemporary projects is full of surprises, tends to produce novel problems, and is “messy” and ill-structured. (2012, 214)

    Throughout this book, we will focus on ways to manage technical projects in a permanent white-water world.

    Predicting the Unpredictable

    Geometric Order, Some History

    Geometric order is a product of the Scientific Revolution. Beginning in the mid-1500s, humans harnessed the power of systematic thought to achieve giant leaps forward in mathematics, physics, biology, and many other areas of study. Thinkers from numerous countries contributed to the advances that made modern science possible, but perhaps the most important was Isaac Newton, who modeled a universe predicated on systematic, unchanging laws whose effects could be accurately predicted by mathematical equations.

    The major human achievements of the last five centuries could not have occurred without this type of systematic thought. Modern life as we know it would not exist without it. However, as project managers, whose major concern is planning projects that take place over time, we need to understand the limits of our ability to predict the future in an ever-changing world.

    Anything that involves human beings doing anything over a period of time, with limited resources, involves a certain amount of unpredictability. This means that projects are inevitably shaped by living order. You might think that you have a good handle on what to expect from your co-workers and project stakeholders throughout the course of a project, but often the traits you might consider the most predictable turn out to be completely unreliable.

    Not too long ago, this realization shook up the field of economics, which was founded on the assumption that humans were totally predictable in their tendency to make choices that enhance their financial well-being. In his groundbreaking work in the field of behavioral economics, Richard H. Thaler demonstrated that the supposedly irrefutable idea that people act rationally in their own self-interest is debatable at best, and probably untrue (Knee 2015). And yet economists consistently refuse to take the unreliability of their basic precept into account. According to Thaler, “Economists discount any factors that would not influence the thinking of a rational person. These things are supposedly irrelevant. But unfortunately for the theory, many supposedly irrelevant factors do matter” (2015).

    Thaler goes onto argue that “unless you are Spock,” supposedly irrelevant things, such as how you feel about saving for retirement, can have far more profound effects on your economic behavior than mere self-interest (2015). Successful project managers succeed, in part, because they never ignore the power of supposedly irrelevant things to affect project outcomes. Since we can safely assume that the vast majority of your future teammates will not be Vulcans, you should probably also assume that supposedly irrelevant things will end up having unforeseen effects on the projects you manage. You never know what living order will throw your way as a project unfolds.

    That’s not to say that, as a project manager, you can dispense with the expectations of geometric order. Quite the contrary. Because this is a book on technical project management, our thinking will necessarily be concerned with geometric order. After all, technical projects involve technical products and services whose performance is governed by predictable laws. Gravity always works the same way, so engineers have to take that into account. The latest computer processors can only work so fast in today’s environment, and so software developers have to take that into account, too.

    However, you need to guard against the tendency to think that because technical products and services are themselves predictable, the projects required to produce them will be equally predictable. That is simply not the case. Because this is a book on management, an endeavor that involves people performing tasks over time, our thinking will be deeply rooted in living order.

    1.4 A Project’s Life Cycle and Living Order

    When you open your eyes to the ever-changing nature of living order, you can begin to appreciate the potential for change inherent throughout a project’s life cycle. The same is true for the result of a project—whether that’s a building, a new smartphone, or software for farm machinery. The product, or result, of a project is created, maintained, adapted, updated, and demolished/retired by various projects during its life. Each of these projects is subject to living-order uncertainty, magnifying the difficulty of predicting what the result of a project will look like in the future, and whether it will indeed turn out to be suitable for its intended purpose. This, in turn, complicates the planning phase for any project, particularly for things that are ultimately judged by how easily it can be dismantled and disposed of, or recycled and reused.

    For example, Figure 1-3 shows the life cycle of a building. The first stage, the making stage, is the domain of the project manager who oversees the building’s construction. Once the building is complete, the project manager moves on to other work, but the building of course has just begun its functional life. During the operating/using/changing stages, the building’s occupants either benefit or suffer from the project manager’s decisions throughout the making stage. Next comes the retirement/reuse stage, in which the building will likely be demolished and something else built in its place. At that point, the entire life cycle starts again. The ease with which these stages unfold depend, at least in part, on choices made by the project manager during the making stage. Only by understanding these later stages can you properly understand the true nature of a project and make decisions that will ensure it produces something of enduring value.

    Figure 1-3: The product, or result, of a project is created, maintained, adapted, updated, and demolished/retired by various projects during its life

    In software development, the time periods between stages are shorter than in construction. As in construction, the operating stage is by far the costliest part of the life cycle process. However, when a software product continues to be used beyond its designed operational life, the operating costs can rise at accelerating rates. In any industry, thinking about the life cycle of the result of a project changes how you think about project metrics. As shown in Figure 1-4 , what seems like a good choice from within the limited confines of the making stage might seem foolish when viewed from the broader perspective of the full life cycle.

    Figure 1-4: Each life cycle stage raises new questions about the success of the initial, making-stage project

    Project Outcome and Project Success

    In its narrowest sense, the term project outcome refers to a project’s measurable output in terms of scope, cost, schedule, quality, and other issues such as safety. In a broader sense, the term also refers to the impact a project has compared to its larger goals. In this sense, we take the community perspective, taking into account, for instance, the project’s multiple use potential and eventual redevelopment. For example, in the narrowest sense, the desired project outcome of a proposed sports arena might be a multi-use indoor facility built according to the planned scope, cost, schedule, and so on. However, in the broader sense, the desired project outcome might be redevelopment and revitalization of the surrounding area.

    For a humorous look at the many ways that project stakeholders can define project success, see “What the Client Wanted” – Arek Fressadi

    The term project success refers to the degree to which a project is done well, with stakeholders having varying definitions of success over time, depending on their perspectives. In other words, the evaluation of a project’s success is a subjective judgement; different stakeholders will have different initial ideas about a project’s overall success based on their own expectations and objectives. To make things more complicated, over time, stakeholders will likely revise their ideas on the project’s success to take into account new information about how the project outcome actually functions in the real world. The changing definition of project success is especially important to keep in mind throughout disruptive projects such as home remodels and road reconstructions. For example, commuters might have an extremely low opinion of an interchange construction when they are suffering through the frustrations of traffic backups and detours. Later, when the interchange is complete, and traffic is flowing more quickly than ever before, they are likely to rate the project’s overall success very high. In the consumer products world, customers looking for a new wireless device might base their idea of project success on ease of use and reliability, whereas the company producing the device might rate project success based on number of units sold. Meanwhile, the industry as a whole might only rate the project a success if it sets a new technical standard.

    If you limit your perspective to the making stage, it’s easy to think that the terms “project outcome” and “project success” are synonymous. For example, suppose you’re hired to build an energy efficient house according to Leadership in Energy & Environmental Design (LEED) standards. If, at the end of the making stage, you see that your team completed the structure on time and on budget, with all the specified LEED features, then you would probably consider that outcome a success. But as the house enters the Operating/Using/Changing stage, information about the home’s energy use might change your ideas about the success or failure of the project. If in fact the LEED features do not function as expected, then you would probably rate the project’s overall success rather low. Perhaps more importantly, the home’s owner would be unlikely to consider the home a success. And depending on the longevity estimates and ever-changing external factors, the lifespan of the house might also be significantly different than originally projected.

    Put simply, project success is defined by doing the project well and meeting defined objectives. Project outcome also encompasses whether you and your team did the right thing. It’s important to consider both at multiple levels—for individual tasks, for the overall project, and for the impact of the project over its life. In every case, we need to think broadly about the factors contributing to a project’s success or failure. We risk losing enduring value if we draw too tight a fence around the boundaries we consider when planning and assessing project success.

    Sustainability and Living Order

    The ideal project manager has empathy for the people who will be using and modifying the completed project in the future, even the people who will ultimately demolish or recycle it. Ideally, this means incorporating materials that can ultimately be recycled. Indeed, in the European Union, automobile manufacturers are required by law to reduce the non-recyclable waste generated by an end-of-life vehicle (ELV) to 5%. This way of thinking necessitates a more complicated view of a product’s life cycle, as shown in Figure 1-5 (Kanari, Pineau and Shallari 2003).

    Figure 1-5: Product life cycle can ultimately include recycling portions of the product (Source: “End-of-Life Vehicle Recycling in the European Union,” N. Kanari, J.-L. Pineau, and S. Shallari, The Member Journal of the Minerals, Metals & Materials Society Copyright 2003 by The Minerals, Metals & Materials Society. Used with permission.)

    Sustainability efforts inspired by a recognition of the realities of living order are well underway in the construction industry. As Lance Hosey, a Washington architect, has argued, sustainable construction means, among other things, creating buildings that can be easily disassembled, minimizing the disruption and contamination inherent in the demolition process (2005). Software developers, too, can develop sustainable software by, for example, writing code that runs even on outdated hardware, thereby minimizing the amount of computer equipment that ends up in landfills (Green Wiki 2015).

    In addition to being sustainably designed, software also has the potential to promote other sustainability efforts, as discussed in the report Software Accelerates Sustainable Development, published by the nonprofit organization Business for Social Responsibility (2008). David Pagenkopf, director of Application Development and Integration at UW-Madison, has this to say about sustainability and software design:

    The use of virtualization techniques has largely eliminated hardware as a material factor in software design. The most important issue in software sustainability is selecting the software languages, tools, and design architecture that ensure that software is maintainable for as many years as possible. One of the best examples is writing software that works entirely in a web browser, which can then work across multiple platforms. Even better is writing software using responsive design that automatically adjusts to the user’s end device (e.g. mobile phone, tablet, or laptop/desktop) to present the best possible interface to the user. (pers. comm., August 25, 2015)

    Consumer products are subject to an ever-increasing array of sustainability expectations. As Bryan Burrough wrote in the New York Times, Wal-Mart reduced “packaging size across its producing lines, saving the company an estimated $3.4 billion a year…while reducing trash“ (Burrough 2011). Over a decade of effort has resulted in sustainability initiatives that “are having a real impact today. The company has strategically used its scale to its advantage to enact change within as well as outside the organization” (Atamian 2017).

    1.5 Four Roles of a Project Manager

    So what does all this talk about change and unpredictability mean, practically speaking, for a real-life project manager? Throughout this book, we will be investigating ways to accommodate the realities of living order in the daily tasks associated with technical project management. For example, in Lesson 6, we’ll talk about pull planning, an adaptive, recursive form of planning that prioritizes regular updating to reflect current conditions. But for now, let’s talk about some general principles for successful project management in a living order world.

    In an article for MIT Sloan Management Review, Alexander Laufer, Edward Hoffman, Jeffrey Russell, and Scott Cameron show how successful project managers combine traditional management methods with newer, more flexible approaches to achieve better outcomes (2015). Their research shows that successful project managers adopt these four vital roles:

    1. Develop collaboration among project participants: “Most projects are characterized by an inherent incompatibility: the various parties to the project are loosely coupled, whereas the tasks themselves are tightly coupled. When unexpected events affect one task, many other interdependent tasks are quickly affected. Yet the direct responsibility for these tasks is distributed among various loosely coupled parties, who are unable to coordinate their actions and provide a timely response. Project success, therefore, requires both interdependence and trust among the various parties” (Laufer et al. 2015, 46).
    2. Integrate planning with learning: “Project managers faced with unexpected events employ a ‘rolling wave’ approach to planning. Recognizing that firm commitments cannot be made on the basis of volatile information, they develop plans in waves as the project unfolds and information becomes more reliable. With their teams, they develop detailed short-term plans with firm commitments while also preparing tentative long-term plans with fewer details” (Laufer et al. 2015, 46).
    3. Prevent major disruptions: Successful project managers “never stop expecting surprises, even though they may effect major remedial changes only a few times during a project. They’re constantly anticipating disruptions and maintaining the flexibility to respond proactively…. When change is unavoidable, a successful project manager acts as early as possible, since it is easier to tackle a threat before it reaches a full-blown state” (Laufer et al. 2015, 47).
    4. Maintain forward momentum: “When unexpected events affect one task, many other interdependent tasks may also be quickly impacted. Thus, solving problems as soon as they emerge is vital for maintaining work progress” (Laufer et al. 2015, 48).

    Adopting these four roles will set you on the road toward delivering more value in your projects, with less waste, which is also the goal of both Lean project management and Agile project management.

    1.6 Lean: Eliminating Waste in Living Order

    Traditional, geometric order project management is often inefficient, leading to wasted time, money, resources, and labor. By contrast, Lean is a business model and project management philosophy that offers a means to streamline projects while allowing for the flexibility required to deal with unexpected events. Based on ideas and practices developed at Toyota after World War II, it emphasizes creating value for the customer while eliminating waste through the efficient flow of work from one phase of a project to another.

    More than anything, Lean is a way of thinking. In their essential book on the topic, James P. Womack and Daniel T. Jones describe Lean thinking as follows:

    It provides a way to specify value, line up value-creating actions in the best sequence, conduct these activities without interruption whenever someone requests them, and perform them more and more effectively. In short, Lean thinking is Lean because it provides a way to do more and more with less and less—less human effort, less equipment, less time, and less space—while coming closer and closer to providing customers with exactly what they want. (2003, 15)

    We’ll be discussing Lean extensively throughout this book. To get started here, we’ll focus on two fundamental Lean ideas: value and waste.


    In ordinary conversation, “value” is a generic term that refers to the overall worth or usefulness of something. But in Lean, value is only meaningful “when expressed in terms of a specific product (a good or a service, and often both at once) which meets the customer’s needs at a specific price at a specific time” (Womack and Jones, 16). In other words, value is defined by the customer, not by the manufacturer, the contractor, or the service provider—and definitely not by the engineer responsible for designing the product.

    Integrated Project Delivery

    In reading about project management and Lean, you might come across the term integrated project delivery (IPD). Inspired by Lean thinking, IPD is a means of contractually aligning stakeholders in a construction project in a way that emphasizes close collaboration, with the goal of delivering value as defined by the customer. One feature of IPD is a type of contract known as a multi-party agreement, which explains each participant’s role in the project.

    A related methodology, integrated product delivery, was developed as a reaction against the silo-ed approach to product development, in which the design team designed a product, and then “threw it over the wall” to the manufacturing team, which had to figure how to build the product with no input into its design. Integrated product development’s more collaborative approach improves time-to-market, while fostering innovation.

    This sounds simple, but it can be a difficult concept for engineers, with all their technical expertise, to embrace. In their book, Womack and Jones include a chapter on Porsche, which suffered a sales collapse in the mid 1980’s largely because its world-class engineers had blinded themselves to their customers’ definition of value:

    Designs with more complexity produced with ever more complex machinery were asserted to be just what the customer wanted and just what the production process needed…. It often became apparent that the strong technical functions and highly trained technical experts leading German firms obtained their sense of worth—their conviction that they were doing a first-rate job—by pushing ahead with refinements and complexities that were of little interest to anyone but the experts themselves…. Doubts about proposed products were often countered with claims that “the customer will want it once we explain it,” while recent product failures were often explained away as instances where “the customers weren’t sophisticated enough to grasp the merits of the product.” (2003, 17)

    This is only one example of the kinds of preconceptions that can distort a company’s understanding of the value it is supposedly producing for the benefit of the customer. Womack and Jones provide in-depth case studies detailing the forces that can prevent a company from understanding what its customers actually want:

    The definition of value is skewed everywhere by the power of preexisting organizations, technologies, and undepreciated assets, along with outdated thinking about economies of scale. Managers around the world tend to say, “This product is what we know how to produce using assets we’ve already bought, so if customers don’t respond we’ll adjust the price or add bells and whistles.” What they should be doing instead is fundamentally rethinking value from the perspective of the customer. (2003, 17-18)

    To make the leap into Lean thinking, you need to fully grasp the nature of value, which is why we will return to this idea throughout this book. You also need to understand its opposite—waste. The whole goal of Lean is to maximize value and eliminate waste.


    According to the Lean Lexicon, waste[1] is “Any activity that consumes resources but creates no value for the customer” (Lean Enterprise Institute 2014). Identifying waste can be as difficult for new Lean thinkers as identifying value.

    Taiichi Ohno, the Toyota executive who pioneered the focus on waste and value that we now call Lean, identified seven forms of waste. You can find countless explanations of the seven wastes in books and articles. The following is adapted from 7 Wastes”- Lean Manufacturing Tools:

    • Transportation: Moving people, machinery, or materials farther than is really necessary. A huge amount of transportation waste is necessitated by poor factory layouts, large batch sizes, and distant storage locations, just to name a few causes.
    • Inventory: A build-up of stock due to, for example, poor planning, or the time required to change over machinery from one process to another.
    • Motion: Any movement of humans or equipment that does not increase the value of a product or service. Examples include bending and reaching necessitated by a poorly designed work station, or by badly organized storage areas.
    • Waiting: Humans or machines standing idle. Can be caused by long changeovers, poorly coordinated processes, or the need to rework flawed parts, among other things.
    • Overproduction: Creating more than can be used or sold in a reasonable time. This is considered the worst form of waste, because “it obscures all of the other problems within your processes”(Lean Manufacturing Tools n.d.). Later in this book, we’ll talk about how to avoid this form of waste through Lean techniques such as pull planning.
    • Over-processing: Doing more than is useful or necessary from the point of view of the customer. The over-engineering at Porsche, described by Womack and Jones, is a clear example of over-processing. A more mundane example might be a restaurant that uses expensive imported cheese on pizzas, when customers would actually prefer domestic mozzarella.
    • Defects: Time and effort required to correct defective parts or poorly rendered services. This is what most people think of when asked to identify waste. But it can be hard to accurately gauge the costs associated with defects, which can include “costs associated with problem solving, materials, rework, rescheduling materials, setups, transport, paperwork, increased lead times, delivery failures, and potentially lost customers”(Lean Manufacturing Tools).

    Another way to think about waste is to focus on how easily it can be eliminated. When looked at that way, it falls into two types:

    • Type one waste: Creates “no value but is unavoidable with current technologies and production assets” (Lean Enterprise Institute 2014). This kind of waste is necessary but might be eliminated in the future. An example of type one waste might be routine inspections required to ensure that a particular part meets government safety standards. While necessary, such inspections don’t actually provide value from the customer’s point of view, and might conceivably be eliminated if the part itself was eliminated from the device, or if it was redesigned.
    • Type two waste: Creates no value and can be eliminated immediately. For example, the time and effort required to transport a newly made microwave oven to the packaging machine is waste that could be eliminated by moving the packaging machine.

    This blog provides some real-life examples of the seven forms of waste in a variety of industries: “Real Examples of the 7 Wastes of Lean” – KaiNexus

    In project management, an example of type one waste might be an audit necessary to measure the performance of contracted work or a promised product against an agreed-upon set of requirements. From the customer’s perspective, such an audit adds no value, but it is necessary to ensure the successful completion of the project. A type two waste often seen in project management is constant requests for status updates. New project managers who haven’t yet built trust with their team sometimes succumb to this form of waste as they try to micro-manage all tasks. Regularly scheduled updates and escalation expectations for unexpected challenges helps to eliminate this type two waste in project management.

    Six Lean Principles

    The six principles at the heart of Lean thinking are: specify value, identify the value stream, flow, pull, perfection, and respect for people. You’ll learn more about these ideas, and how they relate to technical project management, throughout this book. We’ll explain them briefly here, to give you a foundation to work from. Most of the examples in this lesson are drawn from manufacturing, where Lean got its start. But keep in mind that Lean thinking has been widely adopted in industries as diverse as construction and healthcare.

      1. Identify value: As explained earlier, value can only be defined by the customer. As a project manager, you have to start by learning what that definition is—ideally by talking directly to the customer. However, you may find that customers “only know how to ask for some variant of what they are already getting”(Womack and Jones 2003, 31). This means that identifying value often entails asking probing questions designed to elicit a definition of value from customers who may not have had the opportunity to think it through themselves. Often, the best questions to start with are: What problem do you want to solve? What does success look like?
      2. Map the value stream: The value stream is “all of the actions, both value-creating and nonvalue-creating, required to bring a product from concept” to delivery(Lean Enterprise Institute 2014). In any industry, the vast majority of activities in the value stream create no value and are therefore waste. Firms that attempt to analyze the value stream for a particular product typically have to look far beyond their own premises, taking into account everything involved in bringing a product to market. For example, the value stream for a new type of bread might begin with groundwater used to irrigate wheat farms in Nebraska. When looking at value streams from a project management perspective, the goal is to understand all aspects of the project, including initiation, planning, executing, monitoring & control, and closeout.

        Batch and Queue: The Opposite of Flow

        Suppose you set up a batch and queue system for baking, frosting, decorating, and boxing a hundred birthday cakes at a bakery. As you bake the cakes, you need to come up with a good storage solution, so they stay fresh until you are ready to frost them. After all the cakes are frosted and you move onto the decorating step, you might find that the decorations don’t stick to the frosting. If you had just bake, frosted, and decorated one cake, you would have discovered and solved this problem before it became a defect affecting all the cakes. But since you have already baked and frosted all the cakes, you’re now in the position of having to buy new decorations that will stick to the frosting already on the cake. A similar problem could arise with the boxes. You might have a hundred cakes frosted and decorated, ready to be boxed, and then discover they don’t fit in the boxes you ordered. Meanwhile, the cakes are getting stale, and might soon become unsellable.

      3. Continuous flow: According to Womack and Jones, most people tend to think the most efficient way to complete any multi-step project is to divide it into batches—performing the first step on all available materials and setting the results aside until all the materials have been processed. After the entire batch has been completed, you then move onto the next step, processing the entire batch, and so on, through all the steps. This approach, known as batch and queue, can be useful in many situations, but it’s often wildly inefficient and can lead to defects that aren’t detected until many steps into the process (Womack and Jones 2003, 22). To avoid the problems associated with batch and queue production, Lean emphasizes continuous flow from one step to the next, with small batches that can be immediately processed by workers at the next step. True continuous flow, which dramatically reduces production time, is only possible after you have eliminated the waste of non-value creating steps, and then rearranged the remaining steps so that they unfold one after the other. It is not a realistic goal in all industries, but you can often achieve some benefits of flow by moving machinery and relocating personnel. In project management, flow can become an issue during scheduling. For example, a project team might make the mistake of laboring over an unnecessarily detailed schedule with overly discrete time blocks, planning tasks for a multi-year project in hours. Then, after wasting all this time on an unrealistic schedule, the team might fail to review and update actual progress as the project progresses. This lack of flow can present real risks to the project’s overall success. By contrast, Lean-thinking project managers understand that a schedule is a living document, and that, throughout a project, they’ll need to address living order changes (both positive and negative), allowing for true flow throughout the life of the project.
      4. Pull: To understand the meaning of pull, you first have to understand the meaning of push. Traditional production systems are considered push systems, with work dictated by production schedules which are sometimes tied to accurate forecasts of customer demand, but often are not. A push system easily results in the waste of over-production. Mark Graban offers some examples:
        • A fast food restaurant making food and storing it under heat lamps (some of it gets thrown away).
        • An automaker building an excess number of cars or trucks and forcing the dealers to take them.
        • The U.S. Mint producing dollar coins that far exceed customer demand.
        • Computer makers building product and shipping it to retailers to sit on the shelves. (2014)

        By contrast, a pull system builds products and uses up materials based on actual customer demand, the way a sandwich shop might make your favorite turkey and guacamole sandwich after you order it. In reality, most systems use a combination of pull and push production. For example, making up your sandwich on the spot is a pull activity, but the store would probably have practiced push production by previously ordering turkey and guacamole according to forecasts of customer demand.

        These examples greatly simplify the Lean concept of pull. In practice, especially in giant factories or on construction sites, it is far more complex. But the basic, waste-reducing principle is always the same: “no one upstream should produce a good or service until the customer downstream asks for it” (Womack and Jones 2003, 67).

        This excellent blog post uses a concession stand example to illustrate the way a pull system avoids the wastes of inventory and over-production by keeping only small quantities of materials on-hand, replacing items as they are used:
        Lean Blitz Consulting – “Toyota Way Principle #3: “Pull” Systems”

        Translating the concept of pull to project management can be difficult but yields powerful results. The team starts with the end-point—the ultimate goal of the project—and pulls activities forward, describing what must be done each step of the way. This differs greatly from standard project management, which starts from the beginning, building a schedule that assumes previous tasks are completely finished before the team starts on the next tasks. By contrast, in a Lean schedule, more tasks overlap. In a presentation on project planning for a transmission line design, Kristine Engel explains that, in a pull schedule, “the ‘later tasks’ may start before ‘earlier’ tasks end,” and that some “design refinement tasks may overlap with the labor bid process or even construction, which reflects the reality of utility projects.” Despite this fluidity, the team is able to track progress by comparing billed hours to the budget. The whole system is built on “regular communication with the client to revise short-term goals in relation to the full project timeline” (Engel 2017).

      5. Perfection: Experienced practitioners of Lean testify that, as you get better at identifying the customer’s definition of value, you become more precise in identifying every step in the value stream. As a result, you reduce the waste of non-value adding activity, thereby improving flow. As you gain experience, you’ll start to see opportunities for Lean improvements everywhere. It’s like lifting weights—the more you lift, the more you can lift. The more waste you eliminate, the more waste you can eliminate. According to Jones and Womack, this happens because

        the four initial principles interact with each other in a virtuous circle. Getting value to flow faster always exposes hidden muda [waste] in the value stream. And the harder you pull, the more the impediments to flow are revealed so they can be removed. Dedicated product teams in direct dialogue with customers always find ways to specify value more accurately and often learn of ways to enhance flow and pull as well. (2003, 25)

      6. Respect for People: Above all else, Lean requires constant communication among all stakeholders. Implementing the first five principles of Lean is only possible when all team members respect and listen to each other, share ideas, accept suggestions, and collaborate to solve problems and eliminate waste. Respect for people is not about being nice—it’s about understanding that you can’t solve problems on your own, and that instead you need to engage sincerely and honestly with co-workers. Sometimes that means challenging them and offering criticism. It always means being willing to admit when you’re wrong.

    Push and Pull

    This two-minute video explains the difference between push and pull production:


    A YouTube element has been excluded from this version of the text. You can view it online here:

    1.7 Agile: Fast Feedback in Living Order

    Lean was originally developed in the world of manufacturing but has been adopted in many industries. In the world of software development, a related methodology, Agile, is becoming increasingly popular. It is essentially an IT version of Lean. Although Agile had its roots in software development, companies have also expanded its use into a variety of project types, including product development, capital projects, and service projects.

    The many flavors of Agile include:

        • Agile Scrum: Designed for completing complex projects, as described on ScrumGuides, Scrum is the most widely used form of Agile. When people talk about Agile, they are usually talking about Scrum.
        • Extreme Programming: Emphasizes short development cycles with frequent releases of software for evaluation, after which a new development cycle begins. You can read more about extreme programming at “Extreme Programming: A Gentle Introduction
        • Rapid Product Development: Emphasizes “simultaneous, coordinated activities by multi-functional teams, striving for smooth transitions between phases for the most rapid time-to-market” (ORC International: Expert Advisory Services). You can read more about Rapid Product Development in this “Introduction to Rapid Product Development.”
  • Another Form of Agile

    Hackathons, another type of Agile experience, are multiday events in which software developers work on a solution to a specific problem with the goal of generating a number of innovative ideas and/or prototypes. Hackathons are similar to Agile sprints, but typically involve more intensive collaboration, with participants gathering in one place and dividing up into teams. Originating as a way for anyone to get involved in creating open-source software, hackathons are now common on college campuses and in the corporate world. For information about upcoming hackathons, see this site dedicated to the topic: HackerEarth.

  • All forms of Agile emphasize an iterative approach to product development, with the project specifications evolving along with the customer’s notion of the software requirements. A project starts with a conversation between the developer and the product owner about what the customer wants the software to do. In Scrum terminology, the customer is the product owner, and the features that the product owner wants in the software are known as product stories.

    With a description of the product stories in hand, the Agile developer gets to work, creating pieces of software that address individual product stories. After a one- to two-week cycle of development (known in Scrum as a sprint) the developer hands off the new software to the product owner so she can try it out and make suggestions for improvement. The developer then begins another sprint, incorporating those suggestions into a new iteration. After every sprint, the product owner has the chance to redirect the team to new product stories, or to revise the team’s understanding of the existing product stories. Through these repeated interactions, which provide fast, focused feedback, the developer and the product owner zero in on a software application that does what the product owner needs it to do. If time and money are tight, as they often are, the product owner has regular opportunities to make choices about which product stories are the most important, and which can be dispensed with if necessary.

    Agile development is essentially a learning process through which the developer and the product owner create a shared understanding of how many features they can create, given the allotted time and money. It’s very much a living order approach to project management, in that the early stages involve some ambiguity and many unknowns. According to Robert Merrill, a Senior Business Analyst at the University of Wisconsin-Madison, and an Agile coach, “Agile is a way to manage projects in the face of unpredictability and constraints—often very rigid time and budget constraints. The fast feedback allows the team to create the best possible software within the given constraints” (2017).

    Like Lean, Agile will be a recurring topic throughout this book. To get started learning about Agile on your own, see the following:

    Agile: A New Kind of Engineering

    In his fascinating lecture “Real Software Engineering,” Glenn Vanderburg presents the history of software engineering (2011). He explains how early software developers tended to think of software engineering in terms that were familiar to them from structural engineering, because that’s what they thought the term engineering meant. Vanderburg advocates a new, simple definition of engineering: whatever works.

    History tells us that what used to be called software engineering actually had little to do with engineering, because so-called “software engineering projects” were riddled with waste, rework, and failure. In other words, it didn’t work. According Vanderburg, Agile is the only real form of software engineering. It is fundamentally different from structural engineering, in part because it allows for instantaneous, essentially-free testing—something that is impossible when building planes or bridges. Also, whereas other types of engineering typically involve modeling something over a long period of weeks or months, and then getting feedback, also over weeks or months, Agile developers receive feedback over different time scales. For individual blocks of code, they can get important feedback in minutes or hours by simply sharing it with another developer or with the customer. For larger parts of the project, such as acceptance testing or a release of new features, getting feedback is more expensive and takes place over weeks or months.

    The main reason feedback and testing in Agile differs so much from other types of engineering is that the source code is itself the model. By writing code, Agile developers create both the testable model and the final product at the same time. In Vanderburg’s words: “Agile processes are economical, cost-tuned feedback engines.”

    ~Practical Tips

        • Be prepared to use both geometric and living order techniques: Projects are often conceived and planned in geometric order, with the naïve assumption of events unfolding predictably. Then reality hits, and they are executed amidst the uncertainties of living order. However, eventually, as projects unfold, and you begin to learn what to expect, they can become more geometric. Be prepared to move back and forth among geometric and living order techniques, adapting to the situation as necessary.
        • When working in geometric order, focus on the following:
          • Define project success.
          • Establish a project timeline.
          • Ensure the project delivers the specified results.
          • Constantly check your progress against the project schedule.
          • Regularly check costs against the project budget.
          • Periodically pause to make sure the project really is unfolding in geometric order and hasn’t shifted to living order.
        • When working in living order, follow good geometric practices when appropriate, but also focus on the following:
          • Ensure that all stakeholders understand the project’s shared value and are committed to achieving it.
          • Incorporate every useful form of communication to make sure project stakeholders understand what’s going on at every stage of the project.
          • Focus on activities that create value and eliminate wasteful activities.
          • Be prepared to respond to changing events, staying agile and adaptable.
        • Take the time to identify the unique and changing context of a project: A project’s context—the day-to-day environment and the larger organizational background in which a project unfolds—is rarely the same from one project to the next, and can change throughout the course of the project. By identifying the unique context of each project, and the many ways it could change, you’ll reduce your chances of making assumptions that could turn out to be wrong.


        • Projects unfold in unique and changing contexts that call for a flexible, adaptable approach.
        • Organizations often conceive projects in the unpredictable upheaval of living order and then attempt to execute them in the more systematic geometric order, planning every step down to the last detail. Successful project managers never lose sight of the unpredictable, permanent whitewater world in which projects actually unfold.
        • Understanding that a project’s life cycle involves more than just the making stage will expand your understanding of “project success.”
        • Lean project management focuses on maximizing value and eliminating waste.
        • Agile project management strategies encourage the flexibility required in living order.


        • Agile—A project management methodology that emphasizes an iterative approach to product development, with the project specifications evolving along with the customer’s notion of the software requirements. There are many flavors of Agile, but the most widely used is Scrum.
        • behavioral economics—According to, “a method of economic analysis that applies psychological insights into human behavior to explain economic decision-making.”
        • geometric order—A type of order identified by the French philosopher Henri Bergson that is characterized by linear development, clear cause and effect, and predictable events.
        • integrated project delivery (IPD)—A means of contractually aligning stakeholders in a construction project in a way that emphasizes close collaboration, with the goal of delivering value as defined by the customer. IPD is inspired by Lean and relies on a type of contract known as a multi-party agreement, which explains each participant’s role in the project.
        • Lean—A business model and project management philosophy that offers a means to streamline projects while allowing for the flexibility required to deal with unexpected events. It emphasizes the elimination of waste through the efficient flow of work from one phase of a project to another.
        • living order—A type of order identified by the French philosopher Henri Bergson that is characterized by rapid change and unpredictable events.
        • project— A “piece of planned work or activity that is completed over a period of time and intended to achieve a particular aim”(Cambridge English Dictionary 2018).
        • project outcome—In its narrowest sense, a project’s measurable output—whether that’s a building, a software application, or a part for a fighter jet. In a broader sense, the impact a project has compared to its larger goals.
        • project success—The degree to which a project is done well. Stakeholders’ evaluation of project success is a subjective judgement, varying depending on their perspective, and typically changes over time.
        • project management—The “application of processes, methods, knowledge, skills, and experience to achieve the project objectives” (Association for Project Management 2018).
        • value—In ordinary conversation, a generic term that refers to the overall worth or usefulness of something. But in Lean, value is only meaningful “when expressed in terms of a specific product (a good or a service, and often both at once) which meets the customer’s needs at a specific price at a specific time” (Womack and Jones 2003, 16). In other words, value is defined by the customer.

    ~Additional Resources

        • The Guide to Lean Enablers for Managing Engineering Programs, published by the Joint MIT PMI INCOSE Community of Practice on Lean in Program Management (2012).
        • Managing as a Performing Art: New Ideas for a World of Chaotic Change, by Peter B. Vaill (1989). In this book Vaill introduces the term “permanent whitewater.”
        • Richard Thaler’s memoir of his life and work in the field of behavioral economics: Misbehaving: The Making of Behavioral Economics (2015).
        • The classic introduction to Lean: The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer, by Jeffrey Liker(2004).


    Association for Project Management. n.d. “What is project management?” Accessed June 15, 2018.

    Atamian, Luna. 2017. “Why is Walmart a sustainability leader?” Huffington Post, December 14.

    Bergson, Henri. 1911. “Creative Evolution.” Project Gutenberg. Accessed June 15, 2018.

    Bloch, Michael, Sven Blumberg, and Jürgen Laartz. 2012. “Delivering Large-Scale IT Projects on Time, on Budget and on Value.” McKinsey&Company. October. Accessed August 4, 2016.

    Burrough, Bryan. 2011. “Behind the Greening of Wal-Mart.” New York Times, May 14.

    Business for Social Responsibility. 2008. “Software Accellerates Sustainable Development.”

    Cambridge English Dictionary. 2018. “project.” Cambridge Dictionary. Accessed May 12, 2018.

    Engel, Kristine. 2017. “Project Planning for Transmission Line Design.” PowerPoint presentation for class in Technical Project Management, University of Wisconsin-Madison, October 12.

    Graban, Mark. 2014. “#Lean: Clarifying Push, Pull, and Flow in a Hospital; the Patient “Pulls”.” Mark Graban’s Lean Blog. February 24.

    Green Wiki. 2015. “Sustainable Code Development.” Green Wiki. June 9.

    Hosey, Lance. 2005. “More Constructive Ways to Build a City.” The Washington Post, January 9.

    Kanari, N., J.L. Pineau, and S. Shallari. 2003. “End-of-Life Vehicle Recycling in the European Union.” Journal of the Minerals, Metals & Materials Society, August. Accessed June 9, 2015.

    Knee, Jonathan A. 2015. “In ‘Misbehaving,’ an Economics Professor Isn’t Afraid to Attack His Own.” New York Times, May 5.

    Larson, Erik W., and Clifford F. Gray. 2011. Project Management: The Managerial Process, Sixth Edition. New York: McGraw-Hill Education.Laufer, Alexander. 2012. Mastering the Leadership Role in Project Management: Practices that Deliver Remarkable Results. Upper Saddle River: FT Press.

    Laufer, Alexander, Edward J. Hoffman, Jeffrey S. Russell, and Scott W. Cameron. 2015. “What Successful Project Managers Do.” MIT Sloan Management Review, Spring: 43-51.

    Lean Enterprise Institute. 2014. Lean Lexicon, Fifth Edition. Edited by Chet Marchwinski. Cambridge, MA: Lean Enterprise Institute.

    Lean Manufacturing Tools. n.d. “Waste of Defects; causes, symptoms, examples and solutions.” Lean Manufacturing Tools. Accessed November 11, 2017.

    —. n.d. “Waste of Overproduction; causes, symptoms, examples and solutions.” Lean Manufacturing Tools. Accessed November 11, 2017.

    Merrill, Robert, interview by Ann Shaffer. 2017. Senior Business Analyst, University of Wisconsin-Madison (October 2).

    Merrow, Edward W. 2011. Industrial Megaprojects: Concepts, Strategies, and Practices for Success. Hoboken, New Jersey: John Wiley & Sons, Inc.

    Mieritz, Lars. 2012. “Gartner Survey Shows Why Projects Fail.” This Is What Good Looks Like. June 10.

    ORC International: Expert Advisory Services. n.d. Rapid Product Development Experts. Accessed September 9, 2016.

    Pagenkopf, David. 2018. “Email on sustainability and software design.”

    Thaler, Richard H. 2015. “Unless You Are Spock, Irrelevant things Matter in Economic Behavior.” New York Times, May 8.

    Vanderburg, Glenn. 2011. “Lone Star Ruby Conference 2010 Real Software Engineering by Glenn Vanderburg.” Published October 24, 2011. YouTube video, 51:56.

    Womack, James P., and Daniel T. Jones. 2003. Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated. New York: Free Press.

    1. In a nod to the origins of Lean, the Japanese word for waste, muda is often used in publications about Lean.

    This page titled 1.1: Project Management Foundations- Principles and Practices is shared under a CC BY license and was authored, remixed, and/or curated by Jeffrey Russell, Wayne Pferdehirt, and John Nelson.

    • Was this article helpful?