What Tips Can You Discover in a Failed Project?

The launch of the healthcare.gov website was marred by technical glitches and multiple challenges, making it an excellent lesson for a manufacturing company launching their own IT project.

By Nick Stonebraker, CIMx Software Developer

Sorry for the delay between posts, but we’re back!  We’re also lining up new posts now, so there won’t be a wait for the next posts.  Today, we’re going to take a look at a few lessons to keep in mind as you plan your next major IT project.

Regardless of how you feel about president Obama’s attempt to reform the healthcare system, the development project for the healthcare.gov site was a well-publicized and technical disaster.  It was over-budget, behind schedule, and lacked much of the promised functionality when it was finally released.  While most, if not all, of the initial problems have been solved, there are information technology lessons to be learned.  Many of the challenges the healthcare.gov project encountered mirror the difficulties manufacturers face as they roll out (sometimes massive) IT projects on the shop floor and in the front office.

We’ll take a closer look at a few of the problems and issues the government encountered during the healthcare.gov project, and identify lessons to give you an advantage as you plan your next IT, paperless manufacturing or MES project. 

Lesson Learned: Agile Behavior, Not Agile Marketing

As soon as healthcare.gov’s failed launch started sweeping the headlines, there was a flood of media commentary insisting a modern Agile development approach could have avoided all of the project’s problems.  It was a simple analysis that made for good media, but it contained little truth.

Once the meeting notes for the project were released, it was obvious the development teams were using some Agile practices.  This led to “Agile” backlash.  Agile was seen by some as the cause of the problems with the website. Many were quick to dismiss Agile.  They saw the failed launch as proof Agile was an overhyped fad. 

In reality neither view is entirely correct.   Agile is not a magic bullet that guarantees project success.  Likewise, Agile isn’t a fad.  We can’t be certain how effective the team implemented Agile.  At its core, Agile is a loose set of principles which are to be interpreted on a philosophical level.  It was never intended to be a formula that when strictly applied would guarantee success, and therefore it should not be directly implicated in the project failure. 

For those unfamiliar with the concept of “Agile” development: it is a loose framework of principles which guide the development process and encourage an evolutionary approach to software development.   There are online resources to explain the methodology, but the Agile approach values effective communication, frequent feedback, and flexibility.  The goal is to produce working software that provides value.  When successfully applied, Agile helps ensure on-time software delivery that meets your needs with no surprises and no disappointments.  If Agile sounds familiar, you might be its history in the success of Toyota Product Development System and the boom of Lean manufacturing.

Key Learning:

Beware of “Agile” buzzwords.  When looking for a software provider don’t fall victim to “Agile”  marketing.  Agile is effective, but only if the team fully understands and implements the core principles behind the development philosophy.  They must be able to effectively apply it to realize its benefits.  Ask the team how it uses Agile.

Agile behaviors like frequent communication, upfront design approvals, feedback/review sessions, and a real focus on providing the customer value are where you benefit.  When a development team effectively applies the Agile philosophy, you can rely on a proven (but not guaranteed) track record of success.

 Lesson Learned: Right-size Your Project

Put simply, one of the most glaring difficulties faced by the development team was the sheer size of the website project.  It’s a fact – larger projects have more potential failure points.  As the number of interdependent tasks in a project increase, the risk of failure increases exponentially.  A few small setbacks cascade throughout the project and have a major impact on success.   A recent Gartner survey found that projects with budgets over $1 million were 50% more likely to fail than projects with budgets less than $350,000.  Creating software on the scale of the healthcare.gov website requires bulletproof development processes and a cohesive development team.  

One strategy for minimizing the pitfalls of project failure is to break a large project into the smallest possible units.  This allows for isolated testing which makes troubleshooting much easier when integrating smaller project pieces into a larger system.  This also provides the project team the opportunity to review individual units of the project with a customer.  This ensures each piece meets expectations, even though the overall project may not be complete.  Especially in large projects, frequent review/feedback sessions are critical to ensure the work being done is focused on value for the customer.

Had the project team split the project into smaller units and implemented a phased implementation or roll-out, they would have likely avoided some of the problems.  The team would have the time and been better equipped to handle issues as they came up.  They could have found solutions before the problems impacted overall project success. 

A phased roll-out would have also mitigated many of the problems.  The team would have identified challenges early, and could have adjusted the schedule as needed.  Having a working site with limited functionality is preferable to a site that doesn’t work.

Project coordination presents another problem for large projects.  Projects the size of the healthcare.gov website requires large development, implementation, and support teams, adding to the project chaos.  All teams must work as a cohesive unit, and require effective communication to maintain a positive group dynamic.  

A large team that maintains a close working relationship can find success and reduce the amount of size-induced overhead, but it’s not easy.  A large, fragmented team must overcome self-induced obstacles to achieve success, often creating more problems than they solve. For example, In-group bias, a socio-psychological phenomenon, often occurs in large projects involving contractors such as healthcare.gov website team.  Members of a group will view other groups as a threat, especially when competing for limited resources, leading to many dangers that result in project failure.  Groups shift blame for the failure to other groups.  More energy is spent shifting blame than solving problems, and the project ultimately fails.  Software which performs poorly is often a reflection of the flaws in the team who created it. 

Key Learning:

In project management, bigger may not be better given the unavoidable overhead that comes from a large team.  Despite this, many companies fear working with smaller software providers, even though smaller software companies are often more accessible and communicative, deliver more successful projects and provide the customer a better overall experience.

When evaluating the chance of success, do not rely on the size of the team or the number of promises they make.  Rather than making a big splash with a massive project, look at adding value in stages.  Focus on the key drivers for the project, and plan a phased roll out or implementation.  Implementing the entire project at once adds complexity and cost.

 Lesson Learned: Start with a Solid Foundation

Many times, key stages of the development process are the first victims as a large project begins to fail.  When schedules are delayed and deadlines approach, thorough testing is often sacrificed.  These projects fail to allocate adequate time for testing upfront, and then cannibalize testing time and resources to get a product (even a faulty product) out the door.  This was clearly the case with healthcare.gov project team.  Last minute specs, tight schedules, and poorly integrated development teams all lead to a disastrous “no time to test” scenario and a product lacking functionality when it was released. 
 
With any development project, it’s important to devote the proper time and resources for testing.  For some projects, this might be as much as 40% of the project time.  In the past, testing was seen as a second rate member of the development process, easily forgotten or ignored.  While modern development practices such as Agile and test driven development make a commitment to testing, it still requires time and resources. 
 
Given the exponentially increasing cost of design, development, and testing, especially in a larger and more expensive project such as the healthcare.gov website, it makes sense to explore strategies which mitigate costs without sacrificing core functionality or stability.  One such strategy is to use an off-the-shelf system which can be configured to your needs.
 
It’s hard to imagine an off-the-shelf solution offering the functionality of a custom-made solution designed specifically for your processes, but consider how many components are common across any software application; user management, external system integration, security, and more.  It makes sense to start with a foundation that has been thoroughly tested and developed, and then let the development team focus on adding value, rather than the base foundation of the system.  More time, focus, and resources can be spent on the features you need, minimizing the custom areas of the program that increase the complexity, cost and potential for failure. 

 Key Learning:

Healthcare.gov was a project that tried to tackle more than was necessary.  Does it really make sense to pay for a development team to start from scratch, when you can use a system that offers some or all of the core functionality you need? Start with an off-the-shelf system flexible enough to be configured to meet your needs.  This provides you with a system that’s been thoroughly tested.  It delivers the most value and allows you to leverage all the existing work the provider has put into their system.  In most cases, this leads to faster, less expensive, and more stable software – offering value that’s hard to beat.

Conclusion

There wasn’t a single problem that doomed the healthcare.gov project to launch over-budget or lacking functionality, or a single solution that would have ensured its success, but a few decisions early in the planning process would have eliminated many of the problems.

Keep those lessons in mind as you plan your next manufacturing IT project.  As always, let us know if you have questions or comments.  We’re always happy to answer questions.