Thursday, September 30, 2010

Root Cause

It's "Military Officer" week here at "Musings.."

July, 2010, Page 62: a former lieutenant recalling his 'coaching' from a a more senior officer:
"Lieutenant....the most important thing you need to remember is to say BS ten times a day." It suddenly dawned on me: ...decisions are the difference between a mission's success or failure....In his artful way he was telling me not to accept things as they initially appeared but rather to look harder, ask questions, and get to the root cause of an issue before rendering a solution
Colonel Kenneth Lynn

This advice may be decades old, but it is timeless

Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Tuesday, September 28, 2010

Managing Millinneals

Did you catch the article on a new training doctrine in the July 2010 issue of "Military Officer"? If not, here's something that caught my eye that--if you are an 'old fart' PM [born before 1980]--you might find instructive:
Members of the millennial generation [born after 1980] "communicate--and recreate--differently, as a result of technology that is omnipresent in our society. .... They question orders like [they] have always done, but sociologists tell us they do that not because they are being confrontational, but because they are interested in improving outcome. They form teams to solve problems in different ways, probably due to the way they use technology to communciate"
LTGEN Mark Hertling

"Interested in improving outcome"? Sounds good to me!

In my last project, populated extensively by millennials, one of my comptemporary colleagues commented of our team: "I have shoes older than these people!"

Time passes!



Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Sunday, September 26, 2010

Risk v. Issue

I recently had a conversation in which I was asked if a budget "constraint" should be identified on a risk register. I answered this way:

"I make the distinction between an issue and a risk, because the methodology for each is different. Different methods are motivated by different time frames.

Issues: current time, present problem. Methods include problem investigation, problem solving, and conflict resolution, among others [These methods are not not normally in Risk Mgmt; see Six Sigma for excellent problem investigation protocols]

Risks: future time, probable problem, but not certain. Amenable to mitigation. Methods include response planning and mitigation actions to implement plan to mitigate occurrence of problem, not solve the problem itself.

So, depending on the timing of the budget constraint, it is either an issue or a risk. Ordinarily, PMs keep a register for issues separate from the register for risk because of different temporal attributes and different methods in the tool box.

And, the constraint may only be a surrogate for the real risk. The "real risk" may be a misalignment between sponsor and PM of--or about--deliverable value, or expected result. This is a point of the Project balance sheet, and Utility.

Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Friday, September 24, 2010

Why we need the explorers

Brian Cox is here. He is a scientist and public speaker in the Carl Sagan mold, and co-author of the new book "Why does E = mc2, (and why should we care)"

In this TED video, he gives examples of why we need the exploration of science. He remarks that studies have shown an ROI on Apollo of 14:1. He quotes--near the end of the presentation in a truly moving way--from Carl Sagan and Humphrey Davey on the need to keep pushing frontiers.

For PM's with projects on the cutting edge, this is a motivating and inspiring presentation by Dr. Cox.

Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Wednesday, September 22, 2010

System Engineering for PM's

If you are managing a technology project and need to understand a bit about what the system engineers will be doing on your project, a read of the eight pages of Chapter 1 of "Systems Engineering Fundamentals" from the Defense Acquistion University is a good place to start.  If you want to go further, dive into Chapter 3.

And, it's a free download for all of , military or not.

Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Monday, September 20, 2010

Freedom of expression

From Dr. Albert Einstein:
Laws alone can not secure freedom of expression; in order that every man present his views without penalty there must be spirit of tolerance in the entire population.

Think about this when you develop project governance or impose arbitrary limits on expression

Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Saturday, September 18, 2010

Future choice decisions

Robin M. Hogarth says this about future choice decisions:
"Future choice decisions are decisions that have three important sources of complexity:
  • First, actions taken today can have unknown consequences at future horizons that are difficult to specify.
  • Second, decisions imply complex inter-temporal tradeoffs.
  • And, third, it is problematic to specify relevant states of the world, let alone assess thier probabilities

As written in "Subways, coconuts, and foggy minefields; an approach to studying future-choice decisions", an essay in the "The Irrational Economist", Public Affairs, New York, 2010

Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Thursday, September 16, 2010

Abstract to concrete

More from the coffee shop:

Ever tried to explain what a 2% improvement in customer satisfaction means? If you're running a process improvement project with that objective: good luck!

And, I might add: So what? How does 2% change business results?

Beware abstraction
If your project needs a supportive stakeholder community--and every project does, so the question is self-answering--the business-results ambiguity of 2% might not get it.

But, as we coffee drinkers know, if 'dissatisfaction' means 2 customers out of 100 take $X revenue elsewhere, then everyone can understand X and, by extension, the impact of 2/100.

Cause and effect
So, can your project 'fix' revenue flight by dissatisfied customers?  Only if you are addressing root cause.  So it's not enough to put a concrete example around an abstraction like 2% improvement; you actually have to get to the real cause and effect.

It's been my experience that to build support for a somewhat intangible--some say: soft--metric, it's best to start bottom-up with a tangible that everyone can understand. Build the top level metric from the extrapolation of the most atomic and tangible metric you can find.

Claiming success
And, as you build up, keep track of additional cause-effects that will come in tangentially as the concept gets broader with abstraction.  The more abstract the metric, the more cause-effect challenges there will be.

Indefinite, or unresolved cause-effect challenges will do great harm to benefit capture at project transition to operations. The indefiniteness gives myriad excuses to not support full implementation and not give credit where credit is due.

Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Tuesday, September 14, 2010

Process breakdown structure

A coffee shop discussion on process redesign and process improvement led me to state the obvious to my caffeine-charged debaters:
Managers responsible for the business buy results [and outcomes], not process. Process, by itself, does not sell well; what sells is results.

Process per se is a tool.  For the most part, business people hire experts for their ability to deliver results; what tools they use are somewhat immaterial [to the business person]. The same for process redesign: the design per se is not the objective; the objective is better business results.

To help the discussion along, I postulated a "process breakdown structure", an obvious play on the WBS

Of nouns and verbs
Just like a WBS is an organization of 'nouns' [outcomes or deliverables] that beget 'verbs' to explain the how of it, so also in a PBS

The PBS is fundamentally 'nouns'....outcomes of the process....arranged  like a WBS.  The PBS has elements of hierarchy--parent/child--and relationship [example: we all have a temporary relationship to each other because we are all engaged in this blog...I wrote it and you're reading it]

The first process improvement is to do away with nouns that aren't valuable.  Lean out the clutter and reduce the complexity

And just like for a WBS, for every noun there is a verb: the activities of the process.

Sequencing the verbs
We all know there is no schedule or time dimension to a WBS.  It's as if the WBS is the 'present value' of the schedule results; all deliverables brought back to the present.  Thus, sequencing has to be done elsewhere, and that is usually in the schedule

So also in a PBS: for each noun there is a verb, but the repository for verbs is the process activity list.  Take the nouns from the PBS and verbs from the process list, and you can just about write the narrative of the process.

Just add to the nouns and verbs the sequencing, durations, and dependencies that are properties [adverbs and adjectives] of the activities in the list.  String them out in a network and you then have the process in the usual format.

Resource the verbs
Verbs require resources. Minimizing the resources; leaning out the non-value verbs and sequences that consume resources; and resolving dependencies that add more friction than value is the way to improve the process.

Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Sunday, September 12, 2010

Performance measurement

Quote:
Performance measurement is an essential part of management control in that it validates whether the results anticipated from planned action are realized.

Because what gets measured gets attention, the kind of performance an organization chooses to measure will motivate actions that improve the measures
Kiran Verma, "Total Factor Productivity Management" (1992)

Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Friday, September 10, 2010

Leadership and followership

I guess this is Michael Porter week here at "Musings". I was struck by Porter's description of leadership v followership in technology:


Leadership increases the size of the "pie", but followership only reslices the pie.  Followers accept "zero-sum"; leaders change the sum.

Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Wednesday, September 8, 2010

Competition primer

If you're in the new products projects business, here's a quick review of the competition basics taken from Michael Porter's classic "Competitive Advantage: Creating and Sustaining Superior Performance"

Porter writes: "...the rules of competition are embodied in five competitive forces: the entry of new competitors, the threat of substitutes, the bargaining power of buyers, the bargaining power of suppliers, and rivalry among the existing competitors".





For emphasis:
  • Entry of new competitors
    • Entry barriers
    • Expected retaliation
  • Threat of substitutes
    • Switching costs
    • Brand loyalty
  • Bargaining power of buyers
    • Bargaining leverage
    • Price Sensitivity and incentives
  • Bargaining power of suppliers, and
    • Switching costs
    • Forward integration risks 
  • Rivalry among the existing competitors
    • Over capacity
    • Exit barriers


 

 
Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Monday, September 6, 2010

So you wanna be a Program Executive

With apologies to my DoD friends who more or less own the term "program executive", I am using it in the context of a senior program manager with a "bet the business" kind of project, something really important and expensive.

If you are yearning for the opportunity, or shopping for a PE, here are five characteristics I look for:

1. Can [and does] speak truth to power. This means standing tall for the project and taking on powerful objections.

2. Recognizes anchoring bias when present, and can pick apart utility responses. In short has a good feel for qualitative and quantitative risk assessment.

3. Understands results have precedence over process, but nevertheless respects and honors process as the capture of past experience...things that work. However, in the end, the customer buys results, not process.

4. Applies political skills commensurate with the political sensitivities of the project. An important discriminator between a skillful PE and a competent PM is political skills.

5. Inspires by drawing from a firm conviction for the task at hand. Motivates by creating a personal value proposition for everyone involved.

Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Saturday, September 4, 2010

Standing waves

Is everyone familiar with the "standing wave ratio", SWR?

If you are a little vague on this, first think about the incident [or driving] energy that is directed toward an objective. If the objective absorbs all the effort directed toward it, there is no reflected or unused effort. But when there is unused effort then interference is felt between the effort directed toward the objective and effort reflected from it or not used.

Interference causes waves form; in the project context interference waves cause periodic delays alternating with progress. The degree, or amplitude of the interference is felt by the duration of the delays and progress.  These waves are called 'standing waves', and the SWR is simply the ratio of the energy directed to the objective to the energy unused and reflected back.

The traffic model
We've all experienced standing waves. Just drive in traffic. Inexplicably the traffic stops or slows, then speeds up, only to slow or stop again.  Why?!

These are standing waves of progress and delay. The objective [the road ahead] can't absorb all the incident effort [traffic], so some effort is reflected that interferes with oncoming traffic.

Typically, traffic waves occur--and flow is disturbed--when the road changes character, usually because of a discontinuity: a traffic accident, a slow driver, a change in the number of lanes, or a traffic light. Remove the discontinuity, and the standing waves decrease, flow improves, and effort is used more effectively. Friction [non value add effort, in this case standing in traffic burning fuel and consuming time without result] is reduced. Thus, during rush hour, you may notice the traffic lights tend to be retimed to reduce the SWR of the traffic and improve flow.

The project effects
Now, what about projects? Don't project discontinuities produce a project SWR? They do indeed. Project processes are like the highway, conveying effort to the objective. But processes are embedded in the project network schedule. If there are sequencing, resource, or task discontinuities then there will be waves of delay and progress.

So, what are we talking about when we say "discontinuities"?  Examples:
  • Successor tasks mismatched to predecessor tasks; the successor resources can't absorb all the predecessor results, thereby creating a constraint and changing flow
  • Incorrect sequencing that disturbs timing
  • Parallel paths joining; two or more teams now feed into one or more successor teams, disturbing flow
  • Work-flow decision loops that are out of sync or not paced to maintain flow in project processes
  • Batch schedules rather than real-time
  • Lead and lag effects in schedules that change the coupling between the project clock and the wall clock
  • Idle staff...marching army effects...who distract engaged staff
So, in one sense, the project SWR is the ratio of the applied effort to the effective effort. Or, in more familar words: the ratio of the total effort to the value add effort.


Think about this the next time you are in traffic.


Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.

Thursday, September 2, 2010

Book report

Agile Book
Many thanks to the readers of this blog that have made the first six months of sales of my third book on project management a success! Needless to say I am grateful for the support. Since the launch in January 2010, the book has done well.

Of course, if you are are an author-wanta-be, let me give you some advice: it's a lot of work, and keep your day job!

Amazing to me, truly amazing, is that my earlier books, the first now ten years old, is still selling, as well as the book on quantitative methods, published in 2003.

Thanks again!


Delicious
 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.