Scale makes it different

---

Scale is its own thing.

Bigger is not always better, but it's always different.

For that matter, so is smaller.

Look no farther than physics: 

• Smaller: Sub-atomic quantum physics features particles with properties that are statistically uncertain, but those same properties would be deterministic but for the small (!) size.
  
  
• Bigger (or greater): For objects moving at near the speed of light the laws of physics don't change, but the math does (Einstein's theories). For example, you can’t just add velocities together the way Galileo or Newton did; you have to add them relativistically. You can’t just treat distances as fixed and absolute; you have to understand that they contract along the direction of motion(*).

What about projects at scale?

At large scale, one observer (*) has said: "The quantitative becomes qualitative" meaning: when it gets big, the whole thing takes on a different character, apart from the numbers. Example: soloist vs a choir; a few people vs a crowd; the Grand Canyon vs a gorge, and so forth. 

There's a lot going on in big projects; some stuff we all know about and have experience with:

• Communications degrade qualitatively and exponentially with the number of communicators. If two people are talking to each other, it's merely bi-lateral. But if 5 people talk among themselves, there's 5*4 ways that communications can flow: N*(N-1)
  
  
• Bureaucracy inevitably replaces personal trust and one-one relationships. You can't know and trust everyone is a large project with myriad subcontractors (1099s or entire companies), remote team locations, etc. So bureaucracy has rules, workflows, organization structure, and other institutional relationships to replace and substitute for personal relationships.
  
  
• Interfaces, whether institutional in the PMO or as part of systems of deliverables, become all so important. You may not have any visibility or understanding beyond the interface specification you must meet. (See: Systems, below)

 But there are other influences that are prominent at scale:(***)

• Systems is the way you think about things. Anything really large has properties of systems, and so you have to think like a systems-savvy person: interactivity; interconnections; dependencies; sequencing; process and constraints; chaotic and impulsive behavior. If you don't know much about systems, start here.
  
  
• Phase or state changes: Increasing complexity arising from increasing parts is usually not linear; there may be abrupt changes of state or performance. Suddenly there are walls you can't get through; people you can't reach. Or, machines reach their absolute limit, beyond which their performance is unpredictable or unreliable
  
  
• Reduction vs construction: What you can disassemble you may not be able to reassemble or construct from the pieces. An unintended explosion may be an "unmanaged disassembly" in systems' speak. You can't put Humpty Dumpty back together.
  
  
• Symmetry, or not: If it's symmetrical, then it looks the same from all points of view. As things scale up, symmetry is often, if not usually, lost. There are just too many different points of view.

Scale effects on cost and schedule

Scale has two effects on cost:

1. Scale increases friction with so many moving parts to the project. That is a cost increase, albeit with the benefit of having access to myriad capabilities and functionalities
2. Scale is improves efficiency, making cottage industry efforts into industrial strength workflows, thereby reducing cost.

Scale requires "loose coupling" in schedules. 

That is, white space or buffers are needed to accommodate a dizzying number of dependencies and interactions. And loose coupling protects the critical path, as we know from Critical Chain scheduling. All of this has a combined effect of stretching the schedule. But that's the "cost of doing business" at large scale.

 

-------------------

(*) Karl Marx

(**) Attribution: Ethen Siegel

(***) If you are into science, read this oft-cited paper: "More is different"

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Shifting baseline syndrome

---

It's a rare project of any significant scale that does not rebaseline sometime in the life of the project.

Why rebaseline?

The PM rebaselines when the "old" baseline is no longer relevant as a guide to management. Either cost, schedule, or scope have gotten so far off the original baseline that the baseline is no longer valid for future management decisions. Thus: rebaseline.

How do you go about rebaselining?

• Gather all the actuals and variances in the current plan. Archive that data.
• Replan the future from the present. That is the new baseline
• At the end of the project, add the archive to the new baseline performance for the overall project performance.

Shifting Baseline Syndrome

Shifting baseline syndrome is the phenomenon whereby, over time, the "old" baseline drifts out of memory, or perhaps new staff never experienced the "old" baseline. We acquire the mantel of the new baseline, and all seems fine in this "new normal" which morphs to just "normal".

Measurements are taken against the new baseline; in effect, the goal posts have been moved. We become insensitive to the position where the goal posts used to be. The new position is accepted as normal, and we move on from there.

Countering the syndrome

Actually, it's not really necessary to counter the syndrome day-to-day and you wouldn't want to if you could. The new baseline is your management plan going forward.

It is only necessary to keep in mind at the PMO level that there is an archive of actuals and variances to be accounted for at the end of the project. 

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Are you sinking? Or sunk?

---

Let's keep the basics in front of us:

• Projects are transformative processes packaged together
• Inputs (cash, people, buildings and tools, overhead like training) are transformed into deliverables that don't remotely look and feel like the inputs
• Deliverables are much more valuable than the sum of the inputs

Too often, the focus of the 'business' is on the inputs being consumed, like cash-flow and resources consumed, whereas the more experienced among us keep an eye on input/output efficiency.

And what do we mean by I/O efficiency?

We mean how well input consumption corresponds to its planned value, and how well the corresponding outputs conform to (planned) expectations, when each is sampled--measured--observed in the same time period.

What about sinking and sunk?

Once the project grabs input and consumes it, that input is "sunk", and can't be changed or refunded

Most of us are familiar with the first law of 'sunk' resources: 'Don't use the sunk resource to make a decision about a sinking project". 

Those focused on the sunk resources are focused on inputs rather than outcomes; are focused on the rearview mirror rather than the windshield, and may not understand the opportunity for adjustments.

That is: the future of your project--if it has one--should stand on its own merits re how resources will be used in the future, not so much how they were used in the past.

Why this first law?

Because at the moment you are challenged--even a self-challenge--to justify your future by citing the past, that is the time to root cause analyze the efficiencies. Depending on the analysis, you will have an opportunity to make decisions to alter the likely future efficiencies, and you have the opportunity to 're-baseline'

The future may not "wash-rinse-repeat" what has already been sunk.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Making a prediction?

---

Making a prediction?
Something to forecast?

Milton Friedman (deceased now), distinguished economist and notably conservative when it came to finances has this advice

If you're going to predict, then predict often!

Yes, it's a bit humorous. But it's also true, to wit: the future is uncertain, subject to change, and subject to change unexpectedly and perhaps even near-term. So, Friedman might have said:

• Sampling theory tells us to same at least twice as fast as the changing situation we're engaged with.
• If we can't reasonably estimate whether change is linear or exponential, then "sample early; sample often"
• Long-term predictions are of low value (See: sampling theory, above)
  
  

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

What's the worst case?

---

Perhaps the most common question in risk management, if not in project management is this one:

"What's the worst case that can happen?"

Don't ask me that!

Why not?

Because I don't know, and I'd only be guessing if I answered.

So what questions can you answer about the future case?

• I can tell you that a projection of the past does not forecast the future because I've made the following changes (in resources, training, tools, environment, prototypes, incentives, and .....) that nullify prior performance ......
  
  
• I can tell you that I can foresee certain risks that can be mitigated if I can gather more knowledge about them (Such being a Bayesian approach of incrementally improving my hypothesis of the future outcomes). So, I have the following plan to gather that knowledge ......
  
  
• I can tell you that there are random effects over which I have no control and for which there is no advancement in knowledge that will be effective. These effects could affect outcomes in the following ways ......
  
  
• I can tell what you probably already know that the future always has a bias toward optimism (there's always time to fix it), and that there's always a tactical bias toward "availability" (one in hand is worth two in the bush ....) even if what's available is suboptimum.

Heard enough?

So go away and let me work on all that stuff!

quality Assurance is free; QC is not

---

Philip Crosby is credited with the idea that "Quality is Free", and he made some money on the book by the same title ... still available from e-book sellers.

When I first heard that phrase -- around the time Crosby's book came out -- my thought was: If so, what is that line item in my budgeted WBS for quality planning and QC? It's not $0 for sure. So how is "quality free". Admittedly, TQM was everywhere at that same time (*)

Actually, the idea here is quality Assurance vs. quality control. The former is "free", perhaps even a profit center; the latter is always a cost, sometimes bolted on at the end.

Characterizing QA as a profit center has these business ideas embedded:

• There is a direct cost for some QA activities, to be sure, but other aspects of QA as an assurance strategy is a mindset that informs PM planning and execution
• There are attributable savings from QA -- taken holistically -- in the form of cost, schedule, and scope assurance that expectations will be met.

QA as a mindset

Perhaps QA should be written qA to emphasize that it's assurance we're after, in the context of "doing good; avoiding evil" of course!

The PM is always seeking  mission assurance. 

And the mission? 

The PM's mission is to meet sponsor expectations by returning a quality product or service in return for the sponsor's resources invested with the PM, taking calculated risks to do so. 

It's a balance sheet idea: sponsor investment balanced by resource transference into product + the baseline cost of risk (mostly the baseline cost of planned mitigation)

Two ideas inform "Assurance"

There are two ideas here to keep in mind at the same time: 

The first is that quality has these actionable artifacts :

• Measurables that validate environmentally fit; functionally, effectively, and efficiently operable; safe and secure (**)
• Value attained that is a multiple of cost (the whole is worth more than the parts; utility is >1)
• Mission objectives of timeliness and scope that are achieved

And the second is that "assurance" embodies some ideas from risk management and some ideas from sampling theory

• Schedule assurance by smart use (read: PM management) of slack to protect the critical path (some ideas on how to do this are embodied in "Critical Chain Theory" formulated by Goldratt
  
• Cost-Value assurance by built-in reserves and attention to value earned by a dollar spent
  
• Performance-to-scope sampling in real-time -- at a sampling frequency that's "inside the performance (work-package) timeline" -- to trap issues and correct deficiencies early when they cost the least, and make agile tactical data-driven decisions that assure strategic accomplishment.

Assurance is free:

Protect the critical path: manage slack by buffering for uncertainties at the critical milestones; have a bias toward "earliest start" rather than waiting; resource the CP before others
Mitigate uncertainties, in part, by allocating budget reserves to underwrite probabilistic event-impacts.
Stay ahead of unfolding events by sampling, measuring, and analyzing frequently enough to be inside the work-package timeline.

------------------- 

(*) Total Quality Management was a movement and a concept that quality ideas and expectations had to be well understood throughout the organization. That is: there had to be a consistent "deployment" from executive to doer of what was expected and also of what was to be done.

TQM audits were conducted to verify deployment (I was an auditor for a year or so).
After a while, the TQM moniker and a lot of the bureaucratic overhead faded away, but the overall concept is valid: everyone should think and do quality practices in a (culturally) consistent manner.

(**) There are a lot of ideas embedded in "effectiveness". Some go to reliable, predictable, non-chaotic performance; high availability achieved by long mean-time-to-fail and quick mean-time-to-repair; long term support after sale or delivery. 

Other ideas of effectiveness are financial: cost-effectiveness which means "good" utility for operating dollars.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Owner's rep: the why and what

---

Having spent the past nearly 10 years in an "owner's rep" role, I can endorse what the American Bar Association (to whom I would not ordinarily look for project management topics) says about being an owner's representative, why the construction industry in particular has room for the role, and why the public sector is in the game.

Of course, before 10 years ago, while I was in the defense systems domain, it was common to have an "SI", a "system's integrator" that more or less extended the reach and expertise of the PMO (or PEO), particularly coordinating scope and sequence for specialty contractors to come in at just the right moment with a unique skill.

From the ABA:

ABA on Owner's rep

The reasons for increased use of third-party owner’s representatives are likely driven by a combination of the growing technical complexity and economic risk associated with modern construction projects, the evolution of new and more complex project delivery methods, and increased specialization of design professionals who have historically served the role of owner’s representative.  Both private owners and public-sector awarding authorities are retaining project advisors to supplement their internal management and administrative capabilities and address gaps in services rendered by the design professional, commissioning agent, and construction contractor.

On public projects, use of owner’s representatives is proscribed by law in many states and local jurisdictions.  Where use of owner’s representatives remains discretionary, owners must consider whether they have the internal capabilities and resources to successfully manage the construction process and whether the additional expense of the owner’s representative will have a positive impact on the schedule, cost, and/or quality of the project.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!