Black diamond risk management

---

If you snow ski, you understand the risk of a Black Diamond run: it's a moniker or label for a path that is  risk all the way, and you take it (for the challenge? the thrill? the war story bragging rights?) even though there may be a lesser risk on another way down.

So it is in projects sometimes: In my experience, a lot of projects operate more or less on the edge of risk, with no real plan beyond common sense and a bit of past experience to muddle through if things go wrong.

Problematic, as a process, but to paraphrase the late Donald Rumsfeld: 

You do the project with the resources and plan you have, not the resources or plan you want

You may want a robust risk plan, but you may not have the resources to research it and put it together.

You may not have the resources for a second opinion

You may not have the resources to maintain the plan. 

And, you may not have the resources to act upon the mitigation tactics that might be in the plan.

Oh, woe is me!

Well, you probably do what almost every other PM has done since we moved past cottage industries: You live with it and work consequences when they happen. Obviously, this approach is not in any RM textbook, briefing, or consulting pitch. But it's reality for a lot of PMs.

Too much at stake
Of course, if there is safety at stake for users and developers, as there is in many construction projects; and if there is really significant OPM invested that is 'bet the business' in scope; and if there are consequences so significant for an error moved into production that lives and livelihoods are at stake, then the RM plan has to move to the 'must have'.  

A plan with no action

And then we have this phenomenon: You actually do invest in a RM plan; you actually do train for risk avoidance; and then you actually do nothing during the project. I see this all the time in construction projects where risk avoidance is clearly known; the tools are present; and the whole thing is ignored.

Show me the math

But then of course because risk is an uncertainty, subject to the vagaries of Random Numbers and with their attendant distributions and statistics, there are these problems:

• It's easy to lie, or mislead, with 'averages' and more broadly with a raft of other statistics. See: How to Lie with Statistics (many authors) 
• Bayes is a more practical way for one-off projects to approach uncertainty than frequency-of-occurrence methods that require big data sets for valid statistics, but few PM really understand the power of Bayes. 
• Coincidence, correlation, and causation: Few understand one from the other; and for that very reason, many can be led by the few to the wrong fork in the road. Don't believe in coincidence? Then, of course, there must be a correlation or causation!

The upshot?

Risk, but no plan.

Or plan, and no action

---

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

Make the maximum cost minimal

---

Full disclosure: I wrote this posting myself, but I did ask ChatGPT for some ideas to include. 

It's always a PMO objective to minimize cost if scope and quality and schedule are constant. But they never are. So, those parameters are usually intertwined and mutually dependent variables along with cost. 

But suppose for discussion that scope and quality are held constant (not to be traded off to save cost or schedule), and the primary objective is minimization of cost. Here are a few ideas.

Labor-dominant projects

I'm talking about projects where labor is 60% or more of the cost. Many software projects fall in this box, but many other intellectual content (IC) projects do as well: HR, finance, marketing, just to name a few.

Productivity

Assuming competence is not in question, the first order of business is productivity, which is always a ratio: output valued by the customer per unit of labor required for achievement. As in all ratios, the PMO can work on the maximizing numerator and minimizing the the denominator. 

Getting the numerator right the first time minimizes the cost of waste and rework and minimizes schedule mishaps. The skill required: good communications with the people who establish the value proposition. 

Minimize the "marching army" cost

But the numerator is also about finding useful outcomes for the "white space" that crops up: you have staff in place, you can't afford to let them scatter when there is downtime, so you have to have a ready backlog of useful second tier stuff. Staff you can't afford to lose, but may have downtime nonetheless, is often labeled the "marching army"

The denominator is sensitive to organizational stability and predictability, personal skills, tools, interferences, teamwork, and remote working. Anything that PMO can do about the first five is more or less mainstream PMO tasking. 

Remote working:

But the issue of large scale remote working is somewhat new since the Covid thing. Loosely coupled to that is greater emphasis on work-life balance rather than "do what ever it takes" and often for no overtime pay. 

Such has then spawned more of the "do the minimum not to get fired" mindset. All that has cast a shadow on remote working.

Cost-free synergism.

Consequently, the pendulum has swung in the direction of minimizing remote working in order to get the synergistic production (at nearly cost free) from casual contacts with other experts and innovators, to say nothing of problem avoidance and thereby waste and rework avoidance.

Risk management and scheduling

When it comes to labor, the first risk is dependable and predictable availability, particularly if the staff are so-called gig workers. Many PMOs limit W9s to less than 25% of the workforce for just this reason.

One anecdote is loose coupling on schedule tasks to allow for the occasional misstep in staffing. After all, even W2s have matters that interfere.

Material-dominant projects

Here is where a lot of construction projects, hardware development, and critical (or scarce) material projects come in.

Material impacts are largely mitigated by the usual strategies of earliest possible order, acceptance of interim and partial shipments, incentives for faster delivery, and strategic stockpiles of frequently used items.

The workforce for many of these type projects is often contracted by specific trades who have licenses to work on specific work. It's typical that these contactors operate in a matrix management environment of multiple and independent customers vying for a scarce and technical workforce. The impact is uncertainty of schedule and availability, and a cascade of dependencies that have to be reworked.

The customary approach to scarcity is cost incentives to direct resources to your need. 

The mitigation for cascading dependencies is schedule as loosely as possible so that slack among tasks forms risk management buffers to a slipping schedule.

  

---

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

Wanted: AI Tokens

---

12 trillion

The estimated number of tokens used to train OpenAI’s GPT-4, according to Pablo Villalobos, who studies AI for research institute Epoch. He thinks a newer model like GPT-5 would need up to 100 trillion tokens for training if researchers follow the current growth trajectory. OpenAI doesn’t disclose details of the training material for GPT-4.

Attribution: Conor Grant, WSJ 

---

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

Slack is the last thing to schedule

---

Slack, aka 'buffer', aka 'white space', aka 'early finish', is the last thing to schedule. 

After all the other stuff is scheduled.

Why?

Because slack should be used (applied) last as a way of making space for schedule extension risk.

Has to be in the baseline

But in order for it to be applied properly, slack has to be in the baseline schedule to start with. In other words a schedule without slack is not a real schedule, but rather just a hopeful schedule.

What can you do with slack?

It seems that scheduling slack is just scheduling free time and unnecessarily extending the schedule. 

Not so.

Here are things you can do with slack that are value-adding:

• Protect the critical path: There are probably a lot of tasks that join the critical path, feeding partial product into the final outcomes. If those dependencies are late, so might the CP be late if it is not buffered to absorb those problems. "Critical Chain" scheduling theory is a good example of how the CP is protected with slack.

• Relieve constraints: Sometimes there is a constraint in the workflow and stuff isn't flowing as it should. Using Theory of Constraint techniques, other elements of the workflow are usually rescheduled, changed in scope, or new tools and training is applied. To make room for these new or changed activities, slack is required. 
  
  
• Protect a milestone: Even if a milestone is not on the CP it needs to be respected for its intended finish date. If there are more than one activity that contributes to the milestone completion criteria, then slack on the various joins to the milestone will protect its date.

Latest start is a no-no

The one thing to avoid is "latest-start" scheduling. Latest-start is, in effect, putting the slack first rather than last and using the slack before any risk appears. A total waste of resources!
  

---

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

"Transformative Trinity" -- Military Projects

---

Are you working in military projects? U.S., NATO, or the so-called 'Five Eyes'?

You may run across this concept in military systems design:

"Transformative Trinity"

And so what is that?

The “Transformative Trinity” in military contexts refers to the integration of new technologies like drones, the democratization of higher-quality information, and collaboration with commercial firms to enhance military capabilities

Generals Mick Ryan and Clint Hinote

So we are talking big project picture here, strategy if you will, with three elements: 

1. an uncrewed device -- a drone --whether on land, air, or sea (we'll leave space out if for this discussion); 
2. the flow-down and flow-across of ISR to the warfighters and joint planners, and 
3. a partnership with industry (we project guys), to include the off-the-shelf-stuff, albeit perhaps modified for the battlefield (See: Ukraine)

The idea of course is to use the "transformative trinity" to transform warfare, less touch except by remote. And tech projects are going to be right in the midst of it!

So add it to your dictionary: the military systems "transformative trinity"

---

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

Why software remains insecure

---

I like a lot of the stuff Daniel Miessler thinks about. 

He has an interesting essay about "why software remains insecure". By insecure, he means released software with known functional and technical bugs at release, and even far beyond release 1.0 and 2.0 and on and on.

Why should this be?

Miessler opines: 

"... the existence of insecure software has so far helped society far more than it has harmed it".

"Basically, software remains vulnerable because the benefits created by insecure products far outweigh the downsides. Once that changes, software security will improve—but not a moment before".

And if you buy that idea, then you probably understand his point that there is no real business or user incentive to repair things to a higher standard of quality. Users put up with it; projects are bound to the clock.

This process will do nicely: Develop, quickly test, release, rinse, repeat.

Domain sensitive

Of course, there are significant and manifestly important project domains where such slack in quality would not be tolerated -- could not be tolerated -- or even understood. Think: space launches of all sorts; command and control systems that are kinetically fatal in outcome; even self-driving systems.

It's not SEI Level 5!

Without a maturity model as a regulatory tool for systemic quality, other priorities dominate.

The cart and horse are in a mixed order: release, measure the temperature of users and regulators, and then fix it -- just enough. Sort of Agile that way: do enough, just enough, to pass the sprint test and move on.

---

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

Budget wisdom

---

"Priorities aren't redal unless budgets reflect them"

CIA Director Burns

Of course, Director Burn's assertion is spot-on and another version of "show me the money", or perhaps sticking with the intelligence domain: "follow the money".

This whole idea is the bane of strategic planning in which long-term plans outrun the budget authority and even outrun the budget planning, in other words: a floating apex, unsupported by a pyramid of budgets.

Nonetheless, lightening could strike. Having an idea on the shelf is not all bad. But if it's technology, it has a half life measured in a year or two. So, a constant dusting to keep current is required. Who knows: the money might show up.

---

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