So how did it get this way? How did $180 million disappear down a hole with only a horribly broken system coming out the other side? While I was not involved in this particular project I think I have a few ideas of what went wrong.
I think there are two culpable parties here, the government and the contractors. Let's examine what the government side is doing wrong.
Poor Focus
If you've ever dealt with gathering requirements the first thing that happens is absolutely everyone is consulted on what they want the system to do. So what happens is that a kitchen sink-full of requirements is drawn up. Every single person from the politician selling it to his constituents, to the higher level directors, to the lady with too many cats in HR is asked to throw in their advice. Funnily enough, end users are rarely consulted until the finished product arrives.Now it's not bad that extensive lists of requirements are being drawn up but sadly that's where things end. There is no prioritization or optimization. So absolutely crucial requirements like 'must protect vulnerable data' and 'must be customizable to official ministry colour schemes' are of equal weight. Countering this are the excessively detailed requirements like must use a 1024x768 display or must use technology 'X'. Is it impossible to know if these requirements are truly firm or if they exist solely as a reaction to getting burned in the past.
This is the first major pitfall, by making all requirements equally important it is incredibly difficult to properly discern what truly matters and what can be skipped. Where does the client derive value? What are their major risk factors? The end result is a hugely expensive, incredibly complicated system that doesn't properly address real concerns but does cover-off buzzwords in the contract spec.
Lack of planning
A big problem is the lack of planning. Not at the department level but at a higher up level. Often a project is stalled or delayed endlessly while waiting for a budget to appear. So a competent provider is found and a plan of work is created and then... nothing. The project languishes for months while waiting for a budget to appear. This is a major problem for smaller ISVs who don't have a diversified revenue stream and can't wait around.The US government has not passed a budget since 2009. 3 Years. Agencies are limping along on continuing resolution and are unable to make any long term plans. These agencies can't make long-term (ie, more than 4 months) commitments because they might be shutdown without warning.
Finally, most government agencies think the clock to begin development starts when they talk to the vendor not when the contract is signed. So ISVs are expected to bear the cost of speculative development in the hope that the agency will follow through. Needless to say this drives up the risk to almost unbearable levels for most small ISVs and drives all the business to large ISVs.
No Oversight
Perhaps the most important thing lacking is proper oversight. In the age of outsourcing governments are pushing larger and larger sections of work out to private business. While this is fine, enough talent must be retained internally to be able to competently evaluate and monitor the progress of the project. This person needs to be aware of the correct ways to keep tabs on software projects and determine actual progress of the development.Software development is usually quite different from other development projects and very few people outside of the industry have the proper knowledge. Common tools like Gantt charts and percentage done numbers are inappropriate measures but are expected to be used. Without oversight it is very easy for the ISV to extract unreasonable amounts of money from the government by dragging out contracts. Without a strong focus on the end goals projects can wander which is good for the ISV but not the client.
Even if the ISV isn't interested in milking the contract, internal forces can cause the project to wander. Shifting political goals and management by committee prevent solid objectives from forming. With shifting objectives it becomes incredibly easy for vast sums of money to be 'wasted' when goals are changed. Pretty soon the project is late, over-budget, and of poor quality.
In the end, governments reap what they sow when they play games with new software development. However, it would be wrong to lay the blame exclusively at the feet of government. Next time I will discuss how the ISVs screw up projects on their end.
Great article!
ReplyDeleteThe problems of poor focus, scope creep, inadequate planning, and weak controlling and oversight are common in many IT projects, but seem especially pronounced in government projects. Perhaps this is partly because government IT failures get more press, while failures in private companies usually go unreported?
But there is a fundamental difference of culture and mentality and responsibility between the public sector and the private sector. (I've never worked for the government but I've worked at private companies that work on government projects.) Market competition, the requirement for firms to stay solvent, and the profit motive are powerful incentives for productivity and results, and these forces are usually absent in the public sector. Budget overruns can put a private company out of business but government agencies can never be put out of business, no matter how bad things get.
Staff appointments and hiring decisions are often politically driven and sometimes key roles are held by people without the proper competence. Poor decision making by these people can then have costly consequences and leads to a "perpetual panic" project atmosphere. Experienced private-sector managers and workers are repelled by the thought of working in such a quagmire, and stay away from government jobs. So the very people who could save the system refuse to take part in it.
Outsourcing projects to private contractors in many cases seems to be a means of shifting blame and avoiding responsibility for project failures. But the private contractors often use exploitative means to drag out cost-plus contracts (especially in the defence sector) and in the end it's the taxpayer who loses out.
The problems are evident but the solutions are difficult. The public might feel that they can get revenge by throwing the politicians in charge out of office in the next election cycle. But putting a new face in charge at the top doesn't replace the people in the bureaucracy and it doesn't fix the fundamental system and the culture that are the cause of the problems.
I look forward to your next article!
I think it comes down to risk or rather the perception of risk. Managing the perception of risk looks a lot like managing risk but doesn't carry the same benefits. Take the problem of IE 6. Migrating to IE8/9 has measurable risks but so does staying at 6. If you're just managing the perception of risk then staying put has no risks. So you end up with cultures of buying millions in software licensing and support without considering that some point all systems are retired.
DeleteBoth private and public sector suffer from the same problem but the public sector has it worse. Having greater transparency sounds great but when all the perceived risks accrue directly to the decision maker and all the actual risks accrue to someone else it creates a really broken situation. Most people would not risk their job for no reward. Someone else can deal with the problem later.