Nothing endures but change.
Heraclitus, 535 – 475 BC

1.1 Technical Project Management in the Modern World

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.

Project Performance

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, with failure often defined in terms of cost and schedule overruns. A study of 975 construction projects by the Construction Industry Institute, for instance, found that only 30 percent met their cost and schedule goals (2012). And a recent report from the Consortium for Information & Software Quality indicates that more than 65 percent of IT projects fail to meet their cost and schedule targets—at a cost of more than $260 billion annually (Krasner 2020).

When considered from the perspective of the client (that is, the one who ultimately receives the final product), failure on a capital project is often defined as a significant breach of contract. If a major project participant cannot fulfill their contract obligations, the project is likely to experience significant impacts in terms of delays and cost escalation—and usually questions about quality. On projects that fail to this extent, final costs can easily exceed the original budget by 50 percent, while project duration often doubles the initial estimate (Russell and Jaselskis 1992, 796).

Combining this client-centered definition of project failure with generally accepted statistics regarding project performance across industries yields a distribution like the one shown in Figure 1-1. This figure clearly illustrates the need to improve on the percent of projects completed successfully, no matter how success is defined.

Throwing more money at the problem doesn’t typically improve project performance. 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 often 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 (those with budgets over $1 billion), which fail more than twice as often as under–$1 billion projects (Merrow and Nandurdikar 2018).  Projects in the oil and gas production sector fare the worst, with 78 percent of megaprojects in this industrial sector classified as failures” (Merrow 2011, 49).

The Value of Professional Project Management

No matter the industry or project size, poor project performance translates into missed opportunities and wasted resources. 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. In the context of this discussion, those organizations are project management “champions,” and when compared to underperforming organizations, they are consistently more successful at achieving project goals and completing strategic initiatives. Underperforming organizations waste 28 times more money than champion organizations because they are unable to successfully complete many of their high-priority strategic initiatives.

Champion project organizations succeed by placing a high priority on developing the technical and leadership skills of their project professionals through ongoing support for training and development. Those organizations are also more likely to have a Project Management Office (PMO) and use more flexible Agile approaches on their projects (see Table 1-1).

Table 1-1: Characteristics of “champion” project management organizations (Source: “PMI’s Pulse of the Profession: Success Rates Rise,” PMI, 2017)

The critical takeaway from this discussion is that project management maturity—at the individual, team, and organizational level—can assist a project manager in proactively managing project outcomes, including cost, time, and quality, and reducing variability. In short, better project management practices can lead to better project outcomes. Organizations with formal PMOs, established project management practices, and a focus on developing leadership and technical project management skills are better situated to improve project performance.

The Impact of Culture

Every project unfolds in unique and changing contexts impacted by internal and external forces. One such force, culture, can have a profound effect on a project’s context and its outcome. You are likely familiar with the concept of culture, which is the set of norms, beliefs, and customs of a particular society, group, place, or time. Culture functions on many levels in human society—in geographical regions, ethnic groups, religions, families, organizations, and even projects.

Projects that use the same tools, contracts, and structures may have starkly different outcomes depending on the culture of the organization and the project team. Organizational culture comprises the set of behaviors, values, artifacts, reward systems, and rituals that make up an organization. The culture of an organization may manifest itself in an expected set of behaviors (e.g., how do people work with customers and each other, how early or late do people work), the structure of the organization’s reward system (e.g., are employees rewarded for cost-cutting, customer satisfaction, innovation, or other factors), its approach to risk, and its overall mission and strategy (Bersin 2015). Project culture, or the set of beliefs, attitudes, and behaviors that exist independently of the individuals working on the project, can be a powerful force, with the result that people joining a project often adapt to the existing culture rather than changing it. At every level, culture is driven by leadership (2015).

The notion of a cultural iceberg serves as a reminder that many aspects of culture are not apparent to outsiders. In an organization or project team, the surface culture—made up of articulated norms, acceptable practices, and strategies—often represents a small fraction of the overall culture. Many more aspects of culture lie beneath the surface, often exerting a much stronger influence on how team members work together. These deep culture elements include communication styles and rules, notions of leadership, concepts of self and time, attitudes toward authority and collaboration, and approaches to decision-making and problem-solving, among others.

Cues to deep elements of organizational and project culture can often be found in unexpected places. Procurement practices, for instance, divulge a lot about culture. If the approach to procurement is price driven, it’s likely that the organizational and project culture is transactional, and possibly adversarial. If, on the other hand, procurement is value driven, the culture is more likely to be relational.

Project leaders should reflect on all facets of organizational and project culture, including the ways in which surface elements are not in alignment with substantive elements of the deep culture. Vera Martinovich, an engineering manager at Boeing, also emphasizes the importance of recognizing when culture—either at the project or organization level—is becoming an obstacle to successfully delivering a quality project outcome. According to Martinovich, that might mean helping the project team successfully work within the existing organizational culture rather than fighting it (pers. comm., June 20, 2020).

Additional challenges related to culture can arise on project teams comprising people from multiple organizations—a common occurrence in many industries. Examples of such teams include a product development team that utilizes supplier designs, a construction project team that includes independent designers and contractors, and a software project team working with an outside consultant to implement purchased products. With such teams, no common organizational culture is guaranteed. In these cases, the project leader has the opportunity to set the tone for the unique project culture, which should align with that of the ultimate customer.

No matter the makeup of the team or the impact of outside forces, the role of the project leader is to build a project culture that encourages team members and other stakeholders to work toward a shared goal. Accomplishing that requires the project leader to recognize their own influence, including ways in which they may be negatively impacting the project culture. For instance, a project leader who passively befriends everyone at the expense of making hard decisions and holding the team accountable may prove to be a team’s biggest obstacle. Likewise, autocratic project managers who act on behalf of the team without soliciting input or those that deliberately withhold information as a source of power can corrupt the project culture and dramatically lower the probability of successful outcomes.

A culture of trust and flexibility on a project team can mean the difference between success and failure. By fostering a collaborative culture, the project leader strengthens the team’s ability to deliver quality and to fix problems when they occur.

Mastering, influencing, and changing a project’s culture takes time and patience. While you are discerning the culture you are working in, be open-minded—listen, adapt, and be patient. Gauge carefully when deciding what aspects of the culture you try to shape. Start with an awareness of a project’s culture, assimilating and adjusting your way of doing things when you can.

1.2 Be a Hedgehog and a Fox

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, predictive 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-2, with one stage necessarily leading to the next.

Project managers have traditionally idealized such an orderly project progression. Indeed, it is the driving force behind the predictive, process-oriented approach to project management that organizations such as the Project Management Institute have tended 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-3 illustrates the characteristics of living and geometric order. Keep in mind that a project can have qualities of both.

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 were 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

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 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 many 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-4 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.

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-5, 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.

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, a 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.

The term project success refers to the degree to which a project is done well. As with failure, clients and other stakeholders often have varying definitions of success that change over time depending on their perspective and their role on the project. A CEO may focus solely on cost performance data, for instance, while a client project manager’s success criteria may be whether the final product is fit for its intended use. The job superintendent, on the other hand, may judge a project on whether it was completed on time and without accidents.

In other words, the evaluation of a project’s success is a subjective judgment; 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. To be effective over the course of a project, you need to be tuned into those dynamics. Be proactive and thoughtful about how you want to manage and lead in that context. Define the collective project success up front and stay focused on that.

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 and how those factors are perceived by the various constituencies. 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-6 (Kanari, Pineau, and Shallari 2003).

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

Predictive, 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.

Value

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.

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.

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.

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. 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 Continuous 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).

      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).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. Kanban is an adaptive project management methodology based on Lean concepts, including pull. We’ll discuss Kanban in more detail later in this lesson.

   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.

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 approach, Agile, has become increasingly popular. Agile software development projects typically involve small, self-organizing teams who work collaboratively in short iterative cycles to produce working product increments. When you hear people talking about Agile, they may be referring generally to a set of values and principles intended to guide project teams in “achieving agility” by continuously adapting and improving the way they work. However, people often use the term Agile to refer to one of the many specific software development frameworks based on those values and principles, including the following.

The many flavors of Agile include:

• Scrum: Designed for completing complex projects using small, cross-functional, self-organizing teams (as described on ScrumGuides), Scrum is the most widely used form of Agile. When people refer to “Agile software development,” they are usually talking about Scrum practices, and we often do the same in this ebook.
• Kanban: Based on Lean principles, Kanban focuses on incremental change and continuous process improvement. Central to this simple framework is the Kanban board, which is a visual display of all the project work in progress, the work waiting to be started, and the work already completed. You can read more about the Kanban framework in this article: “Kanban”
• Extreme Programming (XP): Emphasizing short development cycles with frequent releases of software for evaluation, XP is based on a set of software development best practices. You can read more about extreme programming at “Extreme Programming: A Gentle Introduction“
• Crystal, Dynamic Systems Development Method (DSDM), and Feature-Driven Development (FDD): These are some of the other more popular Agile frameworks. You can read more about them and the other Agile frameworks in this list at “Project Management Frameworks”

Most Agile approaches emphasize an iterative approach to product development, with the project specifications evolving along with the customer’s notion of the software requirements. According to project manager Steve Caseley, in a Microsoft Growth Center article, projects using these iterative development approaches “plan, develop, and implement project functionality in small chunks (or iterations). The key to successful iterative delivery is that each small chunk effectively operates as a smaller mini-project under the umbrella of the total project” (Caseley 2019).

A Scrum project starts with a conversation between the development team 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 included in the software are known as user stories, which may be expressed in simple, nontechnical language from the perspective of the person who wants that feature—for example, “As a car owner, I want to schedule my service appointment online so that I don’t have to spend time on the phone calling my mechanic.” Often, the person is a fictional persona representing a type of user or stakeholder.

The product owner prioritizes the user stories, which are collectively referred to as the product backlog, and in each development cycle, the team creates pieces of software that address one or more user stories. After a one- to two-week cycle of development (known in Scrum as a sprint) the team presents the new software to the product owner in a sprint review meeting so she can try it out and make suggestions for improvement. The team then begins another sprint, incorporating those suggestions into a new iteration and beginning work on new user stories, depending on their capacity. After every sprint, the product owner has the chance to redirect the team to new user stories, or to revise the team’s understanding of an existing user story. Through these repeated interactions, which provide fast, focused feedback, the team 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 user stories are the most important, and which can be dispensed with if necessary.

Agile development is essentially a learning process through which the development team 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).

Some companies use a combination of Agile frameworks (often called hybrid Agile) or a combination of some predictive, plan-driven processes with elements of an Agile framework (also called a hybrid development approach). A hybrid Agile project might include classic Scrum elements such as a product owner and development sprints as well as a Kanban board that is used to pull work based on capacity. A hybrid development approach could involve predictive project planning along with more flexible Agile development cycles. Decisions  about which approach to use—whether it is a strictly Agile approach, such as Scrum, or a hybrid approach—should be based on the needs of the project as well as the organizational environment in which the project will unfold.

Paul Dandurdan, CEO of PieMatrix, a company whose products include a visual project management software platform, argues that there is value in both Agile and predictive, or waterfall, approaches. He propose a hybrid Agile/waterfall manifesto in a blog post that also highlights what he sees as the limitations of the original Agile Manifesto: “Hybrid Agile Manifesto and Spider Man.”

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

• In 2001 a group of software developers published the Agile Manifesto in which they outlined the 12 principles of Agile software development. You can read the entire manifesto here: “Principles Behind the Agile Manifesto.”
• A Gentle Introduction to Agile, a blog post by Eric Bruno.
• “What is Agile Methodology?”, a five-minute video.
• “Agile Product Ownership in a Nutshell,” a 15:51-minute video about software development.

~Practical Tips

• 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. Those same considerations can help you determine which project management approach to use on a given project. Before introducing an Agile project management methodology, assess the extent to which your organizational culture lines up with Agile values and principles. Implementing Agile or hybrid Agile approaches within a more traditional organization can require patience and advocacy for the benefits that working in living order offers.
• If you are joining an existing project, learn all you can about the team culture, and set your immediate expectations accordingly: Start with an awareness of a project’s culture, assimilating and adjusting your way of doing things when you can. Use your indirect influence to shape project culture by building relationships.
• 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.

~Summary

• Clients and other stakeholders often have varying definitions of success and failure that change over time depending on their perspective and their role on the project.
• Organizations with formal PMOs, established project management practices, and a focus on developing leadership and technical project management skills can improve project performance.
• Projects unfold in unique and changing contexts that call for a flexible, adaptable approach.
• Projects are impacted by a myriad of internal and external forces. One such force, culture, can have a profound effect on a project’s context and its outcome. Projects that use the same tools, contracts, and structures may have starkly different outcomes depending on the culture of the project team and the organization.
• 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.
• Project management frameworks based on Agile values and principles encourage the flexibility required in living order. Hybrid Agile approaches and hybrid development approaches combine features of one or more Agile frameworks—sometimes in combination with elements of more traditional waterfall approaches.

~Glossary

• Agile—A set of values and principles intended to guide project teams in “achieving agility” by continuously adapting and improving the way they work. Also sometimes used to refer to one of the software development frameworks and methodologies that are based on those values and principles; Agile approaches emphasize an iterative approach to product development, with the project specifications evolving along with the customer’s notion of the software requirements. Popular Agile frameworks and methodologies include Scrum, Kanban, and Extreme Programming (XP).
• behavioral economics—According to OxfordDictionaries.com, “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.
• hybrid Agile— A combination of Agile frameworks—such as Scrum sprints and a product owner used along with a Kanban board.
• 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.
• organizational culture–The set of behaviors, values, artifacts, reward systems, and rituals that make up an organization.
• 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 culture—A set of beliefs, attitudes and behaviors that exist independently of the individuals working on the project.
  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).
• sprint—In Scrum, short cycle of software development (often one or two weeks).
• user story—A feature that the product owner wants included in the software being developed. It may be expressed in simple, nontechnical language from the perspective of the person who wants that feature—for example, “As a car owner, I want to schedule my service appointment online so that I don’t have to spend time on the phone calling my mechanic.”
• 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).

~References

Association for Project Management. n.d. “What is project management?” apm.org. Accessed June 15, 2018. https://www.apm.org.uk/resources/what-is-project-management/.

Atamian, Luna. 2017. “Why is Walmart a sustainability leader?” Huffington Post, December 14. https://www.huffingtonpost.com/entry/why-is-walmart-a-sustainability-leader_us_5a329da5e4b00caf3d59eae8.

Bergson, Henri. 1911. “Creative Evolution.” Project Gutenberg. Accessed June 15, 2018. http://www.gutenberg.org/files/26163/26163-h/26163-h.htm.

Bersin, Josh. 2015. “Culture: Why It’s the Hottest Topic in Business Today.” Forbes. March 13. https://www.forbes.com/sites/joshbersin/2015/03/13/culture-why-its-the-hottest-topic-in-business-today/#27b6f20f627f.

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. http://www.mckinsey.com/business-functions/business-technology/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value.

Burrough, Bryan. 2011. “Behind the Greening of Wal-Mart.” New York Times, May 14. http://www.nytimes.com/2011/05/15/business/15shelf.html?_r=0.

Business for Social Responsibility. 2008. “Software Accelerates Sustainable Development.” bsr.org. http://www.bsr.org/reports/BSR_Software_Accelerates_Sustainable_Development.pdf.

Cambridge English Dictionary. 2018. “project.” Cambridge Dictionary. Accessed May 12, 2018. https://dictionary.cambridge.org/us/dictionary/english/project.

Caseley, Steve. 2019. “Project Management: Traditional, Iterative, or Hybrid?” Microsoft: The Growth Center. June 20. https://www.microsoft.com/en-us/microsoft-365/growth-center/resources/adopting-the-best-project-management-process-for-your-business.

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

Flyvbjerg, Bent, Nils Bruzelius, and Werner Rothengatter. 2003. Megaprojects and Risk: An Anatomy of Ambition. Cambridge University Press.

Graban, Mark. 2014. “#Lean: Clarifying Push, Pull, and Flow in a Hospital; the Patient “Pulls”.” Mark Graban’s Lean Blog. February 24. https://www.leanblog.org/2014/02/flow-push-and-pull-in-a-hospital/.

Green Wiki. 2015. “Sustainable Code Development.” Green Wiki. June 9. http://green.wikia.com/wiki/Sustainable_code_development.

Hosey, Lance. 2005. “More Constructive Ways to Build a City.” The Washington Post, January 9. http://www.washingtonpost.com/wp-dyn/articles/A57855-2005Jan7.html.

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. http://www.tms.org/pubs/journals/jom/0308/kanari-0308.html.

Knee, Jonathan A. 2015. “In ‘Misbehaving,’ an Economics Professor Isn’t Afraid to Attack His Own.” New York Times, May 5. http://www.nytimes.com/2015/05/06/business/dealbook/book-review-misbehaving-by-richard-thaler.html?_r=1.

Krasner, Herb. “The Cost of Poor Software Quality in the US: A 2020 Report.” CISQ. www.it-cisq.org/the-cost-of-poor-software-quality-in-the-us-a-2020-report.htm.

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. http://sloanreview.mit.edu/article/what-successful-project-managers-do/.

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. http://leanmanufacturingtools.org/129/waste-of-defects-causes-symptoms-examples-and-solutions/.

—. n.d. “Waste of Overproduction; causes, symptoms, examples and solutions.” Lean Manufacturing Tools. Accessed November 11, 2017. http://leanmanufacturingtools.org/114/waste-of-overproduction-causes-symptoms-examples-and-solutions/.

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

Merrow, Edward W., and Neeraj Nandurdikar. 2018. Leading Complex Projects: A Data-Driven Approach to Mastering the Human Side of Project Management. Hoboken, Wiley New Jersey: John Wiley & Sons, Inc.

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. https://thisiswhatgoodlookslike.com/2012/06/10/gartner-survey-shows-why-projects-fail/.

ORC International: Expert Advisory Services. n.d. Rapid Product Development Experts. Accessed September 9, 2016. http://www.orcexperts.com/experts.asp?strSearchType=all&strQuery=rapid+product+development.

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

Project Management Institute. 2017. “Pulse of the Profession: Success Rates Rise,” PMI, https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf.

Russell, Jeffrey S., and Jaselskis, Edward J. 1992. “Predicting Construction Contractor Failure Prior to Contract Award.” Journal of Construction Engineering and Management, 118(4), 791–811. https://doi.org/10.1061/(asce)0733-9364(1992)118:4(791).

Thaler, Richard H. 2015. “Unless You Are Spock, Irrelevant things Matter in Economic Behavior.” New York Times, May 8. http://www.nytimes.com/2015/05/10/upshot/unless-you-are-spock-irrelevant-things-matter-in-economic-behavior.html?abt=0002&abg=0.

Vanderburg, Glenn. 2011. “Lone Star Ruby Conference 2010 Real Software Engineering by Glenn Vanderburg.” Published October 24, 2011. YouTube video, 51:56. https://www.youtube.com/watch?v=NP9AIUT9nos&feature=youtu.be

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.