What Serves Projects Better: Controlling or Optimizing?

The Lost Notion (and Art) of Optimization

I stated in a previous blog (When Means Become Ends,” February 2013) that over the last few decades we have seen a gradual (and, I believe, less than helpful) shift in focus within Dominant Project Management ideology and practice such that what used to be a means to an end too often becomes an end unto itself. May we begin this discussion by agreeing that the ultimate end goal of Project Management is to complete the Project successfully, with “success” defined  in terms of pre-established goals, be they temporal, financial, functional, quantitative, or whatever? In this blog I want to talk about the lost art of Project Optimization and how it is a most legitimate means to our desired end (a successful Project) that has been all but forgotten or prevented.

In our personal lives we understand and appreciate the importance of optimization, as a general concept.  But as a technical term related to Project Time Management, just what do we mean by optimization? Dictionary.com offers four useful definitions:

  1. To make as effective, perfect, or useful as possible.
  2. To take full advantage of.
  3. To plan or carry out with maximum efficiency in storage capacity, time, cost, etc.
  4. To find the best compromise among several often conflicting requirements, as in engineering design

These four definitions suggest a common implication: a willingness and ability to self-correct as circumstances change (which they always do).  It is said that the only constant in life is … change.  To be sure, we can be certain of few things in life, but one of them is that there will always be change.

Two Distinct Dimensions to Optimization

I am wondering if you happened to spot the significant difference between the fourth definition and the other three above it?  The first three definitions speak to how we do whatever it is that we have taken on to do. But the latter definition asks us to question whether what we have taken on to do is the “best” choice.  What I am trying to highlight is that, taken together, these definitions suggest that complete Project Optimization requires examining both sides of a challenge. It asks us to be open to the need to constantly reconsider whether what we are pursuing is in our ultimate best interest (the fourth definiton), as well as whether our manner of pursuit indeed holds the greatest promise of success (the first three definitions).

If you peruse Dominant Project Management literature you will find that, for the most part, Change is represented as an imposing condition that the Project Team must respond to. That is, the Change comes to the Project and the Project Team is then called upon to react to such change. Dominant Project Management thus devises Change Management as a series of recommended processes aimed at reacting to sudden Change that has been thrust upon  the Project.

As an important aside, most Change (as the term is meant and used by Dominant Project Management) tends to emanate directly from the Owner. This is not to say that Change from the Contractor or external influences is not also possible, or is not considered by Dominant Project Management. But there is an implied, if not expressed judgment, that Owner-originating Change is always legitimate, whereas Contractor-inspired Change must first be justified and then, if ultimately legitimized by the Owner, is typically heavily regulated. And as for externally-originating Change, this is characteristically portrayed as a negative condition: e.g., acts of God, force majeure, sudden shortage of key labor, etc.

The Current Ideology Disregards Optimization as a Worthwhile Exercise

Through this distorted prism, Change Management centers on limiting any Changes other than the ones which the Owner is free to introduce at any time. The question I pose to you is this: “How does such an atmosphere of strict intolerance for Change (other than the Owner’s) impact Project Management’s desire, need, or opportunities for Project Optimization?”

Of the five Project Phases, the two that are most primary and essential  are Planning and Execution. Maybe that is why the most familiar battle cry of Project Management is “plan your work, and work your plan,”  for neither phase alone is adequate: Execution without planning is reckless; Planning without execution is pointless. But only Definition 3 takes pains to explicitly speak to both phases. By including the words “plan or carry out” it acknowledges that opportunities for Project Optimization are present while both planning the work and working the plan. Do we appreciate what this definition is telling us? That there are opportunities to optimize our projectized effort, both before and during execution?  This is a major piece of advice!

How We Can Incorporate Optimization into Project Management

And while Dominant Project Management has all but ignored the importance of Project Optimization (try finding reference to it in popular Project Management literature), this guidance has been taken to heart by Cognitive Project Management which makes Project Optimization a central process both before and (repeatedly) during Project Execution.

  • At the Plan your Work phase, Cognitive Project Management has a specific process called “Optimization Planning” that is performed well before Project Execution commences.
  • At the Work your Plan phase, Cognitive project Management has a process called SCORE: Self-Correcting, Optimized Recourse Examination (which is the subject of this blog).

It is here where we see the greatest difference between Dominant Project Management and Cognitive Project Management as to how the two Project Management models recommend that Change is managed; the difference is in their respective treatment of Project Optimization opportunities during Project Execution. The difference is not just methodological, folks: it is ideological. Cognitive Project Management recognizes Change as both an opportunity and a need for Project Optimization. By contrast, Dominant Project Management perceives Change with distrust, concerned about the possible (maybe even likely) threat that the Change poses to the ongoing credibility and authority of the pre-established Initial Plan (the Baseline Schedule).

For, in the Dominant Project Management model, the Baseline Schedule is supreme, and must be maintained at all costs. In fact, according to the most influential Project Management literature, the culmination of the entire Project Time Management program is … Schedule Control. And this is defined as maintaining the schedule as a viable management tool.

Is the Current Project Management Ideology Conducive to Project Optimization?

But, I digress! Back to the topic! Under Dominant Project Management, internally-caused Change can only be sanctioned by the Owner; Owners alone can Change the Project’s scope. Likewise, only Owners have the power to sanction changes in Project Execution Strategy; Owners alone approve Contractor-proposed changes in construction approach. But Dominant Project Management training has instructed Owners to discourage or prevent Contractor changes that deviate significantly from Baseline Schedule, with “significantly” dubiously and inconsistently defined from one Owner to the next.

In such a restrictive climate, how then can a Contractor achieve the kind of Project Optimization explained in Definition 1, during either of the two primary phases of the Project?

  • Pre-Execution Phase: As to “The Plan” (planning the work), is the Contractor allowed to change the Plan once it has been accepted as the Baseline? In most contracts, the answer is “only with Owner approval;” and in some contracts, the answer is “not at all.”
  • Execution Phase: As to “Execution” (working the plan), is the Contractor allowed to deviate from the Plan so as to Optimize the work that is being “carried out?” Again, some contracts strictly prohibit deviations beyond a very narrow margin of tolerance.  Most, though, require prior Owner permission. Most contracts prohibit arbitrary deviations from The Plan and many impose stiff penalties for such deviations. Indeed, the overwhelming essence of what is thought of as “Project Controls” focuses mostly on monitoring for deviations between what was Planned and what is Actually happening!

Is such a restrictive climate conducive to Project Optimization? In what practical way is a Contractor allowed “to make as effective, perfect, or useful as possible” either its Execution Plan or its Execution Effort? It is not allowed to change its Plan once it is baselined, and it is not allowed to change its Execution Effort if such change deviates from the Plan! It would seem, then, that the Contractor has little opportunity for Project Optimization.

The Owner, on the other hand, has a very opposite circumstance. It has completely unrestricted opportunity to optimize … but rarely chooses to!  The need for a scope change may evolve naturally (and unexpectedly) enough; that is not point. Rather, it is how that new scope is handled by both the Owner and the Contractor that gets to the heart of the current resistance to Project Optimization. In practice, the Owner presents the new scope unilaterally to the Contractor: “Here it is. Tell me what it will cost to perform and whether it will extend the end date.”  That is the extent of the discussion!

Where is there any candid and receptive deliberation on whether the contemplated scope is in the best interest of the Owner, and whether perhaps there might be another “solution” to whatever problem provoked the scope change in the first place? You may be thinking that Optimization discussions may well have been held between the Owner and the Design Team, but how does that introduce ideas emanating from the implementation team, those who are the ones to put the new scope in place?

Introducing SCORE: A Cognitive Project Management Process for Project Execution Optimization

Turning out attention to the typical in-process reviews performed during the prosecution of the work, our take-away from the previous discussion is that the Dominant Project Management model does not encourage Project Optimization. But, as I noted earlier, Cognitive Project Management does. What Cognitive Project Management advocates is a formal process that is repeated with each periodic (usually monthly) progress review. We use the acronym SCORE as a mnemonic for what we believe is an essential practice to be performed in each progress review cycle. It stands for Self-Correcting, Optimized Recourse Examination.

Let’s take it apart.

  • Examination: Examination is an honest, no-holds-barred, nothing-off-the-table study of both the Plan and the Execution. The intent is to maintain a rigorous and constant vigil on how to maximize opportunities for gains on project goals and objectives. By not restricting such reviews, we are free to constantly rethink the Way Forward just as we are free to critique and modulate what we are currently doing.
  • Recourse: More of a play on words than a literal definition, the word recourse suggests laying out a different course, as in rethinking a course of action, like recalibrating. So, in the Original Plan there is an original course of action.
  • Optimization: But upon subsequent reflection and deliberation, we chart a new course, a better course, one that optimizes our chances from this point forward.
  • Self-Correction: There can be little debate that a Project qualifies as a complex adaptive system, as that term is understood by Complexity Science. A Project meets the four essential characteristics of any complex adaptive system: self-similarity, complexity, emergence, and self-organization.
    • Self-Similarity: A self-similar object is exactly or approximately similar to a part of itself.  Projects, especially as we have structured their organization and management, are almost always fractals.
    • Complexity: Complexity tends to be used to characterize something with many parts in intricate arrangement.
    • Emergence: Emergence is the way complex systems and patterns arise out of a multiplicity of relatively simple interactions. A “system involves more than the rules of the game. It also includes the players and their unfolding, moment-by-moment decisions among a very large number of available options at each choice point.” [Wikipedia].
    • Self-Organization:  A process where some form of coordination arises out of the local interactions between the components of an initially disordered system.

Now, if a Project is a complex adaptive system then it must also be self-correcting, for that is hwo it maintains healthy function. Consistent with this, our Project Management processes must therefore support and encourage self-correction, not prevent or sabotage it. As just stated, because Projects are complex adaptive systems it is vitally important that they be able to self-regulate, to self-correct through feedback. The periodic progress review cycle provides the ideal opportunity to perform such self-correction. That is why Cognitive Project Management advocates a change in ideological treatment of how Project Schedules are utilized, and behooves the Project Management community to rethink our current obsession with the notion of Project Control.

How to Incorporate Optimization Techniques into Routine Project Execution Processes

What if, rather than using the monthly schedule update/analysis cycle to identify and react to (even the most subtle) differences between planned and actual conduct, we instead use it as an opportunity to perform an introspective examination of our status and progress, and to chart a new and better Way Forward from the current position toward our stated goals? If the point of periodic reviews is to improve our chances of a successful Project outcome, wouldn’t the Project be better served by a program that seeks and seizes opportunities to optimize our efforts, than by one that fixates on preserving the authority of an Initial Plan, one that only grows more obsolete and less relevant with each passing day?

For decades I have spoken about the overly retrospective and reactive nature of most Project Management reporting systems. Folks, we need to get out in front of the power curve! My dad, a semi-pro bowler, used to tell my brothers and me to “ignore the scoreboard. Just focus on the pins, son. If you knock down the pins, a good score will follow.” Today, though, Project Managers are taught to manage by the numbers. Everything is about KPI, Key performance Indicators.  The problem is that these are after-the-fact statistics; they have no causative power. They only measure and report on what has already come and gone in the past.

By contrast, the concept behind Cognitive Project Management’s SCORE process is to make it a routine practice to constantly rethink where we are, where we are headed, what obstacles and challenges stand between those two, and what is our current best strategy for achieving our end objectives. I am all for rethinking, revisiting, and recalibrating our Execution Strategy with each cyclical pause in the action.  If we lay a new course, a better course, we will have our optimized Recourse to achieving our objectives.  This is the essence of self-correction.

I happen to believe that effective Project Management is more like playing chess than playing pinballs. The choices and actions of a player of pinballs are mainly reactive.  Gravity (and the electrical “bounce” of the bumpers) are the main opponents of the player.  The player’s response options are two flipper buttons and (if the machine allows) a subtle amount of machine “tilting.” But, mainly, the player simply watches where the ball goes, and takes one of these two actions in response. And the better player is the one more experienced at predicting where the ball will go next. And since the only variables at play are gravity and bumpers, such predictions get better with more experience.

Contrast that with a game of chess.  Chess is bound by a set of rules, but mastering of the rules alone is not enough to guarantee success.  Why? Because there is another player who is making decisions and taking actions.  Each new move is a contemplated and calculated response to the most recent move by the other player.  At the outset of a game, no player can predict with any reasonable credibility just how the game will play out: how many moves will be required to win the game, who will win, what moves will be made by each player.  Why is there such uncertainty, despite the game having very rigid rules regarding how the chess pieces can move, and so forth? The answer is emergence, one of the four characteristics of every complex adaptive system.  As the system evolves, from the actions of some components, response emerge from other components.

Project Management theory must account for the emergence of decisions and choices by Project Players all along the way. Cognitive Project Management not only understand the presence and importance of emergence, it celebrates it as the ultimate opportunity for Project Optimization.  For with each new day, and each new set of evolving circumstances, the Project Team has a fresh opportunity to optimize its efforts.  Now contrast this approach with what the ideology of Dominant Project Management, which is all about creating an Initial Plan (Baseline Schedule) and then spending the duration of the project forcing the Project Team to adhere to that Initial Plan. And as they do, all of these wonderful opportunities for Project Optimization are squandered away.  How sad.  How unfortunate. How unnecessary.  (How misguided.)

Those who defend the Dominant Project Management model will be quick to argue that the current Project Controls ideology does also call for self-correction, where identified deviations between what was planned and what has recently occurred require “corrective” actions. To them I respond that, while the word “corrective” certainly appears in this well-adopted management practice, the essential question we must ask and answer is: “what is being corrected, and against what barometer is it being corrected?” Let’s face it, one can recalibrate a thermostat, a scale, or any other relied-upon control device, but what if we calibrate it to a faulty benchmark?

You see, when we “correct” field performance so that it more closely corresponds to an obsolete and irrelevant Initial Plan, while we may technically be “correcting” our Way Forward the consequence of such correction might often be to only further separate our upcoming actions from what would be a truly better Way Forward — the very one that we might find through Project Optimization but is being ignored while we fixate on an Initial Plan and whether we are following it or not.

Your thoughts?

2 Comments to What Serves Projects Better: Controlling or Optimizing?

  1. Murray Woolf says:

    Michael, you are not incorrect at al.. But that is the point of this article; to consider the effect of such a policy. Remember the name of the Blog Series: “Thinking OUTSIDE the Box.” I chose that name because I intended to challenge the Status Quo.

    Sure, many (if not most) contracts on large public and private sector projects (that require a CPM schedule) impose the kind of restrictions you are talking about. What the article asks us to consider is whether this is in the best interest of the project.

    What do you think? Do you think that extremely tight control over changes to the schedule gives the Project Team the latitude they need to “roll with the punch?”

  2. Michael Neal says:

    Correct me if I am incorrect, there are projects that will not allow the work to be altered from that of the schedule. The use of a recovery schedule allows for deviation as to the work plan. The owners for negotiated work tend to be more acceptable to change as it benefits the project finishing ahead of schedule

What is your opinion? We'd like to know!