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!

Risk Un-management

---

Assert: "The vast majority of identified project risks go unmanaged."

Really?

Is that assertion calibrated with historical performance? Actually not; it's more intuitive, after thinking about the numbers of risks a large-scale project encounters.

And, we're talking risks; not issues.

So when looking at this, keep the distinction in mind between a risk and an "issue"

• Risks are events or outcomes that are characterized as having a probabilistic eventuality (meaning they may or may not occur) and a probabilistic impact, for which there is a root cause driving the uncertainties of outcome and impact. Example: There is a risk, when constructing a seawall, that storm surge may exceed some design limit, causing unusually severe damage, if a coincidence of high tide, moon, and storm peak should occur.
  
  
• Issues are circumstances that encumber efficiencies, lead to rework, and generally hold back progress. Example: Dealing with the communication inefficiencies of language and time zone is an issue. Such is not a probabilistic; the circumstances are determined and somewhat fixed. The "costs" of time/language inefficiencies are to be baselined in the budget and schedule. 

Define unmanaged

When I say "unmanaged" I mean that a decision has been made, hopefully consciously, that the risk consequences will be addressed if and when an event occurs, rather than baselining a risk management plan to identify root cause and trying actively (that is, spend resources) to reduce impact and affect probable occurrence. 

Consequences

And so you decide not to manage some risks. Who then pays for unmanaged consequences? Per se, their cost is not in the baseline. The first-order answer is project reserves. A second possibility is warranty premiums, or product-return reserves. Unfortunately, the user/owner may pay as well (hopefully, it doesn't come back to you in a lawsuit, but I used to be in the product liability business).

Unmanaged is a decision

There are several reasons why risks might go unmanaged or not be actively mitigated:

Lack of Awareness: Sometimes, project stakeholders and team members may not be fully aware of all the potential risks associated with a project.

Limited Resources: Projects, especially smaller ones, might lack the resources (both in terms of time and personnel) required for comprehensive risk management.

Overconfidence: Project managers or team members might be overly optimistic about the project's success and underestimate the potential risks.

Inadequate Planning: If the project planning phase is rushed or lacks thoroughness, potential risks might not be identified and addressed adequately.

Poor Communication: Ineffective communication among team members and stakeholders can lead to misunderstandings about project risks and how to manage them.

Organizational Culture: In some organizations, there might be a lack of a risk-aware culture, where risk management is not given due importance.

Recognizing the value of risk management

Project management methodologies like PMI's PMBOK and PRINCE2 emphasize the value of risk management to project success. There are well documented processes for identification, assessment, and mitigation of risks throughout the project lifecycle. So also are a myriad of standards from ISO, the U.S. DoD, NASA, AIA, and on and on in every major domain and industry. Experienced project managers understand the significance of managing risks.

While there are instances where risks are not managed, many organizations and project managers are smart enough and experienced enough to know they must actively engage in risk management to enhance the likelihood of project success.

---

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

System Integrator (SI) Owner's Rep

---

In the government domain, the government often contracts for an SI -- system integrator -- whose scope of work is to be an independent evaluator of program plans and progress, an expert adviser to the program executive for risk management and value engineering, and a voice in the project office not beholden to the prime contractor(s), system architect(s), or other implementers. 

In large programs, the SI may work simultaneously with multiple prime contractors, overseeing their coordination, communications, consistency in approach, integration of scope, and guarding for "white space" gaps. The SI may even evaluate the integrated program for 'chaos' ... the unintended outcomes of an integrated 'whole'. 

In some limited situations, the SI may even develop an interface that seems tagged to white space.

In the commercial domain, a similar scope and role is often given to an "owner's representative". 

Necessary or Nice to Have?

Your first thought may be: Another scope of work .... do I really need this for project success? If I don't engage with a service provider for this scope, is this something I am going to have to learn how to do myself, and then allocate my resources to the task? Or, can I get by without it?

Quick answer: It's work that has to be done ... to some level of scope ... so either the PEO or PMO does it with in-house resources, or the PEO/PMO engages an SI who is expert in the scope and presumably not learning on the job on your nickel.

And, by the way, if you do engage with an independent SI, then cooperation with the SI on the part of your architect, prime contractor, and perhaps other stakeholders has to be made part of the Statement of Work (SoW) with those parties. Question worth asking: Does that cooperation come at a cost, monetized or functional?

What's the ROI on the SI engagement

So, whether you are a government program office or a business unit with a large capital project, what's the value-add of having an SI or owner's rep on the scene? Is there a monetized ROI to the cost of a SI, or is the advantage with a DIY model (do it yourself)?  

In many respects, it's the insurance model: High impact with low probability, to take a square from the risk matrix. Thus, a low expected value, but nonetheless the impact is judged unaffordable. 

The usual risk management doctrine is this: You've got a big (big!) project with a lot of moving parts (different contractors doing different stuff). Get yourself an SI! (At a cost which is usually a small multiple of the expected value, if you think of it in terms of insurance)

SI Scope

The SI is on alert for these 'black swan' impacts that could derail the program, extend the schedule, impact performance, or cost big bucks for rework. 

The SI comes on the job early, typically from Day-1, working down the project definition side of the "V" chart (see chart below)

The SI is an advisor to the PEO or PMO regarding threats to the cost, scope, schedule, or quality. If there are value engineering proposals to be fit into the program, the SI is usually the first to evaluate and advise about their applicability.

The SI is an independent evaluator ("red team") of specifications, looking for inconsistencies, white space gaps, sequencing and dependency errors, and metric inconsistencies

The SI is an independent technical reviewer for the PMO of the progress toward technical and functional performance. The SI may provide much of the data for earned-value analysis.

The SI can be an independent trouble-shooter, but mostly the SI is looking for inappropriate application of tools, evaluation of root cause, and effectiveness of testing.

The SI may be an independent integrator of disparate parts that may require some custom connectivity. This is particularly the case when addressing a portfolio. The SI may be assigned the role of pulling disparate projects together with custom connectors.

The SI may be independent integration tester and evaluator, typically moving up the "V" from verification to validation

In a tough situation, the SI may be your new best friend!

What about agile?
'Agile-and-system-engineering' is always posed as a question. My answer is: "of course, every project is a system of some kind and needs a system engineering treatment". More on this here and here.

And, by extension, large scale agile projects can benefit from an SI, though the pre-planned specification review role may be less dominate, and other inspections, especially the red team role for releases, will be more dominate.

V-model
Need to review the "V-model"? Here's the image; check out the explanation here.

---

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