Tuesday, October 27, 2015

Adopting agile

To succeed with agile, management’s need for results must be greater than their need for control. —Israel Gat, formerly of BMC Software*

This statement is so profound, I should have used it to drive Chapter 12 in my forth-coming book "Project Management the Agile Way: Making it work in the enterprise" Second Edition.

*Source: Originally quoted by Dean Leffingwell in "Agile Software Requirements", Chapter 22.

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

Saturday, October 24, 2015

Measurement principles -- at least one version

There are, of course, a myriad of measurement principles. But here are a dozen from noop.nl you might find instructive.

1. Measure for a Purpose
2. Shrink the Unknown
3. Seek to Improve
4. Delight all Stakeholders
5. Distrust all Numbers
6. Set Imprecise Targets
7. Own Your Metrics
8. Don’t Connect Metrics to Rewards
9. Promote Values and Transparency
10. Visualize and Humanize
11. Measure Early and Often
12. Try Something Else

There are a three that deserve special comment:
5. Distrust all numbers: I take this to mean: be a skeptic. Just because it's quantitative doesn't mean it's not just a guess and not backed up by reason and experience

6. Set imprecise targets: In other words, have some slack in your estimates. Nothing in the future can be precise

8. Don't connect metrics to rewards: this is Edwards Demming from the 1950's. In part, it means no special rewards for doing your job. But in reality, stretch goals are usually rewarded if achieved. In other words, the innovation economy is driven by incentives. An absence of incentive robs the drive to innovate and improve.

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

Thursday, October 22, 2015

The voice of the customer and system engineering

General James F Amos, in a 2011 interview says that he had appointed himself player-coach (his phrase) on a number of troubled projects. That caught my eye: I had to read further.

 Math decisions are easier than thoughtful decisions based on strategy and what's best for [the mission]

[To his professional acquisition team]: You're telling me it will take 14 years to get the requirements right, develop this thing [a new amphibious vehicle], source select, test, and then field initial capability? You're crazy!
And of course he's right: if the Marines had waited 14 years for major solutions, like the mine resistant reconnaissance vehicle developed for Iraq, it would have never arrived in time.

Perhaps General Amos should take a page from USAF General Bernard Schriever, the father of modern program management and system engineering.  In the post war 1950s, Schrieve's team pretty much invented how to do military weapons programs -- the exception being the WW II program for the 'bomb', a program that Schriever did not participate in.

In the book, "A Firey Peace in a Cold War: Bernard Schriever and the ultimate Weapon", by Neil Sheehan, General Schriever's acquisition methods are explained in a great tale of the Cold War.

His idea is to put system engineering on the front burner, work quickly with prototypes, develop high risk ideas with multiple concurrent solutions, drive hard for the initial operating capability, and don't let better defeat good. In other words, don't let strategy, or strategic purpose starve innovation. Be prepared to accept opportunity as perhaps a better way.

Perhaps, Schriever was the original agilist!

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

Monday, October 19, 2015

Integrating the risk register with the project

David Hulett has a presentation on his website, projectrisk.com, entitled "Schedule Risk Analysis using the Risk Driver Method and Monte Carlo Simulation".  In this presentation, he develops an interesting operating idea: first, shift the Monte Carlo method to the higher level of events on the risk register, and then use those results as drivers on the schedule.

His idea he explains this way:
"Applying first principles requires that the risk to the project schedule be clearly and directly driven by identified and quantified risks. In the Risk Driver Method the risks from the Risk Register drive the simulation.

The Risk Driver Method differs from older, more traditional approaches in which the activity durations and costs are given a 3-point estimate which results from the influence of, potentially, several risks which therefore cannot be individually distinguished and kept track of.

Also, since some risks will affect several activities, we cannot capture the entire influence of a risk using traditional 3-point estimates of impact on specific activities.

Here are the steps:
1. Assign risk distributions to the events on the risk register.  This is more than just a simple PxI calculation.  It means do a three point estimate on each risk event; the real world distribution, likely unknown, can be modeled as a Triangular distribution for simulation purposes.

2. Also evaluate whether or not the risk event, if it occurred, would actually effect every task on the schedule, or just some tasks, and--here's a twist--evaluate whether or not a true event would actually effect the schedule/cost plan. 

That is, if for example labor rate escalation is a risk event, and it actually occurs, does the escalation really get applied or not?  Perhaps there are reasons that the escalation, even though authorized, would not be applied in every case; only be applied in some cases.  Hulett recommends that the latter assessment be on a continuous scale of 0 to 1. 

With this evaluation, you now have two probabilities associated with a risk event: will it occur, and if it occurs, does it have an effect?

3. Now run a Monte Carlo on the schedule; then, run a Monte Carlo on the risk register; then create an intersection between them, in effect identifying correlations between schedule and risk drivers.

What do you get?  You get a simulation result that integrates the probabilistic characteristics of the risk events on the risk register with the probabilistic characteristics of the schedule/resource plan. 

Of course, this is method is all but impossible without a tool to model both the three point estimates and the correlations. That's more or less the secret sauce behind the curtain, but nonetheless the idea of the risk driver method is first rate.

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

Friday, October 16, 2015

Not-measurable predictions and forecasts

Not-measurable predictions and forecasts: ever made one? Actually, who hasn't?

There's personal safety in not being measurable. Indeed, you can fill space and take up time with blather that is not accountable: if what you forecast and predict are not measurable, but yet fill a space where a forecast is needed, what's the risk? Nobody can hold you accountable for it!

Actually, there is a risk, not usually found on the project risk register: Absence of accountability often begets exaggeration, if not also overconfidence and extremism, all of which may have measurable consequences.

And, so we read that others have gotten onto this idea also:
There is a familiar psychological mechanism at work here. [Studies] show that if people expect that others will evaluate the accuracy of their judgments — that is, if people feel they will be held accountable for their views — then they tend to avoid cognitive pitfalls such as overconfidence and the failure to update beliefs in response to new evidence.

[Researchers] have demonstrated that accountability has this effect because it encourages people to pre-emptively think of ways in which they might be wrong — before others do it for them.

But when people make non-falsifiable predictions, they feel less accountable. After all, if a prediction can never be disproved, then it poses no reputational risk. That lack of accountability, in turn, encourages overconfidence and even more extreme predictions.

And, so the antidote is?
  • You can measure anything? Perhaps in theory, not really in practice, but nonetheless the idea sells books and lectures. However, it's the place to start: How would I know I'm DONE in project parlance?
  • Don't accept blather as a substitute for critical thinking. Of course, this requires you have a "blather filter" you can engage, and then the personality to challenge the blatherer
  • Always ask: can I measure the outcome; recognize success? If not: back to the drawing board for a different formulation.

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

Tuesday, October 13, 2015

Bureaucracy is not a nice thing

As a former member in good standing of the Federal bureaucracy I've got some first hand experience to pass along, which I distill this way into two rules:
  1. Almost anyone can say "No" and at least slow, if not stop, initiative (See: ankle biters around decision makers)
  2. Almost no one can say "Yes" and make it stick (See: ankle biter effect from rule 1)
Ergo: the bureaucratic default position is a "NO", and only a determined effort can make it YES. (Observation: there are many more jobs for those that can say "no", holding the fort as it were, than there are for those who can say "yes", so the default position is naturally supported by self interest)

And so, as I was reading a biography of military intelligence chief Admiral Wilhelm Canaris, I came across a passage written by the biographer -- Richard Bassett -- which just jumped off the page:
"Only those who have worked in an established organization of any size can understand the myriad of bureaucratic techniques that can be deployed to delay the requests of hostile outsiders"
Offense or defense?
Well yes, Bassett has it nailed. But, is a hard shell bureaucracy offense or defense? Answer: Yes, and yes.

The case for defense:
  • Barbarians at the gate?
  • Need political leverage?
  • Don't trust people?
  • Want to slow down change?
  • Not sure of yourself?
  • Have faith in process and procedure?  Then, put in a bureaucracy.
The case for offense:
  • Need the leverage of scale?
  • A lot of remote workers not inculcated in your culture?
  • Compelled by regulatory compliance which can't be a game for cowboys?
  • Need plug-and-play personnel rotations in and out of many projects?
  • Want to take the emotion and bias out of decision making?
  • Need crises reaction capability in a split second?  Then, put in a bureaucracy
.But it's not nice, ever:
 ... Today, the term bureaucracy suggests a lack of initiative, excessive adherence to rules and routine, red tape, inefficiency, or, even more serious, an impersonal force ..... (The American Heritage® New Dictionary of Cultural Literacy, Third Edition)

.... any administration in which action is impeded by unnecessary official procedures and red tape (Collins English Dictionary - Complete & Unabridged 2012 Digital Edition)

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

Saturday, October 10, 2015

Left of boom -- aka, risk management

"Boom" is one of those risks that's on everybody's list to be avoided

Here's some jargon, given to us by John P. Watters, iSight’s chief executive, that probably belongs in the standard project risk management plan:

“left of boom,” ...  military jargon for the moment before an explosive device detonates.

Well, that makes sense to me: "left of boom", i.e. 'before the risk' is good; otherwise: not good. If we can manage to stay left of boom, then the ideal will be: 'there will be no boom!'
  • Assess the threat with the intent of staying one step ahead of the threat (in the old west, one always wanted to stay "one step ahead of the sheriff" )
  • Do the drill to fill out the threat intelligence assessment: who? when? how? why? enablers?
  • Gauge the threat vulnerabilities
  • Get inside the threat cycle: faster, quicker, more nimble decision making
  • Exploit vulnerabilities

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

Wednesday, October 7, 2015

More about boundary spanning

In my posting on General McChrystal's book "Team of Teams", I made the point that McChrystal advocates networks and teams rather than hierarchies as an means to organize at the operational mission level. Indeed, he -- the general -- sees networking of teams (aka, team of teams) as an antidote to silos and hierarchy boundaries that are structure artifacts that do not add value to the mission. Unquestionably -- can we say -- such are manifestly too slow for much of the mission oriented work of projects.

Now, to add to that discussion I point you to an earlier work on the same theme: "Flat world, hard boundaries: how to lead across them" .

The authors are in close alignment with McChrystal's theme, saying about boundary spanning leadership that it's an ability to create these:

The authors, Christ Ernst and Donna Chrobat-Mason, posit five boundaries [or barriers] to business success--easily mapped to project success--and six practices, which they call the boundary spanning leadership model, to span those boundaries.

What I like is the matrix they have developed that summaries the whole paper into a five by six digest of the barriers and practices. [When you read the article, click on the panel titled "practices vs boundaries" to open a picture of the matix].

In a word, without rewriting the article for the authors, what you'll see is:
  • Boundaries: Vertical, horizontal, stakeholder, geographic, and demographic
  • Practices: Buffering, reflecting, connecting, mobilizing, weaving, and transforming
What's not too exciting is some of the recommendations at the cross points of the matrix. For example, this one at the intersection of Reflecting x Vertical Boundaries: 'call a meeting senior managers to facilitate upward movement of ideas generated by employees'

But, there are some good ideas, as given at Mobilizing vs Stakeholder Boundary: develop an appealing goal that will motivate competition with your market competitors

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

Sunday, October 4, 2015

Pushing squishy scope and risk around with contracts

Is your scope understanding squishy? How about your understanding of risk? Squishy also?

Here's the question of the day: Can you contract for 'squishy'?

Answer: yes, cost reimbursable contracts are for the squishy among us.

Default to CPFF
The usual answer, if no incentives are involved, is  CPFF (cost plus fixed fee). But, CPFF often gets confused with just paying all the costs and paying a fee on all the costs.

Noooo! paying all the costs and paying a fee on all the costs is CPPC (cost + percentage of costs). In federal contracting, which is my experience base, CPPC is a prohibited contracting procedure.
Obviously, there is no incentive for the contractor to control costs ... as the cost goes up, the contractor makes more, so the latent incentive is actually to drive (or allow) costs to go up.

It's shocking! to think a contractor would contrive to drive costs up to make money, but there you are ... no CPPC in federal contracting

CPFF is different: the fee is fixed at the time of award. (See excerpt below from the federal acquisition regulations [FAR])  If costs go up, the %-return goes down because the denominator, cost, is going up, but the numerator, fee, is not.
The CPFF contractor has some incentive, admittedly modest, to control costs so that a %-return business objective is achieved. 

Change management
The project office always anticipates change orders in CPFF because, if the scope and risk were not squishy, then FFP (firm fixed price) would have been the contracting vehicle. 
When there is new scope which requires a change order, then that scope change would carry its own CPFF estimate.

The issue always is: what is "new scope" which justifies a change order, and what is simply under-estimated on "old scope" which does not justify a change order?
CPFF is always in tension between project office and contractor about justifiable change orders that bring new fee to the contractor.

Cost control mitigation:

Now, as a practical matter, setting aside how change orders might be handled, CPPC and FPLOE (estimated level of effort [LOE] with estimated labor mix, supported by fixed price labor rates) are not materially different re cost-control incentives. As the cost goes up, the contractor makes more in either case.

As in all cost reimbursable contracts, sans specific cost-control incentives, there is no incentive in a FPLOE  to control costs (other than not to be so irritating to the project office that the contract is terminated for project office convenience).

  • Ceiling cost, with contractor assumption of cost-over-ceiling. Ok, but there's no free lunch. The contractor will build risk mitigation reserves into the FP labor rates. Only competition will hold down the rates, but all competitors will cover the risk somehow
  • Job orders. Actually, I like this one. It's zero-base in effect, and agile in its outlook on evolving scope and risk. You estimate the immediate future and put that estimate in a JO. Then, when the horizon arrives and the first JO completes, you zero-base the next JO. (Zero base does not ignore history, but it does re-baseline with every JO. Thus, variances are reset with every JO). If you don't like where things are going, you've got time to react.


FAR 16.306 Cost-plus-fixed-fee contracts.

"A cost-plus-fixed-fee contract is a cost-reimbursement contract that provides for payment to the contractor of a negotiated fee that is fixed at the inception of the contract. The fixed fee does not vary with actual cost, but may be adjusted as a result of changes in the work to be performed under the contract.
This contract type permits contracting for efforts that might otherwise present too great a risk to contractors, but it provides the contractor only a minimum incentive to control costs."

16.601 Time-and-materials contracts.

"A time-and-materials contract may be used only when it is not possible at the time of placing the contract to estimate accurately the extent or duration of the work or to anticipate costs with any reasonable degree of confidence.
A time-and-materials contract provides no positive profit incentive to the contractor for cost control or labor efficiency. Therefore, appropriate .... surveillance of contractor performance is required to give reasonable assurance that efficient methods and effective cost controls are being used."

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

Thursday, October 1, 2015

Innovation or efficiency

For F.W. Taylor, the scientific management guy, success was to be found in efficiency. He was the guy with the process stop watch and the job descriptions. But recently, efficiency has given way to innovation, even in PM. Traditional methods, honed and efficient, have been displaced by agile and empirical methods, not particularly efficient they are, but resilient with failure, to be sure.

WW II  and innovation
Now, it may seem that a war that ended some 60 years ago this summer is a bit distant to connect to contemporary dots. But no! WW II ushered profound changes into the culture and society of the United States that is fuel for the innovation fire.
  • WW II empowered 50% of our workforce for the first time. Women entered the workforce in large numbers doing jobs never open to them before. They have never looked back

    WW II beget the 'GI Bill' that sent millions to college and all but invented the modern middle class from which yet more innovation, inventiveness, and entrepreneurship has arisen.
The scope of WW II projects was unprecedented, leading to the military-industrial complex that defined and codified program management, system engineering, risk management, analog simulation, and a host of other project practices heretofore unknown or undefined.

  • WW II unleashed innovation as no other world event. The modern research university was empowered. During the war, the laboratories at MIT and CalTech and Stanford were at the forefront of new ideas, inventions, and applications. Since then, a multitude of research universities have been drivers of the innovation explosion in the United States.
  • Although the war drove atomic science, atomic science drove quantum mechanics, an understanding of the sub-atomic structure. From this we have all manner of semiconductors that have in turn been the underpinning of the information age.
Throughput won the war
The enormous industrialization of WW II all but put defined process control on the map. Repeatable process and process control gave us unprecedented throughput. Who knew you could build 55K ships and 600K aircraft in four years?

And now, we have "throughput accounting" which many say is the only way to value projects: the value is in the "add", ignoring the infrastructure and permanent staff sustaining cost that gets allocated into the project overhead.

The "good" war?
It sounds like "...there's nothing like a good war".  But that's not the case.  The emergency of warfare has always raised the bar.

Before the U.S. civil war in the mid 19th century, railroads as a means for tactical support for forces was unheard of; so also electronic messaging ... the telegraph in those days ... changed not only the timeliness of reporting, it changed forever the influence of "high command" on the tactics of the moment.

What we can say:
Innovation, as a consequence of great national emergency, is the sidebar that always gets a boost.

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