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.

Random thoughts while on vacation in southern Spain:

Want to know how to motivate people? Forget the books and formulas — even mine; even Daniel Pink’s!

Just pay attention to your life. For example, there I was, “canyoning” at the top of a 90-foot cliff (estimated from the top; from the bottom estimates ranged from 3 to 4 meters). Below me was a pool of water of uncertain depth.

In the pool were my stepsister and stepbrother who had just cheerfully jumped in. Next to me was our guide and a young woman, perhaps 27 years old, who had joined our little expedition.

While perched on the rock, while our guide was explaining that all I had to do was take one step, I idly wondered if the proper diagnosis was acrophobia (fear of heights) or bathophobia (fear of falling).

But with two already down an all four watching me …

This is why, when you manage projects, you want a weekly status meeting, where everyone on the project interacts with everyone else on the project team as they discuss whether they made their deadlines for the week or not. Neither my list of motivators (need for approval, exclusivity, fear, greed, and guilt) nor Pink’s (autonomy, mastery, purpose) mentions peer pressure.

But peer pressure is what launched me off the rock and into freefall. And when you’re managing a project, peer pressure is the your most effective tool for keeping everyone on schedule.

* * *

We drove to Gibraltar. On the way we  read  a wee bit of its history: England got custody as part of the Treaty of Utrecht, and Spain has been angry about it ever since.

Having driven there, gazed upon it, and admired it, and also having spent time and energy facilitating discussions and brokering agreements, I have this advice for Spain:

Get over it. It’s a rock. Sure, if you owned it maybe you could get Prudential to pay you for usage rights, but probably not. Other than that … your economy is in depression, your overextended banks took you there, bailing them out nearly bankrupted your government, and you have no control over your own currency.

My advice: Ignore the rock. My related advice to the managers and staff who read this missive on a regular basis: Someone you worked with slighted you recently, or insulted you, or otherwise took possession of your Rock of Gibraltar. Your best strategy just might be to ignore it, too.

(Along these lines, Ambrose Bierce once wrote of a lion’s encounter with a skunk. Feeling threatened, the skunk did what skunks do best, but the lion took no apparent notice. So the skunk said something like, “Sir, I beg you to notice that I have set upon the earth an implacable aroma.” To which the lion replied, “You needn’t have bothered. I already knew you were a skunk.”)

* * *

My Dad updated his iPad to iOS 7. It froze mid-update. As I’m the closest thing to a resident tech here, it was my responsibility to do something. It being an iPad, I pushed various buttons in varying combinations until it unfroze, at which point the screen informed us that nothing else was going to happen until we plugged it into iTunes.

With my usual technical panache I figured out this meant the iTunes software and not the iTunes store. So we found an appropriate Windows laptop, downloaded and installed iTunes, plugged in the iPad, and pushed various buttons in varying combinations once again, until voila! The iPad booted up. Remarkably, it was then able to restore from iCloud and my Dad was back in business.

Apple. It just works. Except when it doesn’t.

So then, for reasons that mattered at the time but not to you, I had to install some videoconferencing software on my personal Windows 8 tablet. Pathetically enough, the software didn’t detect that it was being installed on a version of Windows with which it was incompatible, but it was, and it didn’t, resulting in a hung system, followed by an uninstall, after which  much of the installed software no longer worked.

Fortunately, Windows 8 comes with a feature called “Refresh,” which is supposed to fix up munged systems without doing any collateral damage. Unfortunately, Refresh caused quite a bit of collateral damage: It uninstalled every bit of Windows Desktop software, including Microsoft Office.

Which is why I’m writing this week’s column using whatever Google calls its office suite these days.

Proving that no matter where you are and whatever you face, there’s probably a way to fix it, but there’s a good chance the way you find will be pretty annoying.