Talk about the weather!

---

The weather in the US and Canada this winter has been a huge risk to projects... polar vortex and other phenomenon have made a mess of project plans, supply chains, outdoor painting, oil drilling, and all the rest. Talk about a chaotic stimulus to the system!

So, here in sunny Florida where we at "Musings" hang out, and where we do have hurricanes -- though not every year, and not for a few years -- this photo from my daughter in cold! Wisconsin seemed to sum it all up:

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Friction: social debt + technical debt

---

And, so now we've all come to the point the art and science of project management that we have various debts to go along with a myriad of biases. The new one (for me) that I've just come across is social debt, as described by Philippe Kruchten

He tells us:

Damian Tamburri, from VU in Amsterdam, has introduced the notion of social debt, as a counter part of technical debt [ICSE2013 workshop].

Social debt is .... the accumulation over time of decisions about the way the development team (or community) communicates, collaborates and coordinates; in other words, decisions about the organizational structure, the process, the governance, the social interactions, or some elements inherited through the people: their knowledge, personality, working style, etc

Now, put social debt together with technical debt -- all the myriad of little things left undone -- and you get the idea of the friction in the project.

So, what price -- actually, for the PM: cost -- is friction? First, friction spreads the tails of the Monte Carlo simulation of cost and schedule, and potentially shifts the mean cost and schedule to the right. Second, and certainly a root cause of the first point, friction holds back productivity and gives rise to lost energy (to overcome friction) and lower velocity (less throughput)

Fair enough. But, what do we do about it?

• New project? Take a look at the history of overcoming debt and make adjustments to the knobs and switches of your project model
• Got flexibility? Reorganize, retrain, change environment or tools, or add SMEs (or dismiss the high-friction nemesis)
• On-going project? Rebaseline. That may cancel a lot of the social debt built up in the existing project. In effect: reboot
• Risk management? Sure, think of both technical and social debt as a risk to be managed

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Asymmetrical understanding

---

A recent conversation, a contractor's lament:

[In the business of ] developing complex IT systems for [public sector agencies], there is an asymmetrical understanding of the risk involved, between the supplier and customer.

Our complex systems have many system interdependencies and potential failure points. There are many uncertain environmental variables, such as changing regulations.

All of this leads to large inherent risks. Yet the [agencies] have limited funding and a very low tolerance for risk.

"Asymmetrical understanding"! Is this a new meme-wanna-be in PMO? Could be; asymmetrical is certainly a meme in the warfighter's planning domain. In any event, I was struck by the phrase.

Here's my experience (after many years in the public/private relationship): the customer (public agency) wants to bottom line it; the project office wants them -- the customer -- to understand the details (insert here: frustration!) but the capacity and the interest to understand the details are just not there. Most particularly this is so when there's political pressure -- unwitting of the facts -- and unwilling to know the facts.

So, to the popular idea of "should've known, could've known, didn't know" you can add "unwilling to know", "incapable of knowing" and -- perhaps the worst of all -- deliberately ignoring "what I do know because it's inconvenient".  Thus: the classic "inconvenient truth".

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Thanks to viewers and downloaders!

---

It's always nice to get a bit of encouragement to keep on truckin' -- and so thanks to all the viewers and downloaders who made this possible -- a Top 2-percenter at Slideshare!

for all the good stuff!

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Product Owner -- the good and the bad

---

Mike Griffiths at "leadinganswers" had a recent posting on what he called the "agile horrors". Here's two lists he provided, one: the good news; and another one: the bad news re the behavior and competence of product owner in an project context.

Now, Mike would say this is all about agile, but hey!: good product owners are an asset to any methodology, and what they do is not that all different in one method over another. Let's not rebottle the wine when it's not necessary; a plain label will do nicely.

First the good news [would you want this any different if it weren't agile? No, of course not]:

C – Collaborative – willing to discuss and evaluate alternative solutions
O – Owners – owning the backlog of work, taking reasonability for its grooming
N – Nearby – available when required to ask questions and get clarifications
C – Committed – having the same person or people throughout the project
R – Representative – representing the group we are building for, not personal goals
E – Expert – knowledgeable about the domain at hand to answer team questions
T – Traceable – contactable when needed or with a proxy available if away
E – Experienced – experienced in the field to warn of outliers and exceptions

And, then there is the bad news about how some product owners don't walk the walk:

C - Contrary – decisions flip-flop with no clear explanation
A - Absent – you cannot find them or get their time when needed
S - Switching – the person changes, no dedicated product owner is assigned
P - Passive – without prompting we would not hear from them for long periods
E - Elusive – they will not provide clear feedback on the suitability of a prototype
R - Reclusive – they withdraw from priority discussions and decisions

Of course, years before this list, Dr Barry Boehm had his CRACK list:

•Collaborative: they will engage with their customer peers and with the development team
•Representative: they know the product or system requirements and can represent their constituents accurately
•Authorized: they can make the decisions needed to keep velocity up, and their decisions stick!
•Committed: they take their job seriously and make every effort to advance project success
•Knowledgeable: they can understand what the developers are telling them in the context of the business or market situation

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Matrix messaging

---

We've all heard of matrix management; many of us have gotten involved in projects with matrix organizations. But recently I was led to the idea of matrix messaging in the context of change management.

How does it work?

Actually, the same as matrix management: YOU are at the intersection of multiple messages: one from one manager, perhaps the project sponsor, and the other from the business. Hopefully, they are the same, but often not.

Messages	Project
Business	YOU

And, so what's a change manager to do? Obviously: take action to coordinate and make coherent the messages... so as to make "music" and not "noise" from all the input.

And, how to do this?

• Form relationships with all the messengers
• Coach them on the message
• Validate the message delivery
• Take corrective action if necessary

This is a form of Messaging 101:

• Tell them what you are going to tell them
• Tell them
• Tell them what you told them

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Do the math!

---

Heard about "merge bias"?

Actually, some of us have. And, probably to everyone's relief it's not one more in a long list of cognitive biases.

So, here's the problem: You have two or more predecessor activities (see also: gates, tasks, swim lanes, projects) joining independently to form a finish-to-start dependency on a successor activity. If the predecessors are both/all supposed to finish (or get DONE) at the set time to set off the successor activity, should you worry?

Yes, you should. Where the activities merge, like at a gate, there is a bias toward having to shift the schedule to the right (see: schedule slip) in order to maintain confidence in the schedule end date.

In other words, by example for two paths, if there is a 50-50 chance of both paths finishing independently together, then there is only 1 chance in 4 that the successor will start on time:

Activity	1.On time	1.Late
2.On time	On time	Late
2.Late	Late	Late

Saying it with confidence: The graphic gets your attention, but it's really limited for understanding what's going on. It's a matter of 'confidence'. In the case illustrated, the proper way to understand this is:

"Your confidence that the successor can start 'on time or earlier' is 25% or less. Your confidence that the successor task will start late is 75%, or more"

How much earlier? How much later? You don't know from what I've said so far, but you can get a handle on it with a Monte Carlo simulation.

Do the math: If I replace the labels "on time" and "late" with quantitative probabilities, you can see that the probability in each cell is the product of the row-column intersection. To wit: 0.5 * 0.5 = 0.25

So, your challenge as schedule architect is to increase the confidence of the successor F-S. How to do it? Here's an idea: re-architect the schedule from 2 paths to 3 simpler paths, each with  higher probabilities on account of their simplicity.

Now the graphics for three paths of different probabilities gets too awkward  because now you need a  figure of 8 (2^3) intersections rather than a figure of 4 (2^2) intersections. Best that you stick with the quantitative probabilities.

You might get something like this, as an example, of three independent activities (probability shown as on-time, so p[late] = 1 - p[on-time]):

• Activity 1: 70%
• Activity 2: 65%
• Activity 3: 75%

The joint probability of on-time is their product: 34%, slightly better than the 25% figure of the two lower probability higher complexity paths.

Now, of course, this re-architecture can go the wrong way: the improvement in probability has to be fairly large to overcome the three path merge bias. Nonetheless, this option is available for risk managers and schedule architects.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog