A contract amendment that adds scope at an inflated price, to compensate a contractor that seriously underbid some other portion of the Work, intentionally or otherwise.
Never issued to one’s own company (which naturally negotiates extra work only at entirely reasonable/justifiable prices): only issued to competitors that buy a contract.
“If you reward effort you get results.
If you reward results, you don’t get effort.”
– DeBono, 2005
We all celebrate the wins.
One company I worked for kept a big hand bell and someone walked (or ran) through the halls, ringing it, when we heard that we had won the contract. It was a great moment.
Then we all went back to the trudge-trudge of our work on the current proposal.
I’ve only ever seen one company that really got what DeBono was saying – not that they were perfect managers, but they understood this truth:
If you reward effort, you get results.
The time to express appreciation for the often extraordinary effort that proposal teams put in is at the time, or just after the proposal goes in – not when the contract is announced. After all, a 1 in 3 hit rate is excellent, so rewarding only the winners ignores the work that 2 out of 3 teams has done.
What the bidder thinks it will cost to deliver the Work if selected as the contractor.
To include something in the costs accumulated for the Work; as in “Is the overtime costed in?”
Many RFPs require narratives on the bidder’s understanding of risk and approach to risk management. Often, what bidders provide wouldn’t be out of place in a textbook: plain-vanilla risk management processes that lay out standard identification, assessment, and mitigation steps. Boring! Worse, they show no sign of being tailored for this scope of work: Indeed, they show no sign of ever having done this scope of work.
Now, granted, clients can do better than to ask about “approach.” But even if they do give you this fuzzy question, it’s not that hard to do a better response. Tips #1 to #4 are about thinking about risk from the client’s point of view. This tip is about being coherent in your risk response; that is, if you create a conceptual framework, using it in all questions that apply.
The RFP asked about risk management: two back-to-back questions in one section, and then again in another section.
Question #1 said, essentially, “How do you categorize risks?”
Question #2 said, essentially, “What risks do you see for this project?”
Question #3 said, essentially, “What risks do you see for this function?”
Using text copied/pasted from a corporate plan (because that glue tastes so good, I guess), Answer #1 was a textbook classification. Not wrong, you understand, but not super targeted.
Using text copied/pasted from another proposal for similar work, Answers #2 and #3 were much better targeted.
Hurray! Right? Well, maybe not.
Looked at together, the three answers had, essentially, no common ground. The classification framework introduced in Answer #1 was never used or even referred to again.
So. What does it mean to have a clever generic risk classification scheme that we don’t, you know, actually use in thinking about risks on actual projects or within specific functions?
Not much, I’d say.
Refers to (often hardware or software) components that are in such common and standardized usage that they can be bought and used without any customization, although they may require configuration to work properly together.
Acronymized as COTS, which is pronounced as the English word “cots.”