Most people in the business have been involved in several projects where the extreme happened, and was written off. "Who could have known X was going to quit?" "We told the client they couldn't change their DB schema, that would break everything!" "That team said they would take care of the testing, but now they've got a new project and haven't got anyone available." Each one of those situations could easily have taken an on-time, on-budget project and knocked it into the red. Similarly, there are unexpected events that come as a benefit - the release of a library that halves the complexity of a task, for example. These generally pass by as small benefits, as we rarely take full advantage of them.

We are unable to predict these events because we believe we know more than we really do. We believe we know what the customer wants when they send us the requirements, but we don't realise that the person sending them to us is not the person using the software. We believe we have allocated the best available staff, when in fact our lead developer is about to move to a hot startup down the road. We believe the client will act in their best interest, when in fact they're locked in fierce internal politics.

Our planning and estimation give us a better view on the scale and scope of a project, but they don't give us as good a view as we think. We assume that things will go pretty much as planned, and once we have seen an unusual event occur, we rationalise back to make it seem predictable (even though, given the information that we had at the time, it may fundamentally not have been). So, we might say that we could have seen hints of the lead developer leaving in his behaviour, or that our account manager could have read the client's mood more accurately.

So what's the result? For a company, the result of this situation would probably look like a history of decent projects, with a few notable problem-projects, which seemed to go wrong out of the blue, due to "bad luck". The company would probably instigate a series of remedies for particular problems, such as pairing less experienced team members with experienced leads, or building extra processes to try and catch common errors. However, they would still run into unusual and unpredicted events which caused projects to run late. While most projects would be profitable, these black swans would end up costing a large amount in extra work, and relationships both internally and externally, and cause other projects to fail in more traditional ways, through pulling resources and attention away from these otherwise healthy projects.

Building up resistance

The challenge, then, is trying to make our projects and organisations more resistant to these kinds of events, even if these events truly were unpredictable from our point of view. Taleb offered ten pieces of advice for a Black Swan robust world after the credit crunch, which we can repurpose, with some poetic license, to the world of web development:

1. Fail early. Smaller projects with clearer focus will still fail sometimes, but the pain will more localised, and hence less costly.


2. Don't spread the pain. If a project fails, fix it within that project, don't borrow resources from other projects in order to prop up a failing one.


3. If a failure isn't seen early enough, don't assume the same project tracking will work next time - change it.


4. Don't offer a bonus tied to a specific project result as it will discourage accounting for unusual events.


5. Balance complexity with simplicity. Don't build complex requirements on top of complex requirements, but try to keep the components of a system as simple as possible.


6. Don't give people the tools of their own destruction. A new team lead isn't necessarily going to be perfect straight off the bat, so ensure that initially they share responsibilities with more experienced staff.


7. Be transparent and simple in your project tracking and management, so people can see what's happening - problems are made worse because of panic.


8. Implement the best practices you can, and don't cut them because it slows the project if things go wrong.


9. Don't get too confident in any estimate or project plan - it's only an educated guess.


10. If a project is failing, break it down all the way, and see if it can be rebuilt into a successful one.

Thinking about projects this way might be slightly uncomfortable, but a healthy concern for the black swan can help make the unexpected just another part of doing business.