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

System Integrator

---

Here in the USA, we've heard a lot about the 'system integrator' of late, mostly having to do with large-scale government projects run awry.

The questions at hand: what is a system integrator and what do they do?

Point 1: the term is "SI"; and they are independent from the system engineer "SE" and the architect
Point 2: the SI works directly for the PMO, not the SE or the architect in most cases... thus, maintaining a degree of independence from the SE
Point 3: the SI comes on the job early, typically from day-1, working down the project definition side of the "V" chart
Point 4: the SI is first responsible for the coherence of the specifications and the test plan. Thus, the SI is an independent evaluator ("red team") of specifications, looking for inconsistencies, white space gaps, sequencing and dependency errors, and metric inconsistencies

Point 5: the SI is an independent technical reviewer for the PMO of the progress on technical and functional performance. They can be an independent trouble-shooter, but the SI is looking for inappropriate application of tools, evaluation of root cause, and effectiveness of testing.

Point 6: the SI may be an independent integrator of disparate parts that may require some custom connectivity. This is particularly the case when addressing a portfolio. The SI may be assigned the role of pulling disparate projects together with custom connectors.

Point 7: the SI is an independent integration tester and evaluator, typically moving up the "V" from verification to validation
Point 8: in a tough situation, the SI may be your new best friend!

What about agile?
'Agile-and-system-engineering' is always posed as a question. My answer is: "of course, every project is a system of some kind and needs a system engineering treatment". More on this here and here.

And, by extension, large scale agile projects can benefit from an SI, though the pre-planned specification review role may be less dominate, and other inspections, especially the red team role for releases, will be more dominate.

V-model
Need to review the "V-model"? Here's the image; check out the explanation here.

---

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

El-Erian speaks on project disasters

---

Mohamed El-Arian is the well known and respected CEO of the investment firm PIMCO who has a blog on linkedin.

In a recent posting, he uses the ongoing project mess of the US healthcare.gov website rollout for some sage advice for CEO's. In fact, this is good advice for senior project managers who are engaged in "bet the business" project initiatives.

Click here to have a read for yourself, although the highpoints are these five points of executive action. This is El-Erian's action plan when facing a project near-failure with far reaching business impacts:

First, ensure that the destination is unquestionably sound and visible – and do so by repeatedly reminding stakeholders (both internal and external) of the validity of the strategic initiative; and by making it crystal clear to opponents that key elements are non-negotiable.

Second, work backwards from the destination to specify and communicate the key steps in the journey of re-establishing comprehensively the credibility of the initiative.

Third, seek some quick wins in implementation to illustrate that the initial slippage, while meaningful, is indeed temporary and reversible.

Fourth, do not allow this whole issue to consume every other part of the business, activities, public interactions and internal discussions.

Fifth, be totally open with your constituents, including by recognizing that the initiative’s full recovery is probably months in the making. Properly managing what are now unanchored expectations becomes a key tenet of leadership and corporate strategy.

---

Scaling down... way down

---

Most of the posts I read are about scaling up to ever larger projects, but what about scaling down? What if you are doing bug fixes and small scale projects with just one or two people? Is a methodology of any help, and if you're working with software, can Agile be helpful scaled down?

To the first point, my answer is: Sure! A methodology -- which is just a repeated way of stringing practices together -- can help. Why invent the 'string' (methodology) each time you do something? Just follow the same practices in the same sequences each time. Thus, you can have a methodology for just driving your car... perhaps the ultimate team-of-one.

Re agile and small scale: Really, the agile manifesto does not inherently break down at small scale; nor do the agile principles. It's actually easier to go smaller than to go larger.

But, not so fast! What about:...

• Teams and all the stuff about team work if you are only one or two people?
• Pair programming?
• Redundancy and multifunctionalism?
• Collaboration and communication by osmosis with others?

Admittedly, you give up a few things in a team-of-one situation -- perhaps pair programming and redundancy -- but there's no reason to give up the other ideas of agile:

• close coordination and collaboration with the customer/user
• a focus on satisfying expectation over satisfying specification
• quick turn around of usable product
• personal commitment and accountability
• collaboration with peers and SMEs on a frequent and informal basis
• lean thinking
• Kanban progression and accountability

The hardest thing to deal with in a too-small team is lack of redundancy -- or not being anti-fragile -- and lack of enough skill and experience to work over a large domain. It's pretty obvious that one person team has a single point failure: when you're away, the team is down. Such a failure mode may not tolerable to others; such a failure mode is obviously fragile, unable to absorb large shock without failing.

And, one person's experience only extends so far... thus limiting the domain and extent of possible solutions (leading, sometimes, to: "if all you have is a hammer, then everything is a nail" misuses and abuses of whatever your skill set is. I once had a person who was a loner and also an expert with MSAccess... no matter the problem, he seemed to solve it with Access!)

As managers we are responsible for making it work. So in the situation of really small teams, there can still be, and we should insist upon:

• an opening narrative
• a conversation about requirements and approach (to include architecture)
• peer review by other experts
• code inspections and commitment to standards
• rotation of assignments among context to drive broadening
• reflection and retrospective analysis

---

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

Frameworks, frameworks... let me count them

---

And, here's your test for today: how many project frameworks can you count?
Mike Clayton has done us a bit of a favor by gathering up some links:

• PMI.org
• Mike Clayton's Eight Steps
• The Association for Project Management planning process
• Glen Alleman’s Five Immutable
• James Leal’s Seven Secrets
• Nick Jenkins’ Ten Axioms
• The Afterburner Combat Mission Plan

---

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

The 'estimate' thing -- again!

---

Likely you not looking forward to another posting on estimates, either here or elsewhere, since that topic seems to have burned up the PM space over the past few months. Nonetheless, Jurgen Appelo, never to lack for humor and pithy commentary, has weighed in with a few words that sum it all up.

He tells us:

When I made my breakfast this morning, I estimated (based on my experience) that two slices of bread and a glass of orange juice would be enough.

I’m glad that nobody asks me to do a #bigestimate and prepare my total food intake for the whole year of 2014. That would be silly.

But #noestimate, or walking back and forth to the kitchen or hotel buffet for each individual bite, doesn’t sound very practical to me. I prefer to estimate just enough to fill one plate, with a good chance of not having to walk back but also not leaving anything uneaten.

---

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

Agile and R&D

---

I was recently asked if Agile and 'R&D' go together. The issue at hand: how do you reconcile agile's call for product delivery to users every few weeks with the unknowns and false starts in a real R&D project?

Good question! I'm glad you asked.

Let's start with OPM ... Other people's money ... And the first question: What have you committed to do? There are two possible answers: (1) apply your best efforts; or (2) work to "completion".

Of course, (1) may be embodied in (2) -- why wouldn't you always apply your best efforts? -- but in the R&D domain (2) is often not a requirement and may be a bridge too far: -- got a completion cure for cancer? "Completion" means more than just effort; it has elements of accomplishment and obtained objectives.

"Completion" is problematic in the R&D domain: completion implies a reasonable knowledge of scope, and that may be impractical depending on the balance of the "R" with the "D". Heavy "R" implies very limited idea of the means to accomplish; "D" is the flip of that.

The best example of "best effort" is "Time and Materials" -- T&M. If you're working T&M your obligation -- legally at least -- is best effort, though you may feel some higher calling for completion.

The most constraining example of "completion" is Firm Fixed Price -- whether by contract or just project charter. FFP is almost never -- dare I say never? -- appropriate for R&D

And so now let's layer on Agile ... what's in and what's out vis a vis R&D:
Among the agile practices that are "IN" (in no particular order)

• Conversational requirements ("I want to cure cancer")
• Prototypes, models, and analysis (even, gasp! Statistics and calculus, though some would argue that no such ever occurs in an agile project)
• Periodic reflection and review of lessons learned
• Small teams working on partitioned scope
• Trust and collaboration within the team
• Skills redundancy
• Local autonomy
• Persistent teams, recruited to the cause
• PM leadership to knock down barriers (servant leadership model)
• Lean bureaucracy
• Emphasis on test and verification
• Constant refactoring
• Frequent CI (integration and regression verification with prior results)

And, among the agile practices that are "OUT"

• Definite narrative of what's to be accomplished (Nylon was an accident)
• Product architecture
• Commitment to useful product every period
• Intimate involvement of the user/customer (who even knows who they might be when it is all "DONE"?)

There may be a longer list of "OUT"s, but to my mind there's no real challenge to being agile and doing R&D.

---

Bookmark this on Delicious

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

Read my contribution to the Flashblog

IT and the PM...

---

How close to the truth is this?

A man flying in a hot air balloon suddenly realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts to get directions, “Excuse me, can you tell me where I am?”

The man below says: “Yes. You’re in a hot air balloon, hovering 30 feet above this field.”

“You must work in Information Technology,” says the balloonist.
“I do” replies the man. “How did you know?”
“Well,” says the balloonist, “everything you have told me is technically correct, but It’s of no use to anyone.”

The man below replies, “You must work in project management.”
“I do,” replies the balloonist, “But how’d you know?”

“Well”, says the man, “you do not know where you are, or where you are going, but you expect me to be able to help. You are in the same position you were before we met, but now it is my fault.”

---

Thanks to Alex Walton, 3pmLLC.com

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting