Donald Rumsfeld, the US Defence Secretary is famous for, amongst other things, the creation of the idea of "unknown unknowns". This was the way he split unknown items into those things that would not surprise them if they existed (known unknowns), and those things which could, if they exist at all, appear out of the blue.

Confused? You are not alone. But the concept of "unknown unknowns" is also a common problem in the property world whenever there is a discussion about IT strategy.

Most of us consider that we can create a strategy for key business functions because we know what we want to achieve and we have a good idea of what barriers there will be. However, when faced with a vast and complex subject like IT, many property people are daunted by the fact that they may create a strategy without considering complications of which they are unaware - and they know enough to realise that neglecting even one aspect of their IT strategy may result in its failure.

However, the truth of the situation is often less problematic than it seems. The secret is to start in the right place: that is, the business need for IT, not with the "unknown unknowns". If we can define what is known, we can then reduce the size of the unknowns to a level that can be managed.

We need to start by prioritising the parts of the business which will have the greatest effect on improving profit or reducing costs. This may be obvious from the corporate business plan and if it is not, this focus will help the whole business improve, not just the IT function.

It is insufficient for the business at this stage to simply say "provide us with flexibility". This may be a part of the requirement but here we need precise business needs; for example, will the potential for REITs change the way we report and communicate financial results? Alternatively, will our proposed outsourcing of property management have an impact on the need for internal systems and how we access data?

Only when we have a prioritised list of activities within the business can we develop an idea of how these activities might improve through enhanced IT support. This will provide our first phase of planning and will guide the IT team in developing their strategy.

In theory, developing the strategy itself is quite straightforward: define the current situation, develop an idea of where we want to get to and plot a route around the barriers and constraints in the way.

In practice, there are many complexities which will constrain us. For example, the baggage inherited from years of previous IT support will prevent us from building a clean new solution and current contracts will be intertwined with service levels which must be maintained. Furthermore, we may need to bring the IT support up to a reasonable standard before proceeding further.

However, we now have a clear set of targets which are defined by the business and, although there will be many ways of achieving those targets, the constraints of our current IT structure will limit our options to the point where we can make a small number of reasonable assumptions and proceed with our planning.

Longer term infrastructure plans can be laid out more clearly because the business has set the agenda. Timescales for change and improvement can be agreed around business requirements and these can be checked against software or hardware upgrade needs. Through this process it will also become clearer where the major costs will be incurred and these will be fed back to the business through longer term budgeting.

Above all, focus on the business needs will drive the process. At this stage we are setting a strategic direction, not defining all the detail - don't worry that some unknowns remain unknown. In the words of General George S Patton, "A good plan violently executed now is better than a perfect plan next week."

I am sure that Mr Rumsfeld would approve of that sentiment.

By Andrew Waller. A version of this article was first published in Property Systems Review - 16 December 2005
Andrew Waller is a Partner of Remit Consulting LLP:

 
Copyright Remitconsulting © 2004     Disclaimer     Top of Page