Saturday, October 24, 2020

The skills stack


The skills stack. Heard of it? Somewhat like other stacks of stuff, except the focus is on skills needed in the PMO ... and elsewhere. 

Actually, to me, the description of the stack as provided by strategic thought leader Greg Githens, is less a stack -- which implies an ordering from top to bottom -- and more a flat mesh of interrelated skills. 
 
As used by Githens, one might argue with the term "skill", given that we usually think of skill as some ability specifically learned, practiced, and applied. But, if you expand "ability" into practiced and applied behavior, and also into directed energy and attention, then "skill" in this broader sense is what Githens is getting at. 
 
So, here are three "skills" ... broadly speaking ... I particularly like, as authored by Githens:
... AMBITION, [which] captures an individual’s desire to... achieve their goals.

... ANTICIPATION, [which] is ... looking into the future, knowing that your decisions today will bear their consequences in the future. ...

... REFRAMING, [which] is .... intentionally adopting new points of view and explanations. ...

To this I might add:

  • Ambition is typically personal, and often self-centered, but in a larger calling, one could be ambitious to be consequential, to wit: to make a difference that affects others as well as yourself. To be consequential, to have made a difference by your efforts, could be your goal. Why not?

  • Anticipation is certainly looking ahead into the future. A skillful anticipator can assemble a narrative, with its attendant consequences, benefits, costs, and risks, and sequence the tactics necessary to achieve the objective.

  • Reframing is a quite useful skill, often stated as "walk in the other guy's shoes". In effect, step out of your frame of reference and see it from your nemesis', customer's, sponsor's, or partner's perspective, experience, and sense of risk.
    Often, you have to set aside many biases, and reorder priorities in order to skillfully reframe a situation.
    Set aside biases? Really? That's not an easy thing to do. The science of game theory, however, provides some of the tooling that useful for seeing things from another point of view.




Buy them at any online book retailer!

Wednesday, October 21, 2020

Counter-party risk


Define counter-party: 
In a transactional relationship, the other party to -- or participating in -- the transaction is your counter-party.
 
In project situations, there are usually many counter-party transactional arrangements, such as contractors and suppliers with transactional relationships. And within the business there may be transactional relationships among business units and the PMO. 
 
Oh! And don't forget the money: there may be financiers of the business or project which have a counter-party relationship to the project.

Fair enough. But now comes counter-party risk: the risk that the other party to the transaction, or perhaps you yourself, will not be able to hold up their side of the transaction.
 
About counter-party risk
So, you are about to enter into a transaction with another party. What might be the risks?
  • Trust: you may not know the other party well enough to convey trust, a willingness to believe what they say without the protections of a written agreement.
  • Ability to perform their side of the transaction may be in question. Do they have all the requisite tools, resources, and experience? Is something required of you in order for the other side of the transaction to be completed?
  • Willingness to perform their side of the transaction when the whole deal comes under stress may require backup
What is your strategy; what are your tactics?
  • Your strategy should be to keep the counter-party fully engaged with intent to fulfill their side of the bargain.
  • Your tactics should be to put in place standard risk management tools: Written agreements with incentives and penalties; sober assessments of their track record on similar activities; and perhaps insurance for consequential damages if the counter-party fails.



Buy them at any online book retailer!

Sunday, October 18, 2020

Complicated and complex


"They" say it's complicated
"They" say it's complex

Are they saying the same thing?
No, actually, there are differences:
  • It's complicated if "it" has a lot of parts and pieces
  • It's complex if the parts and pieces have a lot of interactions among them, and many of the interactions are not readily apparent, hard to model or predict, and may even lead to chaotic responses 

Good or bad; fix or ignore?

So is complicated or complex a good thing or bad? How would you know? And, what's to be done about them? 

Short answer: Chaos is almost always bad in a system, product, or process -- whatever is the project's outcome. Thus, for that reason alone, complexity may not be your friend.  

But, even without chaotic propensity, complexity is usually not a good thing: complex systems are hard to service; hard to modify; difficult to integrate with an established environment; on and on. If such are present, then complexity is present -- that's how you know.

Complicated is usually a matter of cost: lots of parts begets lots of cost, even if there is minimal complexity. Simple is usually less costly and may not necessarily sacrifice other attributes.

So, what do you do? 

You've read the theory; now, to action:

  • Chaos is bad; let's start there. The fix is to reduce complexity. To reduce complexity, a generous number of interfaces are required.
    The purpose of the interface is to block propagation of chaotic responses and contain risk to smaller elements of the system.
    Proof is in the testing. All manner of stimuli is applied to try to induce chaotic responses, and address those that occur. 

  • Complexity is first addressed by interface design; then by service design. To wit: if you have to fix something, how would you separate it from the system for diagnosis, and then how would you repair or replace? Addressing these functional problems will in turn address many of the issues of complexity

  • Complicated means a lot of parts. If that's more expensive than you want to afford, then integrated assemblies will reduce the part count and perhaps address some of the issues of complexity.
    If you've ever looked inside an old piece of electronics circa 1960 or older, you can appreciate the integrated modular design of today's electronics. Hundreds of piece parts have been integrated into a dozen or fewer assemblies.





Buy them at any online book retailer!

Thursday, October 15, 2020

Delusions of vision


In this blog and elsewhere, the visionary leader is extolled, aspirational in every respect.
But, what if their strategic vision is delusional?
  • From predicates A and B, the leader envisions C
  • But, inferring C from A and B is a delusion, unsupported and unsupportable
Perhaps such a delusion is revealed in hindsight, but in the moment who can say C is a delusional inference to be drawn from A and B? How can anyone know that a person is deluding themselves?
There are some signs:
  • C is a possibility, yes, but a really long shot by probability
  • C is a black swan; there is nothing from history to support C as a consequence of A and B
  • C requires new physics, unlikely to ever be realizable
  • C requires unusual political support, unlikely to be anyone's political investment
  • C is just "confirmation bias" for an outcome wished for but otherwise unlikely
What to do?
So, if your PMO is being led by a leader you think is deluding themselves, what should you do?
 
First, look for your own confirmation bias. Indeed, are you the one that is deluded into thinking the bold and brave is not possible and you look for the supporting evidence to confirm your point of view, discounting ideas to the contrary?

Second, are there others that have the bona fides to not only agree with you but to also speak truth to power about the likely outcomes?

And third, if not C, then what is the inference to be drawn from A and B? Which is the greater error: the cost of accepting C as the objective, or the cost of discarding C and going for C-alternative?

Obviously, all situational. There's no fixed process or recipe.
Did I mention: Good Luck!


 


Buy them at any online book retailer!

Tuesday, October 13, 2020

Coupling, coherence, and other stuff



Has someone in your PMO suggested applying a dose of system engineering to portfolio management? If they have, I wonder if they think of it as "three C's and D"?

A bit cryptic? Well, not so much when you spell it out:
Coupling, coherence, cohesion, and diversification

The short form explanation of  three C's and D looks like this:

Here's a little explanation:

Coherence

Coherence is what gives rise to reinforcement and to synergies. Coherence gets its power from phasing and sequencing....in other words, timing. Take 20 people and let them chat at a party and you have--to the macro listener--noise; but phase things correctly and you could have a choir. In other words, from noise a song!

Cohesion

Cohesion is what makes things stick together and perform under stress; to accept tension among parts and keep on going. In a portfolio, it's a matter of making good on the overall business value proposition, and doing so under stress.

The qualitative idea is weak or strong cohesion; ordinarily the metric is strength under stress, which for projects is tolerance for failure.

Strong cohesion means that if one project, or some aspect of a project, fails in some sense, the tensions created among projects because of failed dependencies are not crippling to the business outcomes. Cohesion requires redundant or alternate paths to customer satisfaction through the network of portfolio projects.

Coupling

Coupling is well understood notionally: it's the idea that one effect or outcome directly influences another. Generally, we think of coupling as being loose or tight, referring to how well one effect is transferred onward. Insulation loosens the coupling between outside and inside, etc. 
 
In projects, loose coupling is usually the desired quality. A failure in one project is not coupled into the next is the idea. In portfolios, the same is true. We want high coherence and strong cohesion but loose coupling. And, all three together is sometimes a challenge.

Diversification


Most of us understand diversification from the financial portfolio experience: when one investment is down, another is up, and the overall result is within a range of acceptability. If all investments are really independent of each other, the range of results is compressed by approximately the square root of the number of investments in the portfolio--the square root of N rule.

The same is true of project portfolios. The secret sauce is independence. If coupling is not loose, independence is forfeited, and so also is the power of diversification forfeited.

How to sum up?

Perhaps I'll just say there's a place for system engineering in project management. 




Buy them at any online book retailer!

Saturday, October 10, 2020

Be Bold; be brave; be calculating



I would hardly think today of making my first flight on a strange machine in a 27-mile wind . . .

I look with amazement upon our audacity in attempting flights with a new and untried machine under such circumstances.

Yet faith in our calculations and the design of the first machine, based upon our tables of air pressures, secured by months of careful laboratory work, and confidence in our system of control … had convinced us that the machine was capable of lifting and maintaining itself in the air

— Orville Wright, from “How We Made the First Flight” (*)

I hope you were able to read the last sentence, as long as it is -- my editor would have been apocalyptic!

So, what have we got here with O.Wright's statement that can inform project management?

He begins with audacity! Audacity: "a willingness to take bold risks"
To be audacious! Audacity is a risk attitude that is at first personal, but then infects the whole project culture.

But not recklessly bold risks. Audacious is one thing; willful recklessness is entirely different.

Then comes the skill and science

So then comes the science, the engineering, and the risk management to leaven the audacity. Afterall, as we learn from author Jo Nesbo, "Someone will no doubt come up with an opinion with the benefit of hindsight, but we prefer to be wise in foresight".

In this case, wisdom in foresight requires:

  • Calculations and tables of metrics
  • Careful laboratory work
  • Confidence in the system engineering
  • Measurable goal: capable of lifting maintaining itself in air

And what does the world get with this elixir of bold thinking, careful consideration of risk, and skill-and-science?

  • Heavy machines that fly
  • Semiconductors of near atomic size
  • Electric, hydrogen, and possibly others that upend the transportation industry
  • Social media
  • Private space travel
  • And all the other stuff yet to be envisioned!


----------
(*) Quotation courtesy of Herding Cats




 



Buy them at any online book retailer!

Wednesday, October 7, 2020

Smart and Not-so-Smart



Harry’s poker-playing friend claimed that probability theory, and how to play your cards according to the rule book, was the easiest thing in the world.

But what separated smart players from the not-so-smart was the ability to understand how their opponent was thinking ...

Harry Hole, Detective,
according to author Jo Nesbo

Now, in project terms, we would like to think we don't have to worry about opponents. But, of course, that's not the case. Most practical projects at scale have a nemesis, either technical, managerial, or political.

Also, it would be great if we could all grasp "Game Theory" which lays out methodologies for assessing what your opponent is likely to do in the context of what you might be likely to do. [You can read some about this in Chapter 12 of my book, cover illustration below, "Maximizing Project Value"]

In effect "Game Theory" combines probabilities, rules for applying game rules, and methodologies for  making an 'informed estimate' of what others might do.

Stability and equilibrium
If you are working with probability theory in your project, then you are thinking and acting with some uncertainty in mind. As our detective friend says in the opening quote, just understanding some of the 'rules' around uncertainty estimates is not enough.

Coming to some sort of stable (and predictable) position in the project environment is perhaps the most advantageous outcome one could expect in an environment of uncertainty. 

 Perhaps the most practical utility of Game Theory, as applied to projects, is developing equilibrium as a stable and desirable outcome. Odd as it sounds, equilibrium is often achieved by accepting a sub-optimum outcome as a compromise outcome between 'adversaries'. 

And why would you settle for sub-optimum? You settle because the alternative is more costly without compensating benefit.

The "Nash Equilibrium" 

The Nash Equilibrium is an example of such an outcome, and it is explained in Chapter 12. In essence, you and your opponent agree to a compromise plan for which their is no net upside for either of you to divert from the plan. In other words, at the Nash Equilibrium, things are worse for you (and your adversary) if either of you make a change.

The counterpoint is obvious: as long as there are incentives for a more advantageous deal, stability will always be on the knife's edge. Recognizing whether or not you've achieved a Nash Equilibrium may be the smartest thing you can do.




Buy them at any online book retailer!

Sunday, October 4, 2020

About compartments


It's how we all get along, especially in the close quarters of a project team -- even if virtual:
"A well-ordered life has compartments. People that have secrets know that other people have secrets. That's how we all get along
Dialogue from "The Paladin" by David Ignatius

 

Of course, in the pristine description of project methodologies in the PMBOK® and elsewhere, projects are an open book. The project pyramid is transparent from top to bottom; information is readily available.

Real projects are compartmented
I should say that a well-ordered project is strategically transparent but tactically compartmented. Everyone should know and internalize the major mission elements, but tactically, there is value in limitations. 

Effective communication emulates life in a lot of ways, and one of those ways is to compartment information. Immediately, the N-squared number of communication channels between N sources is reduced exponentially.  From that one action, communication quality goes up:

  • Fewer rumors, more authoritative information
  • Less noise, greater signal

And, compartmentation is helpful when you need to put space between big egos; separate clashing personalities, and limit people interactions. It's how we all get along.

But also, compartmentation is a tool for limiting information according to sensitivity, proprietary protections, and utility according to function. Sometimes, it's just better to know less, at least with respect to tactical detail.

And, compartments reduce risk.
How so?
In the sailboat business, we speak of "rip stops" in sails. Sails are never one large sheet; they are always compartmented by seams. If a problem arises in one part of the sail, the "rip stop" seam contains the problem, prevents its spread, and usually leaves a lot of the sail useful for powering the boat.

The same goes for a project: compartments are "rip stops". A problem in one aspect of the project is contained, but the rest of the project goes forward.

And, I might add: In system engineering, we build with subsystems linked by carefully constructed interfaces. The interface provides "loose coupling" that helps contain and compartmentalize any issue in one subsystem.

The architecture of project methods
When developing the architecture of your project methodologies, think of what it takes to have a well-ordered project





Buy them at any online book retailer!

Thursday, October 1, 2020

All is not a Bell Curve



It's a bell, unless it's not
For nearly all of us when approaching something statistical, we imagine the bell-shape distribution right away. And, we know the average outcome is the value at the peak of the curve.

Why is it so useful that it's the default go-to?  Because many, if not most, natural phenomenon with a bit of randomness tend to have a "central tendency" or preferred state of value. In the absence of influence, there is a tendency for random outcomes to cluster around the center, giving rise to the symmetry about the central value and the idea of "central tendency". To default to the bell-shape really isn't lazy thinking; in fact, it's a useful default when there is a paucity of data. 

Some caution required: Some useful stuff in projects is not bell shaped.  Yes, the bell shape does serve as a most useful surrogate for the probable patterns of complex systems, but no: the bell-shape distribution is not the end-all and be-all.

But if no central tendency?
Lots of important stuff that projects use every day have no central tendency and no bell curve distribution. Perhaps the most common and useful is the Pareto distribution. Point of fact: the Pareto concept is just too important to be ignored, even by the "bell-thinkers".

The Pareto distribution, which gives rise to the 80/20 rule, and its close cousin, the Exponential distribution, is the mathematical underpinning for understanding many project events for which there's no average with symmetrical boundaries--in other words, no central tendency.

Jurgen Appelo, an agile business consultant, cites as example of the "not-a-bell-phenomenon" the nature of a customer requirement. His assertion: 
The assumption people make is that, when considering change requests or feature requests from customers, they can identify the “average” size of such requests, and calculate “standard” deviations to either side. It is an assumption (and mistake)...  Customer demand is, by nature, an non-linear thing. If you assume that customer demand has an average, based on a limited sample of earlier events, you will inevitably be surprised that some future requests are outside of your expected range.

Average is often not really an average
In an earlier posting, I went at this a different way, linking to a paper on the seven dangers in averages. Perhaps that's worth a re-read.

So far, so good.  BUT.....

What's next to happen?
A lot of stuff that is important to the project manager are not repetitive events that cluster around an average. The question becomes: what's the most likely "next event"? Three distributions that address the "what's next" question are these:

  • The Pareto histogram [commonly used for evaluating low frequency-high impact events in the context of many other small impact events], 
  • The Exponential Distribution [commonly used for evaluating system device failure probabilities], and 
  • The Poisson Distribution, commonly used for evaluating arrival rates, like arrival rate of new requirements


Even so, many "next events" do cluster
But project managers are concerned with the collective effects of dozens, or hundreds of dozens of work packages, and a longer time frame, even if practicing in an Agile environment.  Regardless of the single event distribution of the next thing down the road, the collective performance will tend towards a symmetrically distributed central value. 

For example, I've copied a picture from a statistics text I have to show how fast the central tendency begins.  Here is just the sum of two events with Exponential distributions [see bottom left above for the single event]:

Good enough
For project managers, central tendency is a 'good enough' working model  that simplifies a visualization of the project context.

The Normal curve is common surrogate for the collective performance.  Though a statistician will tell you it's rare that any practical project will have the conditions present for truly a Normal distribution, again: It's good enough to assume a bell shaped symmetric curve and press on.




Buy them at any online book retailer!

Monday, September 28, 2020

Strategic leadership


Are you willing to follow -- or be led by -- a  leader who can't do the job you're doing?

What I'm speaking of is the distinction between the strategic leader and the operational leader
  • The strategic leader is the visionary -- usually -- but most importantly is the leader that connects all the dots in the long game; allocates resources strategically; causes integration to occur for the benefit of the far future. 
  • The operational leader leads by example -- can step in and do your job if necessary; more tactical and willing to make course corrections in the short term. Definitely in touch with the details

A bit tricky, this leadership thing: if you don't think your leader can do your job, do you think they are an "empty suit"? Many pin that label on the strategic leader.

It's not always clear cut:

The strategic person often has to make the tactical call at the cross roads to go this way or that way; or relieve and replace subordinates that are not performing. And, the operational person is going to engage strategic planning and engage with their Board, regardless of their main focus and agenda.

Optimistic v pessimistic

 From the concepts embedded in the "cone of uncertainty", we generally think of strategic people as optimistic in their outlook for the simple reason that the long reach gives time to make things right.

The flip side: the press of immediate actions -- and problems -- makes the operational leader more pessimistic

Situational leadership style

From the concepts of "situational leadership", we generally think of the strategic leader as the delegation person: give the tacticians all the rope they need and stand back. If they fail, replace and repeat.

Planning as a methodology

And, the strategic leader is going to put more stock in long range planning. In fact, to the strategist, the planning itself is more important than the plan. As soon as you've got a plan, you're in tactical mode. Let others do the execution.




Buy them at any online book retailer!

Thursday, September 24, 2020

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!

Monday, September 21, 2020

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!

Friday, September 18, 2020

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!

Tuesday, September 15, 2020

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!

Saturday, September 12, 2020

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!

Wednesday, September 9, 2020

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!