We are all intuitively aware of the risks that we face in projects. We know them only too well as often we are the ones who deal with them when they come to light.

As developers, we want to duck for cover when a new feature gets added as a great new idea and "we'll work out the details later".

As project managers, we get suspicious when a developer says "if we just upgrade to version x" it will be all fine.

As the project team, we want to run and hide when the Sales Manager tells the client "sure we can have it done in six weeks".

We talk about what we know is going to be a problem after the meeting, over coffee, at drinks after work. We know when a project is going to be problematic, when the timeframes are unreasonable, when the feature doesn't make sense.

We know this in our hearts. But what do we do about it? Most often, the answer is not enough. And that's not because we don't care or don't want to, it's because there's rarely a formal approach that we can use...