Federal Gov employee here. Can't speak for a project with this scope, but the procurement middlemen get into everything, far for the worse.<p>Two years ago our team wanted to buy a small cluster (~300 cores, ~$50K). We talked directly to two good vendors (good recommendations from university partners) and came up with a fine machine and 2 bids for it. Sent recommendations to procurement.<p>Procurement put it out for bid, and a fly-by-night company undercut the bid by $10K... by noticing that procurement had not specified details of service level (that were in the bids we'd gotten and forwarded). Procurement, once it goes there, is a true black box. No communication, no understanding.<p>Five months later, we were basically delivered 2 pallets of unassembled parts and no instructions. Believe me, we spent 3-4x as much in labor as the $10K savings to get it working, and it's been plagued with issues that would have been under the onsite service warranties for the better companies.<p>The biggest irony is: I firmly believe that procurement acts this way not because the government is fundamentally incompetent, but because the Public, and thus Congress, BELIEVES we are incompetent, so puts so many levels of "check" bureaucracy in place that the people who know what they want can't participate directly in getting it.
That diagram for the "waterfall" approach that they yanked from Wikipedia is a complete straw-man representation. It's nonsense.<p>Here is the actual, original source for the Waterfall approach, first published in 1970:<p><a href="http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf" rel="nofollow">http://leadinganswers.typepad.com/leading_answers/files/orig...</a><p>If people would just bother to scroll past the first couple of pages, they will notice that the approach <i>already includes</i> some iteration cycles between steps.<p>In other words, this whole "agile vs. waterfall" debate which has wasted countless hours of human effort is based on a <i>complete misunderstanding</i> of what "waterfall" is in the first place. No one ever seriously proposed a model without iteration. It simply never existed in the first place!
For the MIT alums out there, I remember a 6.170 exam that had the question: "When is it appropriate to use the waterfall model of development?"<p>The answer was any time you are developing software for the government! The professor specifically mentioned it in lecture once, so that alone was enough for full credit on the question (other reasonable answers were fine too).<p>Later I TA'ed the class twice and made sure to eliminate these pure lecture-attendance-check questions.
This isn't going to change until there is a thought process shift for leaders on both the government and contractor side. I worked on a project that fought tooth and nail to create a project using an agile development process and it was one of the best projects I worked on for the government. It was killed due to politics, but the feedback, functionality, UX, and collaboration up to that point were great. Everything else I did was waterfall and we always has the same cycle.<p><pre><code> while (true) {
// Contractor working for a year
Government: This isn't what we wanted!
Contractor: We met all of the requirements... See all of the boxes are checked.
Government: Well we want to change 1,2...n things.
Contractor: Okay, Let's do a follow on contract.
Government: Okay, Here is the money; Go.
}</code></pre>
Has anyone noted that the government perhaps just shouldn't be in this kind of business to begin with?<p>Any market based solution website has to be very agile and responsive [edit: to succeed at it's goal] but the government can't be super responsive and in many ways <i>shouldn't</i> be super responsive. The state spends all of our money and enforces mandatory decisions concerning our lives. The state <i>shouldn't</i> have the agile qualities needed to produce the beautifully <i>flexible</i> websites created by the private sector.<p>In general, I'd claim the state should certainly be smaller but that it shouldn't be less bureaucratic, shouldn't be more like a corporation. Civil service is boring and bureaucratic <i>by design</i>, specifically it was created to combat the "spoils system" that plagued the early American state [1] (though the prize of modern state eclipse what Tammany Hall etc could have imagined). Modern corporations are agile by having a command structure which lets them quickly maximize profits - which is great if we believe the market system benefits everyone when operating properly. But states with the ability to trample the fences of ordinary market shouldn't not be also given the ability to move quickly and agilely to do this. Corporations have no internal limits to their "greed" but we citizens of democratic market capitalism are assuming that's OK, indeed desirable, as long as the corporation face the strong <i>external</i> limit of markets and individual choice.<p>The current fashion for what could be called "state-enforced private consumption" is sold as giving us the best of all possible worlds but in reality gives us the worst (IE. the reality is the wealth of this society is indeed being vacuum-out by a kind of private-public rent seeker limited by neither the traditional bounds of the democratic state or traditional bounds of the market).<p>Note: I'm not a conservative rooting against Obamacare. It seems like it was a terrible approach for achieving affordable healthcare but I still would prefer it succeeded that failed because, well, I and many friends need it.<p>[1] <a href="http://en.wikipedia.org/wiki/Spoils_system" rel="nofollow">http://en.wikipedia.org/wiki/Spoils_system</a>
The US (and rest of world) should take a leaf out of the UK's recent initiative: GDS (Government Digital Services)<p><a href="http://digital.cabinetoffice.gov.uk/" rel="nofollow">http://digital.cabinetoffice.gov.uk/</a><p>Aside from creating <a href="https://www.gov.uk/" rel="nofollow">https://www.gov.uk/</a> which laid down a lot of principles on how to fulfil a government contract (as well as the foundations of what goverment websites should look like and how they should be developed), GDS is also looking at the problem of procurement.<p>The GDS team essentially are wrestling back from the big contractors the major contracts, breaking the work down into a large number of bitesize contracts and then farming them out to a wide variety of smaller vendors.<p>So instead of finding a Fujitsu/Siemens JV team, or an IBM Professional Services team, operating a £50m project, the plan is to offer 100 x £250k projects to a large number of smaller suppliers instead. Each project having a clearer purpose that is more able to be fulfilled.<p>Of course there are obvious overheads in managing so many projects, and of course some of these projects will fail. But... overall the savings will be such that the overheads are cheap, and the failed projects will only have a smaller impact on a major programme initiative than a failure would today.
I would also add that the project had too many cooks in the kitchen, by some accounts. I have heard there were upwards of 50 distinct companies subcontracting on this project.<p>I work on projects that are probably on par in terms of complexity. We typically only involve a handful of firms. And even then, coordinating them all is a challenge. I can't fathom making the process work with 50+ firms.<p>Maybe that number was hyperbole. I don't know. But if it's true, I shudder at the thought.
It's not just the US government that has crazy, weird, inefficient technology. I'd be surprised if every government wasn't like this. The biggest IT failure in the world was the UK's attempt at healthcare computing that cost 12Bn GBP and didn't deliver a functioning system.<p>I work as a contractor for the Australian government. I personally know of multiple project failures in the 10s of millions of AUD range and a few in the hundreds of millions. These stories don't even make the news.<p>I've worked at small companies, research institutes, universities and now in government. I've not worked big corporate but have heard that it is similar, although more efficient than government. Size means you get less feedback on what is really useful.<p>Government fundamentally lacks feedback on what really matters. In the US the department of health cannot be driven out of business by another department that does what is important 10% better. In private industry that discipline and feedback makes things work.<p>If you build a widget X and it isn't something that people want you go under. That doesn't happen in government. If you build a donkey but it's the donkey they paid for it could be in service for 20 years.<p>It's hard to see how to make it all better. Perhaps trying to keep components small and having multiple groups build them and select the best might help. Then at least 2+ groups would have to compete to build a better system.
ex-cgi contractor here and I am not surprised. they did the Massachusetts health care system that cost over millions of dollars and didn't deliver on the first day.
The government had to shell out even more to keep it running bcoz Gov. Patrick didn't want that to fail on his watch.<p>The way they work is purely in water-fall project management mode. Project managers are gods and spend insane amount of time on ms-office calculating hours per each task that are 2 years out.
then they bring CGI indian sub-par programmers on L1 to save on costs. Technology is least of their concerns since its about shipping code.
Also blame shouldn't be just on CGI, the government is at fault as well. Simple request for information would take about 4 biz days to get it. everything is slow and the Gov IT staff has no clue on how to scale.
Anyway, when I heard CGI won this project, I knew it would fail.
If this is the software that's developed for millions of public users, imagine the software developed for in-house use, where the users are too few and too unsavvy to see how the software could be better (this is the case with most businesses, not just government)...this applies to basic information processing and to software interfaces for our sophisticated weapon systems.<p>And even the software for info systems can have dangerous consequences. Does anyone remember the underwear bomber, who almost brought down a plane and caused a nice surge of invasive security measures afterwards? His own father exposed him, but the State Dept's visa system failed to find the terrorist because someone misspelled his name when entering it into the system<p><a href="http://www.cnn.com/2010/POLITICS/01/08/terror.suspect.visa/index.html" rel="nofollow">http://www.cnn.com/2010/POLITICS/01/08/terror.suspect.visa/i...</a><p>Think about it...the State Dept has been dealing with foreign terrorists well before 9/11, whose names are easily misspelled by Westerners...there's not even a consistent way to spell Osama bin Laden, depending on you interpret he phonetics. And yet no one thought that a fuzzy spellcheck would be useful, apparently. And a whole bunch of people almost died because of it (and the security apparatus greatly increased)
I've had federal employees tell me with a straight face that waterfall development is the only model that works, and that is why 'all of the tech companies use it'. These people have often gone and gotten certifications for stuff like six sigma and CMMI. They will never change their tune. You basically have to wait for all of them to retire. The average government tech worker is so different from the commercial tech worker that they may as well be a different industry all together.
The problem is not necessarily Waterfall, it's people's unimaginative approach to it. I've done plenty of projects for clients that wanted a Waterfall methodology, and I did it by writing the documentation and the prototyping code at the same time. In other words, Agile fits inside Waterfall. The requirements gathering phase in Waterfall projects is so incredibly long that you can definitely afford to make a prototype or 5. And you win huge points with your client when you're done with the requirements phase and get to say that development will take "only two months".<p>You have to treat prototyping as part of the requirements gather process. Then, when requirements phase is done, you have to treat "development" as really "testing". Because, for the types of clients that are going to insist on a Waterfall project, the final testing is really only a cursory user acceptance testing and they really don't have the skills necessary to determine if you've met their requirements or not.
It's interesting that the UK seems to be getting around this by doing stuff in-house. So now we have the open government license (<a href="http://www.nationalarchives.gov.uk/doc/open-government-licence/version/2/" rel="nofollow">http://www.nationalarchives.gov.uk/doc/open-government-licen...</a>) and government websites that take pull requests for content.
Have a look at what's happening in the UK:<p><a href="https://www.gov.uk/transformation" rel="nofollow">https://www.gov.uk/transformation</a>
(fully responsive design pages together with new service backends delivered with Agile / Scrum)<p>and the teams doing it: <a href="http://digital.cabinetoffice.gov.uk/" rel="nofollow">http://digital.cabinetoffice.gov.uk/</a>
(they are hiring more than a dozen people in the moment)
This is not a bad article. The reporter manages to cover a complex subject in an easy-to-understand way. I liked it.<p>I will point out, however, that there's a huge assumption lurking in there that wasn't explicitly stated: <i>somebody on the government side has to know what they want and be willing to take the heat if they get it wrong</i>. _This_ is the reason so many agencies prefer waterfall -- there's enough obfuscation and paperwork involved that when somebody complains, and in high-risk projects there'll always be complainers, nobody is really at fault. The coder guys can point back to the designer guys. The designer guys can point back to the requirements guys. You'd think that the requirements guys, the guys at the front of the waterfall, would catch all the blame, and they do. But they just write bug tickets because some aspect of the process wasn't followed well enough.<p>You can spend hours or days trying to figure out what went wrong and not know anything more than you did before you started. Which is exactly why the system has evolved the way it has.<p>I hear a lot more government projects are going to be Agile. Here's wishing them luck. If done correctly, Agile will 'debug' the organizational problems that lead to this bad performance over and over again. If they just sprinkle a little Agile nomenclature on top of things, it won't do anything at all.
So, for everyone who feels that they have anything resembling a better solution, I'd suggest that you go and actually try implementing it at a smaller scale first. Start with your homeowners' association, your neighborhood, or your nearest town. You'll have relatively few people to convince, more access to decision makers and funding sources, and less capable contractors gaming your system.<p>Get that down, and then get several neighboring communities--again, HOAs, neighborhoods, or towns--and get them to adopt your ideas as well. With that amount of variation, you've got a strong base from which you can convince a major city, or a county, to adopt your ideas: after all, many of their constituents are already on it and can endorse it.<p>This isn't meaningfully different from founding a startup taking on governments as clients.
The most important part of this article is paragraph two, for without the exclusivity present in the government procurement process, it's unlikely we'd have a lack of innovation in regard to development practice.<p>I've led or worked on tech contracts and grants for ED, HHS, NSF, CDC, and others. Several people have pointed out some important points that are not getting enough attention in my opinion:<p>by @mcone: "The procurement rules were designed for that, yes. But in real world scenarios, those rules effectively do exactly the opposite. Since there are so many hoops for potential vendors to jump through, only the most established players get to bid on most contracts. And in my experience corruption and cronyism is still alive and well in federal IT contracting."<p>It's true, incest between government and industry is rampant and has led to wide spread cronyism despite the system's best efforts to limit the effects. People that once worked for company X, now serve on the proposal review panels when company X competes for work. No, they don't receive direct compensation and thus there is no immediate conflict of interest, but the reality is humans are drawn to (or don't want to disappoint) the people they know (former colleagues) and thus pick their old companies. In addition, they know there is a chance they may once again return to said company (so there is long term conflict of interest potential).<p>Another point that hasn't been discussed is how the government's procurement process provides next to no incentive for companies to efficiently produce good products. If our industry loves the DRY concept, everything about the gov procurement process points to a !DRY (or do repeat yourself). We built and rebuilt the same database for offices of the government that shared a building with one another. But because everyone is in a silo, they don't collaborate well and don't realize that they could pool their needs to develop more universal products. (And on the industry side, as long as gov continues to work this way, they don't even have an incentive to re-use their work or propose innovative, generalizable solutions.)<p>And for those of you that might say, 'but can't you win a gov contract by bidding lower by working off of existing work?' The truth is price has very little to do with who gets selected for a gov contract.
Maybe US should look to the number of successful websites launched in European governments and public sectors. There were obviously a lot of failures along the way, but that is what you learn from. And if US can skip some failures, thats maybe a few billions not lost. Worth looking into.
I have respect for people who are doing waterfall and admit to it. In my personal sphere I see far too many people talking agile all day while actually running waterfall projects. It seems like people think agile means "waterfall, but skip most of the upfront planning".
actual problem: government is incompetent at leadership because it is saturated with politicians whose main skill is only convincing you they are competent leaders. no leadership skills actually required.<p>if government were competent stuff like capitalist economy and privatising public services would always be bad (provably - actual proof, not just overwhelming evidence - but there is overwhelming evidence too).<p>leaders intuit things like agile and don't label them - instead of picking it up from a book and implementing it badly because they don't understand first principles.
Coming from a 6+ year stint in a defense contracting, I can safely say that the issue with this approach happens well before the testing. The problem more often than not occurs at the requirements level.
"<i>A tank is a tank is a tank, pretty much, plus or minus a few bells and whistles."</i><p>Geeze, such amazing ignorance. If you're vaguely interested in this sort of thing, and want to learn all the process and engineering reasons the Abrams M-1 became the <i>King of the Killing Zone</i>, get a copy of the book by that name: <a href="http://www.amazon.com/King-Killing-Zone-Orr-Kelly/dp/0393026485/" rel="nofollow">http://www.amazon.com/King-Killing-Zone-Orr-Kelly/dp/0393026...</a><p>Written by someone who initially expected to castigate it due to early (mis)reported teething problems (e.g. the whole "it throws tracks (more than other tanks)" was due to a proving ground's faulty tension meter), he got completely sold on the tank which has since totally proven its worth.<p>Lots of fun stuff, from their modeling everything with strong constraints like weight (i.e. what bridges can it cross), e.g. they didn't want to provide a heavy M2 .50 BMG but the tankers demanded it. To the successful development team's leader, a grizzled Chrysler car exec who drove them crazy with "that doesn't look good" sorts of complaints.<p>Which often turned out to be a boon (ignoring that weapons should look good so their users feel good about them, which the M-1 delivers on). Said it was too high in an ugly way, so they figured out how to shave a foot off, which is very important for the European theater (not so good for deserts). Didn't like how the armor skirts didn't extend all the way to the back. So they gave in (I'm sure the modeling said it was only a minor net loss) ... and found that made a critial difference in keeping cruft thrown up by the tracks out of its turbine engine.<p>Very much an iterative process, in a domain where you truly "bend metal" to get things done.<p>So take the author's words with a big grain of salt, she's woefully ignorant of a huge domain in which we've been building for a very long time the world's most sophisticated artifacts, and learning how to, and how not to do it ... with stakes no less than national survival. Digital computers used for IT are a very recent development as these things go.