All Posts in Project Management

|In: Industry Commentary|Last Updated:

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.

Comments

|In: Industry Commentary|Last Updated:

It’s a scandal! It’s a waste of taxpayer dollars (roughly $1 per taxpayer)! It’s proof, if I’d just take my partisan blinders off, as one commenter put it in response to last week’s column, that the federal government is totally incompetent at project management!

Bad project execution is a partisan issue? Seriously?

One failed project no more proves the federal government is “bad at project management” than NASA’s three blindingly successful Mars rover missions prove it’s good at it.

For that matter, the myriad, usually buried-in-the-back-yard private sector project failures tell us Healthcare.gov’s problems probably have little to do with the .gov part. Big projects are risky, for well-known reasons.

Any number of commentators have emitted strongly-held opinions about this mess, whether or not they know anything at all about software development, systems integration, or project management.

And yet, few of the mistakes that mattered were either intrinsic to government or were project management failures. What they were was entirely unoriginal. For example:

Integration engineering: It is by now well known that Healthcare.gov integrates information from more than a dozen back-end databases, synchronously, in real time. It is the big flaw.

But project management isn’t software engineering. Project managers make sure the tasks in a project adhere to the budget, schedule … and specifications. They don’t pass judgment on the specifications, unless they also happen to be software engineers.

The design was questionable at best. When a system has to consult a bunch of other systems … Healthcare.gov retrieves applicant information from quite a few other government databases … its response time can’t be any faster than the slowest of them. And as those systems weren’t designed to handle the additional processing load from Healthcare.gov, this was risk piled on risk.

My guess, based on no knowledge at all of this project, but plenty of experience in how these things happen: Either an engineering purist insisted on design elegance, or a non-technical manager overruled the experts for political reasons. Regardless, this problem had nothing to do with project management.

Agile? Quite a few commentators have suggested this should have been an Agile project. They’re wrong.

First, see above. Agile wouldn’t have avoided bad integration engineering. Second, Agile shines when planners can break a big effort into small chunks; when the whole organization has to “learn its way into” how the software should work; and when user-interface design dominates the effort. In the more common software development situations, that is.

But not Healthcare.gov. It had a detailed spec. It’s called the Affordable Care Act. Its business logic is complex. This is where you do want waterfall, not iteration and high levels of user involvement.

Slavish Adherence to Deadlines (SAD?): This was a sponsorship issue, making it a project management problem but not a problem of having bad project managers.

It’s banal and ubiquitous: In big projects, when early phases go long, everyone tells each other they can make up the time in later phases. Eventually, the only phase left to make it up in is testing.

And as everyone in the software business knows, you always test software, and test it thoroughly. The only question is whether you test it before it goes into production or after.

Deadline-adherence is a choice. Sometimes, as in Y2K remediation or product rollouts, the deadlines are real. Usually, SAD comes either from politics trumping engineering or the next topic, which is …

Optimism bias: I’m speculating but it’s a pretty safe bet. Throughout any big effort, sponsors … who are supposed to be professional optimists because otherwise they’d never do anything as crazy as sponsoring the project … often pressure project managers to commit to an aggressive schedule, or accept risks they shouldn’t.

Among the reasons is the time-honored tradition of Solving for the ROI. Another is the sponsor’s reputation for delivering the goods.

With Healthcare.gov, on the front end contractors knew that price and schedule would be key to winning the business. At the back end, everyone in the Obama administration’s decision hierarchy had committed to a date.

I doubt any of them lied, except to themselves. They succumbed to optimism bias.

Learning?

There’s nothing to learn from this little contretemps. Nothing at all.

The problems with the Healthcare.gov project are well-known, entirely preventable mistakes. If you want lessons to learn, maybe these: Make sure your sponsors know how to sponsor, and make sure key engineering decisions get a thorough vetting.

But really, I sure hope neither of these are lessons. Reminders, perhaps … of lessons learned long ago, over and over and over.

Comments