Previously, I’d posted about people and risk – and how we’re bad at judging it. The second part of the thoughts I’d had while driving to work was how risk applies to software development.

There are many sources of risk in a software project. There are lots of lists of the risks to software development and to some degree that isn’t very interesting – most experienced software engineers have already met those risks – and hence the popularity of things like The Daily WTF. I suppose I should have my own though – I’ll try to keep it short.

1. Failure of sales
2. Failure of specification
3. Failure of technology
4. Failure of personnel
5. Failure of management

Yup. That’s right – I believe that salesmen can cause software projects to fail. It doesn’t matter how objectively good your software is, if it doesn’t meet the client’s expectations, well, you’ve failed. And your sales team are the first point of contact for those expectations. Sure, you’re going to have management draw up a project plan, and development draw up a specification, but it’s the sales team who make that first impression, who sell the customer on the vision and the idea.

Customers invariably have a wish list of features for their software. Often, a lot of items are either practically impossible, or difficult enough to be too expensive. If you just say ‘Yes, we can do that’ to each item with considering that cost, well, the customer will end up disappointed. Aye, but here’s the rub – your competition will probably be saying yes to everything too. That’s why the best customers have realistic expectations of what they want, and of the features they need – and the best software is the stuff that just does what it says on the box.

Failure of specification is, in my opinion, the most common risk. And it can fail in a lot of ways – simply being omitted being one of them. It’s fascinating how the second thing people want to ditch to reduce the price of software development is the definition of what it is you want to develop! (The first thing to be ditched, typically, is testing). The games then begin as the development team builds their interpretation of the solution, while the customer is expecting something else. You’ve just missed expectations again.

I suppose that actually this is really a failure in communication of the purpose and operation of the software between client and developers. And that can happen at both ends. Even if you do write a set of requirements and draw up a specification, well, both client and developers can can miss items, ignore the documents, etc., but it is fascinating how often often specification and testing time is drastically cut.

Anyway, carrying on with the list – technology failure can happen, but is unusual. Usually, it’s only really new technologies that have all sorts of unknown, ahem, features that can cause it to fail. Normally, the quirks of different products just add to the development time, which adds cost, but if you know what you’re dealing with, you can factor that in.

Failure of personnel – well, I’ve been luck enough to not really come across this, but there are definitely those who can code, analyse or manage, and those who can’t. With all these things (especially the coding) there seems to be fairly little by way of middle ground. Anyway, this is sort of a ‘meta-failure’ – it’s not really at a project level.

Finally, failure of management. Projects need managed, and yet curiously, sometimes the expenditure on this can be ditched too. We have had customers who refused to pay for a project manager at our end; this is usually a disaster. The only occasions that it’s not been, the customer has already had their own project manager who was experienced in managing software development projects. Typically, though, it ends up with some arbitrary middle manager taking on the role, and the truth is, they lack the experience to make it work (and so don’t appreciate the risks and costs of their decisions), and you end up with a communications gap between your manager and development team (‘cos they don’t really speak the same language).

So, those are the risks, how does that relate to how people perceive the risks?

Well, from my experience, development time seems to be treated as a fixed amount, and a necessary thing. Sure, it can get squeezed sometimes, but usually if your expert is telling you something will take a week to build, you don’t turn round and tell him it’ll take 3 days. Well, okay, that does happen, but not normally. However, development time might not be as inflexible as it is treated. For some applications, you can cut development time by cutting features. It’s usually best to plan for this contingency from the start, though.

Instead, things like management, specification and testing are treated more as ‘overheads’ and cut drastically. Personally, I think that testing (dull as it is) should typically take up as much time as development. Specification could well be longer. But customers perceive themselves as having ‘obvious’ requirements which have been ‘clearly’ communicated, so there can’t be any harm in not bothering with that specification (and, very, very occasionally, that might be true). Similarly, developers feel that they know what they’re doing, that they’re testing as they go along, so surely that testing phase is a bit irrelevant. And lastly, well, you have a development process, so everyone knows what they need to be doing – so you don’t need management, right?

So much for measure twice, cut once. More like the opposite, really.

My degree gave me IEE accreditation, and I used to get their magazine. Most of it was pretty irrelevant (I have a knack for killing electronic things, so didn’t want that as a career), but I remember an article “40 Reasons why projects fail”. I reckoned that over half were to do with specifications. A quarter were about management. A handful were about other factors, such as internal politics in the customer. It really struck me, not least as I’d seen about 30 of those things in the last year in ourselves, our customers, our suppliers.

So, the short of the conclusion – specification makes sure you know what you’re building – don’t skimp on it. Testing makes sure that you’ve built what you wanted to – don’t skimp on it. Management makes sure that the building part actually happens in the correct way – don’t skimp on it. If budgets won’t stretch far enough, cut back on the features of the system. If you can’t do that, well, reconsider the wisdom of the whole thing.