Pages

Monday, April 29, 2024

Non-compete agreements disputed


Most projects apply non-compete agreements when key project people leave with competitive-sensitive and proprietary information that could help the competition.
 
The U.S. Federal Trade Commission has issued a rule to prohibit such agreements.
The U.S. Chamber of Commerce has sued to have the rule nullified.

The two sides seem to see it this way (as reported in the WSJ)
  • The Chamber’s lawsuit says policymakers and courts have for decades recognized the value of noncompete agreements, and the federal government has never regulated them. 
  • An FTC spokesman defended its authority to issue the measure. The agency argues that noncompete clauses hamper competition for labor and result in lower pay and benefits for workers.
It will take a long time for this to wind its way through the legal system.



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

Friday, April 26, 2024

ISO 42001 AI Management Framework


Late in 2023 ISO published ISO 42001-2023 "Information technology Artificial intelligence Management System"

To quote ISO:
ISO/IEC 42001 is an international standard that specifies requirements for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System (AIMS) within organizations.

It is designed for entities providing or utilizing AI-based products or services, ensuring responsible development and use of AI systems.

For project offices and project managers, there are some points that bear directly on project objectives:

  • The standard addresses the unique challenges AI poses, which may need to be in your project's requirements deck, such as properties or functionality that addresses ethical considerations, transparency, and continuous learning. 
  • For organizations and projects, the standard sets out a structured way to manage risks and opportunities associated with AI, balancing innovation with governance.
Learn More
Of course, with something like this, to learn more about this you need not go further than the ISO website (more here) for relevant PDFs and FAQs. But, of course, you can also find myriad training seminars, which for a price, will give you more detail.



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

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.

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!

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

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!

Tuesday, April 2, 2024

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!