I'm sure that all of us, at some point in our lives, have personally and professionally been in circumstances where our experience has not prepared us for the situation we find ourselves in. Welcome to the world of the conceptual emergency.

Before Donald Rumsfeld's "unknown unknowns", back in 2001 some enlightened souls at BP asked the question about what you do when you are in a world which you cannot understand and cannot control. (NOW DOES THAT SOUND FAMILIAR?). They funded a two year project based in Scotland, home of the Enlightenment, called the International Futures Forum.

The output of that work was a pamphlet "Ten things to do in a Conceptual emergency". The IFF is still there and has now produced a second edition of the pamphlet authored by Graham Leicester and Maureen O’Hara. I have used the pamphlet and the associated card game since it came out in 2003 and have found it funny, awkward, inspiring and insightful.

The research that went into the pamphlet looked at the issue of what do you do when you don't know what to do. Maureen is a psychologist by background and they explored a range people in arts/politics business and all sorts of lives. You may wonder where this is going. Let me explain. My own view is that I have not experienced in my life time a period in which so many people in so many organisations and circumstances have simultaneously experienced the "conceptual emergency" and this on a global scale. The challenge that this creates is that it is extremely hard to take today's decisions with the future in mind.

My belief is that as IT professionals and as users and suppliers of technology that we could play a really significant role in the rebuilding process. My concern is that with all the other challenges that industry, government and society face, our voices can so easily be drowned out. The jargon of our industry and the solutions we build are not easily communicated to leaders in industry and government. My colleagues Carl Bate and Nigel Green wrote a book a while ago "Lost in Translation" which illustrates the challenge of bridging the gap between the language of business and the language of IT. It's a good read.

If I have a criticism of our industry, it is that we are very reactive and less often proactive in our dealings with the wider community. I oversimplify to make the point but we tend to want customers to tell us requirements so that we can respond with our engineered solutions. The problem is that it is difficult to state requirements when you don't understand what's possible and indeed when what's possible keeps changing. I have a rule, experience changes expectation. So often over my career I've seen systems which have "met the requirements" but left the users disappointed. What I would argue now is that many organisations now are sitting in conceptual emergencies and, beyond survival, really have limited time and energy to articulate "requirements" which we can translate into systems.

There have been great strides in tools, visualisation and agile methods to enhance the fuzzy upfront part of the requirements process, but my challenge, dear reader, now is to make a step change in the performance of our discipline. What can we do now so that we can play the part in rebuilding the economy and society that I believe we can? In conceptual emergencies, as Maureen points out, we can react pathologically in many ways or we can be creative and innovative. The latter I assure you is more fun. Brickbats and bouquets anyone?