Earned value in intermediate projects

Now that the basics for earned value in projects with simpler complexity is out of the way, I feel it is time to move on to the basics for projects that are not so straightforward. In the previous article we looked at projects, whose main concern was cost development, and how our anticipated final cost looked compared to the original budget.

This kind of view is effective for all types of projects, but some projects have additional aspects that needs to be addressed as well.

Consider for instance a project with a critical time component. It might be a project that needs to be finished before the competitors finish similar projects (such as the development of new cell phones) or before a given date (this could be the completion of a new production system that needs to be operational before Christmas sales). In both of these projects, time will be a a vastly important factor, and some times even more so than cost.

In this article I will look at ways to reflect this in the monitoring of the project, using the earned value method and combining it with a few other tools.

The first thing we need to clarify is that when we have scheduled all the work-packages for our projects (all the goals that needs to be met before we can say the project is completed), some of them cannot be started right away. Manufacturing cannot begin before the design is complete, for instance. As we plan out all the work-packs, it will quickly become apparent that there will be a dependency in our network of goals (or tasks). An example, for a project with 10 work-packs, could be depicted like this:

If we made the (unrealistic) assumption that the completion of each work-pack would take the same amount of time to complete, we can see that the minimum time needed to complete the project would be the road that requires the maximum consecutive work-packs to be completed. In this case it would be:

We call this our critical path. The reason for this is that if we encounter any delays along this path, then the entire project will be delayed. If we have delays on the other two paths then we wouldn't necessarily have to delay completing the project. So in a project where time is of the essence, the critical path becomes a vitally important factor to monitor as well.

This is something we should definitely observe when using earned value to monitor our project. There are different ways of doing this, depending on how elaborate the project set-up is, and what your preferences are. I prefer a simplistic one, where you weigh the value of all work-packs on the critical higher more than you would have if you hadn't looked at schedule as a critical factor. In the simpler projects we could, with a high degree of accuracy, use the budgeted cost of each work-pack as a key for distributing the earned value. In projects where schedule is critical, we would do the same initially. Then we would redistribute some value away from the work-packs not on the critical path, and place it on the work-packs on the critical path.

Furthermore I have found it to be a good idea to place a slight overemphasis on the work-packs that the highest amount of dependencies in the project; such as A and B, on which all following work-packs depend.

This added emphasis on work-packs with schedule-critical elements will ensure that if the project is neglecting these work-packs, then the project will fall behind the planned value (PV). This in turn, should raise a red flag with the controller.

It would also be a prudent measure for a controller to keep an eye on the current length of the critical path, as an added measure of control, to make sure that the schedule is not slipping.

The last issue I am going to touch upon, when using earned value in time-critical projects, is that you should always keep your eye out for the possibility that the critical path might change in the project. If we imagine a scenario where one of the work-packs not on the original critical path, suddenly experience an issue that delays is seriously, we might end up with a new critical path. In the example from before, if work-pack C suddenly tripled in time consumption, the new critical path would be A-B-C-D-I-J.

Though this does not happen often, I have seen it happen enough times to keep an eye out for it (such as last-minute changes to a long-lead item or a vendor delaying a delivery due to an external event).

If the critical path changes, you do not necessarily need to change the earned value assigned to the work-packs, but you should make sure that there is sufficient focus on the new critical path, and set up a routine for controlling that helps you identify further threats to the schedule along the new critical path.

To round it all up, I think the basis for using earned value properly in projects (and in project controlling) is to ensure that you have proper planning. This goes both for simple projects and more complex ones; if you don't have a proper work breakdown structure or list of activities, or you haven't spent enough time assigning the correct values to the work-packs, then your controlling will suffer.

Earned value in simpler projects

After having written about the fundamentals of work breakdown structures, I will finally get to earned value (hooray!). Since there is quite a lot to cover, I won't waste precious words on too much of an introduction. I will instead jump into a short review of what the purpose of earned value (EV) is.

Earned value is, at it's core, an expression of how far a given project has progressed. It is expressed either as a unit of value (such as total units to be produced) or in how much of the budget has been earned. To give a very simple example, consider a project that has a budget of USD 200.000. We have a percentage of completion (POC) of 40%. The earned value for the project will then be: USD 80.000.

In other words we have earned 80.000 out of the original budget of 200.000.

Now how is that useful?

Well if we look at the amount already spent, we might see that we have already spent USD 110.000. If that was the case, then we would have a clear indication that the project would exceed the budget. Conversely if we had only spent USD 60.000 to earn USD 80.000 we would be justified in expecting the project to go under budget.

If we didn't use earned value, we would simply see that the project had a budget of USD 200.000 and we had spent USD 110.000. We wouldn't be able to see if this was good or bad. If we had the percentage of completion we might have an intuitive feeling of how it went, but we wouldn't be able to quantify it.

Of the three factors in the equation (EV, budget and POC), EV is the result and the budget should be quite certain. The factor with the least degree of certainty is always the percentage of completion. I have often seen projects where the POC hasn't moved for half a years reporting, and then suddenly take a leap and double in a single month. This would mean that in all the reporting where the POC didn't move there was no progress on the project. This was not the case (luckily). So what was the problem?

The project manager didn't have a reliably, objective way to estimate the POC. Therefore the EV was of significant less use than it could have been (but still quite useful).

So the problem comes in estimating the POC. This is where I have found that a solid work breakdown structure (or at the very least a list of milestones) comes in handy.

If you assign 100% completion to level 0 (the project goal), and then break that up on level 1, splitting those 100% out on the different objectives (and then continue this process until you're all the way down to the bottom of the hierarchy), then you end up with a list of work packages that each have a percentage of completion attached to them. It may be as few as five different work packages or milestones, or it may be as many as 70-100. When each work pack has been completed, you have earned that much of the overall completion for the project. For simple projects, this could merely be equal to how much of the budget each work package represents, or it could be a number defined by the project manager before project start-up.

Obviously this works better with a larger number of work packages, since the progression will be a lot smoother. But even with fewer WBS' (or even just a list of activities) this can actually work quite well; the important thing is just, that the fewer work packages or activities there are, the more important it is to get a secondary input from the project manager.

In a project with a 100 work packages, where each one had been assigned 1% completion (how lucky for us), then we would be fairly certain of the POC when 35 work packages had been completed.

Let us say we had five activities instead in the project and assigned each of them 20%. When the first two had been completed we would estimate that the project was 40% complete. The problem is that the POC would make 'jumps' of 20% with no numbers in between. We would then get the PM's input on this, and he would then, hopefully, estimate somewhere in the range of 35%-55%.

It is obvious that the controlling would be more precise, and therefore normally better, in the first example. But my definite experience is, that we would still be able to do a great deal of controlling in the second example as well. I have normally had the experience that the project managers ability to estimate the POC (coupled with a basic framework) is reasonably good.

The most basic way to add the value of a work package to the POC is to say that when it is completed, it's value is added to the total POC. But for larger work packages, that stretch over longer periods of time, it can often lead to a more precise POC if you add some of the value when the work package is begun. Different preferences prevail for different projects, and indeed for different controllers. I have often found a 40/60 split of the value of the workpack to be the best (i.e. 40% of the workpack value is added on start-up and the remaing 60% is added at completion of the workpack).This includes a reasonable progress when the work is started, but the completion still has almost two thirds of the value.

Finally I would like to go through a bit of the math for earned value controlling, especially in simpler projects.

EV = Earned Value

PV = Planned Value

AC = Actual Cost (sometimes ACWP = Actual Cos of Work Performed)

This indicates that the project is over budget already.

This gives an indication of the project is performing.

If is less than one, the project is below budget. If it is above one, there is an indication of budget overrun.

To express how much the current trend is compared to the budget simply multiply the budget on:

The same rules apply when comparing EV to PV:

This indicates that the project is behind schedule.

This gives an indication of the project is performing schedule-wise.

Finally:

There are, of course, a lot of other formulas for controlling based on earned value, but with simpler projects, I have found it best to keep the controlling relatively simple as well. Most importantly since you can get a very accurate picture with little work, but also because you should take care to avoid 'over-controlling' on a simple amount of input. You end up making conclusion, based on analysis that overinterpret. 

In my next article I will broach the subject of earned value for projects that have a slightly higher degree of complexity, and some of the tools you can use to deliver more detailed controlling on those.

A look into Work Breakdown Structures (WBS)

At the very end of my last article I promised that I would return to earned value in this article, but alas I must fall a bit short on that promise. After giving it a some thought I felt that the subject of earned value deserved more space than could reasonably be given within a single article. Why not make the article longer, the astute reader might wonder. The reason is that I have a self-imposed 1,000 word limit for my entries, since I am hard pressed to believe anyone can maintain interest beyond that. Even for a subject as interesting as financial- and project-controlling

Therefore I will use my next three articles to discuss earned value. This article will concern itself with what I feel is the basis for all proper project management; work breakdown structures (abbreviated as WBS).

All projects contain, at their very core, a number of tasks that needs to be executed, or goals that need to be achieved, for the project to be seen as a success. For simpler projects, it might be enough with a list of activities. For more complex projects, I have found them to benefit greatly from a hierarchy where the tasks need to be completed are broken down into small packages of work to be delivered. A fairly simple example (that could definitely be completed with merely a list of activities) is the creation of a new bicycle.

First we will list the overall outcome that is desired (level 0). Then we will list the results that needs to be reached to complete that output (level 1). The we break those results, or outputs, down into a new subset of goals (level 2). We will continue to break these down until they are as small as is reasonable. To give an example, it would look like this when expressed graphically:

If we look closer at the box called design, then we could break that down further like this:

This should, of course, be done for all activities on any given level, until we've reached a level where breaking them down any further wouldn't make sense¹. This should give you a hierarchy, or pyramid, with the goal of the project at the very top.

The advantages of doing it this way are straight forward; you get a way to track all the activities needed to complete the project, and an understanding of how they relate to the overall goal. Furthermore, I feel that any controlling done using earned value has no real value, unless based on a work breakdown structure or, at the very least, a list of activities.

There are a few important rules and reminders to take into account when using a hierarchy like this for a project. The first one is the “100% rule”; all of the project scope must be included in the structure. If it isn't then the breakdown structure will not give you a complete overview of the activities, and there is a very real danger, that these activities will not be follow-up upon.

The second rule is the “rule of mutually exclusive elements”. Behind this rather wordy rule is the simple idea that all the elements must have unique content, understood in the way that no task or activity may appear in more than one package in any given level of the hierarchy.

The third rule is more of a reminder than a rule per se. When defining the WBS, you should define goals or outcomes and not the actions needed to reach them. The WBS should serve as a structure and hierarchy for the goals you need to accomplish. If you define the tasks needed instead of the goals, you end up with a structure that needs to be amended and changed frequently, as new tasks needed to complete the projects pop up all the time. There is also a risk of forgetting some tasks all together.

The fourth rule is the “rule of bottom level input”. This should be understood in the way that you should always report at the WBS packages at the bottom level. No registration should occur at any level with a lower number than the bottom level. This is closely tied with the fifth rule (which is more of a guideline), “same level input”; you should always strive for the work packages (where input is to be given) to be at the same level. The reason I include this is that, even though it is strictly not necessary, I have found that people often report on other levels than the bottom, if it not the same for all work packages. Also when it comes to ERP systems, they often have even more problems keeping track of data and proper reporting, if it is not the same bottom level. One could easily imagine a project where the work needed to complete two different level 1 tasks would be of vastly different scope. This would mean that if the work packages at the bottom level should contain roughly the same amount of work (which is a good idea) then they would end up with a different bottom level. This can be solved easily with a structure like this:

As you can see the rightmost work package at the lowest level is exactly the same as the one above. There is nothing wrong with this, it is merely implemented as to have the same bottom level for all work packages.

Why a WBS is so important when it comes to earned value should, hopefully, be very obvious in my next article, which will be on earned value in projects with a low degree of complexity.

1There are different rules for when this has been reached. One that I have come across more than once is the ”80 hour rule”. A goal shouldn't be broken down further than units that would take roughly 80 hours to complete. I have found that it is normally fairly easy to see when it doesn't add any value to break down tasks any further.

The benefits of controlling

In my last article I went into some detail regarding controlling in simpler projects. Before I dive further in to the uses of earned value and work breakdown structures, which will become even more detailed, I felt I would touch upon a subject that was a bit broader.

Though I have never been confronted with the question directly, I have felt it looming a few times, especially in the mind of more technically minded project managers; why do we need controlling?

I am not talking about the mandatory financial and economical controls and functions, such as handling invoices, monthly reporting, doing the annual report etc. Rather I am thinking about the controlling of projects or activities. How does it add value to the business?

I have always perceived finance as a service provider. The interesting part is that it is a service provider for two very different recipients. One is the management, and the other is typically the executing organisation, such as a project organisation. Therefore, some of the controlling you are providing is directly for the benefit of the management, and some of the controlling is directly for the benefit of the project organisation (and indirectly for the management). Generally speaking, the justification for the existence of a controller is to have a person that has sufficient knowledge to look at the activities in the business, and put it in a financial context. Of course such areas as knowing which internal controls to implement, and to analyse the trends are also vital parts of being a controller.

Getting back to the question at hand, the first part of the controlling function, servicing the management, is the most straight-forward to justify. Through his, or her, expertise, the controller enables the management to have a reliable overview of the portfolio of activities, and hopefully to provide early warning if something is deviating significantly from expectations. These two functions are vital for the management of any company with more than just a handful of employees, and for the same reason, management normally has a fair understanding of the need for controlling.

Even though I do not feel the same understanding from the executing organisation, who often express exasperation over the need to deliver reporting and answer questions from the financial organisation, I feel that there are just as many benefits for them to be reaped as there are for the management.

The most simple example I can think of, is merely the act of delivering feedback, and helping the organisation to reiterate in case of inconsistencies. An example of the effect of this is readily at hand. At one time I served as the facilitator for the budget process where a portfolio owner invited the technical organisation to a full day workshop to brainstorm new ideas and rate these ideas on importance vs. risk.

The ideas generated were placed in a matrix by the project managers with risk on x-axis and importance on the y-axis. As was to be expected, an over-abundance of the ideas were rated as low risk and high importance. After taking a 15 minute break, the portfolio owner and I discussed all the rated ideas with the assembled staff, merely helping them to understand their ideas in relation to the other ideas and the existing infrastructure. The before and after of the process can be seen by the two pictures below:

As can quite clearly be seen, there was a definite progression from categorising almost everything as low risk projects to accepting that some of the projects were actually associated with considerable risks.

This not only helped in regards to being more cautious as to which projects to start, but also made sure that the project managers themselves were aware of the increased risk, and included a higher contingency in their initial budgets. This in turn led to a far smoother execution of the projects, since the projects were not under-budgeted.

Another example of benefits for the executing organisation include early warning indicators. If these are reported back to the project manager on a regular basis, they allow him to take corrective measures, or flag it to management earlier than would otherwise have been the case. This allows the project manager to keep his budget on track, and either deliver on the project goals, or to obtain sanctioning to deviate from the plan (either on cost, schedule or scope).

The examples of benefits continue on, such as increased overview of the project, helping the PM to clarify and communicate the weighing between schedule and budget, to identify scope creep and much much more. If you have any objections, or examples of where controlling has yielded a clear cut benefit in your organisation, you are more than welcome to share in the comments, since I love such stories.

In my next article I shall return to earned value, for an in-depth look at projects with low or medium complexity.

Controlling in an imperfect environment

The companies I have been in, have rarely had an organisation that followed the textbook rules for implementing projects. The larger the company, the more formal the project organisation, but even in an organisation that implemented projects with a budget of tens of millions of dollars, I have run into some fundamental challenges. This could be lack of a proper WBS structure, lack of detailed budgets or purely technical project managers, with little understanding of project management theories.

Whatever the reasons, the consequences are the same; the lessons from formalised economic education, and controlling theories, normally assume a more or less perfect world. When faced with the harsh realities, I have often had to find out how I could maximize my controlling within the existing organisational structures. Some changes can be implemented relatively easily, such as asking for monthly forecasts or having the PM deliver a monthly percentage of completion for the project. Other changes are require longer periods to implement, and often need to be anchored at a management level. This could be the inclusion of contingency in budgets, to deliver more detailed budgets, the use of weighted milestones or a WBS structure.

If we reach back and look at some of the input I mentioned in my articles on soft and hard data, I will list an overview of what I have typically found to be useful in even simple project organisations:

There is a lot of controlling to be done on the basis of these, but in the interest of sparing you from reading ten pages of calculations, and their merits in controlling, I will only show those that has most often yielded positive results.

If this is less than one, then it is an indication that the project is in danger of a budget overrun.

I typically do not raise this as a red flag before it reaches 0.85 in the earlier stages of the project (i.e. POC less than 50%).

If this is higher than one, it means that the project will have to spend more per month than it has previously done. Like all other indicators, this in itself is not a problem, but it should prompt further investigation, as it suggests that the project schedule is slipping. This is one of the most common inconsistencies I have seen in PM reporting; the schedule is slipping, but the project manager has an (unrealistic) expectation of being able to catch up, by working a bit harder. This a typical consequence of best-case planning, and definitely somewhere I focus a lot. Normally this will also be reflect if we look at the current year exclusively:

If we use the above formula as an indication of whether the forecast (and schedule) for the current year is slipping, I have normally found it as a good indication of whether the entire project faces the same problems.

Finally I would like to include two softer indicators, that have, none the less, proved quite useful for me:

1. If the anticipated end date is moved further into the future, then you should expect tan increase in the AFC. Maintaining a project organisation is associated with continuous cost, and open projects have a tendency to attract costs.
2. If the time remaining is less than 15% of total project duration, I would expect ETC to be less than 10% of the AFC. The reason for this is that projects typically follow an S-curve, and at the end of the curve the rise in accumulated costs is significantly slower than earlier in the project.

If any of the two indicators above 'trip', then I wouldn't raise it as a red flag, but more likely I would contact the PM and present him with my data, and see if there is an explanation for it.

If any of you have any experience with, or ideas on, implementing changes in an existing PM organisation or on other focus areas for controlling, I would be very interested in hearing about them.

My next article will be more generic, and in it I will try to discuss some of the general merits of controlling. I will, as per usual, put it in the context of experiences, in this case where there has been a clear (and positive) effect of controlling.

The harder the data

In my last entry I wrote about my experiences with PM reporting, and their subjective evaluations in a project (forecasts, anticipated end date, percentage of completion etc.). All of these reportings I considered 'soft' data, because they were subjective estimates made by the Project Manager.

In this entry I will focus on another type of data, which I shall, conveniently, think of as 'hard' data. These are data about the project that are objective, and will rarely be subject of discussion. These include, but are not limited to:

• Cost spent (ACWP)
• Project start-up date.
• Original budget (original baseline cost), including breakdown on activities.
• Latest approved budget (baseline cost)
• Current project phase
• Costs committed, but not yet spent.

Other examples could be number of active WBS work-packs, number of total WBS work-packs, distribution of earned value on activities, percentage of projected budget released (with regards to funding).

From these costs alone, it is possible to control a lot with regards to the project, as long as it is coupled with historical data and a knowledge of typical project behaviour. In other words, knowledge of controlling. What I have typically found useful to look at, using purely hard data, are the following areas:

• Cost of completed activities compared to budget of the same activities.
• Phasing of the accumulated costs over time.
• Comparison to historical data.

I we look at the three bullets above, the first one should be the easiest to perform controlling on. It will give you a clear indication of whether or not the project has been able to keep it's budget so far. This will give you two very important indications, both of which are very straight-forward: most importantly, you can use the current development, compared to budget, to project how the project is going to progress, going forward. If it is under budget, then there's a good chance that it will continue to develop that way. If there is a budget overrun on completed activities, then this should definitely be a red flag when looking for early warnings of a total budget overrun¹.

The second indication is, that if the project is progressed significantly (for instance 50% of the budgeted costs have been spent), then it might be a good idea to include the current over- / underspending in the forecast, since it might be significant. For me a good rule of thumb has been that when the deviation equalled 10% of the total budget, I include it in my forecasts (or in my feedback to the project manager when asking him for the forecast, if he is responsible for preparing it).

The second bullet, the phasing of costs, I prefer to do graphically, with periods on the X-axis (typically months) and accumulated cost on the y-axis (in local currencies). This should, hopefully, give something that resembles the typical S-curve we would expect for projects. Some types of projects might not have this profile when it comes to spending, but then you should be able to do a comparison with similar projects that has either been executed in the past within the same organisation, or from similar projects done by others in the same type of business.

The last bullet seems obvious at first glance, but I have often found it hard to determine exactly what data to compare. Unless the company is selling turnkey projects within the same market, it is often hard to find projects that are easily comparable. I usually try to look for rules of thumb that applies to the projects overall, even if these may be very broad. To continue my extensive use of bullet point lists, here are some of the thumb-rules I have found useful:

• The ratio between cost spent on studies and cost spent on total project.
• Costs spent on documentation (as-built documentation for example) compared to budget size.
• The amount of costs (mainly man-hours) spent on project management.

The important point about the different methods of controlling using the hard data, is the amount of manual work that goes into controlling them. Comparing the completed activities with the budgeted costs should be a fairly simple task, once it is up and running (for instance if a work breakdown structure is used). This process should therefore be fairly automatic, and you should be able to quickly identify if there are any budget deviations that exceed your pre-set control limits (such as +/- 10%).

The second, the graphical depiction of the phased costs, is very quick to control, as long as it is used as a sanity check. If it shows something is wrong, it may take a while to determine what, if anything, is deviating, and if this is cause for any alarm.

Comparing to historical data is only something I would recommend doing if you have historical data that are easily comparable (1-to-1 projects, an easy way of finding out which costs relate to which phase etc.). It is all about finding the easiest way of doing the comparison, with minimal margins of error. For example; in practise I have found that comparing phases can be fairly simple from an 80/20 point-of-view. You simply look at the costs spent up until a decision gate was crossed, and treat all costs until that date as belonging to the same phase. This will, by it's very nature, not give you a 100% correct split, but I have found the uncertainty to be immaterial (from an empiric perspective).

My thoughts on controlling the 'hard' data is that it should be as automatic as possible, giving you a fast overview of which areas you should focus further on. It should, however, not take up half of your total time spent controlling projects. The main focus, and time spent, should be on comparing the information gained from the hard and the soft data. I will go into much greater detail in my next entry, which will be on exactly that topic.

1It is important to remember that an indication is not the same as a complete and final truth. There might be a perfectly valid reason for why these activities have gone over or under budget, but the remaining activities will not. An example could be that during the feasibility studies, a simpler, cheaper overall solution was identified, but it required extra cost be spent on studies to make sure it fulfilled the project success criteria.

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.

Mission statement

During the last couple of years I have often come across problems, that I feel are symptomatic; or to put it in other words, it is often the same problems I have come across, but in different situations. This has led me to believe that other people working with economy (especially within a project structure) face similar problems, or at least problems with common denominators.

With that in mind, I decided to share some of my thoughts. Partly because writing down my ideas and thoughts on a subject, is a good way to focus my thoughts, but mainly so that my experinces can serve as a basis for discussions with people also working with controlling.

Before I start this project, I feel the need to pen a mission statement or a purpose. This is something I feel any proper project should do (as you will propably find out in time, I have a good many feelings when it comes to proper project; and what they should and should not have). Since I am at the beginning of this project, I might as well be a bit lofty in the wording:

"With this blog, I shall aim to approach financial and project controlling from a practical point of view. Each entry will aim to be based on a situation taken directly from my own professional experience, or make heavy use of the same. In cases where this is not possible, the focus of the discussion shall always be a practical implication."

With my brand new mission statement being no more than a few lines old, I already feel it's time for some caveat's; some wiggle room if you will. I foresee a few cases where it will not be my own experience, but the experience as related to me by someone in my network, that I have deemed worthy to appear here. Without any special precognitive powers, I also forsee the occasional essay that will be a wildcard in the form of some topic or other that has occupied my mind to such a degree that I find it relevant to share here.

With my mission statement all penned out, I shall proceed swiftly to the essays. There is only one last thing I would ask of you, the reader. The content is presented for your viewing pleasure, and I hope you will find it usefull in one way or another. Should you have any comments or disagree, either mildly or vehemently ,please use the opportunity to comment on the essays. It is, after all, the best way for me to learn more, and for others to be made aware of your views.

Lastly, should you wish to reprint some of my advice, please procure my permission before doing so (I guarantee I am quite liberal with it, when it comes to such things).