a thoughtful web.
Share good ideas and conversation.   Login or Take a Tour!
comment by goobster
goobster  ·  365 days ago  ·  link  ·    ·  parent  ·  post: Pubski: February 27, 2019

11 months of work: complete. 10 months of stupid and 4 days of panicked rushing around, should result in about $15m/year for my company for at least the next 5 years; possibly 10.

But ya know what? Government contracting is just the stupidest way to solve problems. If I cared at all, it would be rage-inducing that this is how our governmental institutions purchase technology products. As it is, I know I can put up with the bullshit easily, jump through all the moronic and meaningless hoops with ease and agility, let all the stupid roll off my teflon back, and I am safe in the knowledge that NOBODY wants my job. And I get paid WELL for it.





johnnyFive  ·  365 days ago  ·  link  ·  

As someone on the user end of government IT, it's no picnic over here, either.

goobster  ·  364 days ago  ·  link  ·  

Yeah, I was a SysAdmin for NASA at Ames Research Center in the 1990's. Fortunately I worked for a contractor (like 90% of NASA workers), so I wasn't in control of the RFP or acquisition process. I just told the NASA guy what we needed to buy, and it magically showed up 6-9 months later.

Now I'm on the other end, bidding on government RFPs... which are just the most stupidly written documents in the world. They define the features, buttons, and screens that they think their software should have ... but NEVER TELL ME WHY!!

Less than 10% of the RFPs I ever see (>100 in a year) actually state what problem they are trying to solve. "We need a better way to track X." or " We need to reduce the cost of Y." or "We are looking to improve the reporting in Z system, with data collected from P, Q, and R."

Instead the RFP says things like, "Must provide functional reporting" or "Battery life of 3 years on a single charge" or "One-click application of user hierarchy" or just a long list of report names with no description of what the contents of those reports should be, or even a glossary of what the terms mean.

If they just told me what problem they wanted to solve, rather than trying to be software and hardware designers, I could tell them how our software solves those problems. Instead I have to try to interpret a bunch of half-assed feature requests from people who have never designed a software application in their life, nor know what apps are available in the market to solve those problems today.

The stoopid. It hurts.

bfv  ·  364 days ago  ·  link  ·  

My favorites are the ones where they really want to go with a particular vendor, but they're required to shop around, so they write the RFP to describe exactly what the vendor they want does and you get requirements like having to store medical histories in an internet-accessible Access database running on Windows ME on a toaster.

johnnyFive  ·  364 days ago  ·  link  ·  

My assumption is that someone, somewhere said "this is what RFPs have to look like."

One of the things I've noticed is that large organizations, both private and public, are very bad at encouraging the right kind of risk-taking. If you're right, you may get some kind of reward out of it, but if you're wrong, you're pilloried. But no one ever gets canned for following accepted practice, and so many managers are content to coast their way up the seniority ladder while never rocking the boat or deviating from standard practice.