Project Management rollout lesson: Push back on unrealistic launch dates

Ken Hardin believes testing and a real sense of consequence might have helped dodge the Obamacare site launch fiasco. Read his tips for tackling forced release dates.

When my editor here at TechRepublic asked if I would be interested in writing about the project management implications of the Obamacare site fracas, my first instinct was to say it probably wasn't all (or even mostly) a project management issue in terms of formal PM disciplines. The site's rollout troubles sound more like a case of a fundamental break down in how an organization handles big projects.

Caveats: This article is not intended as either an endorsement or a criticism of the Affordable Care Act. It's also not intended to be a deep analysis of what has gone awry with the software development project. Since I didn't work on the project, I probably never will have an idea of what specifically went wrong. I will take the liberty of saying that folks who are shocked that a big ol' website launched with some significant problems have probably never worked on a big ol' web site launch, or for that matter paid very close attention to similar private-sector boondoggles that don't tend to grab headlines.

There's only so much a project manager can do when presented with unrealistic objectives and deadlines set arbitrarily by senior management (or Congress, or what have you), and that is my general impression of what went wrong on this project. I was taken by the "analysis" -- really it's just common-sense business advice -- from PM guru Dr. Harold Kerzner in this Huffington Post article. I am a sucker for any Star Wars analogy, and Kerzner draws a perfectly lucid parallel between Darth Vader threatening that the new Death Star darn well better be ready for the Emperor's visit and pushing for an unrealistic deadline just because, you know, that's when we want it.

(Spoiler: The new Death Star wasn't really "fully operational," as the Emperor boasted, unless you consider one entire exposed side just waiting to get strafed by Rebels "fully operational.")

But what do you do when your Dark Lord … err, executive team … announces that a project has to be completed on such a date / time, and that is how it is? The first recourse is to try to hash out accurate time / cost projections and triage off enough functionality to make the deadline at least plausible, while maintaining some core value in the deliverable. But even if you, the business analyst, and a few mid-tier managers are able to pull off a reasonable pruning exercise, the odds of you being able to squeeze in a credible effort against a purely arbitrary deadline are still slim.

Come launch day, you are likely to end up with:

a)  a gelded deliverable that does not deliver on the proposed business value.

b)  a buggy mess.

c)  both a & b

Again, dark fate A is mostly an issue of the dreaded IT / business misalignment (i.e., incompetent management) and just something project managers have to deal with, or at least try to mitigate.

I have racked my brain for several years on how to tackle the bugginess of forced releases, and I have come up with no perfect answer there, either. Once, however, I did get all the stakeholders to buy into two terms for launch that did actually result in the "hard and fast" live date slipping a bit and the client avoiding a serious data security problem.

Term 1: The prescribed QA time in the project plan could not be trimmed, under any circumstances.

Term 2: The stakeholders had to identify 15 general requirements that were non-negotiable.

Term 1 is the toughest to enforce, since QA at the tail end of a time-sensitive project always gets slashed, even though it's even more vital when developers are in a hurry. I have seen projects go live with only developer peer testing, and managers congratulating themselves over it. Argh.

You'll find an ally in the QA manager for setting Term 1, and with any luck you'll be able to push back hard on folks who agreed to the terms when they start thinking that fudging is a good idea.

Term 2 is a little dicer, and will require the help of a business analyst or a project sponsor. If at all possible, try to quantify in dollars the damage that will likely occur if the requirement is not met. And this agreed-upon list should be communicated up the food chain to the Big Guy well in advance of the launch date. It should be simple enough for senior executives to grasp; hell, put it in a PowerPoint.

Again, I cannot stress this enough: When the launch date is mandated by the Big Guy, making that date becomes a goal unto itself, regardless if the actual product is even remotely useful. That's just politics, on Capitol Hill or in your office campus.

By codifying the most essential needs of the project – "we need multiple security layers, so that teddy bears with sticks can't make us completely vulnerable to attack" -- and ensuring that the team has time enough to test those requirements, you can at least go to senior management with a very clear message as to why the project simply can't launch on a purely arbitrary date.

Would this have worked in the case of the Obamacare site? Maybe, if the project team knew about some of the more serious bugs and faced credible penalties for launching a buggy mess. Or maybe not -- the U.S. federal government is enormous, and as I said from the outset, I don't really know what happened here, and frankly have no insight into the professionalism and honesty with which those involved acted.

But here's hoping that at least in your shop, if you can clearly quantify the pain of launching just to say you launched, someone Up There will listen.



Ken Hardin is a freelance writer and business analyst with more than two decades in technology media and product development. Before founding his own consultancy, Clarity Answers LLC, Ken was a member of the start-up team and an executive with TechRe...


It is not the first time that this lesson in learnt or not something project managers don't know about. It is more of a routine with clients who do not understand software. But the project managers must ensure that they exhaust all their options to make the other side understand. After that the PM and the team need not feel guilty and they can tell themselves that they did their best.


This is the first news article I read about this failure so not even small percentage data to analyse anything.

But based on my experience of looking at similar government projects, they tend to take lots of time agreeing on everything; even very small unrelated matters are disagreed between parties to ascertain their authority (who is daddy?). 

Actual engineering of solution, building and testing is small part of it. Since most of time is wasted in initial requirements and specification stage, it keeps shrinking time available for development and testing and that's where such issues crop up.


Quote of the Day  “Fathom the hypocrisy of a Government
that requires every citizen to prove
they are insured...but not everyone
must prove they are a citizen.”  


Not trying to be political about this (if that is even remotely possible) but there was a lot of arrogance and stupidity on behalf of the Obama administration in this whole thing.

 Several months ago the HHS web site proclaimed that the white house was "setting the standard for web API development."


 I did a quadruple take when I saw that since-removed statement. Do they even know what a "web API is?" Why on earth would anyone make a statement like that?

Perfect example of not even knowing that they didn't know.


The Biggest problem is the Whole thing, ObamaCare!

what they should have done is not let the Insurance Companies right the law !

what they should have done, 1} write down how they would like there Insurance to be ! If it is Not Good Enough for our President, His family, & the rest of Our Elected Government than Don't Cram it down our throats. It should by Unconstitutional for our Elected Officials, and President to Write in to law anything that they are Exempt From, We are not there Slaves.


This Obamacare web-site disaster is not about "unrealistic launch dates".  It's about a failure in management from top to bottom, but mostly at the top.

3 1/2 years is plenty of time to deliver a good working system, especially with the budget allocated for the thing, and the number of people involved.  

The problem with the site and the roll-out is about the lack of accountability in higher management, like Sebelius, and with Obama.  They delegated and didn't follow up, and they needed to insist on deliverable stages throughout the life of the project.  The biggest deliverable should have occurred at least a year before the roll-out, and that should have been an alpha version of the system, and once that was deemed adequate enough, to be followed by a beta test system, some 3-6 months later.  Then, a roll-out version should have been ready months in advance.  Those are things which neither Sebelius nor Obama nor anyone in the administration were trained or skilled at.  Top management should never feel comfortable in their jobs, and they need to understand that, heads will roll if their is any failure towards the end or at roll-out.  When people understand that they can't or won't be fired, then, they'll just hope for the best, and accountability is just a word without any meaning to them.


We will have to wait for some of those involved to retire to know the inside story.  It will likely be an interesting case study covered in business textbooks in a decade or so.

I expect the failures outlined to be the same as numerous other failures due to poor planning, lack of testing, feature creep, etc.  

Nothing in this failure will likely be shocking except for the total cost in the end.


@adornoe , 70 years ago this country built hundreds of thousands of jeeps, tanks, aircraft, and even two nuclear bombs (which only existed as theories at the onset) with little more than slide rules in less time than the Obama Administration had to build a working web site.

I don't think there's much to learn here from a "project management" viewpoint.  The problem was entirely somewhere between politics and sheer incompetence.

IT Security
IT Security

There were several levels of delegation and, as stated in the article, sometimes the PM is presented with a hard and fast deadline and has to work with that. In the government, that happens too many times to be counted, this is just the latest problem-filled launch.  It's easy to say the President should have followed up, but that is why Secretary Sebilus should have done better in following up.  The CMS Director had her hands tied because of the set-in-stone launch date, so even if she had informed the Secretary and President of the issue, would it have made a difference? It's easy to guess after the fact, but only those involved really know what they may have done. Yes 3 1/2 years should have been enough time, but the question is when did the contractor actually start building the system.


@IT Security It's not a matter of when the contractor started working on the system.  There was a deadline, and that deadline gave the builders plenty of time to come up with a fully working system; no excuses.  But, with the management at the top, the builders weren't being held accountable for delivering on time.  The management at the top, btw, were/are political animals, and if they were going to be involved on a minimal level with day-to-day development of the system, then they needed to delegate to people who would be held accountable for any problems.  As it stands, the people that the project was delegated to aren't being held accountable.  But, in the end, the buck has to stop somewhere, and it's not stopping at Sebelius's desk, and it's not stopping at Obama's desk either.  Politics is a very bad way to run any system or government; politics should stop at the point where people have been selected to actually run things, and accountability should be untarnished by the politics of the people involved.  . 

Editor's Picks