Trying to find out anything from public sources is pretty tiring, as they start out partisan and get worse. I rather liked this one from Reuters

I don't think there was a real System Integrator on the whole project. The guys at CMS were out of their depth. They had their doubts about the delivery date quite early. But as we all know, the customer manager and the salesmen have the last word on that! Responsibility without power leads to insanity.

The CGI contract was apparently based on the ongoing contract for IT services, based on an older RFP. (The same sort of thing goes on in NYC, for instance. You have to use on of the short list of pre-qualified contractors.) It appears that CGI were responsible for "the website", which to my mind is only part of the project. But integration with the middleware, back end, and inter-system communications is SOMEONE'S responsibility. That is why there is all this finger-pointing.

It appears also that CGI were more or less successful in the smaller implementations by the states that took responsibility. Possibly their management skills were spread too thin. Well, it all seems to be more or less working now, which is a great accomplishment. Thanks to all who participated over many sleepless nights!

Yes, I have been there, on both sides actually LOL. Sometimes the business actually REQUIRES some sort of bid document and generally it is safer to propose the preliminary design phase before committing to the rest of it, as one generally does not know what is involved before actually finding out what is needed. That is, asking over and over again, what do you need to know and when do you need to know it? Anything bigger than a breadbox requires a bit of planning.

The point is not that you have to produce a document. You really have to find out what the project is. One of my jobs back when I was a consultant was to help produce a Request for Proposal for the US Navy. Now that was a document! Even for that, I had to find out what we were trying to buy and what the reasonable shape of it would be.

But you are quite right about bloat, lard, narcissism, and petty bureaucracy. The worst thing is that at some level you run into management who have no idea of what they are going to need, because they don't use it anyway. But they feel threatened by the people who DO know what they need, so you don't get to interview them.

CMMI just the latest scam. I can't remember the names of all the attempts to "manage" software development that I experienced in about 30 years of it, but it was all a way to get expensive experts in expensive suits to annoy the crap out of the project and development groups. I don't know if it started in the days of Anderson Consulting (not to pick on them, but that was the period where I started to run into it). Six Sigma, anybody?

Not really having project management is what made Healthcare.gov such a fiasco. Probably CGI Federal had the wrong kind of managers to herd the cats that were the subcontractors. They may not have really understood testing, which was critical in this multiple-system case. Test planning is really boring but can't be skipped. Huffing over the documentation doesn't really help unless it is test planning documentation, but I bet it wasn't. Corporate-speak loses something in translation.

If buildings were built this way we would all be living in mud huts. Well, maybe not, but nobody would have built a cathedral or a skyscraper this way.http://news.slashdot.org/story/13/12/30/2219243/us-requirement-for-software-dev-certification-raises-questions#

This discussion doesn't really belong in /.,but Muslims have been slaughtering, maiming, and raping each other all over Asia and Africa with no encouragement from the US. The only reason there are so many Muslim countries is that there was an endless war of conquest starting in the 7th century. At this moment, Muslim countries and freelance gangsters are exporting terrorism all over the world. And they would be doing so if Israel did not exist.

The fact that some male told her to do it and then walked away. She probably had no idea what she was doing. While when I made nitrogen tri-iodide from ammonia and iodine, I definitely did know what I was doing. We did so many units on explosives in high school chemistry that we were heartily sick of them!

That is what I meant.

And that is why
"Between 60 and 80 per cent of all business transactions performed worldwide are processed—very effectively and efficiently—by COBOL programs running on mainframes. Within the financial industry (banks and insurance), COBOL is used extensively to process the vast majority of their transactions."
https://scs.senecac.on.ca/~timothy.mckenna/offline/COBOL_not_dead_yet.htm

I stopped writing COBOL in about 1985, but we were smart people, and our code was pretty good. It has lived all this time. Most of the new wave crap I have been involved in since has drifted off somewhere. It was relatively easy to create, but the technologies changed so fast that most of it was ephemeral. I bet some of my CICS is still running!

Right! Remember, dudes, we females are watching you...

Yes, users always lie. It's not their fault. I used to find little scraps of paper up on walls (if I was lucky), with some corner case that everybody knew about, or nobody knew about but the one user. Of course by now these users have long since departed the planet, so lots of luck... You captured it very well!

Every once in a while the head of Operations (most places) will look at the print queues and wonder if anyone would notice if a particular report were not produced. Possibly this report's number finally came up. If nobody complains, the report output is commented out of the JCL.

Odd that it didn't have a report divider cover sheet, though.

Yes, the hard part is finding out what the old system actually did, and how much of it was necessary and/or correct. Every miserable data transformation, data structure, business rule, magic number, compiler kludge, and dead end has to be discovered. It is not just a matter of translating the COBOL source either, supposing it is available. The job control and run books have to be examined, and every damn tape or tape emulation has to be dumped.

Nothing good happens without analysis and specifications up front.

Frequently the consulting company analysts are more interested in the user interface, where very little happens! But that is the sexy part, of course.

I was the only girl in my high school physics class. At some point we had to make 1-tube radios (6J5). This was a way long time ago! Anyway, I was very nervous about cutting my wires too short so I had quite a bit of wire on there. I had an extra "tickler" coil which was patched with nail polish where I had to splice two wires together. The tuning knob was stuck through a piece of a refrigerator dish.
The day of the trial came. The teacher came in with a big battery and a pair of earphones. First they tested all the techie boys. They had nicely arranged boards. Many of them had actually done some electronics work at home. Some of their kit worked; some didn't. There were only about 7 of them. They drifted out of the room.
The teacher hooked me up -- and mine actually worked! A surprise to all of us. I had never soldered anything before, and had biked around town assembling the collection of parts that I had looked up in a book somewhere.
The point of this is that those of us with no engineering background whatever can be relied on to do something weird when first confronted with it. Not that those young women were really qualified; that is another issue. But big loops of wire? I can relate to that!

I found one (or two) of these once as part of a study. The old M-- H-- bank was going to replace some important system, and I was on the illustrious crew of analysts documenting all its interfaces. One of them was a deck of cards that was output at the end of the run. So very early one morning I followed it from the output room to the mail room, and then the wagon to an office, where the cards were placed on the desk of the person who ran that machine. She and her young assistant ran them through the machine, which duplicated them and added some columns, probably totals of some kind. Then they took the new deck and loaded it into another of the same sort of machine, programmed differently. It read the cards and printed a report. Then she put a rubber band around the report and cards, and it went back on the mail cart. I followed it down the hall and to another floor, where it arrived on someone's desk.
And...
He picked it up and threw it into the trash.
When I wrote it up, nobody wanted to believe me.

Jah, SAP. World's slowest suicide method.

I never actually programmed one, but when I worked at Siemens in Iselin, NJ we had some of these. For physical inventory, we needed it to print the name of the spare part on the card my program punched out of the Spectra 70. So a bunch of old guys from all over the company found themselves poking around on the board. And they were successful too. The inventory cards were beautiful! To take inventory, the warehouse people wrote the count on the card, we had it punched at the end, and fed back into the Spectra. (We ran COBOL on that, 64 K of memory allowed even the SORT to run.) Good old days!