Well, depending on who you believe, Healthcare.gov cost between $70 million and…let’s call it an even $100 quintillion-Simoleans (I think we can all agree that it’s definitely somewhere in there.)

In older news, IRS modernization projects cost somewhere from “hundreds of millions” to $4 billion. I haven’t built very many skyscrapers personally, of course, but that sounds like a pretty large amount of money to me.

Personally, from talking to executives of some local insurance companies I’m told a “mid-sized” legacy modernization project can cost $40-50 million over a number of years, and that’s just for their own company to use. These systems sometimes replace – I kid you not – scrolls. (I’m serious – some old insurance documents are on climate-controlled rolls of paper locked in tubes in the basement because they are updated infrequently but still active for that many years.)

A mid-sized company can easily have a development staff numbering in the thousands, and all are expected to work on inter-linking pieces of software – with relatively few working truly in isolation.

What happens when you screw stuff up?

Well, how about killing people? Is killing people bad? (Therac-25 killed people with radiation overdoses in the 1980’s). Knight Capital lost approximately $440 million in 45 minutes from a software problem – can you buy a sky-scraper for that much? Well, maybe a little one…

Rockets have blown up in mid-air, like the Ariane 5. Edward Snowden’s NSA leaks were made possible by problems in the implementation of security systems. Heck, the whole system of global surveillance that has made so many headlines (and probably not enough of them) is, in fact, probably a far larger software effort than any of these previously mentioned projects. Whether or not it counts as a screw-up shall be left to the opinion of the reader.

But honestly, getting into a skyscraper-measuring contest is rarely a productive way to spend one’s time. The fact remains that some software projects are big and need planning – sometimes more or less than was actually done – and other projects? Well, they aren’t so big, and so it isn’t always necessary to have a big waterfall-style requirements/planning phase.

As always, it’s not the size of the budget that counts…

One of the biggest influences in agile software design is actually the reason why software cost estimates are so hard to come by: reusable software.

The tricky thing about reusable software is that it tends to fit in an uncomfortable middle ground between “packaged, ready to go solutions” and “build from scratch.” It is not always obvious how to determine whether software can be reused or not. In fact, in many cases I have found that it is cheaper to actually go out and build the product than it is to get a reasonable error bound on how long it would take!

It would be ideal for us to build up a decent repertoire of packaged solutions, but the software world moves so mind numbingly fast compared to other worlds (such as civil engineering). Over time, we have found that the cost of packaging up a solution properly rarely pays for itself because the package becomes obsolete too fast.

So this leads to the interesting difference between civil and software engineering: software engineering’s influences are positive, while civil’s appear to be negative. We rarely have a large landscape of constraints to work with. We don’t have as many regulations or environmental limitations to consider. However, we have a mindblowing number of positive influences to consider. If a project fits well with a particular partially-packaged block of goodness from a previous project, I can cut serious time off. If it doesn’t fit, I have to build it from scratch.

I have actually given this estimate to my boss once: “the job will take somewhere between 1.5 days and 18 man-months.” He was not pleased, needless to say, but when I ran down my logic of why the variability was there, he was forced to agree. (The solution, by the way, was that we went agile: we spent the 1.5 days to try to do it the easy way. If we failed, we’d come back and discuss if it was worth our dollars to do it the hard way. In the end, the easy way worked).

There is a lot of opinion in the agile world that planning actually works against you. Requirements work both ways. It tells the contractor what to produce, but it also gives them a powerful piece of paper to say “this is all you told me to do, so I did it.” This double edged sword often forces customers to write requirements that prevent the 1.5 day solution. Even government contracts are transitioning away from big-up-front requirements planning because the benefits outweigh the rewards.

1. What are the costs figures of a big software construction project? Any published large scale well known projects documentation I can get numbers from?

There are a large number of projects that have various levels of publicly available information regarding project costs. The documentation is commonly available in the form of case studies. The project management institute has a library of case studies and many other similar documents are available via a web search for say “case studies in IT projects”.

2. What are a software project influences (besides the goal of the project itself)?

This is a broad question but focussing on cost the two largest impacts for cost over runs in my experience are:

1. Poor control over the scope of the project and,
2. Over optimistic self assessment of team members/sub contractors ability to estimate effort.

Good scope control is about establishing an agreed statement of work and, importantly, having a disciplined method for adjusting time tables and cost estimates when the client requests changes to the statement of work. The causes for the change requests are normally valid and will always carry a time and money cost.

Over optimistic self assessment is usually mitigated by utilising a PERT analysis where the cost estimate is based on the weighted average of three separate estimates being the optimistic, realistic and pessimistic.

With that there are other influences on the costs depending on the scale of the project which each have well established mitigation methods. Some of these include, in no particular order:

• inflation
• foreign exchange rates
• company failures (Arthur Anderson as example)
• reorganisations within the client company
• loss of key personal (resignation, reassignment, illness, death)
• low skilled team members
• ineffective cost control mechanisms
• poor product development techniques
• fraud