Technical writers and subject-matter experts often struggle to explain their plan for delivering the work in a way that non-techies and clients can understand (or be impressed by). Too often what comes from the writer and/or expert is generic descriptions of the function that would look good in a textbook. The answers aren’t “wrong” in the sense of being untrue, but they’re definitely “wrong” in the sense of getting low marks, and being boring besides. Insult added to injury.
Editors sometimes use high-falutin’ phrases like “concept of operations” but what we want is specific answers to three simple questions:
- What matters for this function?
- What’s different at this location or for this client?
- How are we going to deliver on both?
Let’s unpack it a bit.
1. What matters for this function? Or, what does it mean to do a good job in this function/activity?
- Quality? And if so, what does that mean? To meet some industry standard? To be accurate, standardized, or consistent? To have high customer satisfaction? To interface effectively with another function or organization?
- Speed? And if so, what does that mean? Fast turnaround time? Low response/wait time? Short service restoration time? Every deadline met? If so, who or what sets those deadlines?
- Cost? And if so, what drives it? Equipment? Other technology? Materials usage? Staffing levels? Approval cycles? Travel costs? Inefficient bundling of work?
- Safety? And if so . . .
- What threatens it? Working with high-voltage electricity? At heights? In confined spaces? With sharp objects? In vehicles? In mixed-mode traffic? Around hazardous materials or scary-big equipment? In bad weather?
- And who’s at risk? Your employees? Client staff? End users? Site visitors? The general public? All of the above?
- Environmental protection? And if so . . .
- What are the bad outcomes? Air, water, or ground contamination? Habitat damage? Species endangerment?
- What are the bad events that trigger the bad outcomes? GHG emissions? Sewage spills? Plant operation by-products? Hazardous materials used in operations? Waste management?
- And what might trigger the bad event? Failure of permitting processes? Of standard operating procedures? Of containment systems? Of response protocols?
- Reporting? And if so, on what schedule? Backed up by what data? Presented in what format?
- Client approval? And if so, when? At start-up (as for project plans)? At initiation (as for small-p project scopes and budgets)? Before work starts? At specified check points? At year end?
2. What’s different at this location or for this client? Or, what special/extra requirements or sensitivities are there in any of the above?
3. How are we going to deliver on both the general things that matter and the things that are different here?
- Our organization:
- In-house or subcontracted resources, and why?
- Number of staff, organized into what work groups and with what level/type of supervision, and why?
- And if they want to know the full detail, what positions will be responsible for each aspect of each task: directing, doing, supervising, checking, and reporting on the work?
- Our tools:
- Hardware, software and any special apps, communications systems
- Our processes:
- Standard operating procedures
- Communications, including reporting
- Hiring and training
- Quality control, inspections, audits
- Our schedule:
- For start-up/transition
- For every season or year
And why and why and why? To what purpose? Giving what benefit?
OK. As usual, simple isn’t the same as easy. This seems like a lot of work, yeah? Yeah. It does seem like a lot and it is a lot, although it can take longer to lay out all the questions than to answer the ones that apply. Technical folks and managers know these answers, they just don’t usually articulate them.
But here’s the thing. Get that first answer once – What matters for this function – and get it clearly, and you can build from there in every proposal from now on. It will inform your planning and simplify your writing. Without any “telling” at all, it will show the client you’ve been there, done that — usually phrased this way in evaluation criteria:
Demonstrate an understanding of the requirement.
And yeah, being able to “Think once, write many times” is good, good news in Proposal Land.