Surely the stupidest of all the commentary about Healthcare.gov is the oft-repeated, “The Obama administration can’t even put up a website.”
Or maybe it’s ignorant, not stupid, because calling it “a website” is a lot like calling the Curiosity Mars rover “a car.” Also, the website part — the user interface — generally receives compliments from those who have looked at it closely. Of all the criticisms of Healthcare.gov, this is probably the only one that is completely wrong.
Healthcare.gov is IT in the headlines … irresistible to Recognized Industry Pundits (RIPs) like yours truly. But instead of participating in this version of “dog pile on the rabbit,” here are some thoughts you might be able to actually use.
Start here: There’s a scale hierarchy when it comes to programming efforts. Ignoring enhancements — efforts one programmer can handle in a month or less — the smallest are projects, which require a team, multiple tasks, and a plan.
For some organizations, that’s it. Enhancements and projects. But smart ones recognize that projects fail, and they fail in non-linear proportion to their size. Once you get beyond about seven core team members and about six months, failure rates skyrocket.
That’s why smart organizations “chunk” larger efforts into multi-project initiatives, and chunk behemoth efforts into multi-initiative programs. Whatever else happens, the individual projects will at least complete, delivering their planned work products as they do.
“Chunking” also helps prevent phase compression. As mentioned last week, there’s a tradition in project milestone management: If an early phase goes long, it’s always because the additional time and effort will allow later phases to be shorter.
That’s the rationalization. The way it actually works is that if the early phase went long, the whole effort is probably bigger than it looked at first. But as saying so is political suicide, the project team assumes subsequent phases will be shorter instead.
With every late milestone, though, the time compression between remaining milestones increases until there’s almost no time left for the final two phases, which are, of course, testing and training.
But if instead of phases you have separate projects, phase compression is less likely. The project manager probably won’t even be responsible for the subsequent projects. Even if he or she is, the subsequent projects haven’t been planned yet. When they are, their project managers have at least a fighting chance of developing reasonable timelines for them.
Sounds like a panacea, doesn’t it? It might sound like one, but it isn’t one. By separating what used to be phases into separate projects, you gain in reliable delivery, but you risk losing coherence. This happens with initiatives complex enough to have multiple concurrent projects going on, and happens in spades with multi-initiative programs.
Among the many coherence problems large programs face, three that stand out are (see this week’s ManagementSpeak for the translation):
First project wins: Large programs that include large-scale software development require standardization on several fronts, from user-interface style through matters of architecture and software engineering. If individual project teams make these decisions on demand, each will be optimized for the project that made it, not for the program as a whole.
Large programs need someone to be responsible for applying the whole-program perspective to these decisions.
Scheduling: This is pretty basic. Projects compete for resources. Not just staff (if it’s just staff, say so — don’t call people “resources”) but minor things like test environments and business department time and attention for whatever you need their time and attention for. Also, some projects depend on the results of other projects from time to time; if the other projects are late, their delays can ripple through the whole program.
With one big project, all tasks are plotted on a single schedule, so interdependencies can be made explicit, letting the project manager at least manage the chaos, even if there’s no way to prevent it.
But with multiple concurrent projects, a whole different kind of coordination is required so projects don’t run into each other, because there are more different kinds of inter-project dependency than just finish-to-start and its brethren.
Silo-ization: What, you thought large programs were different from any other large organization? They’re just as prone to devolving into rival siloes, based perhaps on which initiative you’re part of, or whether you’re process or tech, or whatever. Preventing silo formation in programs is the same as anywhere else, too: You foster a global sense of identity, and define a collaborative culture.
And, of course, privately “coach” the guilty.
Bob,
Again, you are far too kind. The website is well designed? The analysis that I have read does not even come close to that conclusion. However, I do agree that however bad the front end is, problems with the back end are worse.
The other problem you are tiptoeing airing is the fact that it is crystal clear that the government managers and the contractor’s managers lied like rugs when asked by higher ups if the project was ready. That is how “no one knew” of the real problems before the rollout. The only acceptable answer that could be given to Obama and his advisors was that everything was going great.
The Obama administration is transparent only in that it is a cult of personality. Like any rock star CEO in the business world, the image of the leader is the only important thing. No one is allowed to utter the words “the system is not ready” because if they do they would be destroyed. It doesn’t matter how you do project management if you are forbidden from telling the truth to management.
Not sure if they were lying or not. Testing got compressed, after all.
And on the personality cult front, I’ve read the accusation, mostly from the same people who accused him of listening to too many differing points of view when the subject was Afghanistan, Libya, and Syria.
Great points, Bob. One of the challenges that we have struggled with (in a global company of 90,000 employees) is how to chunk the initiatives. The natural chunking is by workstream or outcome. However, this has caused us to encounter the principle-agent problem; teams will not have the best interests of the company or program at the top of their minds, rather they are most interested in the political interests of their organization. To overcome this, we will chunk by organizational accountability, but that leads to inefficiencies in its own right. I am interested in how others overcome this.
Not having worked ar that scale before I can’t say this with certainty: I’m pretty sure an important ingredient is establishing a program sense of identity. If most participants switch their allegiance, I think the rest can work.
As I understand it, the ACA website was originally intended to be 50 websites, one for each state. Each website would have had to support only residents of that state and interact only with insurance companies that sold policies in that state. Each state’s system would have had a lot fewer moving parts than the nationwide website has.
Such an approach would have reduced the scheduling problem and a lot of the competition for resources. It would have caused differences in UI and architecture, but since few people would have had to interact with more than one state’s system, the effect of those differences would be small. And yes, each state would have been a silo, but the effect of silo-ization would be no worse than for other state-operated programs.
The refusal of so many legislatures and governors to provide their own healthcare exchanges made the software much more complex. It’s almost as if those legislatures and governors wanted the program (in both senses of the word) to fail!
You make a good point, and I haven’t seen it mentioned before. No matter what your position and affiliation, when someone says they’re going to do everything possible to cause something to fail, it’s hardly cricket to say, “You loser! It failed!”
This is an interesting point. However, I think that the fact that many states use the National Exchange could have given them a potential advantage.
They should have architected the system to scale at a state level and spawned 34 websites that had independent front ends that would talk to the same back ends.
Now if the back end communication is the real problem, this won’t solve much. But the front end issues could have been scaled based on the state divisions and they might have helped things.
This speaks to what I think is a major failing in the law, which is that health insurance should not be regulated at a state level. I work for a company that is not from my state. The health car policy they by is based on their state’s laws not mine. The only consolation I have is that they have provider network agreements that cover providers in my state as well. Having health insurance only be regulated at the national level would eliminate a lot of hassle and confusion and save a lot of people a lot of money on insurance.
However, the feds maintain healthcare as a “state” responsibility so that they can make states pay cash for Medicaid in their state, and lower the federal burden of payment for that program.
As usual, another great column. But, how do you chunk a huge project, when you are trying do something that has never been done before?
I don’t mean the website, which has been done on a large scale before by the government, e.g., the Medicare website. I mean coordinating and interconnecting with all of the various Blue Crosses’ databases, as well as those of other insurers’, in a web-timely manner. Many states, like California and Illinois have their own Blue Crosses.
If I had to chunk such a project, right now I wouldn’t know where to start.
I know exactly where I’d start. I’d either triple my billing rate or else run and hide until they found some other poor schmuck to take on the project.
One thing I’m confident of: The integration architecture would have been one of the chunks. For all I know it was. I sure hope this puppy wasn’t built on a bunch of bespoke custom-coded interfaces.
“Surely the stupidest of all the commentary about Healthcare.gov is the oft-repeated, “The Obama administration can’t even put up a website.”
I dont think it’s stupid, I think to the normal citizen who is facing the “reality” that they just lost their healthcare that this is exactly what they are thinking. Face it, with all of the technical innuendos and explanations and blame placing – it doesn’t matter to them – at some point “someone” has to take ownership of it (and this administration should – they made lots of promises.. remember?)
someone sent me this, thought you might enjoy it…
“Putting things in perspective:
March 21st 2010 to October 1 2013 is 3 years, 6 months, 10 days.
December 7, 1941 to May 8, 1945 is 3 years, 5 months, 1 day.
What this means is that in the time we were attacked at Pearl Harbor to the day Germany surrendered is not enough time for this progressive federal government to build a working webpage.
Mobilization of millions, building tens of thousands of tanks, planes, jeeps, subs, cruisers, destroyers, torpedoes, millions upon millions of guns, bombs, ammo, etc. Turning the tide in North Africa, Invading Italy, D-Day, Battle of the Bulge, Race to Berlin – all while we were also fighting the Japanese in the Pacific!!
And in that amount of time – this administration can’t build a working webpage.”
Well, now, let’s see. (1) It isn’t a working webpage it’s a complex website. (2) Total spend on Healthcare.gov = $63M. Total spend on WWII = the total output of the U.S. economy. (3) Healthcare.gov’s priority compared to other issues needing the president’s attention: up there somewhere. WWII’s priority: It was the only priority. (4) The opposition party has been explicit in its goal of causing, not just Healthcare.gov but this president to fail. WWII? Roosevelt was despised by many in the opposition party, but none were trying to cause us to lose WWII.
Offhand, I’m at a loss trying to spot even a single parallel between Healthcare.gov and WWII that makes any sense at all.