Since people are still throwing spears at it, I figured I should know more about it than I do. It turns out, the basic idea was to reduce the government's involvement and allow contractors to do things their own way, as efficiently as possible, without undue influence or involvement by the government.
Maj Henry Pandes wrote a pretty good article about it, if you want to read more. James Gill wrote a short response to Maj Pandes' article. Also a good read.
Unfortunately, many people today seem to have decided that the problem with TSPR was that it involved too much trust. Trust is bad, they conclude. We can't trust those slimy contractors. They're bad, they're bad!
Hold on. Let's not get the wrong conclusion here.
After a bit more investigation and reflection, it seems to me that the problem with TSPR wasn't trust, but rather ignorance. Instead of reasonable delegation, we turned it into abdication. The government wasn't merely hands-off, it was eyes-shut. Anyone surprised that didn't work out very well?
The truth is, I think the government should trust contractors more than we do (as I've written elsewhere). But that doesn't mean we should take the "wake me up when it's ready" approach. We can still be involved and informed, without turning it into excessive meddling.
More to the point, trust isn't weakness, naivete and stupidity. Trust requires strength, judgment and wisdom. A lack of trust indicates, among other things, a lack of trustworthiness and a significant degree of unreflective foolishness. Yeah, I said it - foolishness. Real rogues trust their partners, 'cause that's a smart and strong thing to do.
The TSPR approach may have been fatally flawed from the start, or it may have been a good idea badly executed. I still don't know. But what I do know is that if we think the lesson of TSPR's failure is to not trust people, we've learned a horribly wrong lesson.
2 comments:
Dan,
Don't know where you find all this stuff...awesome. I appreciate that your eloquence and viewpoints go back to your CGO days.
I survived the tail end of TQM/QAF and pretty much all of TSPR as an analyst, and neither was a good fit; QAF was an abuse of analysis to fit predetermined conclusions, and TSPR was used/abused to reduce oversight. Trust but verify was, in many cases, limited to the trust portion. As a junior analyst I refused to sign off on contract bonuses for non-functional software. I was fired, and another analyst signed. Later, an almost exaxt recurrence of this involved the F-22 Ops Testing. I can recall two specific cases of contractors providing contract oversight (but it's OK, they signed an agreement to work fairly).
Real rogues may trust, but I consider myself rogue-ish for my willingness to question the info I'm given. In one briefing the real data matched the simulation very (VERY!) well. I asked how they got such an impressive match. The answer? Change the constant of gravity. The engineer who answered my question was never heard from again on that program, and no, I will never trust that company again. Trust is a personal relationship, and I've only rarely been given the chance to develop that relationship before I, or the contract personnel, were reassigned.
Contracting can work great -- witness the lack of military at the gates of stateside bases -- but we need to keep oversight in the mix. We (Gov't) want to pay for a service and be done with it, and not pay ongoing benefits to the providers; and contractors want to provide those service for money. This is a good match. We should go in with reasonable expectations of trust, but not be afraid to throw up the BS flag if that trust is violated.
Kudos,
dave
Hey, thanks for the kind words, Dave, and the insight & personal experience.
You bring up a very good point, which I should have mentioned in my post. Sometimes, trust isn't possible. And in those cases, we need to figure out a way to either develop trust or find a different person / organization to work with. When trust is violated and can't be repaired, it's time to walk away.
The ability, courage and willingness to throw the BS flag, as you said, is an important part of the whole dynamic.
Thanks again!
Post a Comment