Less is more...

... at least when it comes to controlling.

This is a typical scenario, I have been in, numerous times; we have an organisation wherein project managers execute a number of technical projects. There is a need for financial controlling on these projects. Normally either the finance organisation or the project owner(s) wants some sort of budget control, an overivew of the progress on the portfolio of projects or an early warning system with regards to schedule and cost (or NPV) on the projects.

Actually, when it comes to management, they typically want all three and whatever else you can deliver.

To be able to deliver these things, and indeed to do any degree of actual controlling, there is a need for data. A lot of this will already be available in forms of reports from the ERP system, in the form of varying reports to give economic data on the project. My experience is, however, that all of these numbers needs to held up against something more to be able to go in depth with the controlling. Some sort of reporting is needed from the project managers. Since the heartbeat of most major organisations, and companies, is timed along monthly reportings, it has proved a good idea to ask the project managers to deliver a monthly reporting as well on some parameters that aren't in the ERP system.

I have always found that the 'hard' numbers (how much is spent, what is the budget, start date and for more well developed projects, what WBS' has been started and finished) is best delivered from the ERP system. Normally it is available there, and if it isn't I feel it should be implemented there. There is no reason to ask the project manager to give this information, when it canjust as easily be found elsewhere. They should only deliver the 'soft' numbers (percentage of completion, forecast etc.)

The reason for this is tied very closely with the title of the article... Less is more. I have learned that the less information we ask the project managers to deliver in a monthly reporting, the more serious and precise the data delivered will be. There is a tendency, especially amongst technical organisations, to feel apathic towards reporting on project status. The complaints I normally hear is that it is an unecessary task, that takes essential time away from the project, or that the project managers cannot see how a monthly reporting contributes in any way to finishing the project.

Some of these questions, or indeed all of them, can be answered simply by sharing information with the project managers. I have found it vitally important to tell the project organisation why there is a need for reporting in the first place, and to give some degree of information on why you need the reporting. Firstly it helps them understand that it is not needless bureaucracy, but also it forces the controller (myself in this case) to think about why the information is actually important. I have often found that if you ask for too much information, not only will you end up with a lower over-all quality of reporting, but you will also loose focus of the key indicators for a project. You should try to listen to the feedback the project managers give you, perhaps you are asking for something you do not actually need.

I would argue that you should keep the numbers of indicators you control on, as limited as possible. You should sit down and think hard, and use your experience, to identify what it is you need to look at to get an indication of wether a project is on track or not. Then you should strive to keep the number of indicators as low as possible. Typically I try to keep the numbers as low as four to five indicators per project (or for larger projects, per WBS at workpack level).

At my last workplace, controlling a portfolio of CAPEX projects on an offshore installation, I asked the project managers to deliver the following information monthly:

• Anticipated final cost
• Spending in the year (for use in the forecasts)
• Anticipated end date
• Percentage of completion overall
• Planned percentage of completion (as agreed with steering committee)

The idea with these indicators was not to have a total and complete overview of every single project on the portfolio. The idea was instead to have a simple list of indicators that, coupled with data from our ERP system, would be able to identify projects that was in danger of going off-track.

When such indications came, I could focus my attention on those projects, and try to find out if the indications were correct (and the project seemed to be slipping either on cost or schedule, for instance). Further I could go into dialouge with the project manager to help him asses if his estimates were correct. Lastly, I was able to present a monthly overview to the project owner where he could see the consequence on the total portfolio of projects, and decide the best course of action from there.

It is obvious to me, that indicators needed (and the excact number of them) vary from project type to project type, and indeed from organisation to organisation. Therefore I would love to see your comments on what you think might be needed, or indeed missing from the list.

In my next entry, I shall discuss my experience with coupling the soft data from project managers reporting, with the hard data from ERP systems.