Why do IT suppliers write better software for themselves than their government customers?

I blogged back last month about research from software testing firm. The research, known as the appmarq report,  that in the UK government applications were the least changeable of all UK sectors.

The less changeable the software  the more expensive and costly it is to replace.

Funny thing is the IT consultancy sector had the most changeable software in the study. And even funnier is the fact that 75% of government applications are developed by suppliers.
So IT consultancies are giving the government less changeable software than they use themselves.

Is this to tie customers in?

The appmarq report carried out analysis of 288 applications at 75 organisations across the UK.

The findings put into perspective the challenge facing the government’s cost cutting plans. New suppliers will need to change systems to support cost cutting.

The report also revealed the most expensive programming languages to fix.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

It really isn't that surprising. Most of computer's task can be taken care of using Linux but the business industry has yet to embrace it as a standard. So it comes down to that your customers are use to using a piece of software and adding radical changes will only confuse them.

Government customers pay money for the software that is developed. When money is involved, politics become involved as everyone wants to control the money. Participants in an IT project will then try to use various means to gain control of the project or be a middleman causing gridlock and ultimately reducing the quality and quantity of capabilities delivered. Further project managers only allow the bare minimum software necessary for the contract to pay rather than the minimum necessary to realistically deploy the software successfully.

Internal projects don't have revenue associated so IT staff working on it are free to innovate and consider quality.


I think the main difference is that internal IT projects have much greater access to the end user than projects for an external customer. A project for an external customer (especially a government project) tends to have a fixed deadline and a fixed cost. However, as with all software projects, the scope varies. Vendors skimp on quality in an effort to deliver greater functionality within the same time/budget constraints.

In an internal application, the scope can be negotiated down to meet cost and time constraints much more easily than in an external contract scenario.

Government projects tend to be the ones where the client often refuses to make their mind up what they want (usually because they can't be bothered to figure it out or are afraid of revealing that they don't know what they're doing), sometimes not until after the supplier has already implemented what they asked for. I've seen at least one public sector project that went through the entire analysis/design/development cycle twice and the government client still wasn't sure what they really wanted. Suppliers know this through bitter experience, so they try to tie the client down through contracts that will heavily penalise late changes.

Meanwhile, government customers also tend towards the "dumb as a bag of hammers" end of the spectrum of commercial acumen, and will often sign pretty much any contract put in front of them by their "preferred suppliers", so these suppliers - with their friends in high places - can often charge whatever they like for whatever service level they like.

Government clients and their suppliers also tend to collude in the fantasy that they need some uniquely complex over-engineered solution to their business requirements, when they could probably solve a lot of problems with an off the shelf product and some sensible revisions to their business practices. Complexity breeds errors, so of course there is greater demand for changes when they get it all wrong i.e. suppliers can charge lots of money for an over-engineered initial solution, then lots more money for all those lovely change requests. Ker-ching.

Overall it's a recipe for exploitation and chaos, which is pretty much what you get on most public sector IT projects with major consultancy involvement.