Used to be that when I told people that my company writes custom software for businesses, they would say, “That’s nice,” and change the subject or ask me for a unique software quick fix. Now, thanks to HealthCare.Org’s highly publicized epic failures, people inundated with information about the dark side of software development think they understand exactly how custom software projects work. But be careful: thinking that all software projects are like healthcare.org is like assuming that all vegetables taste like spinach.
3 ways that HealthCare.gov was not a typical software project
1. Integration requirements were extremely complex.
Be realistic. How often does your business software need to include live integration with the IRS and Social Security Administration’s data? (Even Amazon and Wal-Mart don’t have to do that.)
Normally systems communicate through a “translator.” For example, system 1 wants to check the date a purchase order was paid in system 2. System 1 uses a secure path to send the question, “What date was PO ABC123 paid?” to a “translator” that sits outside system 1 and system 2. The translator validates the request and then securely asks system 2 for the date PO ABC123 was paid. System 2 returns the information to the translator, which then returns the information to system 1.
Even a simple system integration project is generally pretty complex, and the HealthCare.gov integration requirements were far from simple. On a scale of 1-10 where 10 is the most difficult, integrating operations, accounting, and sales systems is a 4 compared the HealthCare.org, which was a 10+.
2. A whole lot of people tried to use the site on Day 1.
How many e-commerce sites will have 50,000 concurrent users and 800,000 visitors per day? As a comparison, some suggest that a standard business website running on Amazon’s smallest and least expensive cloud (Elastic Computer Cloud (EC2)) will handle between 50 and 100 concurrent users.
Seldom do companies get this kind of traffic on the day the site launches. If your traffic builds gradually, you’ll need to do initial stress testing and closely monitor your site so you can make adjustments, if necessary, as the number of concurrent users increases.
If you anticipate this kind of traffic on your site from day 1 – way to go! Build time into your schedule and money into your budget for stress testing your system using tools that simulate realistic numbers of users.
3. There were more than 50 companies working on the project.
All successful software projects share a common feature: there’s clear communication among the stakeholders, subject matter experts, and technical team (developers, testers, etc.). For tiny software projects, the company owner and programmer may directly discuss requirements and review results. With qualified parties, these projects have a high probability of success because the person who will use the system is working directly with the programmer.
For typical business projects, there’s a project manager (PM) who is responsible for the communication, schedule, and delivery. The PM works directly with the stakeholders, subject matter experts, and technical team, and with experienced PM’s and developers, these projects are highly likely to deliver results that meet requirements on time and in budget.
With very large projects that have multiple project managers and a large technical team, one PM has to be responsible for the overall project; however, instead of working directly with the stakeholders, subject matter experts, and technical team, the PM is communicating with the other PM’s, who are in direct contact with their own teams.
Think about the old game of “telephone,” where one kid whispers something to another, and the second kid whispers what she heard to the next person, and then the third, fourth, etc. whisper to the next person. The more people, the more likely that by the time the words get back to the first person, they are completely different than what the first person said.
Now translate that to a team of 50+ companies working on a project. When the developers need to clarify requirements, they ask their technical team leader. The technical team leader asks her PM. The PM asks the subject matter expert if the question can be answered within their team; if not the PM goes to another company’s PM, who follows the channels to the person who has the answer. Then the communication goes back through the same chain, and by the time it gets to the developer, who knows what is said.
In the same way, communication has to go up the chain, from each company’s technical team through PM’s to the overall project PM, who has to translate all that into status of each deliverable.
When you think about it this way, it’s a miracle that anything actually worked!
How do you avoid this disaster? If it will take more than three companies to develop your software solution, look for ways to break the project into smaller, manageable pieces.
Next time – 2 things to avoid so you don’t repeat HealthCare.gov’s mistakes.