Managing Director & Senior Partner
The science of managing large-capital-expenditure energy projects has undergone considerable development. Google “large project management” and you’ll quickly get a sense of the abundance of information now available on the subject: a host of consulting companies, auditing firms, software publishers, and others offer a variety of managerial tools and rules, including sophisticated frameworks, templates, reporting models, software, and workflows. Yet major projects often encounter delays and cost overruns. There must be a flaw in the science somewhere.
We believe it lies in something the literature does not address: what the people involved in the project are actually doing. Conventional wisdom holds that successful project management largely hinges on having the right managerial tools and rules in place. But project outcomes are ultimately determined by overlapping human actions that are driven by the requirements of the work that individuals are doing and their behaviors and decisions as they do that work. Surely, project management philosophies should reflect this fact and focus on how to influence those workplace realities to the project’s advantage?
Unfortunately, that is not the case. Instead, companies tend to stick with the conventional wisdom, to their detriment. The processes, rules, and standards (as well as the common goals, mission statements, and visions) that companies routinely employ are poor influencers of behavior. And when they do influence behaviors, the outcome is rarely the desired one. Rather, it’s often defensiveness and an outsize focus on meeting procedural standards: “Hey, I’m doing precisely what the rule book says I’m supposed to be doing.” Such reactions can come at the expense of actually doing what it takes to get the job done. The result: projects underperform.
BCG has witnessed this across industries and geographies and at all management levels. Our experience has shown us that the problem goes beyond a lack of the right capabilities, company culture, or project management handbook. The problem is project management without a realistic sense of and plan for work on the ground.
We believe that companies fall particularly short in one critical element of project management: scheduling, a discipline that often gets short shrift despite its significant potential to determine a project’s success. One of the most damaging practices in scheduling is an overemphasis on dates. That seeming paradox is actually a key to unlocking insights, improving communication, and more.
To run a project well, you need good schedulers. Scheduling has long been perceived as a largely administrative task, but belief in its importance is growing and, at many companies, a shift to place scheduling at the heart of project management is under way. Many organizations are scrambling to build internal scheduling expertise; others are recruiting from the outside. Yet if you ask today’s most sought-after schedulers why their services are now in such high demand, most will likely say they don’t know.
What do managers expect from their project schedulers? Primarily, they want them to deliver a schedule that, when incorporated into the company’s offer to a client or prospect, sufficiently meets expectations to allow the company to win the tender. Managers also rely on project schedulers in the execution phase, when schedules can aid in setting targets and monitoring teams’ progress. But what managers really want from their schedulers is not the schedule itself but the specific dates—for milestones and so forth—that they can use in their own reporting and in negotiations with their teams, clients, suppliers, and, of course, their own managers.
The problem is that the dates that they request and receive typically do not correspond to what people on the project will, or even can, actually do. Instead, they represent the deadlines that the company committed to (influenced by the company’s competition, the client’s targets, and other factors) when it pitched for, and won, the project. They also reflect managerial objectives or ambitions. Once these dates are in place, though, managers will use every trick in the book (and some not in the book) to create the illusion that those targets can be hit. Let’s face it—who wants to be the one to announce that the project is behind schedule?
If, in the traditional scenario, some smart scheduler created a schedule that had realistic dates, he or she would likely be told to redo it. We once saw the scheduling team of an offshore engineering, procurement, and construction company replace its carefully calculated dates with dates based on the initial assumptions made by senior management because, the team was told, the latter were the “right dates.” In another example, when the procurement team of a European transmission system operator was involved in a scheduling exercise, it would first ask for the completion date expected by senior management; the team would then provide milestone dates for schedulers by working backwards.
With examples like this, it’s easy to understand why schedulers are perplexed by companies’ increasing eagerness to pay for their skills.
Schedulers who adhere to predetermined dates do so at great cost to their professional integrity. Schedules that are largely representations of managerial ambition, contractual objectives, or wishful thinking offer users poor predictability and, over time, become increasingly disconnected from the reality of what people are actually doing on the project. This translates into wasted time for skilled staff and managers. It can also jeopardize a project’s success.
Inevitably, when projects are governed by such schedules, things unravel. Planned tasks are not completed “on time,” and milestones are missed. The schedule is then redone to take these misses into account, but only by making patchwork adjustments that are as unrealistic as the first ones were, given that the original final target date stays put. (See Exhibit 1.) For a pulp and paper company that was constructing a plant, for example, management’s solution to a slipping schedule was not only to reduce the scheduled duration of future tasks so as to maintain the original final target date but also to accelerate future milestone dates by another 10% in order to “create” greater float in the overall schedule.
In such cases, the scheduling of future tasks is not viewed through the lens of what people will actually do; rather, it is an isolated and bureaucratic process. Faith in the schedule’s credibility is lost: the only thing about the schedule that is now certain among would-be users is that it is wrong. Consider, for example, the schedule created for the construction of a new power plant: ultimately, it was used by no one except the arbitration lawyers, who found it easy to show that critical dates were not met.
A dysfunctional schedule has ripple effects. Project teams are hauled in front of ad hoc reporting and steering committees to explain why the first milestones were missed and how the project will get back on track. Meanwhile, no one is concerned with the bizarre otherworldliness of the schedule. In fact, when mayhem finally breaks loose, the schedule will give managers their only bit of breathing space: when the top brass asks for an update, all managers will need to do to get through the meeting is point to the schedule, whose final date remains intact. Managers can then continue working frantically with the best assistance that they believe they can get from their superiors: zero interference.
Because the original, unrealistic schedule provides poor predictability and diverts managers’ time and attention, subsequent hurdles are not anticipated. Delays accumulate in waves, managers are increasingly taken off guard, priorities become unclear, contradicting orders become the norm—and the project sinks even further.
When the project is foundering, the schedule is no longer injecting urgency into the effort or improving results. Instead, it has anesthetized the company by hiding the issues under the illusion that things are proceeding on time and, therefore, satisfactorily. Internally, however, the project organization is fractured. Those who know about the problems try to correct them, without seeking help from senior management; doing so would require letting on that a crisis is brewing. Those who don’t know about the problems wonder, in the ominous silence from the project front, what on earth those project teams are actually doing. If delays are not visible in the schedule and are not visible to the organization, help in solving them will certainly not be forthcoming.
How to fix this? As stated, the solution to the problem isn’t to develop a new project management handbook or competencies. Instead, it lies in changing the behaviors of the project’s very competent and engaged managers, schedulers, and other stakeholders, who are working under immense managerial or contractual pressures. One effective way to optimize these individuals’ behaviors is to remove the initial constraint: the dates.
Yes, make a schedule that has no dates—a chart without the x-axis.
We know this well from experience. When BCG is asked to reestablish a baseline for a troubled project and produce a schedule, we start by literally banning dates from the discussion.
Our first workshops focus solely on defining the work process—identifying all the deliverables and mapping all the interfaces among them. We aim to reach a perfect understanding of the actual sequence and interdependencies of the events and actions that underlie the remaining work. It’s not about when each bit of work will be done; it’s about what has to be done and in what order, and why it has to be done—how many pipes have to be welded or thermometers calibrated—so that X, Y, and Z can happen next.
Similarly, we do not determine the duration of a given activity according to its proximity to the next target milestone date. Rather, we determine it on the basis of the relationship between what needs to be accomplished and the company’s productivity and resources.
Of course, a schedule without dates doesn’t serve its purpose. So, once the optimal logic flow and activity durations have been determined, dates can be calculated using a set of concrete physical assumptions (about such factors as quantities, resources, and working conditions).
The work doesn’t stop there, though, because the result might still fall short—the target date set by top management might not be reached or the overall schedule might not constitute a competitive bid. But the situation is now totally different.
First, managers can now discuss commitments with their clients or senior management armed with full knowledge of the actual risks associated with the project and the conditions necessary for completing it.
Second, there is now more time to fix issues as they arise or even before they arise, because they’ve been properly anticipated. Teams are also more open to talking about problems (and therefore fixing them), because the problems have been identified through a transverse and collective process that is based on an objective technical model (rather than a manager’s falling short of his or her personal performance objectives).
Using this approach liberates intelligence that had been contained by the tyranny of dates. Scheduling becomes a truly value-adding exercise. It can also help a project in danger of derailing get back on track. (See Exhibit 2.) What’s more, engineers and other experts can be called upon to speak up and be creative rather than being kept out of meetings (or, worse, sitting through them in uncomfortable silence). Managers will have a solid footing for engaging in technical discussions with their superiors—and they might be pleasantly surprised. They might discover that their superiors, just like them, reached their positions not because they could come down the hardest on an already hard-pressed team but because they know something about devising solutions to problems.
Removing dates from the scheduling process does not loosen the overall rigor of project governance. Instead, it reinforces cooperation along two dimensions. In horizontal cooperation, once-siloed divisions or units contribute to a collective success rather than fight to protect their own margins.
We used this approach to resolve a long-lasting dispute between a nuclear-engineering procurement and construction company and its civil work contractor: when the sole objective of their meeting was to negotiate the final completion date of a building, both parties became locked in arguments that were not constructive. By removing the dates, we forced the discussion to focus on the actual industrial process. Technical solutions (including agile management of skilled steel reinforcement workers) emerged and even accelerated construction. In vertical cooperation, discussions with managers become more fruitful because they focus on solving future problems rather than pointing fingers for past failures.
Enormous responsibility falls on the shoulders of project managers, who face competing demands: they are supposed to be responsive to the considerable pressure from their own managers and clients to meet established schedules; simultaneously, they’re expected to encourage transparency among the project team regarding future problems and to ensure realistic scheduling.
To strike this balance, managers should accept that a milestone actually has a virtually infinite number of possible future dates. These dates include the one targeted and communicated by senior management internally or by the company to the client; the one expected by the project team, given the team’s current knowledge; and many others, each having its own degree of probability given known risks and unknown factors. As shown in Exhibit 3, actions and decisions regarding industrial aspects of the project that are taken or made with the intention of increasing productivity (that is, moving to the left on the project duration timeline) or reducing risk (that is, narrowing the range of related risks on the risk distribution chart) do not affect the project’s completion date; rather, they affect the probabilistic distribution of tasks involved in reaching completion. Viewed through this lens, the schedule can become an extremely useful representation of managers’ critical path amid a high degree of uncertainty, one that can guide their day-to-day industrial actions, rather than a constant reminder to managers of their own wishful thinking.
Transparency in scheduling is worth the inevitable efforts required to achieve it—and managers can actively encourage transparency by asking the right people the right questions. They can ask, for instance, for the project development’s logic flow rather than a simple series of dates—that is, the how instead of the when—and recognize that issues (such as missed milestones) that arise may reflect not the wrong dates but rather an entirely wrong scheduling approach. Managers can also reward transparency over compliance with the initial schedule.
By focusing on what people actually do in projects, managers can ensure that schedules are not just another deliverable. Instead, scheduling can become a process that adds significant value and helps managers productively allocate resources, suggest workarounds, and optimize decision making.