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 . . .
Poker Hands, Descending Order
. . . 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.
Maybe betting is analogous: something dangerous (competition) in a safe environment (insignificant amounts, unimportant outcomes).
How Does it Work?
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.
How to Execute?
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:
The number of questions that the RFP will provoke
The number of RFP amendments the client will issue
Whether there will be an extension and how long it will be
Anything that transforms the activity into a game is worth considering.
Still Skeptical?
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.
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?
General Rules of Teamwork
Most teams go through standard stages, neatly if somewhat cutely named as follows:
Forming – coming together
Storming – fighting for power and over differences of opinion, style, and values
Norming – agreeing, at least implicitly, on how the team will function
Performing – doing the work assigned
How It Works on Proposal Teams
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:
Interpersonal conflicts, as unacknowledged issues fuel snippiness
Professional conflicts, as undoubted experts dig in their heels on their approach/solution
How It Can Work Better
An external focus – trying to see our proposed solution through the client’s/user’s eyes – fosters proposal teamwork in two ways:
By fostering an overarching us/them mentality, increasing team cohesion and derailing the natural impulse to splinter into small, like-minded, and ultimately ineffective sub-groups
By establishing an objective and blessedly impersonal norm for resolving disagreements; to wit, “How would the client/user see this?”
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.