Guessing and Bayes

---

In my posting prior to this one, I gave an example of 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!

---

Buy them at any online book retailer!

Schedule merge: the biggest hazard of all

---

Do you understand the risk you are running when two events come to a merging point in your schedule?

Here's the situation:

• There's a series of tasks running along on one path, call it "A"
• There's another series of tasks, not dependent on "A", running along on path "B"
• But, all the events set to begin on path "C" can't begin until everything on paths "A" and "B" finish.

In effect, the completion of everything along "A" and "B" gates, or controls, the beginning of "C".

So, where is the hazard? 

The hazard is that "C" will be late starting if either "A" or "B" are late. Actually, that doesn't sound like such a big deal, so what's the problem here? 

It's all in the probabilities. Consider this example:

• "A" probably late 1 chance in 4 [written as: 1/4], and
• "B" probably late 3 chances in 10 [written as : 3/10].

Not great, but not too bad for either one of them. But what can we say about the chances for "C"?

 

We'll show in the discussion that follows that "C" will be late approximately 1 chance in 2. That's a good deal worse than 1/4 or even 3/10. It's a biggie if you are trying to figure out when "C" is going to kick-off.

 

Reasoning with probabilities

To deal with probabilities, we have to deal with a number of chances of "A" and "B" because probabilities are determined by observing variations in the same thing over and over.

 

So, for this example, let's use the common denominator of 4 x 10 for the number of chances (*).

• In 40 chances, we expect "A" to to be late 10 times (1 chance in 4, 10 chances in 40), but on-time 30 times. Of course, "C" will be late those 10 times that "A" is late.
  
• But when "A" is on-time, 30 chances (out of 40), the performance of "B" determines the performance of "C" ("B" late makes "C" late).
  
  
• In 30 chances we expect "B" to be late 9 times (3 chances in 10, 9 chances in 30).
  But if late 9 times, then "B" is on-time 21 times
  
  
• Consequently: "C" is expected to start on-time 21 of 40 trials, or just over 50% (about 1/2)
  
  
• But, that means "C" is expected to be late almost half the time -- 10 late starts from the effects of Path A and 9 more from Path B. Altogether, that's 19 late starts out of 40  -- a serious performance degradation from either that of "A" [25% late, 10 out of 40] or "B" [30% late, 12 out of 40]
  

(*) the common denominator of 1/4 and 3/10 is 40

We can show all this with this mapping chart:

	Path A	Path B	Path C
Probably late	1/4	3/10	1 – 21/40
Probably on-time	3/4	7/10	21/40

Independence simplifies:
Notice that along the bottom row, Path C is just the multiplication of Path A and Path B probabilities
Along the top row, the probabilities in all cases are just 1- bottom row, cell by cell. [the number 1 represents all possibilities]

These calculations are only valid if Path A is in every way independent of Path B. If not, then there is cross-talk between paths that will degrade the calculations. 

But in a project, what does independence mean?

• No shared resources that could cause conflicts
• No shared lessons-learned after the tasks on Path A or B begin
• No changes in "A" because of what is happening in "B"

Now, in a in-person project, maintaining independence may be difficult, perhaps not even desired -- to wit: why not share?  But in a remote/virtual project, independence may be the order of the day, even if it is not desired. Another effect of the virtual thing, to be sure!

 

 

---

Buy them at any online book retailer!

Permanently remote?!

---

You just got the memo: the project is transitioning from temporarily to permanently remote!

What does this mean?

• At a minimum, you've got to go in and clear out your physical office ... if you ever had one.
• And, you may need to go ahead and make an investment in renovating your home office 
• Or, maybe it's time to rent some desk space somewhere so you have a place to go other than Starbucks to work remotely, but yet get away

Relationships
On a larger scale, many of your relationships will fade from familiar to official. Many team members you will never meet in person. If you are a team leader, those career very personal counseling sessions, mentoring moments, and casual exchanges that build strength and trust into a relationship may be gone.

Trust, respect, and fear
Trust and fear are often counter-parties to many relationships. Fear may come first, then respect, then trust. Generally, we don't trust strangers, though we may respect them. If they are somehow different from us, unconscious fears about differences that are the drivers of survival instincts may kick in until we get to know them and they are no longer strangers.

Body language is 50%
They say body language is 50% of our communication mechanisms. Well, Zoom may fill in a lot of that, but not all. Consequently, other communication skills will have to be strengthened and given more weight. Yikes! We may have to take greater care in text and email messages. 

Velocity
And, it all slows down. There just isn't the bandwidth in a remote setting to duplicate face-to-face and the casual and fortuitous communications of the office espresso machine. 

Meanwhile
Meanwhile, get a big box, go to the office, and clear out!

---

Buy them at any online book retailer!

Projecting the past

---

Some people live in fear because they project the past into the future

Anonymous

Now, to put that in project terms, some PM's may see fear in the future because they project (extend) troublesome project history into the future. The poster child for this are the two common cost metrics:

• What is it going to take to finish this thing? and
  
• What is going to cost when it's all done?
  

Your project analyst may know them as:

• "estimate to complete ETC"
• "estimate at completion EAC"

How are these calculated?

Two common methods, and each will give a different answer:

1. First method: From cost history, extend (that is, project) the historic trend into the future
2. Second method: Take cost history in account, but simply re-estimate the remaining work

Both methods have their fear factors.

Trend line

Simply projecting .. or extending .. a trend line assumes that the future is some predictable function of the past. If this is true, then such a "predictable function" can be described with an algorithm more or less of this form: Y = aX + b

• Where Y is some future cost figure, X is some past cost figure, and "a" is the velocity or slope with which X marches toward Y.  And "b" is some past sunk cost that predates X; "b" is often zero. (*)
  

But fear not! If you don't like Y as an outcome, then don't accept "a" as a given for the future. To wit: force a discontinuity in what is otherwise smooth trend line, making a break between the trend of the past and the direction of the future.

Discontinuous trend

You deal with fear by forcing a discontinuity in the trend line.

“The best way to predict the future is to to create it.”

A. Lincoln

To wit: "a" before you act becomes "A" after you act.

What to do to make "A" different from "a":

• The PM can reallocate resources; retrain existing resources; evaluate remaining scope differently; change the environment; bring in different relationships among users, sponsors, and developers; in short: the PM can markedly make the future look different from the past, nullifying the trend line.

Simply estimate

Now, having set new conditions in place at the discontinuity, estimate the new baseline. The trend will probably be an equation of this form: y = Ax + B, where:

• y is the new target, replacing the historic Y
• A is the new velocity, replacing a
• x replaces X
• B is the sunk cost of the history. B = aX + b at the point of discontinuity.
  

All clear? Excellent!

------------------------

For those with an understanding of algebra, it's necessary to keep everything dimensionally correct. Thus, if Y is dimensioned in dollars, then so must be aX and b. X is dollars, so that requires that "a" be dimensioned as dollars per dollars, or dollars/dollars. Consequently, "a" is an expression of efficiency, meaning so many dollars of cost per so many dollars of budget.

---

Buy them at any online book retailer!

The business of projects is Business

---

The business of projects is Business. Don't believe it? Don't understand it?

• If the customer is not satisfied, they may not want to pay.
• If they are not successful, they cannot pay.
• If they are not more successful than they already were, why should they [pay]?

Niels Malotaux
Paraphrased a bit

Now, let's say your project doesn't directly touch the external customers. Maybe you're doing a project for the HR department, or maybe you're upgrading the painting process for something your business manufacturers. Does Niels' little ditty still apply?

Perhaps this rewrite will make the point:

• If the project's sponsor is not satisfied, they may not want to trust you with resources again
• If they are not successful, they cannot help you be successful
• If they are not more successful than they already were, who needs you?

Consequently, can you say you were consequential to business success? If not for you as the PM, would there be a successful project, or as successful a project? Did you really add enough value to pass through the gates I described just above?

Truly, let's hope so!

---

 

Buy them at any online book retailer!

Training budget for project robots?

---

Are you busy building your project budget?

Are you going to include a budget for training your project's working staff?

• New developer and testing tools;
  
• New frameworks;
  
• New process and workflow management?

If that's a Yes and Yes, have you thought about this? You may need to train your project robots also.

 

Really?

Really!

Robots, whether mechanical and real, or virtual, all depend on training data to get their AI parameters set. Now, sometimes it's all built-in and there's no API, like the robotic vacuum cleaner, but for most AI-based [robotic] project tools some degree of training on test data sets is necessary.

• Expert systems which execute according to rules trained on knowledge bases
• Data estimators that fill in the blanks ... from history and current trends
  
• Fuzzy logic that studies patterns and offers assistance with scheduling and administration
• Predictive analytics for risk assessments based on risk histories (unlikely to predict a black swan, but don't rule it out)
  

How to start

And so, having decided about how AI is to be integrated into the PMO -- that being no small matter by itself -- the questions are begged:

• At what cost do I go about assembling a training data set,
  
• What should the data set contain,
  
• Who will administer the training, and
  
• Who's done this before?

Look here for the answer

Actually, you won't find those answers here because project AI is too situational dependent. But, the major frameworks all have user group forums; the major tool vendors all have support systems; and there are a myriad of consultants around this industry. 

Your job: don't forget to budget to train the robots!

---

Buy them at any online book retailer!

Plan v Objective

---

"In war [projects] nothing goes according to plan, but always remember your objective"

Israeli general

Good advice.

And, of course, your objective always is -- or always should be:

Apply your resources to maximize their value added while taking the least risk to do so.

But our general's admonition begs the question:

Is "nothing goes according to plan" the same as there's "no value in planning"? And, if so, why plan in the first place? Why not maximize agility?

Or, why not be Bayesian about it: Make an educated guess to begin, and then replan with new information or circumstances?

The usual answer

The usual answer to those questions is that the value of the plan is in the planning, that is: discovering one or more paths to victory! One or more ways to accomplish the objective.

And, if there is more than one way to get there, then whatever plan is adopted is not totally fragile; an alternative is available if things go really wrong.

That all said, planning is about doing these tasks and investing intellectually in their development:

• Establishing the scope detail that fills out the objective .... or narrative
• Anticipating the risks and devising mitigations .... or not (some risks can be ignored)
  
• Assembling resources; training staff and robots [AI is in the training frame these days]
• Establishing a sequence for doing the work
  

Such that, when the plan goes awry, it can be reconfigured -- perhaps on the fly -- and re-baselined, always with the most strategic objective in mind.

And, did I mention that the foregoing is Bayes-style planning methodology: always update your first estimate with new information, even it makes the first estimate look a bit foolish or optimistic

Yogi said:

Yogi said a lot of things, but he said this that seems to apply:

"If you don't know where you are going, you may be disappointed when you get there."

In our business, you might write it thus:

"If you don't [or won't] plan what you are going to do, you may be disappointed in what you wind up doing"

And, you might miss the objective altogether. You spent all the money -- presumably other people's money [OPM] and you didn't do the job! [That's usually a challenge to your career]

---

Buy them at any online book retailer!