While many obvious warning signs exist on projects that point to an unhealthy state of being – in jeopardy of not meeting business, cost, schedule, quality and safety objectives, there exist other red flags that are not as obvious and often overlooked by project teams. Among these, five standout: 1) Re-baselining, 2) Asking Superficial Questions to Determine Project Health, 3) More Will Fix It Approach, 4) We Have Plenty of Time, and 5) We Keep Doing the Same Thing (And Expecting Different Results). Regardless of their subtlety, the impacts to projects from these red flags can be (and usually are) quite detrimental. The purpose of this paper is to explore these five not-so-obvious signs including real project experiences on how they manifest, and in so doing, establish common themes for project professionals to be cautious about.
Keywords: Project Production Management; 5 Levers; Variability, Re-baselining, Little’s Law, Project Health, Red Flags, Planning Fallacy.
SaaS Implementation Lead | Business Performance Improvement | Engineering, Construction, Defense, Oil & Gas, Tech | Helping Organizations Be The Best They Can Be | Lifelong Learner & Wellness Enthusiast
Regardless of the industry ecosystem, warning signs exist in project delivery as red flags of impending danger, a mistake about to be made or something to avoid doing, signaling the project is in trouble. They’re Robby the Robot, arms waving, loudly bellowing, “Warning! Warning!”
Everyone who has been part of a project team has seen obvious red flags. We hear things like, “We’re not getting things done on time and we’re way behind schedule,” “We’re not completing our work each day / shift,” “We’re not hitting our milestones,” “We’ve overspent on one or more areas,” etc. These statements highlight two very frequent red flags: Schedule (we’re behind) and Budget (we’re over). Both telegraph: our project is in trouble. What they have in common is when we see them, they’re the result of a trigger already having occurred, it’s the “effect” realized in the cause-and-effect relationship.
But lurking in the background are many other ominous red flag warning signs, which are not so obvious, often overlooked or ignored by project teams, and in some cases, become the norm rather than the exception, which signal their project is in trouble. This paper focuses on describing five of the most commonly overlooked red flag warning signs: 1) Re-baselining, 2) Asking Superficial Questions to Determine Project Health, 3) More Will Fix It Approach, 4) We Have Plenty of Time, and 5) We Keep Doing the Same Thing (And Expecting Different Results). Along with the discussion of the warning signs, real-world accounts are included of capital projects that have experienced these five specific red flags.
A practice that has become standard in the world of project delivery is the creation of multiple versions of master schedules to arrive to a final version that sets the baseline for project progress to be measured against it. Coupled with the use of rules of credits, this practice is now part of how most enterprises do project accounting. So, it is common these days to see a capital project following such practice including forming dedicated teams to perform it.
So, in simple terms, re-baselining means adjusting the schedule in a way that the baseline is altered due to numerous reasons specific to each project. Some re-baseline efforts focus on restructuring schedule details, but not modifying target completion dates (e.g., end dates remain the same). Other efforts include a complete schedule overhaul including changing targets dates that set key milestones’ completion for later. Independently of the case, re-baselining is a warning sign. However, and for the purpose of this discussion, we will examine the latter situation.
More often than not, re-baselining a project’s schedule to change milestones’ target dates becomes the means to address negative variance between target and forecast dates, and in so doing, recover the gap. Something most professionals involved in project delivery has either witnessed or participated in.
On the surface, re-baselining may seem like the only strategy, and therefore, considered by many as a necessary effort so the schedule catches up with reality making the project to be on time against the new target. “Just push the date out,” is a frequent remark on projects when work isn’t completed when expected. Pushing the date out magically eliminates the negative variance, or at least reduces it, on paper. So, what’s wrong with changing milestone target dates? If it fixes the schedule issues, why should project teams avoid it? (Worth noting is, if the date cannot be pushed out, more activity is scheduled concurrently resulting in the schedule becoming more “vertical.”)
Unless the reason for changing milestones’ target finish dates is the result of a top-down leadership strategic business decision to, for instance, alter asset design, this strategy is problematic. Importantly, it neglects to address the root causes for why variability is occurring in the first place and causing the slippage. And by failing to address and minimize that variability – a key lever in Project Production Management to influence the project’s outcome, slippage will likely just continue, especially if the capacity of the project production system cannot meet the demand and /or inventory levels (including Work-in-Process) are not optimal. Secondly, and from a production perspective, changing milestones’ planned due date alters the demand (desired throughput rate) the project production system should respond to. So, by constantly moving the goal aways out during the game, the project team does not have an accurate understanding of where they are really in delivery and what they should do. All re-baselining does is hide reality plus represents modifications to the ‘paper’ schedule, not the actual project production system.
As a real-world example, a facility and production capability upgrade project in Central Asia experienced the re-baselining flag quite significantly. The multi-year project was complex with multi-national regulatory requirements, intricate stakeholder network and geographically dispersed resources and supply chain, among others. As the project continued its late delivery creep, several work scopes were keen to change their milestone’s target dates further into the future as a strategy to garner more time to complete their work. However, there was little consensus on just how much more time was needed or the work execution process leading to the milestones. Nor was there a clear understanding of the root causes for the variability causing the slippages along with an effective means to mitigate future variability. Also, the team lacked an understanding of the true complexity of its integrated work. This, in addition to other factors to lengthy to include here, resulted in the team adopting a re-baselining strategy. However, very rapidly after, the late schedule variance continued, and the team saw firsthand the ineffectiveness of the re-baselining strategy. As work execution (not scheduling) is at the core of this variance, not addressing variability, not having an effective means to plan, control and improve work execution, allowing for too much Work-in-Process in the production system, not working the right things at the right time, etc., were some areas neglected of attention.
Re-baselining kicks the can down the road, as some would say. It ignores the reality of high levels of variability (especially undesired / detrimental), too much (or little) Work-in-Process, too high process cycle times, inefficient capacity utilization, along with potentially sub-optimal product and process design. Everything is squeezed to the right, putting more and more pressure on each subsequent functional team to deliver in a compressed period of time. The same situation occurs regardless of which milestone is re-baselined. Projects (even mega ones) do not have infinite quantities of time, resources and money. At some point, milestones’ target dates cannot be extended into the future as the net result is further and further compression of downstream activities to an eventual absolute project end point where you must get product to market, go-live, etc. or risk catastrophic business failure, or at a minimum, be confronted by a very angry shareholder group.
So why do project teams not see what appears to be so obvious? Simply put, they often miss this red flag because project schedules are complex, with thousands of line items and with the weeks it often takes for schedule revision – it can be too hard to see. Another reason is teams have been taught it is the right way to manage projects (we’ll discuss this aspect more in Red Flag #5: We Keep Doing the Same Thing). Also, it is common for the project team to think that because the end milestone is so far out in the future, they eventually will be able to make up the lost time somewhere, so they operate based on hope (more on that in Red Flag #4: We Have Plenty of Time).
How many times have you heard leadership / management ask you during the course of a week, or even a day, “How is it going?” “What needs attention?” and “What can I do to help?” Or if you’re a leader or manager, how many times do you say that to your teams in a week or day? In an effort to effectively support the team, ensure constraints are removed and confirm the team has everything it needs, well-intended project management and leadership stakeholders often have a habit of asking these very questions. While the intentions are good, these kinds of questions are none-the-less superficial and vague. Most importantly, they fail to reveal the project’s true health including how likely the major milestones, and the project itself, will be delivered on time.
One marine vessel maintenance and overhaul project illustrates the prevalence of superficial questions that while well-intentioned, were insufficient to understand true project health. This project had over ten redundant regularly scheduled “status” meetings held over the course of a week attended by many of the same management and project leads. The meetings’ primary purpose was to ascertain activity status, centered on repetitious updating of Microsoft Excel downloads of the P6 schedule. Typical questions asked during the meetings included, “How is it going?” “Is that done?” “What date do you want to push that activity out to,” instead of fundamental production-based questions grounded in Project Production Management principles and processes to expose true project health such as:
Needless to say, the approach used in the project meetings was a huge administrative burden and created frustration for the management and leads who spent nearly 50% of their time on administration tasks rather than actual production-centric work. And ultimately, employing superficial questions to gain execution transparency and understand delivery progress prevented the team from discerning the project’s true health.
A classic project management strategy to recover from being behind schedule is for project teams to want more – more resources, more time, more budget, etc., thinking that having more of “X” will make up for a deficit in delivery, even including doing more work – effectively opening more work fronts or in engineering, increasing the number of deliverables being worked on at any given time. The default thinking being that to complete the backlog of work, the team need more of “X,” to fix or prevent project delivery issues, such as more planning, meetings, planners, labor resources, time . . . ultimately, the team often believes they need more of everything.
It is human nature to think doing more will achieve greater or improved outcomes. While on the surface, this may seem true, however, this rarely is the case, nor does it achieve the desired result. Take for instance a multi-national defense project to rapidly build what was essentially an entire small city on a tiny piece of land in the middle of an ocean. Due to mission criticality, the project had deep pockets, which one would assume would enable project success. However, even as check after check was written to secure resources, materials, etc., the project was unable to meet objectives, construction was delayed, equipment was not available when needed or was unsuitable for the environmental conditions, information inputs were lacking, the team was unsure of where they were at with delivery, work execution was disconnected from the project schedule, work was not integrated, resources were unsure of what to work on, etc. So, even with seemingly unlimited resources, having access to more of everything, did not yield success.
Counter to Project Production Management principles, “more” will not fix late delivery, the solution is just not that simple or projects with hefty bank rolls (like the above defense project) would be completed without issue. From the Project Production Management perspective, projects are viewed as production systems, “A specific or defined set of operations within a larger supply network or value chain that produces technical or physical output to satisfy an external demand.”1 And with Operations Science, which lays out how the production system will perform, a simple example of why “more” is not the fix can be seen in Little’s Law2 relationship of Throughput, Cycle Time and Work-in-Process. Accordingly, the more Work-in-Process e.g., ISOs generation, welding, fabrication in a system, the higher the Cycle Time will be i.e., the longer it will take to complete the work. And the more Work-in-Process there is, at some point Throughout (delivery) will flatten out and not proportionally increase.
Looking at a project finish date that’s months, and especially years in the future (a typical lifecycle for large and mega-projects), it’s common for project teams to perceive there is an abundant amount of time to complete milestones and successfully deliver the project. Even when the project team sees milestones are not being completed on time and the schedule is slipping, the overriding mentality is, “We’re still okay. We have plenty of time.” And because the future is so far out and project teams believe they will eventually be able to make up the lost time somewhere, they operate on the (false) strategy of hope.
Project teams commonly only see what is immediately in front of them, incorrectly believing there is abundant time in subsequent months and years on a project to sufficiently enable on-time delivery. As projects are typically broken into multiple teams (e.g., design, procurement, construction, commissioning), it is not uncommon to see people saying that others will fix the problem later (e.g., commissioning completes construction, construction completes engineering, etc.). Also, teams intentionally add fire breaks to their project schedules for various reasons including they don’t know how much it actually takes to do the work, they’re trying to shield themselves against variability or they’re just following the conventional project management practices they’re familiar with, which include task time buffers and fire breaks as a common practice, not understanding or being aware of the implications. Examining the psychology behind this phenomenon, project teams’ over optimistic view of time and how they use it in their project delivery is due to what’s referred to as planning fallacy: “The tendency to hold a confident belief that one’s own project will proceed as planned, even while knowing that the vast majority of similar projects have run late, has been termed the planning fallacy.”3
A yearlong software development project comes to mind as a good example of time perceived as limitless. In this case, the project was behind from the beginning with the team lacking an understanding of the complexity of the effort. Although not fully implementing a non-traditional project production management methodology, the elements the team was able to employ enabled them to develop a robust production schedule that provided the necessary execution road map. However, due to the limited implementation, gaps remained including insufficient variability control, capacity not aligned with demand, process inefficiencies etc., leadership’s perception was there was plenty of time to recover the late delivery, despite project leads stating otherwise. Only through careful and constant production analytics monitoring, which provided risk data necessary to persistently escalate the criticality of the issues, were the risks mitigated and on-time delivery achieved. Had the project team been swayed by leadership’s thinking that time was in an abundant supply, and not taken appropriate action, the project would have been delivered late, missed key revenue targets and affected the product’s entire customer base.
While teams cannot wish themselves into better performance, at the beginning of their projects, teams start out with high optimism, assembling lessons learned and saying things like, “We’re going to do it right this time,” “We’re determined not to let all the bad things that happened on the other project happen on this one” and “We’re smarter this time, we won’t make the same mistakes.”
However, generally speaking humans find comfort and security in the familiar and tend to resist change to do things differently, particularly when they’re unable to consciously control change. When faced with a project that is in trouble, the team’s initial optimism morphs into hopeful expectation. How many times have you heard project stakeholders (or maybe even yourself) say something like, “We’ll be fine, we just need to try harder,” an accompaniment to that underlying hopeful expectation that the situation will improve if the team stays the course and continues doing the same thing?
Many are looking for predictability (of positive achievement) by applying the same strategies and tactics they have been using, but what they continue to get is the same result – a project that is unhealthy and in trouble. Even with the current trends and technological advances that are not effectively applied to project delivery such as IoT, digital twining, AI, modularization and more, RADM Grace Hopper’s warning to project teams of a “We’ve always done it this way,”4 mentality rings true today. This is exacerbated by the organization’s drive for compliance to standard delivery process although the success rate of the approach may be less than desirable.
Each one of the teams on the aforementioned projects, and many more that are too numerous to count, had in common the mentality that by continuing to do things on their project the same as they had been doing would somehow rescue their projects. Unfortunately, 100% of the time, this proved false and the project teams that were successful were only able to do so by augmenting their project administration perspective with frameworks, processes and systems to effectively perform project production.
If things are going well on your project – you are hitting your milestones, delivery is on schedule and on budget and you are meeting project objectives, kudos – you are in a unique place, what you are doing is working. Or perhaps, is it possible you have massive artificial task time buffers and fire breaks that are absorbing the inefficiencies and ineffectiveness of your project delivery system? If this is the case – watch out.
However, if that sweet spot (on schedule, on budget, objectives attained, safety and quality) is elusive and you recognize some, or all, of the above five red flags, or even other potential warning signs on your project, what can you do?
Here are three proposed options:
[1] Project Production Institute Glossary. Accessed Jul 21, 2024. [Online] Available https://projectproduction.org/resources/glossary/
[2] W.J. Hopp, Ph.D. & M.L. Spearman, Ph.D. Factory Physics, Third Edition, Waveland Press, 2008.
[3] Kahneman & Tversky, “Exploring the ‘Planning Fallacy’: Why People Underestimate Their Task Completion Times,” Journal of Personality and Social Psychology, Vol. 67, No. 3, pp. 366-381, 1994.
[4] B. Smith. “We’ve Always Done It This Way.” Nationalcioreview.com. Accessed: April 8, 2024. [Online]. Available: https://nationalcioreview.com/articles-insights/leadership/weve-always-done-it-this-way/