Hey, we can put it off until .....

---

Are you a procrastinator?
Do you procrastinate and still try to manage schedule?
Do you think of yourself as a procrastinator who can manage risk?
Do you understand that managing schedule risk is tantamount to managing the concept of schedule buffers and the critical chain methodology?

Then, you'll understand that handling your tendency to put things off, and thereby forcing upon you managing slack and schedule buffers are not that much different.

In fact, what I see most of the time is managers wasting slack by doing a "latest start".
At the other end, they've got no buffer or slack to work with.
That is all wrong.
In spite of the risk of incomplete information, getting over the inertia of getting started and getting going on addressing the issues that will inevitably arise is paramount.

So, if you need some help on this, this humorous video is for you!

---

Buy them at any online book retailer!

Job done?

---

Agile Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Trust them to get the job done. What job?

• Is it the job described in the business plan and in subsequent project plans, albeit lean plans consistent with the Agile Manifesto?
• Is it the job that has been estimated and scheduled?
• Is it the job as interpreted in near real time by the functional user?
• Is it the job that evolves over several iterations and is adapted to the emergent value proposition?

Trust them to get the job done. What’s the definition of “DONE”?

• Is it done when time/money runs out?
• Is it done when the backlog is fully exhausted?
• Or, is it done when the customer says it's done, or someone else says it is done?

If you can't give a 30 second elevator speech on each of these to the satisfaction of sponsor, product owner, and customer/user, you are not ready for prime time

---

Buy them at any online book retailer!

About 'positive'

---

Keep your thoughts positive
because your thoughts
become your words

Keep your words positive
because your words
become your behavior

Keep your behavior positive
because your behavior
becomes your habits

Keep your habits positive
because your habits
become your values

Keep your values positive
because your values
become your destiny

--Mahatma Gandhi

---

Buy them at any online book retailer!

The new "they"

---

Pronouns are problematic
I've said before pronouns should be banned in technical and official writing .... Why? because people screw up or unwittingly mess up the antecedents.

But, if pronouns are to be used, take note that the rules -- such as rules are want to be -- are changing as a matter of culture and usage, not because the rulebook has been rewritten.

About you
Dating from the 16th century, "you" was plural, with "thee" and "thou" as singular mates. But today "you" is singular most of the time .... but not so fast! "You" can refer to an audience of unknown size, as in the first sentence of my second paragraph. (I'm putting aside "y'all" as not distinguished enough for official correspondence, but hey! here in the South, y'all is just good talkin')

We, of course
And. of course, from about the same time (16th century), or even earlier, the so-called royal "we" has been a singular form of what is traditional thought to be a plural form.

He/she
For the past 30 years or so "his/her" or "he/she" form has replaced the dominant masculine "his or he".

Who is "they"?
The latest news is that "they" is now somewhat like "you". It can be understood to be singular, handily replacing "he/she". Thus, (royal) we might have written:

"When a project manager directs an action, he/she must be cognizant of the teamwork necessary for the task"

 But, now (royal) we can write less awkwardly:

  "When a project manager directs an action, they must be cognizant of the teamwork necessary for the task"

 ESL
 This stuff is hard enough for the native speaker; just think of the ESL's! (English as a second language)
 

---

Buy them at any online book retailer!

Statistics does not require randomness

---

Do you buy this?

"Statistics does not require randomness.

The three essential elements of statistics are measurement, comparison, and variation.


Randomness is one way to supply variation, and it’s one way to model variation, but it’s not necessary.

Nor is it necessary to have “true” randomness (of the dice-throwing or urn-sampling variety) in order to have a useful probability model."
Andrew Gelman 

How about this one?

" ... the #1 neglected topic in statistics is measurement "

All this, and the image, are what Andrew Gelman asserts in his posting here.

Statistics does not require randomness (just variation) --- an arresting statement to be sure. It's what caught my eye.

Gelman is on to a different agenda, however. His point is that in his experience -- which may be more academic than empirical -- measurement is given a back seat, almost neglected in some respects. (Measurement occurs here; lets press on)

But of course, if you are going to stand in front of your team or sponsor and spout statistics, it would be good if you had real observations to back you up. And, shocking as it may seem, you have to take measurements of real events and phenomenon in order to have back-up data

In turn, that leads toward accuracy and precision, cause and effect, and correlation. Perhaps all that is a bridge too far for one posting. I am leaving the building now...

---

Buy them at any online book retailer!

Confidence that feels like knowledge

---

Going back a bit to 1999, psychologist David Dunning, PhD, and his graduate student, Justin Kruger, published their research that in their own words revealed, "incompetent people ... cannot recognize just how incompetent they are."

Now, this isn't to suggest that most, or even a lot of us, are incompetent. That's not the point. The point is we all suffer from cognitive bias. We all believe we are smarter and more capable than we really are. (*)

Incompetence doesn't leave individuals with empty thoughts. They don't feel disillusioned or even cautious. [editorial: Yikes! incompetent and not cautious .... bad karma!]

Stephens goes on:

Inappropriate confidence
Dunning explained that instead, the incompetent are filled with inappropriate confidence that feels to them like knowledge.

The result is people tend to overestimate their skill. They fail to recognize their own mistakes or lack of skill.

They are also poor judges of genuine skill or the expertise of others

Sum it up
So, let's see. If your manager or leader is "full of knowledge", not cautious about risky adventure, and seems to pick poorly equipped or skilled people, then you conclude: Incompetent!


(*) Extracted from an article on "MedPage Today" by Phillip Stephens, DHSC, PA-C

---

Buy them at any online book retailer!

Micrometers, chalk, and axes

---

On a recent aircraft restoration project I learned this 3-step process of mechanics (who knew? You can't make this stuff up!), which in three short statements illustrates the axiom that a process, viewed end-to-end, is not better than it's worst component, and also ...

Precision and accuracy, no matter how diligent, are wasted on the poorest resolution of the process

1. Measure with a micrometer
2. Mark it with chalk (in our case, Sharpie marking pens), and
3. Cut it with an axe! (in our case, shears of one kind or another, or (gasp!) the band saw)

The high precision guess
Ooops! This very process shows up in project management. See: accuracy vs resolution and the spreadsheet -- estimates that are just a bit better than a guess (the axe) are entered into cells with zillions of digits of resolution (the micrometer). Nonsense.

Domain distortion
And, we see it as domain distortion when the defined process crowd with six sigma control limits wants to port their ideas into the domain of the one sigma program office. Again, nonsense (except for the problems defining process in six sigma that is quite portable and worthy)

Small stuff gets washed out in the big picture
It seems I'm constantly explaining why/how the precision of a estimate in a work package more or less washes out at the PMO level in a Monte Carlo simulation of all the work package effects.

Monte Carlo is the 3-step process micrometer-chalk-axe writ large:

1. Agonize over every work package estimate (micrometer, but the WP manager does this step)
2. Enter all the WP data into a simulation package using 3-point estimates and benchmarks (chalk, likely applied by the project analyst)
3. Run the simulation to get the "big picture" (axe)

What I find is those in the PMO wielding the axe seem to get inordinately excited about an outlier estimate here or there. If you're the axe-person, don't sweat the micrometers!

---

Buy them at any online book retailer!

Thoughts on "change"

---

I ran into a blog item on change the other day, at a blog site called Rule of Thumb.

The posting entitled "The Change Curve", depicts a project management adaption of the change model proposed by Elisabeth Kubler-Ross in her book "On Death and Dying" when she described the "Five Stages of Grief"

Rule of Thumb proposes this adaptation for project management of the Five Stages into these six ideas:

•Satisfaction: Example – “I'm happy as I am.”
•Denial: Example – “This isn’t relevant to my work.”
•Resistance: Example – “I’m not having this.”
•Exploration: Example – “Could this work for me?”
•Hope: Example – “I can see how I make this work for me.”
•Commitment: Example – “This works for me and my colleagues.”

Of course there are many other models of both change and change resistance. One useful model of change (not change resistance) is by Kurt Lewin; I like it because it's similar to Deming's PDCA (plan, do, check, act). Lewin's model is three steps:

1. Unfreeze previous ideas, attitudes, or legacy
2. Act to make the change
3. Freeze the new way in order to institutionalize the change.

And, A.J. Schuler, a psychologist, has his 10 reasons about why change is resisted in a paper entitled "Overcoming Resistance to Change: Top Ten Reasons for Change Resistance". His lead-off idea is "doing nothing" is often perceived as less risky than "do something"--in other words, Plan A (do nothing) trumps Plan B (do something). 

But the one I like is that people fear the hidden agenda behind the reformers ideas! Amen to that one.

---

Buy them at any online book retailer!

Backlog management

---

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 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 transferrence, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
• Tight coupling: there is almost complete transferrence of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost none 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.

The most common remedy is to buffer between effects. The effect has to carry across the buffer. See Goldratt's  Critical Chain method for more about decoupling with buffers

But buffers may not do the trick. We need to think of objects, temporary or permanent, that can loosen the coupling from 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; this is sort of a "us vs them" approach, some might say stovepiping.

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!

---

Buy them at any online book retailer!

Communication, communicating

---

"They" say that the three most important tasks of project management are:

1. Communicate
2. Communicate, and
3. Communicate

To that end, I recently had an opportunity to try out my skills. My neighbor, a very nice young woman, had to travel on business and asked me to keep watch on her cat.

After a few days she called from the road to check on the cat:
She asked: "How is Millie doing?"
I responded: "Millie is dead"

A pause

She scolded: "You could have let me down more easily; you could've said Millie is on the roof. 
Then later you could tell me she fell off the roof and died"
With contrition, I responded: "Yes, I was insensitive. A lesson learned, to be sure"

A pause

She asked: "And, how is my mother?"
Confidently, I responded: "She's on the roof!"

---

Buy them at any online book retailer!