Our site keeps going down. How do I find out why?
It depends on tracing each outage back to its cause, not on fixing the latest one. A site that keeps going down usually has a process problem, a technology problem or an ownership problem behind it, and from the inside it is very hard to tell which. An outside look at the people, the code and the infrastructure finds the cause and ranks it by the damage it does.
Evidence
The best-known site that kept failing is Healthcare.gov. I wrote about what turned it around in Saving a Bureaucratic Software Project, drawing on The Atlantic's account of the small team that rescued it.
The cause was not a shortage of people. The government ran the build as a bureaucratic process: one central waterfall schedule, with project managers managing project managers, and the whole thing broke. Adding more people would not have helped. Brooks' law says that adding manpower to a late software project makes it later.
What worked was a small, empowered team working like a startup inside the government. According to the reporting the post cites, it replaced contractor-made apps with ones costing one-fiftieth of the price. The fix was a change in how the work was run and who owned it, which no amount of patching the old system would have found.
The Software Project Audit is how I look for that kind of cause in your project. I interview everyone from the sponsor to the newest developer, look at the code and the infrastructure, and trace each complaint back to its actual cause. You get a written report that ranks the problems by damage, explains the root cause of each, and lays out fixes detailed enough for your team to act on without me.
What it takes
Access to the people. The sponsor, the developers and whoever gets the call when the site goes down, each with time for an interview.
Access to the code and the infrastructure. The repository, the hosting and deployment setup, and whatever monitoring and logs you have, even if they are thin.
A willingness to change how the team works. Most fixes are process fixes, and a report nobody acts on keeps nothing up.
The honest limits: an audit finds the cause and says what to fix, but it does not fix it. Your team does that, or a Fractional CTO engagement does. And if you want a report that confirms what you have already decided, this is not it.
Next step
Tell me what went down and when. The Software Project Audit is a fixed-price investigation that finds why your site keeps failing and tells you plainly what to fix first.