Lessons in Software Project Management from Healthcare.gov
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
As the woes to the roll out of the “Obamacare” Affordable Care Act (ACA) website continue to unfold, it becomes clear that those tasked with responsibility for this initiative don’t really understand software or programmers. If they did, then they would not have managed or be continuing to manage the roll out the way they appear to be. They clearly have never heard, or have ignored, many of the rules of thumb for software development that are important for those of us tasked with such responsibility to know.
In our book Managing the Unmanageable: Rules, Tools and Insights for Managing Software People and Teams we collected over 300 such rules of thumb, some of which seem obviously applicable to this software debacle.
For example, in spite of the promise that the ACA website will be rolled out fully functional by the end of November, this rule of thumb known to anyone practiced in the art of software development may yet prove true:
Brook’s Law: “Adding manpower to a late software project makes it later.”
-Fredrick Brooks Jr., The Mythical Man-Month
This undoubtedly applies to adding “experts” too. Also, did anyone else wonder why they didn’t consult these “experts” earlier in the project?
Other rules of thumb from the book that seem broadly applicable to the ACA project include:
“For every 10-percent increase in problem complexity, there is a 100-percent increase in the software solution’s complexity. That’s not a condition to try to change (even though reducing complexity is always desirable); that’s just the way it is.”
-Robert L. Glass, “Frequently Forgotten Fundamental Facts about Software Engineering.”
There were over 55 different teams working on this project at a reported cost of hundreds of millions of dollars billed by federal contractors, plus unaccounted costs for the government workers. To read the reports, they have to connect to every insurance company, access every insurance policy, and connect to every state system and a whole lot of municipal systems (every one of which is wired differently, of course). Just a bit of complexity…
“Requirements engineering is primarily a communication activity, and it takes surprisingly little geographic separation to impede effective communication.”
-Karl E Wiegers, Principal Consultant, Process Impact
More than 55 different teams, disparate locations.
“Large teams (29 people) create around six times as many defects as small teams (3 people) and obviously burn through a lot more money.”
-Phillip Armour
Over 55 different teams, many of them very large teams. No wonder it didn’t work.
“In practice, [Fred] Brooks found, nearly all software projects require only one-sixth of their time for the writing of code and fully half their schedule for testing and fixing bugs.”
-Scott Rosenberg, in his book, Dreaming in Code
Brooks himself wrote, “My rule of thumb is 1⁄3 of the schedule for design, 1⁄6 for coding, 1⁄4 for component testing, and 1⁄4 for system testing.” From reports on the project management of ACA, this project was given a fraction of that QA.
“Never trade a bad date for an equally bad date.”
-Jim McCarthy
Let’s see what happens when the end of November rolls around.
“When you want a project in the worst way, that is often how you get it.”
-Watts Humphrey
Case in point…
These are only a few of the rules of thumb that seem to apply to the ACA project. From the outside, it seems a classic case of a date driven project. Even when it’s the President or Congress that says “this must be ready by October 1st”, they can mandate that it will be delivered, but they can’t mandate that it will work.
For something so complex, best software development practices appear to have been thrown out the window. There was no comprehensive beta test. No more than cursory user testing could have been performed. And perhaps the smoking gun most revealing of the ineptness of this project’s management was that reportedly there was NOT a comprehensive security audit completed before the initial roll-out on October 1st with the lame excuse given that “security testing is never complete and is an on-going process”.
The simple lesson from the ACA project is you cannot legislate or dictate good software.
As Donald Knuth, one of the true gurus of software development, said years and years ago,
“Software is hard.”
All of these “Rules of Thumb and Nuggets of Wisdom" come from the section titled "Managing Teams to Successfully Deliver,” which begins on page 203 of our book Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams. There are many more Rules of Thumb in the book and in that section that provide excellent guidance for anyone managing programmers and the managers of the ACA project(s) in particular, if only they would read and understand them.