Your technical reports stink. There’s little doubt about it.
Whenever I go into classroom training, it is universally felt by contracting officers and contracting specialists that technical reports are poorly done and add nothing to proposal analysis. After all, saying you accept everything the contractor proposes doesn’t give me insight into the technical knowledge you have.
I suspect this has to do with a few things.
A) There is little or no formal training on writing technical reports.
B) Contracting officers saying “It’s ok this one time”, except it turns into every time.
C) Contracting officers and specialists aren’t asking for the right things.
There is something brewing on this front to improve the situation. Stay classy and stay tuned.
Although you imply that some of the blame is with Contracting Officers, your answer is to train people… and make the technical people change. Personally, I think Contracting Officers need to change, and that could solve a number of problems.
Before taking on my current roles as Contract Specialist, COTR, and Tech Eval facilitator, I spent a decade in procurement in the private sector (Buyer, Contract Negotiator, Contract Manager, Strategic Category Leader). The biggest problem that I see in our agency is that the Office of Procurement Services does not involve themselves enough in the entire process. They don’t do ANYTHING with the pre-acquisition planning, they don’t do ANYTHING with the technical evaluation process, and they don’t do ANYTHING with the daily management and oversight of post-award contractor performance. Their argument is that they’re short staffed and don’t have the time to do anything other than the solicitation, award, and contract mods.
NEWS FLASH: Every procurement organization I know of in the private sector is short staffed and doesn’t have enough time. The best ones don’t FIND the time (when did you ever find some extra time just lying around?). The best procurement organizations MAKE the time to be involved throughout the procurement process… but especially in the beginning.
If Contracting Officers were more actively involved with the programs during the pre-acquisition planning process, they would be able to guide the technical folks towards creating better SOWs, pricing models, and evaluation criteria. All of the various elements would be properly connected, the solicitations would go smoother, and the outcomes would be better. But I can’t get our Contracting Officers to see that MAKING time early in the process can SAVE much more time later on. If nothing else, we would avoid having to make (sometimes significant) changes in the documents at the last minute because the CO would have had input up front, not AFTER we thought we were finished. Last minute changes are always disruptive, and they can cause unanticipated problems.
Frankly, when I was in private industry, I was involved in every technical evaluation for every solicitation that I was supporting as a buyer. The technical reports were always solid because I was part of the team that worked on them. Because of that, I knew what I was buying, the people involved learned what was important to document for each acquisition (and why), and strong working relationships were formed between procurement and the folks we supported.
I generally support the need for additional training, and I believe that proper training is important. But I don’t see this as a training issue. It’s an attitude issue. Contracting Officers don’t have time to get involved with the programs, and the programs see Contracting Officers as bureaucrats who are roadblocks to accomplishing the mission. Shove more training at them, and they’ll see it as one more roadblock — making someone else work more so that COs can work less… and they’ll just do the bare minimum needed to get by. Perhaps that’s an improvement over what you get today, but I think that’s a lot of effort for marginal returns. If you’re not going to change what the Contracting Officers are doing, then just give the programs a good template, a solid example to look at, and tell them “do this”. Don’t waste everyone’s time on more training.
I agree that “making” the time to complete and understand any job is really the corner stone to a job well done.
In the study of human reasoning, one of the perennial observations is that people whose strengths lie in verbal and social skills tend to lack in spatial/quantitative ones, and vice versa. This tends to show up in male/female differences quite often, but is certainly not confined to that. Within each sex we can all point to someone who is a “whiz” in the one area, and hopeless in the other.
Just why these two domains of human ability don’t wish to “play nice” with each other is open to endless speculation, some of it physiologically based, tied to evolution, tied to rates of physical maturation, sex chromosomes, social learning and socialization, culture, and a gamut of other factors.
I’ll set any notions or hypotheses of causation aside. What matters to us here is that it is a regularly-observed occurrence that when someone has substantial competence in something technical and quantitatively based, they can be more than clumsy when turning it into discourse and explanation…and written reports.
Yesterday, I attended a user group for a software package our division has long pursued purchase of, and the chief developer was in attendance. Bright kid, excellent product, but he could not explain his way out of a paper bag. The documentation is pathetic, and the tutorials an incoherent blur of mouse movements. So, strong on the technical, weak on the verbal/social – one of the many Sheldon Coopers of the world.
This is not to declare the situation itself as hopeless. Such individuals CAN be taught/trained how to write more effective technical reports. Just don’t expect it to come natural to them, in spite of all their technical expertise and insight. It is NOT their “cognitive reflex”.
And, it goes without saying that when such individuals become managers of junior staff like themselves, they’re not going to be the best judges of whether any technical reports coming from their corner of the organization are readable, coherent, and helpful in assisting decision-making.
I’ve said it here before, and will repeat as necessary: we don’t provide students with any training in how to explain, at nearly any level of education. We ought to rethink that situation, because, as Sterling’s comments indicate, it’s getting in the way.
If we lived in a perfect world the specialist would fully understand the contracting officer role/mission and the Contracting officer could identify smoke and mirrors and they could fully understand that they are on the same team. but alas we don’t live there so hopefully we ALL can strive for that perfect world
How about a meaningful conversation between the CO and the head of the technical team BEFORE a single proposal is evaluated on what the CO needs in terms of value. Then the tech team chair can train the evaluators on making valuable comments. A strength isn’t a strength if it just meets the requirement; it needs to go above and beyond and as an evaluator I need to be able to explain why it’s a good thing. Same goes for weaknesses and risks – tell the CO the impact of the weakness/risk and what it would take to improve it. You’re not only helping with the best value determination and trade-off analysis but also potentially giving the CO ammo for negotiations.
Love the comment by Mr. Jubar about attitude.
Here’s the real trick — attitude is a people issue, not a training issue. I once had a conversation with the Under Secretary for Memorial Affairs at VA, a great, knowledable, and humble gentlemen by the name of Steve Muro. His division of VA, known as NCA, has the highest customer satisfaction rating (95%) in all of govenrment, and one of the highest of any organization, including top-ranked private companies like Google. I asked him — your org is so successful, what is your secret? And you know what he said?
Attitude. You can’t train attitude, you have to hire it.
In other words, if your technical reports stink, or any product, stinks, it could be because your employee(s) sthink. If they’ve been around a while, there’s a chance that it’s not because they haven’t been properly trained (although it certainly happens, don’t get me wrong), but because, instead, they really just don’t care. And if they don’t care, your new, fancy approach just isn’t going to work.
Check out Chapter 2 of James Collins’s “Good to Great” — getting the right people on the bus.
Mark, love the way you write. Most of the “tekkies” can “do” tech, but cannot explain it or demo it to save their lives. Sheldon for all we know is HFA. Social/verbal skills are weak, that is just the way of the wiring and no amount of training is going to do that.
Thanks for the nod, Julie. Much appreciated.
I don’t know if its wiring, or if any putative wiring is enough of an obstacle to make it impossible.
About 14 years ago, I was teaching a community college class of computer science students, and the course lent itself to insertion of a module on technical writing. I let the kids know that at some point, even if it was to simply write a note explaining that the photocopier was not working presently, they were going to have to write documentation and explanations. I knew from looking into the text comprehension and reading literature, that one of the ways in which technical writing and documentation falls down is because the writer neglects to imagine the novice learner, or has a hard time drumming up the characteristics of the novice learner, hence fails to provide what they need. IN a sense, it’s not so much their skills as their goals: they think in terms of what they are reminded of or know at the moment, and not what the reader wants.
So, I wheeled in a cart with a laptop and video projector, and we collaboratively wrote “documentation” for something they knew far too well, Monopoly one year, and Scrabble the next. Their chief shortcoming, or trap, was identical to what the software developer I complained about was doing: they could not wait to get to the fancy stuff. Meanwhile the reader had absolutely no idea where all those details flying by them were supposed to fit. The phrase that kept coming up again and again was “Ask yourself, does the person want/need to know this NOW, or will it make more sense if we wait a bit?”. They would grudgingly admit that maybe, yeah it was a little premature, and we’d go back to something more comprehensible.
At the end of 90 minutes, they were in a lather, and tuckered out, because it was darn hard suppressing those tendencies. But we WERE able to write something coherent, with decent flow, and instructive…for that 0.02% among us who have never played those games. Like I say, it’s not their “cognitive reflex”, but it IS within their capabilities if we coach them.
I think another reason why technical reports can be an irritating read is because the writer themselves hasn’t really taken the time, or been allowed the time, to attain a higher-order conceptual view of the material. Simply having all the data doesn’t necessarily mean you know or see how it fits together, and of course if you have no overview to fit the details into, it’s a pretty safe bet you’re not going to provide it for the reader/end-user, even if you want to.
Ok Mark, I’m the novice learner, what in the world does “putative” mean? I loved the story, and yes, you are so right. As one of the technical illiterates, you have to take me by the hand and “explain” it clearly “in writing”. Down low on the jargon please, no $100 words….use the K.I.S.S. principle. Most Sheldon’s who are in the tech field (and yes most are HFA) in their writing of “how to’s”, the picture of the end user is not on their mind. It’s more like, “this is how you start, and this is how you end.” Got it. No, what is the stuff in the middle and how do I get from start to there? Bless you for having the patience to coach them. Teaching them sit inside someone else’s head for a bit is a brain drain for sure, because they have to bring some “emotion” into the picture. When I think of something “technical” or the word “technical” followed by “manual” or “instructions”, I’m lost. I need adjectives, adverbs……I’m right brained. When my son was in college one of his classes was called Technical Writing. I enjoyed picking up some of his books and randomly leafing through them. This book was a doozy. I gave me a headache. I’m still trying to get the hang of MicroSoft Office Access. I can write you a poem, draw you a picture, act out a skit, but please, please, don’t give me anything “technical” or “mathematical”. When I have to call tech support for my computer at work, I am glad they log in remotely to my computer so they can see what I see vs. me trying to explain it to them and they in turn speak to me in a language I don’t understand.
putative = presumed, presupposed, proposed.
Generally, people who understand math, stats, and computing best tend to be the least able to explain it. Math itself isn’t “hard”, it’s just taught by the very last people who ought to be teaching it. But we foolishly think…or are led to believe, that the flaw is ours, not the teacher’s.
Some years back I went to a talk by text comprehension guru Walter Kintsch ( http://psych.colorado.edu/~wkintsch/ ). Kintsch commented on the poor quality of technical documentation, but also said that he had recently had cause to dredge up some software manuals for a package he had been using for a while. He noted that, in retrospect, it actually wasn’t all that bad, and in fact was reasonably well-written…if you were already an expert in that software package. If you were a novice, though, you were screwed. And that’s the weak link, technical experts have a hard time imagining the novice.
I’ve had a grudge for years about all those books “for Dummies”. The first ones were for software. What I particularly disliked was not the content of the books, but the presumption in the title that the fault was in the learner, and not in the technical writer; that the “rest of us” need it explained in “simpler” fashion because, y’know, we don’t catch on very quick and all that. In fact, what those books were is the same content, only explained properly by someone who knows how to explain. There ARE people who can do it, just not enough of them, and usually not writing the technical reports you need to depend on.
As for tech support, you may be familiar with the character Jimmy Fallon used to do on SNL: “Nick Burns, your company’s computer guy”. He would roll his eyes at everything, explain the problem in a torrent of buzzwords and jargon, and end with a sarcastic “There, now was THAT so hard?”. I’m not sure the millions of Nick Burns in the world recognized how deadly accurate that was. 🙂
Brandon – Love your comment. Often it’s less about training and more about the right types of people and mindset.
I’m curious – as a private sector buyer, what types of things did you NOT do in order to make the time to be involved throughout the process?
Hi Sterling: You may find that prior to any technical evaluation commencing, it will be time well spent if the Contracting Officer has a meeting with the Evaluators and reviews the evaluation criteria in the RFX & the evaluation plan, provides samples of the kinds of evaluation responses that are acceptable and clearly lays out the expectations. If you don’t do this, you may end up with a real mess, especially if the evaluation “back-up” is released through the GAO bid protest or Court process. Absolutely, do not accept sub-par evaluator reviews. After all, you will be the one ultimately held accountable for any failure in the evaluation process.
@SteveRessler… in general, the two things we did NOT do in order to make time throughout the process were “re-hashing” and “re-working”. We found that when a Buyer worked on a procurement from cradle-to-grave, there was no need to do a knowledge transfer as we handed off the procurement from pre-award to solicitation to post-award (ie. re-hashing); and when the Buyer was involved at the early stages, procurement issues were identified and addressed immediately, which kept the team from heading down one path and then having to back-track because Procurement wouldn’t let them do it the way they had envisioned (ie. re-work).
As a Buyer/Contract Manager, I always had a “category” or “specialty”. Because of the expertise I developed and the relationships I built within my area, I required little time to get up-to-speed on a new requirement, I understood the best acquisition options for various types of procurements, and I was able to ensure that everything was done properly as we went along. Doing it right the first time is MUCH easier than reviewing someone else’s work and looking for possible gaps/holes.
On a slightly different note… as I think about it more, perhaps the biggest difference I see between my time in the private sector and the procurement group in my agency today is that, at my old job, we saw ourselves as critical team members who guided our teams through the procurement policy jungle. The Office of Procurement Services here at my agency see themselves as the Procurement Police. They don’t try to figure out how to best meet the needs of the programs, they just make sure the programs don’t break any rules.
Perhaps instead of assuming that the programs need more training, perhaps Contracting Officers should start by asking themselves this question: Am I a guide or just a rules enforcer?
There’s a HUGE difference between those two.