Tuesday, April 23, 2024

Efficient product quality design

I'm borrowing shamelessly from an essay by D. Miessler about efficiency in security design for user products by generalizing to the quality -- in the broadest sense -- of a product. That is to say: quality as evaluated by a user (quality is in the eye of the beholder, as it were)

And, I might observe that the principle explained below corresponds closely with the Agile idea of "enough, but not more than enough"

The Efficient Quality Principle

1. The quality baseline of an offering or system faces continuous downward pressure [i.e. less quality demanded] coming from customer excitement about, or reliance on, the offering in question.

2. The baseline for an offering’s quality will be set at the point at which people will not stop using the offering because it’s quality is not pristine.

3. The better the offering is, the lower the quality baseline can be without losing customers.

In other words, the way we know something has the “right” amount of quality built in is when people just keep using it. People use these offerings or systems because the value they provide massively outweighs the quality lapses  in user's minds.

The moment enough people stop using something due to quality being too bad, the baseline goes up. And not before.

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

Saturday, April 20, 2024

Mary and John on the Critical Path

In project management school, the lesson on Critical Path includes this rule:
Apply resources first to the critical path, and subordinate demands of other paths to ensure the critical path is never starved.
Beware this hazard: Resources may be real people:
The problem of applying resources arises when we move from the abstract of 'headcount' to the real world of 'Mary' and 'John'. 

Alas! The "resources" are not interchangeable. Mary and John are unique. Consequently, consideration must be given not only to the generic staffing profile for a task but also to the actual capabilities of real people.

Considering Mary and John uniquely
Take a look at the following figure: There are two tasks that are planned in parallel. If not for the unique situation that Mary and John can't be applied to two paths simultaneously, these tasks could be completely simultaneous.

In fact, the critical path could be as short as 50 days -- the length of Task 1. Task 2, as you can see, is only 20 days duration. But for the assignment of Mary and John pushes Task 2 to the right.

But with only Mary and John as resources, the schedule plan stretches out to 65 as shown.

 Here's an idea:
Reorganize the network logic to take into account unique staffing applied to schedule tasks.

Now the schedule plan is shorter, though not as short as it could be if there were resources other than Mary and John. 

And that is actually the embedded lesson learned: With only Mary and John, the two tasks are no longer independent. 

And with a lack of independence, there is a "co-dependency" that is a phenomenon that has to be scheduled also. Thus, we form the rule that interdependency always stretches the plan!

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

Tuesday, April 16, 2024

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!

Saturday, April 13, 2024

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.

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!

Thursday, April 11, 2024

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!

Monday, April 8, 2024

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.
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!

Friday, April 5, 2024

"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:

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!