A pendulum too far
a case for action vs. detail
Rapid launches, global teaming, concurrency, and other complexities have led to teams struggling with detailed plans straining under their own weight. With today’s accelerated schedules and complex work, the assumption that planning will be completed prior to execution is often no longer valid. Our experience across several industries shows us that project teams are either held back by “analysis paralysis” or proceed without linkage and awareness to a common plan and its strategic context.
Several common myths about project management prevent team performance in this context. It is often argued that a more detailed plan with central control is better. Project managers sometimes insist that the development cycle be slowed down to do “good” project management. Steps are taken to minimize change and uncertainty, as if a perfect, fully achievable, detailed baseline plan is possible, or worse, because changing the plan itself becomes too much work. More detail becomes an impediment while creating false confidence.
This paper presents a case for promoting ACTION by teams rather than DETAIL. This approach engages teams in complex initiatives to “explore the territory rather than just drawing the map.” Projects, early on, are parametrically planned at a high level, before detail is generally available. The high-level project plan is designed in a way that makes it easy for it to evolve as the project proceeds. Detailed documentation is replaced with simple tools and real-time team exercises for rapid decision making and course adjustment. Planning becomes an ongoing dialogue. Tools for project monitoring are lean, linked to the original strategic value of the project, and allow a focus on the details that matter.
The needs for and successes from this approach based on cases in the consumer product, aerospace, HVAC, software development, and other global industries are explored in this paper.
Drivers to Detail
From the beginnings of project management a century ago, the drive to detail and search for perfect, repeatable plans have been deeply rooted in industrial practice. Efforts in “scientific management” by Fredrick W. Taylor, Frank Gilbreth and others improved industrial output through standardization of process and reduction in variation. Management became control through decomposition of work. The first principle of scientific management was summarized in a 1912 journal article: “…it is necessary in any activity to have a complete knowledge of what was to be done and to prepare instructions as to what is to be done before the work has started… the laborer has only to follow direction” (Zuboff, 1988, p. 44 ). In this view, work is analyzed by breaking it down into tasks. By doing so, work that is inefficient or purely wasteful can be identified and eliminated. These tasks are related to other tasks by sequential dependence. The work is integrated in the schedule and, due to the complete knowledge of the work, leads to performance that is optimal, predictable, and repeatable. The view promotes the belief that the ideal work process can be planned ahead of time in a scientific manner (Meiksins & Smith, 1996).
Over the last century, and in particular the last three decades, the forces that drive project managers to detail continued to increase. We present five of the significant trends from our experiences that continue to push organizations to increase detail in their plans and processes.
Increasing Product/Project Complexity
As technologies and systems evolve, products become more and more complex. The deliverables of modern projects extend beyond the product artifact to include the entire product system over a life cycle, including supply, training, services, upgrades, and support for the multiple markets the product enters. In addition, these product systems are delivered rapidly and concurrently, responding to the complex and changing marketplace.
Thirty years ago, a small aircraft gas turbine bill of material (BOM) could include 100 parts and a handful of suppliers. Generally all development teams were located nearby and in one country. Today, the BOM for a similar product would contain 1,000 parts and hundreds of suppliers that are scattered around the world.
Success of the Project Management Professional Discipline
The Project Management Institute and A Guide to the Project Management Guide to the Body of Knowledge (PMBOK® Guide – Third Edition) have been very successful in evolving the profession of program management. Thirty years ago a program manager (if the title existed) would establish a 20-line schedule and a total estimated cost. Today, planning and tracking is expected in the nine PMI knowledge areas. The expected project management deliverables and their depth continue to drive detail.
At a heavy machinery manufacturer which invested in project management practices and tools, the project management office (PMO) team facilitates the creation of project plans at several layers, bottom-up, in each product development initiative. In a recent project, the Gantt chart for a multi-year development included well more than 40,000 lines. The effort to maintain the plan became a project itself. The “conventional wisdom” is that such detail and discipline is required for success.
Planning by Cross-Functional Teams
Many organizations have evolved from small functional silos to cross-functional matrix organizations to improve the quality of products and execution. The cross-functional teams are engaged by program managers to generate “their piece” of the total program plan in a bottom-up manner. This drives much more detail at all levels, even though the performance of teams may not require the detail knowledge of effort internal to others.
Failures Leading to Process Bloat
Many organizations have improved their product quality by implementing rigorous root-cause corrective actions or post-project lessons learned. To ensure that problems are mistake proof for future projects, the corrective actions lead to creation and addition of detail to existing work processes. Reviewing and ensuring that all “previously seen” failures “will not” occur again forces more detail into standard work and thus program plans.
In a large multi-national company, cost control initiatives led to a requirement of 11 executive signatures for a resource or capital allocation. In parallel, decisions at project gateways were strengthened to allow adjustment of resources to the most critical projects. Each of these processes, viewed separately, seemed to improve the organization practice. However, the gateway decision process conflicted with the cost control processes. Even though the consequence of delay on critical projects was apparent, the detailed, embedded processes were difficult to overcome.
IT Tools for Project Management
The proliferation of information technology systems, and specifically generic program management planning and cost tracking tools have made it easier to store and manage detailed schedule, costs, resources, and scope. This has tended to drive more detail in the project plans, simply because detail is easy to add. Often this detail is not based on real knowledge.
In the 1970s, prior to the advent of personal computers, organizations often set dollar thresholds for the use of CPM.
Exhibit 1: Drivers to Detail vs. Action in Projects
Drivers to Action
We argue that the tradition and recent drivers in our project management profession have pushed the pendulum too far toward detail. Pushing the pendulum too far has negatively impacted performance, as project mangers defend detail without a measured focus on strategic results. In fact, while these drivers to detail in our profession continue, the recent work environment has introduced counteracting drivers. These five drivers to action urge us to pull the pendulum back, towards action and a less onerous emphasis on detail.
The markets for most products continue to become more dynamic, as customer expectations change ever more quickly and unexpectedly. These changes often make large portions of a detailed plan useless. This reality tends to push project teams to focus on “doing” rather than “planning.” This rapid change also reduces the relevance of experienced-based judgment in planning. “In the past, the rate of change was rather slow, so in a person’s lifetime change was virtually imperceptible. But now, in a lifetime, one experiences significant change influencing all aspects of life” (Jaafari, 2003, p.49 ).
Many corporations are recognizing the need to increase response to market dynamics. At Honeywell, the chief innovation officers get part of their bonus (15%) based on time from idea to market (Lafley & Charan, 2008).
Impact of Detail
Getting and maintaining detailed plans clearly has a cost and schedule impact. The detail must be collected, loaded into IT systems, and maintained throughout the project. Some aerospace projects can have program plans with tens of thousands of tasks, each with timing, scope, and resource information. The cost of simply maintaining these plans can be 2% to 5% of the total program cost. Many organizations are beginning to question if this detail is delivering the desired value. With so much detail overwhelming the capacity of teams to understand the basis of the plan, some choose to ignore the plan and focus on their part of the schedule only.
A large chemical corporation embarked on a supply chain transformation. The project manager created a 60-page Gantt chart, which was passed among the team leaders each week. Much effort was spent in maintaining and trying to understand the plan, which evolved haphazardly as real-world deadlines continued to pass. The team leaders reported “We have no view of the forest for the trees.” Since the detailed master plan was no longer relevant to their day to day activities, the project managers were driven to duplicate management effort for their teams, creating ad-hoc spreadsheets with measures of progress, and simple tracking. The meaning and impact of dependencies across teams were not visible.
“Lean Process” Initiatives
Quality systems like ISO, Six Sigma, and the root cause corrective action/mistake proofing (as mentioned previously) have driven many organizations to be process heavy. This trend in turn has forced project teams to execute tasks which may be required by the process yet do not add value to the customer or to the stockholder. Recognizing this problem, many organizations are driving “lean initiatives” or the development of “lite” versions of their processes to help project teams focus on getting the job done (action), adding detail only where appropriate.
Globalization has allowed many large organizations to deliver their products in larger markets. In project management this means that project teams now include new team members, suppliers, and customers in other countries, in multiple time zones, and various languages. As the “old processes” and project estimates were based on local work, they are often unusable or irrelevant. These global unknowns reduce the value of detail and drive program teams towards “doing” rather than “planning.” Even local projects, driven by the diversity and change in the workplace, are confronted with these unknowns (Lipnack, 1997). Teams will need to adapt through action, rather than relying blindly on detailed old processes and judgments.
Due to many of the trends in business, many large organizations are evolving to become “system integrators” and, as a result, increasing their dependence on expertise of their component suppliers. This typically helps to reduce financial risk. On the other hand, to protect their expertise, suppliers tend to be less willing to share the detailed cost, schedule, resource, and risk information that may have been available when things were done “in-house.”
A project team in the consumer products industry was installing the manufacturing equipment to manufacture a new liquid laundry product. The date of first production was established early-on, and the team focused intently on achieving the date, spending over $250,000 to accelerate critical items. Having achieved the goal, while overcoming significant equipment and construction delays, the team proudly reported production readiness, only to learn that negotiations with a critical supplier were incomplete and that the product was to be delayed several weeks.
Balanced, Forward-Looking Approach Emphasizes Action over Detail
While it is understandable that the pendulum could swing so far, given the tradition of project management and the drivers to detail, the current work environment and key trends require us to balance detail with lean, adaptive, action-oriented management approaches.
We offer our own experience across several industries. Given our backgrounds in product development and global manufacturing, we observe that our experiences, project to project, have been to mitigate waste and risk from detail while pushing teams toward action and awareness. We encourage a view of the whole project, rather than a partial view of its parts. The elements of our approach emphasize progress under uncertainty, high-level representation of the key aspects of the project, and—most importantly—the action of teams “exploring the territory” to inform ongoing planning, decisions and adaptations as the project evolves. These elements are shown in Exhibit 2.
Exhibit 2: Components of a balanced, action focused approach
Parametric Basis of Scope
A detailed schedule requires a chain of planning steps; the mapping of requirements to scope, to direct effort, to teaming, to scheduling and so on. If the requirements or scope options to fulfill those requirements change, that chain of planning tasks must be revisited.
We have found it effective to capture—early-on—the scope in parameters of progress and deliverable, related to one another in a configuration. This high-level parametric model can be simple, captured in a spreadsheet, and makes sense both to marketing and the project team. It is not an expression of duration, total effort, or cost. The parametric basis of scope shows the mapping between requirements and deliverable options at the project charter. As requirements or deliverables change, the parametric scope model allows a quick re-calculation of total deliverables and direct effort, which in turn drive accurate forecasts of the change in cost, schedule, and quality.
An industrial equipment manufacturer launched a new global platform with products to be derived for each region. The original completion date target was based on a complexity estimator, taken largely from industry benchmarks and historical data. Naturally, as the project moved from phase to phase, much was learned about scope, options, and feasibility. However, the original deadline and matching schedule were not adjusted. After the project finished YEARS after the original target, it was shown that a simple parametric model of scope would have been easy to update and would have revealed an accurate forecast of completion within a month rather than years.
Top-Down Design of the Project and Early, Realistic Forecasts
The next step is to begin the design of the project, top-down, for consideration of architecture, teaming, and initial forecasts of duration and cost. Since a bottom-up planning approach does not make sense yet, this “project design” approach can rapidly (1) provide meaningful forecasts of duration and cost and (2) expose the important dynamics at the architectural level for the project at hand.
These early designs of the project begin with the default workflow and teaming from a company’s standard work. High-level concurrent and mutual dependencies are easily captured. Teams are engaged in workshops to see the total activity and how their role links to strategy and the work of others. This total activity includes the integration of product, process, and organizational structures (Pugh, 1990). Detail is added as teams discover real knowledge about the nature of the work and their capacities. A baseline plan at a sustainable level of detail emerges.
The important social role of these sessions is to confront the project manager and sponsors with realistic estimates as early as possible, preventing the false precision of detail from creating confidence without evidence. In complex projects, as typically 30% to 50% of cost and duration is driven by coordination effort across teams, it is common for traditional planning to miss up to half of the effort required. (Moser, 1999)
And so this early project plan is less detailed yet more meaningful. The decision making by the project manager and team leaders is architectural. The project team designs and architects their project for the situation at hand. Joel Moses, a pioneer in thinking about how knowledge, architecture, and people interact, calls this the art of decomposition. “A big architectural idea breaks a problem up in really big ways. All you need is one or two of those, and you can win big” (Vargus, 2000). “Big ways,” he emphasizes, not detailed ways.
The design of a transformation project in the outsourced services industry showed most likely completion at least one year later than expectations. Even with increased concurrency, scope paring, and accelerated hiring, the best, feasible plan would generate results five months later than hoped. The executive sponsors confronted the result with a simple (and loud) “Unacceptable!” They had already promised the boss. Ignoring the design result, the sponsor increased detail and control, forcing an infeasible schedule into the baseline plan. The end result, two years later, was even worse performance than the original estimate. Teams struggling under detail and infeasible expectations were less able to perform. Had they followed the original design, the project would have completed a year earlier.
Teams Explore the Territory
We have found that the value of engaging a team early is not bottom-up detail, but instead exploring what is behind the scope targets and exposing the risk territory. We involve the teams to challenge assumptions in the plan, pursue detail through action and evidence, and then to confirm or adjust the assumptions that matter the most to overall project strategy. In parallel, their involvement early builds awareness and ownership in the overall project.
Therefore, the role of teams in not to just follow a prescribed, detailed direction, but to confirm the feasibility of the plan within their team’s responsibility while looking forward to progress and adjustments. If they see a roadblock or reason the existing baseline forecast is not accurate, they are to pursue other ways of proceeding. They know when it is important to deviate from the planned route for systemic project success.
One of our co-authors was en route to an appointment in an unfamiliar city several years ago, following detailed directions provided by his hosts: Exit the Interstate at exit 110, turn left, proceed five blocks and turn left, proceed three blocks and turn right, and so on. Unfortunately, a truck accident had occurred an hour or so earlier, and the highway had been cleared by removing wreck to the exit ramp, thus closing the exit. The only way to find his destination was to exit the interstate at the next exit, which happened to be several miles away, and drive back to exit 110 on city streets , where he could resume to follow the instructions he had been given. In project management terms, the unquestioned reliance on a detailed plan caused a significant schedule delay.
Baseline includes Mechanisms and Agreement for Change
Sometimes a detailed baseline causes commitment to the schedule, rather than a commitment to the deliverable itself: a winning product. Therefore, the early design of the project and baseline plan should define sufficient progress—at a high level—in strategic and deliverable units of measure. With these terms in place, a mechanism to report when data shows that change in the baseline may be required. For example, an arbitrary deviation of one percent from the baseline may not have relevance for the project at hand. In contrast, not delivering a key fourth prototype by a key milestone, causing a specific supplier cost, has meaning and is linked to strategy.
The IT division of major international company was upgrading all the employee workstations to a new platform. Because the laptops used by the sales division were near the end of their leases, the project manager decided to issue new laptops with the new platform already installed, thus significantly reducing the overall project cost. Unfortunately, once this decision was made, schedule became the critical project objective, and the fact that the new platform was incompatible with some unique software used by the sales division was completely overlooked. The inevitable result was an enormous productivity loss, for both the project team and the sales division.
Assumptions Tested through Knowledge Events
As teams proceed with their own work, they should be aware of which assumptions and targets in the current baseline plan need to be tested (e.g., parameters in the scope: tests needed per model family, effort per drawing, degree of concurrency, dependency strength). We refer to these “knowledge events” as the action that reveals real evidence about the project at hand. The events should be focused, limited, and with an immediate course of action (the mechanisms listed previously). Similar to smart prototyping in product development, we promote prototyping the project activities so as to replace assumptions with evidence in critical areas of the baseline plan.
A team in an air conditioning manufacturer was developing a new chiller. Months into development testing, the team determined that two of their design targets could not be met simultaneously. The knowledge event showed that one key risk could not be mitigated in time. Based on a good parametric program plan, the team quickly assessed the schedule and cost impact of various compromise scenarios. At an emergency stakeholder gate review, the scenarios were evaluated and a decision made to adjust one of the design targets, change the baseline plan, and proceed. The product was delivered on time, with sales surpassing the business case. This example of “lean decision making” by the project team enabled them to quickly assess, decide, and re-baseline.
Acceptable Baseline Change Based on Data
In many organizations, the discipline of earned value management has reached a point where a “change to the baseline” is a failure of the project management process. This is unfortunate and tends to drive behavior where “meeting the plan” is more important than deliver of the “right product.” As we have said, market dynamics are ever more quickly changing the needs of the customer. To be successful, teams must quickly react to scope changes and update the baseline. To do this, there is a need to quickly assess the impact of desired changes, and then reach agreement on the change with the project stakeholders. This is difficult unless the team has a parametric program plan that can easily assess the impact of the scope. Detail program plans, with tens of thousands of tasks, make this very difficult.
A manufacturing plant in a semi-arid part of the United States was ordered to reduce its water consumption by 10%. Although the plant was already one of the most water-efficient facilities of its kind in the world, the project team compiled a list of additional recycling and conservation measures, and began implementation. Several months later, the company decided to close down an orange juice facility that happened to be located at the same site, thereby reducing water consumption by almost enough to meet the mandated target. The project team was thus able to return the unspent funds to the company. Had it been focused on implementing the project scope according to the initial plan, this opportunity to achieve the real goal without additional spending would have been missed.
Ongoing Re-Design Maintains Plan and Team Awareness
With the other elements in place, the projects teams are now capable of rapidly re-designing the baseline in response to acceptable baseline change (Moser, Murray, & Woodward, 2005). With early involvement, events tied to strategic decisions, and an ongoing planning dialogue, teams are much less likely to become isolated in their own local schedule silo. In contrast, details without linkage can become a wall insulating a team from strategic consequences. Awareness leads to teams able to make smart adjustments even as traditional project planning would have them wait.
A paper manufacturing company with five plants across North America decided to increase its manufacturing capacity by embarking on a debottlenecking program. A project team was formed to install the necessary equipment and charged with completing the work in 18 months at a cost of $26 million. But almost immediately, the project team was asked to defer major expenditures until an unrelated cash flow problem was resolved. Rather than stop work completely, the team adopted a strategy of prototyping the technologies on which the debottlenecking program was based, and actually developed some cheaper and more effective solutions. Even when the project was authorized to proceed, the team continued this same approach. The project eventually spanned five years, but the resulting capacity increase was three times the initial commitment. Not surprisingly, the company immediately appropriated another $40 million to continue the program.
We have described tradition and drivers that led to an overemphasis on detail—a pendulum swinging too far to one extreme. In contrast, we presented drivers to action, which reveal pressure on project teams to perform faster, adaptively, and globally, but these drivers conflict. The pendulum needs to swing back. We presented examples of practices we have deployed to move the pendulum back.
Indeed, these trends are not limited to project management. A view that natural and social systems perform best when adaptive, coordinated yet de-centralized, and responsive to natural uncertainty is transforming many fields. “Mankind is at a turning point, the beginning of a new rationality in which science is no longer identified with certitude and probability with ignorance (Prigogine, 1997, Introduction)
Therefore, this view challenges the thinking from a century ago, in the roots of our profession.
They (American managers) learned from Taylor and others like him that the interior of the labor process had to be penetrated, explicated, and rationalized. Buried in the detail and habit of each task was a hidden truth -- the ‘one best way’ to accomplish the work according to criteria of efficiency. Workers left to perform on their own would never achieve a ’scientifically’ rigorous organization of their tasks. (Zuboff, 1988, p. 230 ).
By adding flexibility, we are not finding that “one best way” in our original baseline plans. It is a compromise. According to Joel Moses, “What you want to do is build in flexibility into a system, so the kinds of changes that the user or customer is likely to want to make are the ones that are easy to implement.” This often leads to a non-optimal design, but “updating an optimal design will often times cause you to make a change which is far from optimal.” With the fast rate of change in today’s world, Moses believes “you have to make it easy for the next guy to make changes readily, even if this means the loss of optimality” (Vargus, 2000)
We recognize that many others have been teaching best practices, fine-tuning the PMBOK® Guide , and in many ways responding to these same drivers for performance in modern project management. We hope our discussion adds a voice to theirs and look forward to the exchange of ideas.
Jaafari, A. (2003, December). Project management in the age of complexity and change. Project Management Journal, 34(4), 47–57.
Lafley A. G., & Charan, R. (2008). The game-changer: How you can drive revenue and profit growth with innovation. New York: Crown Publishing Group.
Lipnack, J. & Stamps, J. (1997), Virtual Teams: Reaching Across Space, Time, and Organizations with Technology, John Wiley & Sons, Inc., New York.
Meiksins, P., & Smith, C. (1996). Engineering labour: Technical workers in comparative perspective. London: Verso.
Moser, B. (1999). Understanding coordination, communication and rework in globally distributed projects. Paper presented at the meeting of the International Association of Product Development, Peachtree City, Georgia.
Moser, B., Murray, P., & Woodward, H. (2005). TeamPort software for visualization and forecast of concurrent dependence during design of complex projects. Paper presented at 7th International DSM Conference, Seattle, WA.
Prigogine, I. (1997). The end of certainty: Time, chaos, and the new laws of nature. New York: The Free Press.
Pugh, S. (1990). Total design: Integrated methods for successful product engineering. New York: Addison-Wesley.
Vargus, A. M. (2000). Structures and the art of decomposition. Retrieved on 6/15/08 from http://sdm.mit.edu.
Zuboff, S. (1988). In the age of the smart machine. New York: Basic Books.
© 2008, Bryan Moser, Global Project Design
Originally published as a part of 2008 PMI Global Congress Proceedings – Denver, Colorado, USA