Make it a 'turn-key'

---

You may say -- you may have heard -- "make a 'turn-key' project".

Fair enough.

What does that mean? 

Actually, there are a few things built into that expression:

• You're throwing off risk by pushing scope and cost to someone else, presumably with a proven track record of expertise and performance.
• You probably mean 'fixed price' for a 'fixed scope' of work. There's no 'bring me a rock' uncertainty; you know exactly what rock you want, and 'they' understand and commit to deliver it.
  
  
• "Call me when its done". You expect them to handle their work like a black box; the internal details are unknown to you, or even if not, you've given up all executive supervision.
• They carry the insurance. Liability, property damage, workman's compensation, OSHA penalties, and the like are all on them. Of course, there's no free lunch, so the cost of those insurance plans are built into the price you pay for the 'turn-key'.
  
  
• Cash flow is largely their problem, though you make be asked for a down payment, and you may be asked for progress (aka, earned value) payments. As cash flow is their problem, so is credit with lower tier suppliers, financiers, and the like.
• Capital investment for special tools and facilities, and expense for special training (and these day, recruitment and retention) are all on them. These financial details will come back to you, proportionately, as part of their overhead figured into their fixed price for the job.
  
  

That all sounds swell as a way to offload issues onto others. But, at the end of the day, you as PM for the overall project still are accountable to your project sponsors. No relief on that score!

Here are a few of the risks to you should be aware of:

• Contractors have biased interests also. The contractor may prioritize some part of the project to serve their interests more so than yours. So, don't be blind to that possibility
• Fixed price is not always a fixed price. Any small change in scope or schedule can be leveraged to the advantage of the contractor for them to 'get well' from a poorly estimated base contract.
  
  
• Scarcity provides leverage: If they've got it and you need it, and there is a scarcity of supply, your contractor is at an advantage. 
• Cash talks: Cost of capital is often no small matter to a contractor. The cash customer is always favored; the customer with a short invoice-to-payment cycle is favored. When you need a contractor for a turn-key, cash talks.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Counter-party risk

---

Define counter-party: 

In a transactional relationship, the other party to -- or participating in -- the transaction is your counter-party.

 

In project situations, there are usually many counter-party transactional arrangements, such as contractors and suppliers with transactional relationships. And within the business there may be transactional relationships among business units and the PMO. 

 

Oh! And don't forget the money: there may be financiers of the business or project which have a counter-party relationship to the project.

Fair enough. But now comes counter-party risk: the risk that the other party to the transaction, or perhaps you yourself, will not be able to hold up their side of the transaction.

 

About counter-party risk

So, you are about to enter into a transaction with another party. What might be the risks?

• Trust: you may not know the other party well enough to convey trust, a willingness to believe what they say without the protections of a written agreement.
• Ability to perform their side of the transaction may be in question. Do they have all the requisite tools, resources, and experience? Is something required of you in order for the other side of the transaction to be completed?
  
• Willingness to perform their side of the transaction when the whole deal comes under stress may require backup

What is your strategy; what are your tactics?

• Your strategy should be to keep the counter-party fully engaged with intent to fulfill their side of the bargain.
• Your tactics should be to put in place standard risk management tools: Written agreements with incentives and penalties; sober assessments of their track record on similar activities; and perhaps insurance for consequential damages if the counter-party fails.
  

---

Buy them at any online book retailer!

Fixed price contracting and Agile

---

In my book, Project Management the Agile Way, now in its 2nd Edition, I make this statement in the chapter on contracts:

Firm Fixed Price (FFP) completion contracts are inappropriate for contracting agile.

I got an email from a reader challenging that assertion, to which  responded:

I always start by asserting that agile is a "fixed price" methodology. But, there is a big difference between a contract for your best effort at a fixed price, and a fixed price contract for working product, to wit: completion (agile manifesto objective)

There's no problem whatsoever in conveying best effort at fixed price through a contract mechanism; it's quite another thing to convey fixed price for a working product.

Agile is a methodology that honors the  plan-driven case for strategic intent and business value; but agile is also a methodology that is tactically changeable -- thus emergent in character -- re interpretation of the plan.

Using the definition that strategic intent is the intended discriminating difference to be attained in the "far" future that has business value, a project can be chartered to develop the product drivers for that discriminating difference. Thus,  think of agile as iterative tactically, and plan-driven strategically. The sponsor has control of the strategy; the customer has control of many of tactics.

Re FFP specifically, I was aiming my arguments primarily at the public sector community, and particularly the US federal acquisition protocols. The public sector -- federal or otherwise -- usually goes to a great deal of trouble to carefully prescribe contract relationships, and the means to monitor and control scope, cost, and schedule.

In particular, in the federal sector, only the "contracting officer" -- who is a legal person usually -- has the authority to accept a change in the written description of scope, a change in the cost obligated, or a change in the delivery schedule and location. The CO ordinarily has one or more official "representatives" (CORs) or technical representatives (COTRS) that are empowered to "interpret" changes, etc,

In the commercial business domain, the concepts of contract protocols are usually much more relaxed, starting with the whole concept of a CO and COR -- many businesses simply don't have a CO at all... just an executive that is empowered to sign a PO or a contract. Thus, there are many flexibilities afforded in the private sector not available to public sector

When I say "fixed price", in effect I am saying "not cost reimbursable". Cost reimbursable is quite common in science and technology contracts in the public sector, but almost never in the "IT" sector, public or private. So, I find that many IT execs have little understanding why you might write a contract for a contractor to take your money and not pledge completion.

Working from the perspective of "not cost reimbursable",  I make the point about a FFP completion contract as distinct from other forms of fixed price arrangements, like best effort. In my opinion, agile is not an appropriate methodology for a completion contract in the way in which I use the term, to wit: Pass me the money and I will "complete the work" you describe in the contract when we sign the deal.

However,  there are FP alternatives for a traditional completion effort, the best of the lot in my opinion being a FP framework within which each iteration being a separate and negotiated fixed scope and fixed price job order wherein the job order backlog is planned case by case.

However, even in such a JO arrangement, the customer is "not allowed" to trade or manage the backlog in such a way that the business case for the strategic value is compromised. The project narrative must be "stationary" (invariant to time or location of observation); although the JO nuts and bolts can be emergent.

Typically if the agile principle of persistent team structure is being followed, where the team metrics for throughput (velocity x time) are benchmarked, then the cost of a JO is almost the same every time -- plus or minus a SME or special tool -- and thus the "price" of the contract is "fixed" simply by limiting the number of JOs what will fit within the cost ceiling.

There are other factors which are vexing in the public sector in a FP contract arrangement:
1. Agile promotes a shift in allegiance from the specification being dominant to the customer needs/wants/priorities being dominate. Try telling a CO you are not going to honor the spec as the first precedence!

2. Following on from a shift in allegiance, what then is the contractual definition of "done". Is the project done when the money runs out (best effort); when the backlog is exhausted (all requirements satisfied); or the customer simply says "I've got what I want"? This debate drives the COs nuts.

3. How does a COTR verify and validate (V and V)? In the federal sector, V and V is almost a religion. But, what's to be validated? Typically, verify means everything that is supposed to be delivered got delivered; validated means it meets the quality standard of fitness for use. If the scope is continuously variable, what's to be verified? What do you tell the CO?

4. Can the "grand bargain" be contracted? I suggest a "grand bargain" between sponsor and PM (with customer's needs in the frame) wherein for a fixed investment and usually a fixed time frame the PM is charged with delivering the best value possible.

Best value is defined as the maximum scope (feature/function/performance) possible that conforms to the customer's urgency/need/want as determined iteratively (somewhat on the fly). Thus requirements are allowed to be driven (dependent) by customer's direction of urgency/need/want and available cost and schedule (independent).

Where the customer doesn't usually get a vote is on the non-functional requirements, especially those required to maintain certifications (like SEI level or ISO), compliance to certain regulations (particularly in safety, or some finance (SOx)), or certain internal standards (engineering or architecture)

---

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

Design-build

---

If you're in the construction industry you probably know about and have experienced "design-build". Notice that there's a word missing after "design", to wit: competitive bidding.

Ooops, a typo? No, there is a body of knowledge around this that says that it's faster-cheaper for the same quality to go "design-build" than "design-competitve bid-build".

In effect, one team -- architect, general contractor, and owner rep -- carry the project all the way through.

Faster-cheaper
The "faster" thing is obvious: there's a missing step, so the cycle has an inherent time advantage. The "cheaper" thing is not so obvious. Why should it be cheaper? There's nothing built in to drive the cost.

Best Value
Maybe it's not cheaper (though the track record over years seems to say it's cheaper), but it should be a best value project. 

That's the segue to: How do you decide which team is the team you are going to go with?  Certainly not lowest-cost, because the cost is not known until the design is known. So you decide on the basis of "best value"

Ah yes! Recall what value is: the best combination of quality, feature, and function that fits a budget. (Did I mention I wrote the book? "Maximizing Project Value". See the cover below)

And so, best value must mean value optimized for one or more of the variables. Of course, your bias will be different from mine, so your optimization will be different from mine. Nonetheless, each opportunity does have a "best value"

And, best value could be "lowest cost, otherwise acceptable". But, often it's not. There are other considerations other than cost. (We'll leave corruption off the list)

Public sector
But, if you're in the public sector, where the public expects probity when expending funds, how do you explain "best value"? Can it even work in the public sector?

Answer: Yes, it works.  In the U.S., some 20 states have made it legal, even desired, to go design-build. So the arguments that convince are out there.

If you read through the Wikipedia article under the link above, you'll see a pretty good to-and-fro on the good, the bad, and the marginally acceptable about design-build. There's even a design-build handbook and of course a design-build society.

---

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

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).

Mitigations:

• 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."

---

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 White House and Agile Methods

---

I don't often look to the White House for guidance on project management, and less frequently (never?) for their view of agile methods. Nonetheless, the White House Office of Science and Technology Policy (OSTP) and the Office of Management and Budget (OMB) are on the case.

OMB in particular runs the gov's CIO Council which coordinates government IT throughout the executive departments by means of each department's CIO. OMB also runs the new (as of August, 2014) U.S. Digital Services.

In turn, the Digital Services has published two guidance documents that are targeted at deploying agile methods throughout the government.

The first is the "Digital Playbook" which describes a dozen or so "plays" (somewhat as a sports analogy of plays).  But the interesting one is the "TechFar Handbook" which you can read and download from this github location.

The TechFar Handbook subtitle is: "handbook for procuring digital services using agile methods". It is structured more or less in a Q&A format, divided among sections. It takes off from the authority in FAR 39.103 which is all about modular contracting authority and procedure. It then shows the compatibility between agile and the intent of modular contracting, and it gives hints on how to "stretch"-- within the law -- to be more modular.

Sounds like it is all going in the right direction. Let's all cheer the U.S. Digital Services

---

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

Fixed price contracts for agile

---

In my book, Project Management the Agile Way, I make this statement in the chapter on contracts:

Firm Fixed Price (FFP) completion contracts are inappropriate for contracting agile.

I got an email from a reader challenging that assertion, to which  responded:

I always start by asserting that agile is a "fixed price" methodology. But, there is a big difference between a contract for your best effort at a fixed price, and a fixed price contract for working product, to wit: completion (agile manifesto objective)

There's no problem whatsoever in conveying best effort at fixed price through a contract mechanism; it's quite another thing to convey fixed price for a working product.

Agile is a methodology that honors the  plan-driven case for strategic intent and business value; but agile is also a methodology that is tactically changeable -- thus emergent in character -- re interpretation of the plan.

Using the definition that strategic intent is the intended discriminating difference to be attained in the "far" future that has business value, a project can be chartered to develop the product drivers for that discriminating difference. Thus,  think of agile as iterative tactically, and plan-driven strategically. The sponsor has control of the strategy; the customer has control of many of tactics.

Re FFP specifically, I was aiming my arguments primarily at the public sector community, and particularly the US federal acquisition protocols. The public sector -- federal or otherwise -- usually goes to a great deal of trouble to carefully prescribe contract relationships, and the means to monitor and control scope, cost, and schedule.

In particular, in the federal sector, only the "contracting officer" -- who is a legal person usually -- has the authority to accept a change in the written description of scope, a change in the cost obligated, or a change in the delivery schedule and location. The CO ordinarily has one or more official "representatives" (CORs) or technical representatives (COTRS) that are empowered to "interpret" changes, etc,

In the commercial business domain, the concepts of contract protocols are usually much more relaxed, starting with the whole concept of a CO and COR -- many businesses simply don't have a CO at all... just an executive that is empowered to sign a PO or a contract. Thus, there are many flexibilities afforded in the private sector not available to public sector

When I say "fixed price", in effect I am saying "not cost reimbursable". Cost reimbursable is quite common in science and technology contracts in the public sector, but almost never in the "IT" sector, public or private. So, I find that many IT execs have little understanding why you might write a contract for a contractor to take your money and not pledge completion.

Working from the perspective of "not cost reimbursable",  I make the point about a FFP completion contract as distinct from other forms of fixed price arrangements, like best effort. In my opinion, agile is not an appropriate methodology for a completion contract in the way in which I use the term, to wit: Pass me the money and I will "complete the work" you describe in the contract when we sign the deal.

However,  there are FP alternatives for a traditional completion effort, the best of the lot in my opinion being a FP framework within which each iteration being a separate and negotiated fixed scope and fixed price job order wherein the job order backlog is planned case by case.

However, even in such a JO arrangement, the customer is "not allowed" to trade or manage the backlog in such a way that the business case for the strategic value is compromised. The project narrative must be "stationary" (invariant to time or location of observation); although the JO nuts and bolts can be emergent.

Typically if the agile principle of persistent team structure is being followed, where the team metrics for throughput (velocity x time) are benchmarked, then the cost of a JO is almost the same every time -- plus or minus a SME or special tool -- and thus the "price" of the contract is "fixed" simply by limiting the number of JOs what will fit within the cost ceiling.
 

There are other factors which are vexing in the public sector in a FP contract arrangement:
1. Agile promotes a shift in allegiance from the specification being dominant to the customer needs/wants/priorities being dominate. Try telling a CO you are not going to honor the spec as the first precedence!

2. Following on from a shift in allegiance, what then is the contractual definition of "done". Is the project done when the money runs out (best effort); when the backlog is exhausted (all requirements satisfied); or the customer simply says "I've got what I want"? This debate drives the COs nuts.

3. How does a COTR verify and validate (V and V)? In the federal sector, V and V is almost a religion. But, what's to be validated? Typically, verify means everything that is supposed to be delivered got delivered; validated means it meets the quality standard of fitness for use. If the scope is continuously variable, what's to be verified? What do you tell the CO?

4. Can the "grand bargain" be contracted? I suggest a "grand bargain" between sponsor and PM (with customer's needs in the frame) wherein for a fixed investment and usually a fixed time frame the PM is charged with delivering the best value possible.

Best value is defined as the maximum scope (feature/function/performance) possible that conforms to the customer's urgency/need/want as determined iteratively (somewhat on the fly). Thus requirements are allowed to be driven (dependent) by customer's direction of urgency/need/want and available cost and schedule (independent).

Where the customer doesn't usually get a vote is on the non-functional requirements, especially those required to maintain certifications (like SEI level or ISO), compliance to certain regulations (particularly in safety, or some finance (SOx)), or certain internal standards (engineering or architecture)

---

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

Hub and Spoke

---

On the HBR Blog Network, Andrew Shipilov has a eye-catching post on "hub and spoke" project networks, or alliances between project partners, as he describes them.

(Say "network" to me, and as an EE, I always jump first to a mind's-eye image of a "mesh", but actually that's one of several general ways to think of networks, and in most situations not a good general model for governance.)

Shipilov posits that simple hub-and-spoke arrangements in truly complex and challenging systems, with the prime contractor and an SI (system integrator) at the hub, inhibits critical interactions between the other partners, each of which is on a spoke. He attributes some project failures to this governance model.

What to replace it with? After all, hub-and-spoke is the essence of prime contractor command-and-control over the myriad partners, to say nothing of the legal details of who has privity of contract.

Shipilov recommends the "alliance network" wherein there are multi-lateral relationships for innovation, data exchange, and cooperation, not necessarily under the watchful eye of the SI (though, if the SI is on the ball, all the consequential stuff is known at the PMO)

About the alliance network, we are told there are these advantages:

"First, alliance partners are more likely to deliver on their promises.  If information flows freely among interconnected partners, how one firm treats a partner can be easily seen by other partners to whom both firms are connected. So if one firm bilks a partner, other partners will see that and will not collaborate with the bilking firm again.

Second, integrated networks facilitate fine-grained information exchanges because multiple partners have relationships where they share a common knowledge base. This shared expertise allows them to dive deep into solving complex problems related to executing or implementing a project."

Fair enough. But one caution: You can't be a control freak and sleep nights with an alliance network!

---

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

Firing your client

---

Are you an independent practitioner? In the US, 1/3rd of the workforce are independents. An amazing proportion to my way of thinking.

One of the advantages -- and at the same time, one of the hazards -- is that you get to fire your boss; and, you even get to select your boss.

A recent article gives a few pointers for the newbie independents -- know when to hold'em; know when to fold'em. You know you've got a bad client when:

• They try to set up the deal at 10pm at night or a weekend... unless you want to work 24x7
• They say it's an easy job they can do themselves.. unless you want to be micromanaged
• You don't really know them and they live in a different country/culture.. some learning required!
• They want to talk about themselves instead of the job task... unless you want to be their counselor
• They say they've tried to get the job done with many others, and they all failed.. so might you!
• Rude, insensitive behavior.. unless you like the bad-ass type
• Those that ask for a miracle, or an unlimited commitment.. unless you give up your independence

One suggestion is to beef up the contract; guard your intellectual property rights (something I really pay attention to) and get a non-refundable down-payment. That one has been a sorting parameter for me. Don't forget the non-poaching clause: your client shouldn't have the freedom to hire your staff.

What's the right wording: "We're not a good fit", or "This job is not a good fit for my skills" (I use that one a lot)

And, if they really insist you take the job, add on a premium for your anticipated trouble!

---

Bookmark this on Delicious

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

Conversation through contracts

---

In the agile business, we've pretty much done away with the 'shalls' and 'wills' of traditional structured requirements, replaced by the conversational story. Even the use case, certainly structured by the UML paradigm, is not so much a 'shall and will' device.

That said, how do you convey a conversation through the vehicle of a contract? Off hand, it sounds like an oxymoron to be sure. There's certainly no more structured device in the project business than a contract. Is it the right framework to converse with?

My recommendation over the past several years that I've been talking about this is that the right contract is a fixed price framework with either fixed or cost reimbursable work orders, each work order corresponding to a iteration. Obviously, to keep the overhead down, a really lean process for writing work orders is Job 1.

First conversation
The time to have the first conversation is before the framework is put in place. This is when you explain the vision and discuss the top level narrative and the overall value proposition. Subsequently, the framework captures the contractual elements of the overall project...if you're building a bridge, that's one thing; if you're building an ERP, that's another.

Retrospective conversation
Then, as part of the retrospective review of the backlog, iteration by iteration, there are more conversations, each one then put more or less into the job order. The JO should still have some flexibility to handle unforeseen backorder problems. However, the foresight of the JO need not be but a few weeks, so it's risk of the truly unknown is foreshortened.

For more, give this a read:

---

Bookmark this on Delicious

Modular contracting

---

From the White House in Washington we get this news:

There is to be "Greater Accountability and Faster Delivery Through Modular Contracting"

And good news that is, indeed. In a document helpfully titled: "Contracting Guidance to Support Modular Development" we learn that it is US policy to encourage:

agencies to shift away from the bloated, multi-year projects so common in the past to a more nimble approach. The guidance provides our IT, acquisition, finance, and program officials practices for how they can, working together as part of an integrated program management team, break investments into more manageable chunks; eliminate the costly lag between when the government defines its requirements and delivers solutions; and begin delivering workable solutions shortly after contract award. By requiring frequent deliverables, agencies will also be better able to hold contractors accountable for keeping projects on track and delivering solutions that truly meet agency needs. And by breaking investments into smaller chunks, agencies may be able to drive more competition – including small businesses that might not have been equipped to compete for the massive, multi-year projects of the past. And more competition means a better value for the American people

Agile government projects, anyone? :)

---

Bookmark this on Delicious

Best value: the concept

I recently had a short debate about "best value" versus "best effort. It's always important to be clear about terminology--words are important--but it's most important to get these ideas clear when it comes to Agile, because 'effort' and 'value' really aren't the same:

In Agile, the grand bargin with the project sponsor is to deliver "best value" at a fixed cost in trade for latitude to evolve the scope details. The concept is like pick of the litter: "the most valuable deliverables" from among all the possible deliverables.

Of course: who says it's "best"? Answer: the customer, or the one holding the customer's proxy.

At each iteration, the customer goes through the backlog and reprioritizes and may invent new things. New things are all put in a backlog stack. The totality of the stack is compared to remaining time and budget. (Mix in a little technical debt to add seasoning to the backlog) At some place in the backlog stack you draw the line--actually, the line gets redrawn at every iteration if anything changes, which it will. Above the line, things get delivered; below the line: there's always V2.0!

At the end of the project, the customer has picked the best value from the backlog. Anything not done is of lesser value than those that were picked.

So what's best effort? Best effort has been around a long time. All cost-plus-fixed-fee (CPFF) contracts are legally 'best effort'. The contractor's responsibility is to apply best effort to the defined scope (defined by the customer in the SOW and specifications); if it doesn't get done, then the sponsor has a decision: bring more money, or terminate the effort. The contractor has no obligation to finish on his own dime.

To the uninitiated, best effort sounds crazy, but actually it works quite well to get difficult jobs done; but it's not the same bargain as made in Agile. The best effort bargain is to bring the best and brightest to the problem and work as responsibly as possible, but at the end of the day, the sponsor is on the hook for the money to finish.

So, where's the rub? It's in the opportunity cost. For the contractor, the fee (profit) is fixed; the contractor can't get richer on a better job, nor poorer on a bad job. In other words, it's economically regulated from the contractor's point of view. Nobody can get "Facebook rich" on best effort like they could on best value.

Bookmark this on Delicious

What did you know and when did you know it?

In a recent report, suggested by Glen Alleman, I read this:

We probed into if and when companies utilize Schedule Risk
Assessment (SRA) within their projects. More than one third
of companies indicated they did use SRA when submitting
proposals. This is interesting because there seems to be
no benefit—in fact there could be a major liability—to
publishing schedule risk during the proposal phase. If a
firm were to analyze its own risk and make pricing or bid
decisions based on that analysis, it would be applicable to
the Truth In Negotiations Act (TINA) and could be required
to be submitted with the bid, damaging the firms chance of
winning. As a result, many firms simply forgo this step during
the proposal phase

The picture below illustrates the statistics:

As a former PMO director that had a portfolio of about 20 - 30 defense projects going at any one time, and writing a dozen proposals a year for replenishment, I can say that what you read and see above is more the case than not. For the last forty years, the mantra of "what did you know and when did you know it" informs much process and decision making.

I used to quip: "the test is whether it will look good on the front page of the Washington Post". If not, don't write it down.

Nevertheless, the need for a SRA, as well its cost counterpart, led me to develop my ideas [in the last century, to put a time frame on it] of the project balance sheet. The idea here is a simple one in concept: there is always a tension between the business side and the project side because they come at things differently. The business, being optimistic, under values risk; the project, being conservative, over estimates cost and schedule.

In the proposal stage, the business wants to win, and at the same time the project may wonder if the business can afford to win. More than once, I remarked: "OMG, we won. What do we do now?"

The Project Balance Sheet

View more presentations from John Goodpasture

 Bookmark this on Delicious  

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

Contracting for agile

Have I posed an oxymoron, to wit: contracting for Agile?

Perhaps. Consider these agile values:

• Tight coupling among, and high cohesion between team members
• Maximum decoupling between deliverables, and decoupling between the deliverables and a pre-planned outcome
• Trusting relationships--all for one; one for all.
• Personal commitment and accountability for team performance
• Subordination of cost and schedule to customer satisfaction

There are more, of course, (check out the agile manifesto) but these are enough to consider how these value collide with, or are consistent with a contract environment.

Contracting has many purposes.  Among the top ten: expand the resource base, gain access to skills and environment, and transfer risk. 

But, in a flip of Agile values, a contract environment loosens the team member coupling and tightens the coupling between a plan and a deliverable. 

What about the cost-schedule-scope relationship? It's a rare SOW that begins: "The contracting agency does not value cost and schedule as much as it values outcomes".  That's a tough one to explain to the public constituency, and their representatives, who have a fixed-price retail market orientation.

And, most troublesome, a contract presumes low trust.  Indeed, a contract's so-called high ceremony--all the terms and conditions of a contract--is the antidote to low trust.  A consequence, if not a purpose, of a vehicle like a contract to institutionalize "low trust high ceremony" is an adversarial relationship.

To be sure, an adversarial relationship need not be unfriendly or acrimonious.  Some of my best friends are contractors!  And, I've been one myself.  However, parties to a contract are not really friends; they are parties to a joint interest in an outcome.  (in diplomacy: countries do not have friends; they have interests).  When stresses set in, the adversarial juices amp up.

So what to do?

1. Set in place a contract framework for all the T's and C's
2. On the agency side, parse the requirements backlog into work orders of scope for which the confidence interval is relatively narrow.
3. Freeze the work order requirements for development (call this an 'ice cube')
4. Push the ice cube through the contract channel as a work order
5. Reflect on the initial results; adjust the backlog; parse a next ice cube
6. Repeat until the money runs out.

In effect, this is a strategy of rationing emergence and scope by a funding cap.  However, in terms of answering the mail from the public constituents, each 'ice cube' should be worth what's paid for it.  In aggregate, the public should be, or may be, satisfied with the aggregate bag of ice.

Do you think this will work?

 Bookmark this on Delicious  

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

Award Fee, Incentive Fee, Fixed Fee

If your project does any contracting, then you're no doubt aware that fee--aka "profit", aka "incentive"--is either a cost, part of an investment, or a project management tool that can help drive results...no surprise: the latter is my bent. 

But there's a new 'hat' to go with these 'old hats':  a relatively new project idea of incentive built around prizes [more about that later]

And, there's been no repeal of the law of unintended consequences: people [and organizations] will act to maximize their benefit, some times in contravention of established processess and protocols.  Although people have friends, they also have interests. More important: organizations only have  interests.  Incentives set in motion and influence behaviors--personal and organizational--and sometimes those behaviors are unintended and unacceptable.

My advice:

• Never put incentives in place without doing a behavior countermeasures analysis [what would you do to maximize your benefit?  What would others do?]. 
• And, as simple as it sounds, do not put incentives in place that conflict with each other [an example from my own contractor experience: cost incentive and best value incentive on the same contract]
• And, never put incentives in place where the situation is compromised with conflicts of interest.

Firm Fixed Price
Maybe you do all your contracting as 'firm fixed price'--FFP. In that case, you'll have no insight to the fee, but be assured, it's there.

Actually, in FFP you are paying two fees: one is the contractor's forecast profit on the forecast cost; the second is the contractor's charge for accepting the transfer of risk from the project to the contract. Think of this second fee as an insurance premium, except that you, as project manager, have no insight to the premium you're paying. Your recourse is to obtain competitive bids and let market dynamics set these fees for you

Other fee arrangements
On the other hand, if you are not contracting FFP, but using a more imaginative vehicle that gives you some insight and control over the incentives, then you have a decision to make: incentive fee, or award fee?

Incentive and Award Fee
Incentive fee arrangements have historically been used to reward behavior--or, at the very least, forestall bad behavior.  But most incentive fee arrangements are on cost or schedule, something entirely objective, and not on value per se.  In fact Federal contracting requires that incentive fee be applied first to cost before other considerations.

However, award fee arrangements--around for at least thirty years--are designed to place incentives on value to the contract beneficiary--value being a larger concept than just cost.  Value does not always have to be objective, and the value proposition can change over the course of the contract, providing the project manager with a much more nimble tool that the rather blunt instruments of fixed fee and cost-driven incentive fee. 

It's obvious that award fee is more difficult to administer.  First, for each award fee period during the contract [and periods do not have to be equal length], as project manager, you are obliged to furnish the criteria for earning fee to contractor.  And, at the end of the period, the contractor is obliged to furnish proof of performance that you then are obliged to evaluate fairly. 

The evaluation is almost always 'analog'--that is, fee is awarded on a sliding scale, rewarding just that part of performance that is meritorious.  This means that the award fee is always at risk, and some is likely to be 'lost' at each award period. Sometimes, 'lost' fee can be 'rolled over' to provide a end-of-contract incentive.

Prize Fee
And now comes a relatively new entrant: prize fees  [new, if you don't count what the British offered in the 18th century for a better way of measuring longitude].  Many have heard about the "XPrize" phenomenon that began with a $10M prize for a reusable space craft that could reach 100KM altitude, now extended to other endeavors. 

But now, some corporations looking for corporate solutions to everyday problems are going the prize route: witness 55,000 entrants for Netflix's search for a better algorithm to suggest movies to its subscribers.  A recent article has described an almost exponential increase in doing projects the prize way...to wit: the ultimate agile way.  State a vision, put up the investment, set a milestone, and get out of the way!

And, they're not all millions for billionaire financiers like Paul Allen.  Some serious results accrue with prizes as small as $10K.  And generally it's been observed that any prize activity brings a lot of activity--critical thinking and innovation--even from the losers.  In fact, the losers line up at the patent office.

Maybe there's something to this for the agile visionary.

 Bookmark this on Delicious

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

Contract concepts Part III

This is Part III of our series on contract concepts.

Today: "The Elements Of A Contract"

A contract is mutual agreement, either oral or written, that obligates two or more parties to perform to a specific scope for a specified consideration usually in a specified time frame. The operative idea here is mutual agreement.

A contract cannot be imposed unilaterally on an unwilling supplier. In effect, as project manager you cannot unilaterally declare the project to be in contract with a supplier, have an expectation of performance, and then return later and claim the supplier is in breach for not performing. At first blush this may sound absurd, but unacknowledged purchase orders and email directives are not contracts until they are accepted by the performing party.

Therefore, it is generally understood in the contracting community that the following five elements need to be in place before there is a legal and enforceable contract:

• There must be a true and valid offer to do business [with a supplier] by the project or contracting authority

• There must be a corresponding acceptance of the offer to do business by the supplier’s contracting authority

• There must be a specified 'consideration' [something of value to be exchanged] for the work to be performed. Consideration does not need to be in dollar terms. Typical contract language begins: “In consideration of _________, the parties agree…………”

• The supplier must have the legal capacity and ability to perform. That is the supplier may not materially misrepresent their ability to perform.

• The statement of work must be for a legal activity. It is not legal to contract for illegal activity.

 Bookmark this on Delicious

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

Contract concepts Part II

This is Part II of our series on contracts.

Today: The main ideas embedded in contracts, organized in three basic concepts:

1. Completion vs best effort:  It may seem strange to those outside the contracting community, but sometimes a contractor doesn't have to complete anything or everything--or at least there is no contractual obligation to complete anything or everything. Contracts for indefinite [to include agile or evolutionary] scope, uncertain requirements, basic research, exploratory risk reduction, and other such objectives only require a "best effort" from the contractor.  Obviously, the contractor is going to get a big "atta-boy" if they do complete something, but requiring a contractor to 'complete' the work requires a pretty good definition of the work in the first place.

On the other hand, if the scope is firm [or firm enough] then the contractor should be required to complete the work, and the contractor should have no reticence to accept the responsibility and obligation to complete the work.

2. Fixed price vs cost reimbursable: the contract price can be fixed [that is, made firm] if the contractor can be given a reasonable expectation of all that is required of performance and delivery; otherwise, it is unwise and impractical to 'fix' the price.  Contracts with elastic price are called 'cost reimbursable', although that is a simple label for a whole class of elastic contract vehicles. 

The chart below says the project can transfer 'all' the cost risk to the contractor in a fixed price contract.  That's not really the case since the project can't ever transfer all the risk--to wit: the contractor may still fail to perform.  So, if the project retains some of the performance risk, [and all of the performance responsibility] then the project retains some of the cost risk as well. 

Nevertheless, if the performance and delivery is fixed--in other words, the value proposition of the contract is known and fixed--then the cost [representing value] can be fixed for that contract instance.  [Next-Gen tanker aircraft, anyone?]

3. Time and materials: this is a pay-as-you go strategy; there's no commitment to completion, but a worthy contractor should commit to best effort.

Next: Contract concepts Part III
 
Click on the image for a more readable picture

 Bookmark this on Delicious

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

Contract concepts Part I

So, you think you need to do a contract to get the project done.  A lot of projects use contracts, no doubt of that.  But, sometimes the contract objective is not all it seems to be.  Sometimes, a contract is a policy choice rather than a technical choice. 

Be aware: Contracts between suppliers and the project team are commonly employed to accomplish three objectives:

• Change the risk profile of the project by transferring risk from the project team to the supplier. Presumably a due diligence examination of the supplier’s ability to perform confirms that the supplier has a higher probability of accomplishing the scope of work in acceptable time at reasonable cost than does the project team.
   
• Expand the capacity of the project and perhaps add to the capability of the project by hiring the help by means of a contract.
   
• Implement policy regarding sharing the project opportunity with participants in the supply chain. If the contract is related to a public-sector project, public policy regarding small business and minority business participation may be operative on the project team. In the private sector, there may be policy to involve selected suppliers and customers in projects, or there be policy to not involve selected participants in the project.

We would all hope that deciding whether or not to use a contract is itself a matter of following decision process and adhering to a decision policy.  For the most part, that would leave politics out of it.  Presumably, the policy says in one form or another: "decide in a manner that is most advantageous to the accomplishment of the project goals".  Who could object to that?

 Bookmark this on Delicious

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