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

Monday, September 28, 2015

The mind is an argument

The mind is not a single voice but an argument, a chamber of competing voices, and a [problem] occurs when we listen to the wrong side
Jonah Lehrer

If you don't believe this, read one of these books:  "Against the Gods, the remarkable story of risk", "How we decide", or "The irrational economist, making decisions in a dangerous world".

Or, you could take a hard look at the papers of Daniel Kahneman and Amos Tversky. 

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, September 25, 2015

It's agile! Why plan? Why schedule? Why estimate?

Remember the Trinity of Estimation? Why plan, why schedule? Indeed, the question might even be: Why estimate? It’s all going to change anyway.

The answer -- as we discussed a couple of weeks ago -- is quite clear:
If there are no plans, any outcome is acceptable; if there are no plans, there is nothing to estimate; without estimates, there is no reason to measure. Without  measurements,  there  will  be  no  benchmarks,  no improvement, and no answer to the questions of where are we? And, oh by the way, what are we doing?

The Estimation Trinity feeds forward into 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. I say, what job is that?
  • It is the job described in the business plan, if you have one, but what if you don't?
  • It is the job estimated and scheduled? Ooops, no estimates?
  • It is the job as interpreted in near real-time by the functional user?
  • It is the job that evolves over several iterations and is adapted to the emergent value proposition? And, where is it we are going with that?
Trust them to get the job done. What is 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’s done?
If you are trying to do a project without management, good luck to you.

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, September 22, 2015

Quality drivers -- four big ideas

On slideshare, you can check out a paper I wrote on four big ideas that drive quality, particularly in agile methods.  Here are the points, summarized for the blog:

1. The Focus should be on Customers: Perhaps this is an obvious idea that is on everybody's list, but actually it is the Deming v Juran debate.
  • Deming was a product guy--make it right, and make it the right way.  
  • Juran was a customer guy--make it fit customer need.  
 Of course, there really shouldn't be a debate; Deming and Juran were both right, but in the end, customers, in the broad sense of the word, pay all the bills!  Customers can only be the ultimate focus because without customer buy-in to the quality of the outcomes, all is for naught.
2. Continuous improvement is a project imperative: There can be no substitute for a learning organization, and that includes project, even short ones.  Every team, group, and enterprise should be a unit in transformation, continually improving performance, capability, and capacity. Plan-do-check-act is nearly sixty years old, but actually it's still relevant, especially the check-act thing.  Take a moment to reflect on what you've done or are going--that's check; and then act to apply learning for improvement.

3. Total participation involves everyone: There is a place for the loner, the eccentric, and the individual contributor, but in general, the best outcomes involve the synergy of everyone contributing.  This may be a little harder with virtual settings, but it borrows a page from the wisdom of the crowds as well as recognizing that every individual can make a contribution, so every individual should make a contribution toward improvement.

4. Societal networking is flattening: Social networking may sound like a new idea, but it's been around since the onset of human groups; just the technology has changed.  What is new, or at least revisited, is the way social networking has flattened the hierarchy.  Now, there's no excuse for misunderstanding the spirit and the letter of the customer's needs: just ask!

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, September 19, 2015

Ah, those requirements!

We may not know much about the requirements; our backlog may be slight; but we do know this about that:
1st requirements paradox:
  • Requirements must be stable for reliable results
  • However, the requirements always change
2nd requirements paradox:
  • We don't want requirements to change
  • However,  because  requirements  change  ....  is  a known risk, we try to provoke requirements change as early as possible

So writes Niels Malotaux in an interesting 16 page paper describing his version of Agile, titled: "Evolutionary Project Management Methods: how to deliver quality on time in software development and system engineering projects".

Here's what Malotaux calls "Magic Words"

•   Focus
Developers tend to be easily distracted by many im-
portant or interesting things. Some things may even
really  be  important,  however,  not  at  this  moment.

•   Priority
Defining  priorities  and  only  working  on  the  highest
priorities guides us to doing the most important things

•   Synchronise [sic]
Every  project  interfaces  with  the  world  outside  the
project.  Active  synchronisation [sic]  is  needed  to  make
sure that planned dates can be kept.

•   Why
This  word  forces  us  to  define  the  reason  why  we
should do something, allowing us to check whether it
is the right thing to do.

•   Dates are sacred
In most projects, dates are fluid. Sacred dates means
that if you agree on a date, you stick to your word.

•   Done
To make estimation, planning and tracking possible,
we must finish tasks completely. Not 100% finished is
not done. This is to overcome the “If 90% is done we
continue with the other 90%” syndrome.\

•   Bug, debug 
A bug is a small creature, autonomously creeping into
your  product,  causing  trouble,  and  you  cannot  do
anything about it. Wrong. People make mistakes and
thus  cause  defects.  The  words  bug  and  debug  are
dirty words and should be erased from our dictionary.

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, September 16, 2015

The book of Teams for Portfolio and PEO

I'm willing to bet that every PEO (program executive officer) in the Pentagon has read General McChrystal's book*, titled "Team of Teams". This book is this year's book on teamwork for the big dogs: PEO's, portfolio managers, and large scale program managers.

Obviously, it's written in a pseudo-military context, covering mostly McChrystal's time in Iraq as the senior special forces commander, but the lessons are easily ported to the civilian domain of large scale projects and business or agency endeavors.

What's in it for program managers and portfolio leaders
The big takeaways are given by the title of the book:
  • The payoff and advantages of teams at small scale -- shared commitment, speed, and collaboration to achieve mission and goal -- are obtainable at large scale
  • By corollary, reduction-style organization (or "reductionism" in McChrystal's vernacular) -- by which is meant hierarchical work breakdown with parallel breakdown of management tasks -- is too slow and too myopic, and too prone to suboptimizing for tactical advantage
  • Networks replace hierarchies; senior management and middle management are all nodes on a common network.
  • As in all networks, multi-lateralism replaces stove-piped escalation.
  • There is network access to decision-making data
  • Complexity is a world onto itself; complexity is a lot more than complicated, because complex systems and situations defy exact forecasting and understanding
For McChrystal, and especially in a context of time-sensitive opportunities, the first point (dare I say 'first bullet'?) is the main point: it's really speed of decision-making and deployment, made possible by breadth of collaboration.

You can't get rid of some stovepipes
One thing he says that struck me is that no matter how extensive a network, at some point it comes up against the boundary of another network or a stovepipe which is not transparent. Then what?

His solution is to send someone into the other camp to be a emissary and collaborator. In the world of States, we call these people ambassadors. The concept is applicable to stovepipes and other management challenges.

ToT is not a new idea, but McChrystal's insights are worthy
In all the project management books I've written over the past 15 years, I've extolled the advantages of teams of teams, though my experiences are small set beside McChrystal's. So, in some ways, I'm a very sympathetic reader of what McC has to say:
  • ToT is not efficient and not inherently lean. Teams overlap; teams have redundant staff and materials; a lot of the network communication is not useful to many who hear it. Reduction style management is F.W. Taylor's management science: everything lean to the point of no excess cost anywhere. But Taylor was not a team guy! (Attention: agile planners. Agile is not particularly efficient either)
  • Reduction style plans are fragile: subject to breakdown in supply and timetables, and require expensive re-work when things go awry (who's not heard: plans are the first casualty of reality?). But.... such plans can be the best way to do something if only all the risk factors would go away.
  • Complexity is non-linear and may be all but unbounded: Nobody has ever calculated how many game of chess there are. "By the third move, the number of possibilities has risen to 121 million. Within 20 moves, it is more than likely you are playing a game that has never been played before"
  • Big data won't save us: Ooops! did McC not get the memo? Big D is the answer to everything. Well, except for the complexity thing. Just ask the climate people to predict the weather. But, the antidote, by McC's reckoning, is to time-box or pin things to a horizon.  Just handle the data and complexity " ... over a given time frame."
  • "Prediction is not the only way to confront threats; developing resilience, learning how to reconfigure to confront the unknown, is a much more effective way to respond to a complex environment."

* Written with Tantum Collins, David Silverman, and Chris Fussell,

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