By Brad Powell

The official deadline to enroll for health insurance through the Affordable Care Act passed last week, but the real deadline day has not yet arrived -- and it's unclear when it will.

That's because the Obama administration announced at the end of March that it would grant an extension to people who are having trouble securing health care through the federal marketplace. There is plenty of debate about the politics behind this announcement, but from the perspective of a technology company like Axiaware, it is clear that this news means the ACA and healthcare.gov are still experiencing technical difficulties.

And this high-profile, massive IT project, while painful for many, can provide some valuable insights into the realities of any IT project.

Healthcare.gov launched on Oct. 1, 2013, and immediately was beset by problems. Very few users could use the site to enroll in coverage. Insurers couldn't rely upon the information the site was relaying to them. Media outlets such as NBC News used terms like "disastrous" to describe the launch.

From our perspective as complex software developers, two problems were apparent as we read about healthcare.gov. One was a problem that probably existed from the beginning of the project, and another was a problem encountered as development progressed.

Let's start with the problem encountered during development. It seems likely that people who understood the site's issues failed to convey their extent to principals in the months leading up to launch.

That's a big mistake. As we say at Axiaware, bad news doesn't get better with age. Once you spot a problem, you need to let people know.

Admittedly, that's not an easy culture to instill. People will try to hide bad news, and developers never want to look incompetent. But an iterative, consultative style of development works best with frequent and frank updates and re-assessments of where a project stands and what can get done in the near term.

Identifying problems and adjusting to the situation could have saved the Obama administration from the onslaught of bad press it received in October (and November and December) of 2013. The pain that might result from disclosing a problem early is never as bad as the pain you'll feel later if you don't disclose it.

Another form of communication breakdown appears to have occurred when the healthcare.gov project kicked off several years ago.

A good software developer makes sure their client understands the project and the key challenges it presents. However, CGI -- the ACA contractor which has since been replaced by Accenture -- seems to have skipped this essential step.

CGI most likely would have known that exchanging data between healthcare.gov and insurance carriers and billers would be difficult. Did they talk about this in the sales process? Did they tell the government how tough this could be? That it was likely to be a failure point? That was their responsibility. The government needed to know this to set basic goals.

When hiring a software developer, it is important to let them help you ask the right questions from the very early planning stages. As the key stakeholder, your company has to set priorities and make final decisions. But you can't do it unless you know what's truly important.

It's hard to say precisely what a company like ours would have done if we had been in CGI's position. But we would have followed a few key principles, as we do with every one of our engagements:

- Prioritize the most important work, with a bias toward front-loading the project with the most difficult tasks.

We have thrived by tackling the hardest issues first. It allows you to identify the biggest problems and adjust goals before a final deadline looms.

- Set simple core goals and focus on those. That means you may have to modify or drop secondary goals -- they can be added to the project later. But you'll deliver on the most important elements.

In the case of the ACA, a simple core goal might have been getting people registered. It may have made sense to launch on October 1 with limited site functionality and instead allow the actual registrations to take place on insurance carriers' sites. Alternately, the registration process might have gotten users to a certain point and had them call an 800 number to complete their sign-up by phone.

These aren't fully automated processes -- but it would have been easier to make sure they worked. And if they worked, more people would have ended up registered for insurance in October. Later, healthcare.gov could have added the capability to fully register online.

- Demand frequent inspection. We perform status checks every month on each of our projects, and then we sit in front of the people who pay the bills and tell them what we've got.

With this approach, there are no surprises. A project could not get to launch day and cause the headaches healthcare.gov did for the administration.

- Re-evaluate upcoming goals. Frequent inspection inevitably turns up problems. Bigger problems often make it clear that your initial plan might not work. That's okay -- we expect to learn a lot once work has begun -- but you have to adjust to those problems and redefine goals.

We don't know everything that happened behind the scenes in the development of healthcare.gov. But we know enough about development to know that many principles we rely on clearly were not adhered to.