A specification of each data deliverable required under the contract. Useful for saving time in determining content and format for reports and forms. Now largely archaic in Canadian government contracting, worse luck, but still extant in American contracting.
Acronymized as DID; DIDs in the collective/plural.
Hire a bookie.
(Betting on shit seems to be galvanizing and brings a team together.)
Rhys Newman and Luke Johnson
As someone who used to play poker with a cheat sheet — you know, this one . . .
. . . I might be less than a credible source for this rule. But betting is akin, I think, to other silly games that proposal teams play, taking their fun where they can find it.
One form of humour is “something dangerous from a safe source” – just ask any 6-month old, giggling while being lofted into the air by a parent.
Maybe betting is analogous: something dangerous (competition) in a safe environment (insignificant amounts, unimportant outcomes).
By building trust? By fostering a sense of common purpose? Hey, what am I? A psychologist? Knowing why it works is less important than knowing that it does.
So what would proposal teams bet on, in this day of Google access? Pretty much anything, as long as it isn’t look-uppable and doesn’t really matter.
Future sporting events (their outcomes, interim scores, number of goals/points)? Of course. The total lunch bill for a group, or the last number in it? Why not?
But proposal teams also have some task-related things they can bet on:
Anything that transforms the activity into a game is worth considering.
Not buying it? Maybe you’d like to lay a small wager. What odds are you prepared to give me that this doesn’t work for your proposal team?
Proposals are schedule-driven projects that require a strict project management discipline. Right? Partly right. In proposal terminology, I’d call that answer incomplete. Proposals are projects, for sure, but they’re also the output of teamwork. I’ve recently been learning how much the design business has in common with proposals.
This post is one of a series on proposal teamwork, inspired by a fabulous article on Medium on design teams:
“No Dickheads! A Guide to Building Happy, Healthy, and Creative Teams.”
Leaving aside marine uses of this acronym (Sea Date Required to Load), a SDRL is a Data/Document Requirements List for a Supplier, Subcontract, or Subcontractor. Pretty much all the same thing: data deliverables under a contract.
See also Contract Data Requirements List.
Invert everything. (See the world through the client’s/user’s eyes.)
Rhys Newman and Luke Johnson
Seeing the world, or, at least, our service or product through the client’s/user’s eyes is obviously good for design, helping us give them what they want, not what we think they need. That applies to proposal teams, too, which are (whether they realize it or not) designing a solution for the client and the eventual users.
But why is it good for proposal teamwork?
Most teams go through standard stages, neatly if somewhat cutely named as follows:
Limited by the hard deadline, proposal teams must go straight from forming to performing – but conflict doesn’t disappear magically just because the team is on the clock. Instead, it emerges in other ways:
An external focus – trying to see our proposed solution through the client’s/user’s eyes – fosters proposal teamwork in two ways:
Proposals are schedule-driven projects that require a strict project management discipline. Right? Partly right. In proposal terminology, I’d call that answer incomplete. Proposals are projects, for sure, but they’re also the output of teamwork. I’ve recently been learning how much the design business has in common with proposals.
This post is one of a series on proposal teamwork, inspired by a fabulous article on Medium on design teams:
“No Dickheads! A Guide to Building Happy, Healthy, and Creative Teams.”
A Canadian and American federal government contracting tool (now not much used by the former) to capture all data deliverables (reports, plans, forms) for the contract in one place in the RFP (usually a SOW appendix). I’ve also seen this as “Contract Deliverables Requirements List”. Although not standard usage, this is, nonetheless, perfectly clear and pretty much means the same thing.
Acronymized as CDRL: pronounced “sea-drl” or “sid-rl.”
During the response period, the CDRL is extremely helpful for bidders trying to gauge and cost the level of effort required to meet reporting and similar deliverables after contract award.
During the contract period, the CDRL is extremely helpful for the contractor and the contracting officer in meeting and enforcing contract requirements, respectively.