Quantitative Methods: It takes a number!

Numbers are a PM's best friend

Bayes Thinking Part II

---

In Part I of this series, we developed the idea that Thomas Bayes was a rebel in his time, looking at probability problems in a different light, specifically from the proposition of dependencies between probabilistic events.

In Part I we posed the project situation of 'A' and 'B', where 'A' is a probabilistic event--in our example 'A' is the weather--and 'B' is another probabilistic event, the results of tests. We hypothesized that 'B' had a dependency on 'A', but not the other way 'round.

Bayes' Grid

The Figure below is a Bayes' Grid for this situation. 'A+' is good weather, and 'B+' is a good test result. 'A' is independent of 'B', but 'B' has dependencies on 'A'. The notation, 'B+ | A' means a good test result given any conditions of the weather, whereas 'B+ | A+' [shown in another figure] means a good test result given the condition of good weather. 'B+ and A+'  means a good test result when at the same time the weather is good. Note the former is a dependency and the latter is a intersection of two conditions; they are not the same.

  

The blue cells all contain probabilities; some will be from empirical observations, and others will be calculated to fill in the blanks. The dark blue cells are 'unions' of specific conditions of 'A' and 'B'. The light blue cells are probabilities of either 'A' or 'B'.

Grid Math

There are a few basic math rules that govern Bayes' Grid.

• The dark blue space [4 cells] is every condition of 'A' and 'B', so the numbers in this 'space' must sum 1.0, representing the total 'A' and 'B' union
• The light blue row just under the 'A' is every condition of 'A', so this row must sum to 1.0
• The light blue column just adjacent to 'B' is every condition of 'B' so this column must sum to 1.0
• The dark blue columns or rows must sum to their light blue counter parts

Now, we are not going to guess or rely on a hunch to fill out this grid. Only empirical observations and calculations based on those observations will be used.

Empirical Data

First, let's say the empirical observations of the weather are that 60% of the time it is good and 40% of the time it is bad. Going forward, using the empirical observations, we can say that our 'confidence' of good weather is 60%-or-less. We can begin to fill in the grid, as shown below.

In spite of the intersections of A and B shown on the grid, it's very rare for the project to observe them. More commonly, observations are made of conditional results.  Suppose we observe that given good weather, 90% of the test results are good. This is a conditional statement of the form P(B+ | A+) which is read: "probability of B+ given the condition of A+".  Now, the situation of 'B+ | A+' per se is not shown on the grid.  What is shown is 'B+ and A+'.  However, our friend Bayes gave us this equation:

P(B+ | A+) * P(A+) = P (B+ and A+)  = 0.9 * 0.6 = 0.54

Take note: B+ is not 90%; in fact, we don't know yet what B+ is.  However, we know the value of 'B+ and A+' is 0.54 because of Bayes' equation given above.

Now, since the grid has to add in every direction, we also know that the second number in the A+ column is 0.06, P(B- and A+).

However, we can go no farther until we obtain another independent emprical observation.
 

To be continued

In the next posting in this series, we will examine how the project risk manager uses the rest of the grid to estimate other conditional situations.

Share this article with your network by clicking on the link.

 

---

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

Bayes thinking, Part I

---

---

Our friend Bayes, Thomas Bayes, late of the 18th century, an Englishman, was a mathematician and a pastor who's curiosity led him to ponder the nature of random events.

There was already a body of knowledge about probabilities by his time, so curious Bayes went at probability in a different way. Until Bayes came along, probability was a matter of frequency:

"How many times did an event happen/how many times could an event happen". In other words, "actual/opportunity".

To apply this definition in practice, certain, or "calibrated", information is needed about the opportunity, and of course actual outcomes are needed, often several trials of actual outcomes.

Bayes' Insight
Recognizing the practicalities of obtaining the requisite information, brother Bayes decided, more or less, to look backward from actual observations to ascertain and understand conditions that influenced the actual outcomes, and might influence future outcomes.

So Bayes developed his own definition of probability that is not frequency and trials oriented, but it does require an actual observation. Bayes’ definition of probability, somewhat paraphrased, is that probability is...

The ratio of expected value before an event happens to the actual observed value at the time the event happens.

This way of looking at probability is really a bet on an outcome based on [mostly subjective] evaluations of circumstances that might lead to that outcome. It's a ratio of values, rather than a frequency ratio.

Bayes' Theorem
He developed a widely known explanation of his ideas [first published after his death] that have become known as Bayes' Theorem. Used quantitatively [rather qualitatively as Bayes himself reasoned], Bayesian reasoning begins with an observation, hypothesis, or "guess" and works backward through a set of mathematical functions to arrive at the underlying probabilities.

To use his theorem, information about two probabilistic events is needed:

One event, call it 'A', must be independent of outcomes, but otherwise has some influence over outcomes. For example, 'A' could be the weather. The weather seems to go its own way most of the time. Specifically 'good weather' is the event 'A+', and 'bad weather' is the event 'A-'. 

The second event, call it 'B', is hypothesized to have some dependency on 'A'. [This is Bayes' 'bet' on the future value] For example, project test results in some cases could be weather dependent. Specifically, 'B+' is the event 'good test result' and 'B-' is a bad test result;  test results could depend on the weather, but not the other way 'round.

Project Questions
Now situation we have described raises some interesting questions:

• What is the likelihood of B+, given A+? 
• What are the prospects for B+ if A+ doesn't happen? 
• Is there a way to estimate the likelihood of B+ or B- given any condition of A? 
• Can we validate that B indeed depends on A?

Bayes' Grid
Curious Bayes [or those who came after him] realized that a "Bayes' Grid", a 2x2 matrix, could help sort out functional relationships between the 'A' space and the 'B' space. Bayes' Grid is a device that simplifies the reasoning, provides a visualization of the relationships, and avoids dealing directly with equations of probabilities.

Since there's a lot detail behind Bayes' Grid, we'll take up those details in Part II of this series.

Photo credit: Wikipedia

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

The SpaceX approach

---

In the September 2-15, 2024 edition of Aviation Week and Space Technology there is an article about the 5-step process at SpaceX for getting the most effective project outcome. In a few words summarized here, the steps are:

1. Challenge the Requirements. Interpret this as: your requirements are dumb; find a way to make them less dumb!
2. Find a way to eliminate a process step of poor value, or a part or component that can be simplified
3. Find a way to make it easier, faster, cheaper to reproduce or manufacture
4. Prioritize speed and responsiveness in everything you do or will have done.
5. Automate everything! Take people out of the manufacturing and production process whereover possible.

---

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

Einstein's methodology

---

"When I have one week to solve a seemingly impossible problem, I spend six days defining it, and then the solution becomes obvious."

Albert Einstein

---

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

The ideal number of project workers is ....

---

One theory of project staffing is that the ideal number of project people is ZERO.

Don't believe it?

The objective of the project is to deliver something to the business in a timeframe and a budget.

At present, it takes people to do that. But ideally, the number of people would be vanishing small if they were super optimized, super talented, and only touched a process when it needed an initiation or some other budget.

Not buying this?

Well, at the business level, the same applies. 

Take a read .... 5 min or so... of this essay which makes the point, and then the counter point for the future of 9-5 jobs generally. 

From the essay (actually, the essay ends on an upbeat, so don't take the following as the only worthy content):

The ideal number of employees in any company is zero. If a company could run and make money using no people, then that is exactly what it should do.

Nobody owes anybody a job. Literally the only reason anyone has one is because there was a problem at some point in that business that required a human to do some part of the work. Building on that, if that ever becomes not the case, for a particular person or team or department of human employees, the natural next action is to get rid of them.

and just now —starting in 2023 and 2024, it is actually becoming possible to replace human intelligence tasks with technology.

---

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

A.I. Risk Repository

---

MIT may have done us a favor by putting together a compendium of risks associated with A.I. systems.

Named the "A.I. Risk Repository", there are presently 700 or so risks categorized in 23 frameworks by domain and cause, organized as a taxonomy for each of these characteristics.

The Causal taxonomy addresses 'how, when, and why' of risks.

The Domain taxonomy goes into 7 domains and 23 subdomains, so certainly some fine grain there. 

YouTube, of course

This is a public resource, so naturally there's YouTube on what it's all about and how to use it.

There's a lot of stuff

If you go the link, given in the first paragraph, and scroll down a bit, you will be invited to wade into the database, working your way through the taxonomies. There's just a lot of stuff there, so give it a look.   

---

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

Slow is smooth; Smooth is fast

---

The blog title is actually from the mantra of the U.S. Navy SEALS

Slow is smooth; smooth is fast.

U.S. Navy SEALS

Now, this bit of wisdom may strike you as similar to the project tips we've been working with for years, to wit: "quality is free", and "it's cheaper and faster to do it right the first time" which recognizes the cost and schedule penalty of rework.

It's about rhythm and balance

From the SEALS website, we learn: "This phrase isn't just about being slow or fast; it's about finding a rhythm that balances precision and pace, ultimately leading to swifter progress. The SEALs swear by it... but how can we apply it beyond military contexts?

More depth:

Of course, there's a YouTube on "Smooth and Fast"

On the website, link given in the first sentence, there is a long-form article on the concept. Two chapters stand out:

Applying "Slow is Smooth, Smooth is Fast" Beyond Military Contexts

Incorporating the Mantra into Business Practices 
Using the Mantra for Project Management

The Role of "Slow is Smooth, Smooth is Fast" in Team Dynamics

Promoting Smoothness in Team Operations
The Mantra's Impact on Team Efficiency

In the PM domain, the recommendations are: 

• Be deliberate; take the time to consider and prepare
• Quality trumps speed (the cost of rework is embedded in this one)
• Keep refining (Sort of a Bayesian idea, not so much continuous improvement)

In team dynamics, few errors and quality outcomes build trust, confidence, and high morale.

---

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

Stability! It counts for a lot

---

Stability!

It counts for a lot.

It implies -- for behaviors and management decisions -- predictability, reliability, under-control (but not risk-free, of course), coherent narrative, steady-state goals, and a strategy that is understandable to those who have the job of implementing it.

Perhaps you are aware, as many are, that stability requires feedback to effect error correction and trap excesses and blind alleys. 

Ah yes!

We know about feedback.

Open loop systems -- those with outcome but no feedback -- are prone to many uncontrolled and unexpected responses. Who can predict what a stimulus will do to a system that has no feedback? Actually, that's a really tricky task.

So, what about feedback? 

What's to know?

• Timing is everything! Getting the feedback "phased" in time such that it has a correcting effect rather than a destructive effect is vital. The former is generally called "negative feedback" for its corrective nature; the latter is generally called "positive feedback" for its reinforcing rather than corrective nature. And, when its too late, it's generally called ineffective.
  
  
• Amplitude, or strength, or quantity is next: It has to be enough, but not too much. Tricky that! Experimentation and experience are about the only way to handle this one.

What could possibly go wrong?

Actually, a lot can go wrong.

No feedback at all is the worst of the worst: the 'system' is 'open loop', meaning that there are outcomes that perhaps no one (or no thing) are paying attention to. Stuff happens, or is happening, and who knows (or who knew)?

Timing errors are perhaps the next worst errors: if the timing is off, the feedback could be 'positive' rather than 'negative' such that the 'bad stuff' is reinforced rather than damped down. 

Strength errors are usually less onerous: if the strength is off, but the timing is on, then the damping may be too little, but usually you get some favorable effect

Practical project management

Feedback for correcting human performance is familiar to all. Too late and it's ineffective; too much over the top and it's taken the wrong way. So, timing and strength are key

But, the next thing is communication: both verbal and written (email,etc). Closing the loop provides reassurance of the quality and effectiveness of communication. You're just not talking or writing into the wind!

And, of course, in system or process design, loops should never be open. Who knows what could happen.

I should mention:

The study of feedback systems generally falls within what is called 'cybernetics'. As described by sciencedirect.com, MIT mathematician Norbert Wiener defined cybernetics as “the study of control and communication in the animal and the machine." 

From Wikipedia, we learn: The core concept of cybernetics is circular causality or feedback—where the observed outcomes of actions are taken as inputs [ie, feedback] for further action in ways that support the pursuit and maintenance of particular conditions [ie, 'ways that support' requires the correct timing and strength]

---

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

The least Maximum schedule

---

To minimize your maximum schedule is a good thing. Or, it should be.

Here's how to do it:

• Subordinate all other priorities to the most important tasks. This begs the question: is there an objective measure of importance, and from whom or what does such a measure emanate?
• If you can measure 'importance' (see above) then do the densest tasks first, as measured by the ratio of importance to time.
  
  Note: a short time (denominator) will "densify" a task, so some judgement is required so that a whole bunch of short tasks don't overwhelm the larger picture. In the large picture, you would hope that the density is driven by the numerator (importance)
  
  
• Always do an 'earliest start', putting all the slack at the end. You may not need it, but if you do it will be there.
• Move constraints around to optimize the opportunity for an earliest start that leads to least maximum. See my posting on this strategy.
  
  
• If a new task drops into the middle of your schedule unannounced, prioritize according to 'density' (See above). This may mean dropping what you are doing and picking up the new task. Some judgement required, of course. It's not just a bot following an algorithm here. 
  
  
• If some of your schedule drivers have some random components, and you have to estimate the next event with no information other than history, then "LaPlace's Law of Succession" may be helpful, to wit:
• To the prior random (independent) outcomes (probability) observed, add "1" to the numerator and "2" to the denominator to predict the probability of the next event. (*)
  
  So, by example, if your history is that you observed, measured, or obtained a particular outcome independently 3 of 4 times (3/4), LaPlace's Law would predict (3+1)/(4+2) as the probability for the next similar outcome, or 4/6. This figure is a bit more pessimistic, as you would expect by giving extra weight to the number of trials (denominator).

_________________________

(*) (n+1)/(d+2) isn't just a guess, or throwing a dart at a board. It is a rigorous outcome of an algebraic limit to a long string of 1's and 0's with historic probability of n/d. Although LaPlace did the heavy lifting, Bayes gets the popular credit for the idea of using prior observations as the driver for new estimates with a modified hypothesis.

---

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

Never a dull moment ..;.

---

For some, boredom is the great fear. Got to keep moving!

"He had a function, an excuse for activity. For a few hours at least he wouldn’t be bored. ... he drank the coffee, which was still too hot. He reflected that the fear of boredom had driven him the whole of his life."

Ann Cleeves, Novelist

The fear or boredom was a driver ...
Frankly, I know how he feels

Add value
It shouldn't be motion for motion's sake
It should be about the utility of what you are doing
I need an activity plan for every day ... how will this day add value to what I am about?

About utility
Utility is the marginal difference between face value and the value you -- or someone else -- puts on what your are doing or offering. 

If you think about it, almost anyone can offer up face value if they have the skills for that domain, but if you are in constant motion -- avoiding boredom -- then that activity should be directed at more than just face value.

Even if it's just reading a book, the question is: how much better off are you for having engaged in that activity? For me, I read a lot of history because I think there are lessons there to be applied forward that will add value to my endeavors. And, of course, I might avoid a risk I might not otherwise understand.

If you are driven to activity ...
Make it count for something.

---

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

Leonardo's Lament

---

"The supreme misfortune is when theory outstrips performance"

Leonardo da Vinci

And then there's this: 

During the technical and political debates in the mid-1930's by the FCC with various engineers, consultants, and business leaders regarding the effect, or not, of sunspots on various frequency bands being considered for the fledgling FM broadcast industry, the FCC's 'sunspot' expert theorized all manner of problems.

But Edwin Armstrong, largely credited with the invention of FM as we know it today, disagreed strongly, citing all manner of empirical and practical experimentation and test operations, to say nothing of calculation errors and erroneous assumptions shown to be in the 'theory' of the FCC's expert.

But, to no avail; the FCC backed its expert.

Ten years later, after myriad sunspot eruptions, there was this exchange: 

Armstrong: "You were wrong?!"

FCC Expert: "Oh certainly. I think that can happen frequently to people who make predictions on the basis of partial information. It happens every day"

++++++++++

Quotations are from the book "The Network"
 

---

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

Out of Sight Activity

---

Back in yesteryear, I recall the first time I had a management job big enough that my team was too large for line-of-sight from my desk and location.

Momentary panic: "What are they doing? How will I know if they are doing anything? What if I get asked what are they doing? How will I answer any of these questions?"

Epiphany: What I thought were important metrics now become less important; outcomes rise to the top

• Activity becomes not too important. Where and when they worked could be delegated locally
• Methods are still somewhat important because Quality (in the large sense) is buried in Methods. So, can't let methods be delegated willy nilly
• Outcomes now become the biggie: are we getting results according to expectations?

There's that word: "Expectations"

In any enterprise large enough to not have line-of-sight to everyone, there are going to be lots of 'distant' managers, executives, investors, and customers who have 'expectations'. And, they have the money! So, you don't get a free ride on making up your own expectations (if you ever did)

At the End of the Day

• I had 800 on my team
• 400 of them were in overseas locations
• 400 of them were in multiple US locations
• I had multiple offices
• It all worked out: we made money!

---

---

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

Do LLMs reason or think?

---

In a posting on "Eight to Late", the question is posed: Do large language models think, or are they just a communications tool?

The really short answer from Eight to Late is "no, LLMs don't think". No surprise there. I would imagine everyone has that general opinion.

However, if you want a more cerebral reasoning, here is the concluding paragraph:

Based, as they are, on a representative corpus of human language, LLMs mimic how humans communicate their thinking, not how humans think. Yes, they can do useful things, even amazing things, but my guess is that these will turn out to have explanations other than intelligence and / or reasoning. For example, in this paper, Ben Prystawksi and his colleagues conclude that “we can expect Chain of Thought reasoning to help when a model is tasked with making inferences that span different topics or concepts that do not co-occur often in its training data, but can be connected through topics or concepts that do.” This is very different from human reasoning which is a) embodied, and thus uses data that is tightly coupled – i.e., relevant to the problem at hand and b) uses the power of abstraction (e.g. theoretical models).

---

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

Data rule #1

---

The first rule of data:

• Don't ask for data if you don't know what you are going to do with it

Or, said another way (same rule)

• Don't ask for data which you can not use or act upon

 And, your reaction might be: Of course!

But, alas, in the PMO there are too many incidents of reports, data accumulation, measurements, etc which are PMO doctrine, but in reality, there actually is no plan for what to do with it. Sometimes, it's just curiosity; sometimes it's just blind compliance with a data regulation; sometimes it's just to have a justification for an analyst job.

The test:

 If someone says they need data, the first questions are: 

• What are you going to do with the data?
• How does the data add value to what is to be done
• Is the data quality consistent with the intended use or application (**), and 
• Is there a plan to effectuate that value-add (in other words, can you put the data into action)?

And how much data?

Does the data inquisitor have a notion of data limits: What is enough, but not too much, to be statistically significant (*), informative for management decision making, and sufficient to establish control limits?

---

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

Is it alright to guess in statistics?

---

Is guessing in statistics like crying in baseball? It's something "big people" don't do.

Or is it alright to guess about statistics? 

The Bayesians among us think so; the frequency guys think not. 

Here's thought experiment: I postulate that there are two probabilities influencing yet a third. To do that, I assumed a probability for "A" and I assumed a probability for "B", both of which jointly influence "C". But, I gave no evidence that either of these assumptions was "calibrated" by prior experience.

I just guessed

What if I just guessed about "A" and "B" without any calibrated evidence to back up my guess? What if my guess was off the mark? What if I was wrong about each of the two probabilities? 

Answer: Being wrong about my guess would throw off all the subsequent analysis for "C".

Guessing is what drives a lot of analysts to apoplexy -- "statisticians don't guess! Statistics are data, not guesses."

Actually, guessing -- wrong or otherwise -- sets up the opportunity to guess again, and be less wrong, or closer to correct.  With the evidence from initial trials that I guessed incorrectly, I can go back and rerun the trials with "A" and "B" using "adjusted" assumptions or better guesses.

Oh, that's Bayes!

Guessing to get started, and then adjusting the "guess" based on evidence so that the analysis or forecast can be run again with better insight is the essence of Bayesian methodology for handling probabilities.

 

And, what should that first guess be?

• If it's a green field -- no experience, no history -- then guess 50/50, 1 chance in 2, a flip of the coin
• Else: use your experience and history to guess other than 1 chance in 2
  

According to conditions

Of course, there's a bit more to Bayes' methodology: the good Dr Bayes -- in the 18th century -- was actually interested in probabilities conditioned on other probable circumstances, context, or events. His insight was: 

• There is "X" and there is "Y", but "X" in the presence of "Y" may influence outcomes differently. 
• In order to get started, one has to make an initial guesses in the form of a hypothesis about not only the probabilistic performance of "X" and "Y", but also about the the influence of "Y" on "X"
  
• Then the hypothesis is tested by observing outcomes, all according to the parameters one guessed, and 
• Finally, follow-up with adjustments until the probabilities better fit the observed variations. 

Always think Bayesian!

• To get off the dime, make an assumption, and test it against observations
• Adjust, correct, and move on!

---

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

Enterprise-quality browser for the PMO

---

The trusty internet browser that has been around since the Netscape days of the 1990's has largely been a lay person's user interface to the internet and sundry consumer internet apps accessed via the browser.

Fair enough

Let's stipulate: In the last 30 years that browser user experience has improved dramatically, to be sure.

Something different

But in recent years, and especially accelerating in 2024, the "enterprise-quality" browser had made inroads in the enterprise business world. New browser companies (*)  have formed and are addressing the heightened security needs of the enterprise as well as a myriad of other needs (see below). This opportunity is not lost on the traditional guys from Microsoft, Apple, and Google; they also have their versions of an enterprise browser. (*)

The general requirements set is this:

• The need for an easier and less complicated way to integrate business apps into the browser. 
• More of a "windows" (small 'w') look with multiple app windows in a common display, decidedly different from a row (or column) of tabs.
• Security protections that are more demanding in the enterprise setting.
• Network, IT, and data protection functions built-in 

PMO effects

So in the PMO you may see new browsers and some of your favorite apps, like Office, database engines, scheduling and costing apps, statistical apps, and others that are somewhat "bolt-on" apps to the consumer browsers (Chrome, Edge, and Safari) become a more integrated app set on the enterprise browser. 

_________

(*) Island and Here, formerly OpenFin, but also "Edge for Business" from Microsoft and "Chrome Enterprise" from Google

---

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

Clearing the backlog

---

Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.

In the event, coupling is the culprit.

Coupling? 

Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.

• Loose coupling: there is some effect transference, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
• Tight coupling: there is almost complete transference of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost no energy is lost flexing the frame.

In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.

 

Managing coupling is a task in risk management because coupling may introduce unwanted risks in the project or the product.

If coupling is a problem, how to solve it?

If coupling is a benefit, how to obtain it?

First, there's buffers to loosen coupling

The buffer -- if large enough -- absorbs the effect. For an excellent treatment of buffers in the PM domain, see Goldratt's  book "Critical Chain Method" for more about decoupling with buffers

Second, there are coupling objects

• To avoid coupling, buffers may not do the trick.
• But to enable coupling, we need some connectivity

In either case, think of objects, temporary or permanent, that can effect the coupling. A common example is seam in one fabric joining to another. The seam forms a "rip-stop" which prevents a ripping all down the fabric. 

 

One system that uses such a rip-stop is the sails on a boat: rip-stops are sewn into the sail fabric to prevent a total failure in the event of damage in one section, and thereby to decouple the damage from one section to another.

 

Now, move that idea from a sail to a backlog, using object interfaces for isolating one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).

With loose coupling, we get the window pane effect: stuff can go on in "Environment A" without strongly influencing "Environment B". 

Some caution advised: this is sort of a "us vs them" approach, some might say stove piping.

The case for tight coupling

Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.

There are two approaches:

• Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
• Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.

Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!

---

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

Government Research you can access

---

Since at least 2013, there's been a push from the President's Office of Science and Technology Policy to make as much as possible of government sponsored research available to the public for free.

On August 25th, 2022, this policy initiative of access to government research got another push when OSTP published more detailed and aggressive guidance to the executive departments.

What was behind pay walls and other barriers may now be in the free public domain. 

Your project might benefit.

Check it out.

---

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

Software: Is it ever Done?

---

The software is never done!

Certainly not news; and certainly not profound to any engineer, coder, or PM working in the software industry, writing apps, or supporting software enabled devices.

Users have come to expect routine and regular updates to all things software.

Ooops, not so fast!

What about the automobile industry?

Traditionally: the car is done! 

• Buy it; keep it; sell it, eventually. Never needs an upgrade!

But that tradition may be short-lived: Cars will need upgrades over the life-cycle

What now?

A few months after I bought a new car I got a recall notice to take it in for an upgrade to the transmission control software. That recall system is probably the way to keep software up to date for many of the in-vehicle software programs. 

• But, is this only a warranty service? 
• How long would manufactures support software upgrades for 2nd or 3rd party apps?
• The life of car is 12 years+ for new vehicles. That's 'forever and forever' in the software industry, comparable to still supporting the iPhone 4! 

Big Tech

So-called big tech is taking over much of the user interface and user apps in new vehicles (except Tesla which does all its own in-house design and does not support Android and Apple apps on its user panels)

Long term support

As a project manager, what can you look forward to as regards long-term supportability of apps?

And, as a app developer, you may be one layer removed from knowing that it will find its way into the automobile industry. 

And as a business manager or customer support liaison, which customer are you supporting most?

• The one that pays the bills (automobile manufacturer) or 
• The customer that buys the car?

In the Agile sense of value-as defined-by-the customer, who is most influential?

Long term, these are my wonderments. I wonder how they would be written into project requirements?

• I wonder if you'll be able to go to your local auto parts retailer and buy an upgrade-on-a-stick for legacy vehicles? 
• I wonder if there is not a whole industry to be invented supporting older cars with updated interfaces?  
• I wonder if its practical to expect the after-market developer to maintain currency for 'a long time'. 
• I wonder if personal security, data security (nav data, for instance, but also other data about downloads to the car like music stations and podcasts, etc), and all the rest will not spawn a whole set of requirements, support issues, and a supporting industry?

Perhaps in the future, the mantra will have to be something like this:

The software is never done!
And, neither is the car!

---

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

Is your enterprise Agile?

---

Applying agile methodology in your software project? Good!

Working for an organization large enough to be called an 'enterprise'? Probably that's good.

Why so?

• Access to resources is the main reason. You may have heard that agile is all about small self-directing teams -- yes, that's part of the doctrine.
   
• But how many teams are needed for your project? Dozens? Hundreds even? Where do those people, tools, training, facilities, communications, etc. come from? And who pays for all that?
  
  
• Answer: the Enterprise.
  

Ah, yes, the enterprise has money!

And where does that money come from? Not you, most likely. Other people! So Other People's Money (OPM) is what is funding you.

Who are these people? If an enterprise, then there are going to be a wide variety: Customers (profit), or taxpayers (if you're a government enterprise), or donors (if you're a charity, church, etc), or owners (if privately held), or investors (if you're a publicly traded company)

Enterprise imposes expectations

So, here's the thing: even if you're doing Agile methods in an enterprise setting, the enterprise will impose expectations up front .... starting with: expected value return on resources invested.

It's natural that Agile people resist too much "up front" definition; we're about evolution and iteration. But there has to be a compromise.

It's the ageless problem: Other people's money! OPM comes with strings, to wit: a value return is more than expected; it's required.

Enterprise expects estimates (gasp!)

And here's another thing: the enterprise expects that you can estimate/forecast/predict what the resource requirements are that will get to something valuable (to the enterprise). In other words, it's rare indeed that there's a pot of gold you can dip into at your leisure and convenience, unless you're just a researcher working on your own small project.

Enterprise brings scale

What makes an enterprise an enterprise is size and scale. 

And what makes a project "enterprise" in it's scope is size and scale.

And there is the rub: Size and scale is always more than what a handful of people can carry around in their head. So, many others have to lend a hand and participate in making and supporting both size and scale. 

Scale is not just a lot of one thing, like a large code base. Scale brings breadth, meaning a lot of different things involved and integrated, and scale brings then brings rules, procedures, accountability, etc. into the frame because a lot of people have to work somewhat anonymously ... according to rules and procedures ... to bring it together, repeatedly, within predictable limits.

The question: "Can it be done what your doing 'at scale'?" Hand-crafted, job shop, one-off are not descriptions of scale.  

Enterprise brings rules

There will be a lot of rules. 

There will be a lot of rules because there will be a lot of people involved, many you will never meet, doing jobs for the enterprise you may not even be aware of, but these jobs will nevertheless touch your project or product.

Enterprise requires a narrative

Invariably, one of the rules is going to be you have to have a viable narrative to get resources committed to your project. The standard elements of the narrative you've heard before:

1. Vision: What is envisioned as the benefit to the enterprise? Who are envisioned as the beneficiaries?
2. Scope: What is it you're going to do (and what are the ancillary or consequential impacts elsewhere in the enterprise that you don't consider part of your scope?)
3. Schedule: when can you likely produce results (no single point estimates, of course. It takes a range!)
4. Resources: how much, and when (cash flow, and resource allocations)

I can't do this!

Narrative, estimates, rules, value commitments?

You're not enterprise-ready!

I almost forgot:

I wrote the book: "Project Management the Agile Way: Making it work in the Enterprise" 2nd Edition

---

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

Activities, Results, Methdology

---

Back in yesteryear, I recall the first time I had a management job big enough that my team was too large for line-of-sight from my desk and location.

Momentary panic: "What are they doing? How will I know if they are doing anything? What if I get asked what are they doing? How will I answer any of these questions?"

Epiphany: What I thought were important metrics now become less important; outcomes rise to the top

• Activity becomes not too important. Where and when they worked could be delegated locally
• Methods are still somewhat important because Quality (in the large sense) is buried in Methods. So, can't let methods be delegated willy nilly
• Outcomes now become the biggie: are we getting results according to expectations?

There's that word: "Expectations"

In any enterprise large enough to not have line-of-sight to everyone, there are going to be lots of 'distant' managers, executives, investors, and customers who have 'expectations'. And, they have the money! So, you don't get a free ride on making up your own expectations (if you ever did)

At the End of the Day

• I had 800 on my team
• 400 of them were in overseas locations
• 400 of them were in multiple US locations
• I had multiple offices
• It all worked out: we made money!

---

---

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

"Against the Gods"... a risk perspective

---

If you are in the project management (read: risk management) business, one of the best books that describes the philosophy and foundation for modern risk management is Peter L. Bernstein's "Against the Gods: the remarkable story of risk".

Against the Gods is historical, somewhat philosophical, and void of math!

It's a book for "thinkers"

Between the covers of this "must read" we learn this bit:

The essence of risk management lies in maximizing the areas where we have some control over the outcome while minimizing the areas where we have absolutely no control over the outcome and the linkage between effect and cause is hidden from us.

Peter Bernstein

"Against the Gods: The Remarkable Story of Risk"

Knowledge and control

Dealing with risk necessarily breaks down into that in which more knowledge will help us understand deal with risk (climate change), and that in which effects are truly random and no amount of additional knowledge is going to help (rolling dice).

Bernstein goes on to develop one of the key themes of the book which is the idea that probability theory and statistical analysis have revolutionized our ability to understand and manage risk.

Picking apart Bernstein's "essence" separates matters into control and knowledge:

• We know about it, and can fashion controls for it
• We know about it, and we can't do much about it, even if we understand cause and effect
• We know about it, but we don't understand the elements of cause and effect, and so we're pretty much at a loss.
• We don't know about it, or we don't know enough about it, and more knowledge would help.

Of course, Donald Rumsfeld, in 2002, may have put it more famously:

" ....... because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know."

No luck
So there is an ah-hah moment here: if all things have a cause and effect, even if they are hidden, there is no such thing as luck. (Newtonian physics to the rescue once again)

Thus, as a risk management regimen, we don't have to be concerned with managing luck! That's probably a good thing (Ooops, as luck may have it, if our project is about the subatomic level, then the randomness of quantum physics is in charge. Thus: luck?)

Indeed, our good friend Laplace, a French mathematician of some renown, said this:

Present events are connected with preceding ones by a tie based upon the evident principle that a thing cannot occur without a cause that produces it. . . .
All events, even those which on account of their insignificance do not seem to follow the great laws of nature, are a result of it just as necessarily as the revolutions of the sun.

Bernstein or Bayes' (with help from ChatGPT)

Following up on the idea of the knowledge-control linkage to risk management, Bayes' Theorem comes to mind. Bayes' is all about forming a hypothesis, testing it with real observations, and using those outcomes to refine the hypothesis, eventually arriving at a probabilistic description of the risk.

LaPlace, mentioned above, is one of the architects of the probability theory that underlay Bayes'.  Thus, one of the most interesting discussions in the book centers on Bayes' theorem, which Bernstein describes as "one of the most powerful tools of statistical analysis ever invented."

Bayes' theorem is a manner of reasoning about random and unknown effects and a mathematical formula that allows us to update our beliefs about the probability of an event occurring based on new evidence. It is a powerful tool for making predictions and decisions based on incomplete information, and it has applications in fields ranging from medicine to finance to engineering.

Bernstein's discussion of Bayes' theorem in "Against the Gods" is particularly interesting because he highlights the fact that Bayesian reasoning is often at odds with our intuition. Humans have a tendency to overestimate the likelihood of rare events and underestimate the probability of more common events. Bayes' theorem provides a framework for overcoming these biases and making more accurate predictions.

Cognitive Bias in risk management

Bernstein talks a lot about cognitive biases and their impact on decision-making under uncertainty.

According to Bernstein, cognitive biases are mental shortcuts that people use to simplify complex decisions. These shortcuts can lead to errors in judgment and decision-making. Cognitive biases can be influenced by a number of factors, including emotions, personal experience, and cultural values.

Some examples of cognitive biases that Bernstein discusses in the book include the availability bias, which is the tendency to overestimate the likelihood of events that are more easily recalled from memory; and the confirmation bias, which is the tendency to look for information that confirms our existing beliefs and to ignore information that contradicts them.

One key point Bernstein makes is that humans have a natural tendency to be overconfident in their abilities to predict and control events. This is known as the "illusion of control" bias. People often believe they have more control over events than they actually do, leading them to take on more risk than is rational.

Another common cognitive bias is the "confirmation bias," in which people seek out information that confirms their preexisting beliefs, while ignoring or dismissing information that contradicts those beliefs. This can lead to a lack of objectivity in decision-making.

Bernstein also discusses the "hindsight bias," in which people tend to believe that an event was more predictable after it has already occurred. This bias can lead to overconfidence in future predictions, as people may believe that they could have predicted the outcome of an event that has already occurred.

Overall, Bernstein suggests that understanding and being aware of cognitive biases is essential to making better decisions and managing risk effectively. By recognizing these biases, individuals can take steps to mitigate their impact on their decision-making processes.

---

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

RaaS .. It's about results

---

It's been around a few years, but RaaS ... Results as a Service ... is getting more play in projects. RaaS is a play on the more familiar and older SaaS, Software as a Service. So the difference is, among other things, that RaaS is end-item focused; tools and processes are in the black box; and the customer is buying a result they can use.

Wait!

Have we just relabeled the firm fixed-price (FFP) contract?

• FFP has been around since the beginning of time it seems.
• The customer contracts for an outcome, a result, and end-item, at a fixed price.
• The customer does not weigh in on process, methods, and tools
• The customer does not weigh in on staffing or schedule details. Major milestones, perhaps only one milestone at the end are all that count.

If Agile Methods are part of the FFP contract, then the customer may be in the loop for partial product evaluation and course corrections, but such has to be within the envelope of the original scope, or the dreaded change order comes out. And if that happens, there goes the "fixed price".

In any event, beware of old wine in new bottles, unless the wine is really different, along with the bottle!

---

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

The ideal number of workers

---

Wow! Is this true?

The ideal number of human workers in any business is zero. The purpose of companies is to make as much money as possible with the lowest possible expenses. So AI and other types of automation are not disruptions to a human-based Capitalism—instead, they’re revealing that today’s Capitalism is not fundamentally human in the first place.  Daniel Miessler

"... in ANY business ... "? Emphasis added by me. 

I have no idea how you could do projects with such a situation. So, I'm hopeful Miessler's idea is not an end-game for the PMO.

---

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

Best-and-Final-Offer Strategices

---

You're in a competitive bidding situation for a new project contract.

The buyer-customer calls for BAFO submission (Best and Final Offer)

What's you game plan and BAFO strategy to be?

Game Theory

You could fall back to game theory ideas:

• You can't cooperate with your competition, so you are adversaries
• You and your competitor both view the situation as zero-sum; there's not a win-win compromise solution
• Everyone has about the same tools to manipulate (Cost, Schedule, Scope)
• You may have some intelligence regarding customer's expectation of what is a winning BAFO strategy re cost, schedule, and scope.
• You may have some intelligence about the bidding history at BAFO of your competitors.
• Everyone has the same timeframe-- there is only one due date for the BAFO.
• The game is fundamentally unstable: You're seeking maximum optimization, not some sub-optimum stability point with your competitor (assuming the customer is only going to make one winning award, which is not always the case) 

Making it to BAFO in the first place

If you've made to the BAFO, then you've made the cut on minimally acceptable cost, schedule, and scope. 

If you're bidding to a government agency, you've also made the cut on past performance, financial strength, and regulatory compliance. 

If you've got subcontractors and specialty SMEs then that cast has made the cut with you.

Do's and Don'ts

• Do read carefully the invitation to submit a BAFO. The bias of the customer may well be exposed in the wording of the invitation.
• Don't bait and switch at BAFO key personnel, labor mix, or technical approach unless you can point to specifics from the customer's feedback to you that suggests that such cuts would be welcomed.
• Do offer a bottom line discount to price if you're bidding fixed price, but 
• Don't jiggle labor rates, labor mix, and labor participation unless you can point to customer comments that justify such. You should anticipate there will be change orders and you will not want rates, mix, and participation to be compromised for the future opportunity.
• Do wiggle the schedule if there are productivity improvements you can point to down the line
• Do rearchitect the schedule to remove constraints and improve probability of success on the critical path. Justify this with analysis you've done since the initial submission.
• Do take advantage of any independent R&D that will feed into the project.
• Don't do anything unilaterally that will damage your credibility in the eyes of the customer. Unsupported changes are often viewed as unworthy business practices and new risk.

---

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

NSA on deep fake detection of video conferencing

---

As I previously posted, there is a growing threat that the person to whom you are video conferencing is really a deep fake. For projects, this threat arises in recruiting strangers remotely by video call, but also in other situations when the 'familiar face' is really fake. (But I know that person! How could the image I'm seeing be fake?)

Here is a report of new research by NSA and UC Berkley about a tool -- 'monitor illumination' -- that can 'fake the fakes' in a way that gives better assurance that the fake is detected.

Of course, now that this has been widely published, the counter-counter-measures are probably already on the drawing board, so to speak.

---

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

Classified projects ... claiming credit

---

Most of my career has been working in the black and grey world of classified projects. 

If that is your domain, heed these words:

It is the nature of classified projects that "successes are unheralded and .... failures are trumpeted"

JFK

So, if you have an idea of putting your successes on your resume, looking for your next job, gig, or career move, beware!

 

---

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

Collaboration ... virtually

---

" ....virtual collaboration is like evaporated milk with 60% of the water removed; safer; mostly up to the job, but a sterile version of face-to-face that leaves an unsatisfying aftertaste"

"Bartelby" columnist in the "Economist"

Our columnist goes on:

"There are downsides to being a clinically efficient worker. They include relinquishing the daily banter and complicity among colleagues..... Hyper efficiency and distance mean less opportunity for interpersonal tension but also less gratuitous job, which is hard to replicate on Zoom."

But then, on a business channel, I hear a start-up guy talking about developing a software application (alternative to Zoom, or Skype, or Webex) that has 'humanity built-in' 

"Humanity built in"! Perhaps, but let's wait and see ....

---

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

U.S. Gov Cloud Security... An architecture

---

Have you got a project providing software services to the civil agencies of the U.S. Government? 

If so, you should be aware of the 'technical reference architecture' authored jointly by CISA, USDS, and the Federal Risk and Authorization Management Program.(*) 

Some of its provisions are likely going to find their way into RFPs and RFIs from the civil agencies.

From the document, we get this insight from the introduction:

This technical reference architecture is intended to provide guidance to agencies adopting cloud services in the following ways:

• Cloud Deployment: provides guidance for agencies to securely transition to, deploy, integrate, maintain, and operate cloud services.
• Adaptable Solutions: provides a flexible and broadly applicable architecture that identifies cloud capabilities and vendor agnostic solutions.
• Secure Architectures: supports the establishment of cloud environments and secure infrastructures, platforms, and services for agency operations.
• Development, Security, and Operations (DevSecOps): supports a secure and dynamic development and engineering cycle that prioritizes the design, development, and delivery of capabilities by building, learning, and iterating solutions as agencies transition and evolve.
• Zero Trust: supports agencies as they plan to adopt zero trust architectures.

This technical reference architecture is divided into three major sections:

• Shared Services: This section covers standardized baselines to evaluate the security of cloud services.
• Cloud Migration: This section outlines the strategies and considerations of cloud migration, including explanations of common migration scenarios.
• Cloud Security Posture Management: This section defines Cloud Security Posture Management (CSPM) and enumerates related security tools for monitoring, development, integration, risk assessment, and incident response in cloud environments.

 

---

CISA is the operational lead for federal civilian cybersecurity and executes the broader mission to understand and reduce cybersecurity risk of the nation
The United States Digital Service (USDS) is a senior team of technologists and engineers that support the mission of departments and agencies through technology and design.
Federal Risk and Authorization Management Program provides a cost-effective, risk-based approach for the adoption and use of cloud services by the Federal Government.

---

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

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

Agile "DONE" defined

---

Now we're getting somewhere! No less an Agile/Scrum eminence than Mike Cohn -- author of some really good books and articles -- has come out with a newsletter on -- are you ready for this? -- what's the meaning of DONE in Agile.

His acronym, a bit a poor choice to my mind, is "DoD"... Definition of Done. But, there you have it... perhaps a new GAAP "generally accepted agile practice" for agile-done

In the past, my definition of "Done" has been framed by the answers to these three questions:

1. Is it done when the money or schedule runs out?
2. Is it done when the sponsor or product manager says it's done?
3. Is it done when Best Value* has been delivered?
   * The most ,and the most affordable, scope within the constraints of time and money

If you can't read my bias into these questions, I line up firmly on #3.

Cohn instructs us differently:
A typical definition of done would be something similar to:

• The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
• The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
• The code was either pair programmed or peer reviewed.
• The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
• The feature the code implements has been documented in any end-user documentation such as manuals or help systems. 

Cohn hastens to add:
I am most definitely not saying they code something in a first sprint and test it in a second sprint. “Done” still means tested, but it may mean tested to different—but appropriate—levels.

Now, I find this quite practical.. Indeed, most of Cohn's stuff is very practical and reflects the way projects really work. But it's very tactical. There's more to a product than just the code. In other words his theory is proven when, in the crucible of a trying to make money or fulfill a mission by writing software, you are strategically successful (deployable, saleable, supportable product) while being simultaneously tactically successful. How swell for us who read Cohn!

---

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

Project Toys

---

I generally do not endorse products on this blog, and this posting is not an endorsement per se, but more of a "heads up" because in the PMO there are always a lot of documents and things to write, many to a multi-lingual project team. Here is a tool that might be of use.

Text Processing "toy": I was attracted to a recent headline that in the Microsoft "Power Toys" suite of tools for Windows11 (*) is a capability -- "Advanced Paste" -- that provides automated text translation and other "processing" in the "cut and paste" function. (All aimed at keeping the PC relevant I would guess)

According to CoPilot, Advanced Paste has these functions:

1. Functionality: With Advanced Paste, you can select the desired text format for pasting, but it goes beyond simple copy-paste. Here’s what you can do:

   • Summarize Text: Request a summary of the text.
   • Translate: Translate text into another language.
   • Code Generation: Generate code based on data from the clipboard.
   • Rewrite Text: Modify text in a different style or structure using natural language.

2. AI-Powered: To enhance these capabilities, the app communicates with OpenAI servers. However, this requires paid access to the OpenAI API.

___________

(*) Note: You can download the Power Toys suite from the Microsoft Store for Windows 11. The download is free, but the AI features required a paid access to the OpenAI API. 

---

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