Tuesday, 5 April 2011

Give feedback early – give feedback often

One of the themes I have touched upon often in this blog, despite the small number of articles, is the distinction between hard data and soft data. Hard data is the objective data, such as actual costs, project start date and original budget. Soft data takes the form of more or less subjective input from the project manager.
As I briefly discussed, sometimes the data does not have the quality you wish, either because the PM has not understood the request the way you meant it, or because it is erroneous.
My experiences are unanimous in these cases; the quality of the data does not magically improve as time goes by. For there to be an improvement in the data, you (as the receiver) needs to give feedback to the person that delivers the data (or organisation, if it is a general problem).

I have generally observed that the sooner you give the feedback, the easier it is to change the behaviour. One example I have of this is of a budget process, where all generated ideas for new improvement to an offshore installation (delivered by a technical organisation) were reviewed shorty after delivery by a trained project engineer and an experienced construction supervisor. Their inputs were given as feedback to the technical organisation, which was then able to respond to it and change their behaviour for future inputs.

Another example is from the budget process as well. In my article on the benefits of controlling (aptly named 'The benefits of controlling'), I presented two pictures showing the dramatic effect of reviewing the data the technical organisation had just given. To recap briefly, the result of the review was as follows:




As can be seen, there was a clear migration of projects moving further along the horizontal axis (increasing in estimated risk), after the review.
If we look at the before and after from the next workshop, for the following year, it looked like this:




You can see that there was some progression in the evaluation of the estimated risk, but it was substantially less than the year before.

For me that was one of the most notable successes in changing the behaviour of the technical organisation (and increasing the value of their input). I think the reason for the success lies in a few simple facts.

  1. We gave the input when the process was still fresh in the minds of the people involved.
  2. It was transparent to those who gave the input what we wanted them to change, and finally,
  3. The feedback was consistent and constructive.

If I think of an example, within the exact same organisation, where I didn't achieve anywhere near the same degree of success, one comes readily to mind; the monthly reporting of percentage of completion on smaller projects. The numbers often had little consistency with other project data, or indeed previously reported POC's.

If I look at back at why this might be the case, I can see a clear pattern in what was done (and that it was wrong):

  1. There was no specified definition on what the POC should resemble.
  2. Feedback on the POC was given inconsistently (only in cases where it was failed even the simplest of sanity-checks).
  3. Feedback was not given in a constructive way.

If I were to achieve a higher level of quality in the reported percentages of completion, I should have devoted a lot more time to giving the feedback. I should have set up a more nuanced degree of controlling on the POC's (for these small projects). This would have allowed me to be specific and consistent when giving feedback.
I should also have spent the time discussing what percentage of completion actually meant, and what we used it for, with the project managers . This could have been coupled with a suggestion for some objective tools to aid in the evaluation of how far the project had progressed.

For me that is definitely something I have taken with me as a lesson, and therefore something I will try to be mindful of in the future.

So far I have only talked about giving feedback where something is lacking, but there is another equally important side of feedback; the positive feedback. Whenever an organisation is delivering exactly what you want of them, or when they are improving after you have presented them with criticism, my experience is that you should always remember to give that feedback as well. Let them know that a good job is being done. If appropriate the project owners and relevant line managers should also be made aware of this.
This will help the project managers know that they are on the right track, and also help them see that their efforts are recognized1.

The last issue I will touch upon here is the form of the feedback. I have found this to be perhaps the single most important factor in reaching your intended target. The theories on how to communicate in the best possible way are many and varied, and I don't have the background to deliver anything in-depth. I think the most important thing to remember is to be aware of the fact that how you communicate your feedback matters a great deal.
As long as I keep that single fact in mind, it seems to go a lot better for me. Here are a few of my experiences on how to deliver critical feedback:

  1. Be specific. Point out the exact thing that you would like changed (or base your general feedback on as specific an example as possible), and explain the reason for it.
  2. Always mention something that was positive as well, when giving your criticism. It may sound trite, but it let's the recipient know that not everything was bad.
  3. Listen to their reactions to your feedback. Maybe you can adjust your wishes, and still have the desired result.

The advice might sound obvious, but it's is surprising how often you forget them if you don't actively keep them in focus.

To sum it all up, the lessons that have served me best are that feedback should be given as often as needed, it should be both positive and negative. You should always remember the form in which you give it, and lastly it is not about making the receiver admit they did something wrong, or having it your way by all means; it's about finding a solution that satisfies everyone.

In my next article, I will discuss a paradox I have come across often in projects. The sooner you act, the greater the result of your changes. The longer you wait to act, the more informed your decision will be.

1Besides, it builds goodwill towards you, the controller. If nothing else, then trust me on this; that alone is reason enough. Having goodwill saved up is very handy when asking them to deliver a whole new dimension of reporting.

Friday, 1 April 2011

Budgets; a controllers point of view.

In the last couple of articles I have covered earned value and work breakdown structures. In my discussions about earned value I have talked about the need to have a budget on work-pack level and I have stated this as if it was self-explanatory. As anyone who has done any work with budgets knows (either from making them, or from controlling them) there are as many ways to do budgets as there are people. While I don't believe there is a single right way of making budgets, there are a number of wrong ways to do it.

In this article I will discuss some of the key elements I think are needed to make a good budget, and how they can be achieved from the controllers point of view.

First off I will start by looking at what a budget is; it is, simply put, a plan for how the economy (or the schedule) of the project should progress. Therefore the plan should be detailed enough for us to follow-up on during the project. A budget with only a total cost on it is as useful as a planned route with only the destination. A good budget will include the expected cost for the activities, broken down to the same level as the goals are (which should be work-pack level, but no further). This will allow the controller to follow-up on cost development for each activity and hopefully detect deviations much sooner.
If we return to the 'planned route' metaphor, we can easily imagine the difference between the two types of planning. The first kind, with only and end destination doesn't allow you to see if you took a wrong turn along the route. Either you get to your goal or you don't. If you planned the route out in smaller steps, you would find out much sooner if you deviated from the planned route, and you would be able to pin-point where on the route the deviation occurred.

So a budget should be sufficiently detailed to allow you to follow-up on the planned activities separately during the project. I also stated that the project shouldn't be more detailed than what you plan to follow-up on. The reason for this should be quite straightforward; there is no value in spending your time over-planning the activities, and certainly not if the planning isn't used for anything afterwards. Project managers tend to look unkindly on controllers who asked for detailed planning and then just threw it away afterwards.

Now that we have covered a bit about what a budget is, and the level of detail that should go into the budget, it's time to cover how this can be done. In some companies, the project organisation is extremely competent at making budgets and execute the discipline almost perfectly. Unfortunately these are far from the majority, and my experience is that the project managers does not deliver a budget that is more detailed than what they are asked to deliver. As I said, I believe a key component in successful controlling is a good budget, and achieving this often means having to change the way the project organisation delivers a budget. My experience is that if you want them to deliver a good result, you have to be specific and you have to explain yourself.

My experience with technical organisations is that they actually do want to deliver the best possible piece of work, but if you give them a list of seemingly arbitrary things their budgets should include, they won't feel a sense of involvement. If you take the time to explain why these things are needed, and what you use them for, then there will be a much greater understanding, and they won't be nearly as reluctant to do them when making a budget. Being specific, is also very important. Firstly because what might seem obvious or straightforward to a controller, might be something completely different for a technical project manager. Secondly, being as specific as possible will give the project managers a much greater idea about what they are asked to deliver, and the more people know what is asked of them, the more willing they are to do it.

What I have found to be a very effective way is make a template, with a list of the the things they need to input (for instance asking them to list the work-packs on the lowest level of the hierarchy and their associated budget).
If you experience that project managers often are unaware of certain costs always associated with the project, this might also be a good place to include those as well. An example from a previous workplace was that almost all projects included off-shore installation, but the project managers rarely included the costs for helicopter flights offshore and the price for a accomodation on the offshore installation. The reason was that these costs were added automatically to the projects, and the PM didn't know how to price it in the budget.

The last thing I am going to cover is contingency. Every project, without exception, should include a contingency for unforeseen events. I will go into much greater detail in a later article about how and why this contingency should be included, but for now it is merely important to know, as a controller, that the project need have an added cost in the budget, which represents an estimate of the unforeseen costs. There are a lot of different ways to calculate the appropriate size of the contingency, but a quick-and-dirty way of doing it, is merely to include a percentage added on top. Later I will discuss why this is far from the best solution, but it is still better than not including a contingency. Especially when keeping an eye on business cases (and NPV calculations) and when the budgets (and forecasts) are used in cash-flow calculations. A final word, in this article, on contingency is that it should always (always!) be presented separately and not included in the individual costs for the work-packs.

The last thing to remember is that a budget is just a budget. It's not a strict manuscript that the project must follow at all cost. There is a saying, that no plan survives contact with the enemy. Even fewer budgets survive contact with the real world. The role of the controller (in my opinion) is not to enforce the budget, but rather to be able to foresee if the project is going to deviate from the budget, estimate the size of the deviation, and present this information to the project owners, so that they can decide which, if any, action is needed.

Thursday, 31 March 2011

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.

Monday, 28 March 2011

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.

Saturday, 26 March 2011

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 sense1. 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.

Wednesday, 23 March 2011

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.

Tuesday, 22 March 2011

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.

Monday, 21 March 2011

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 overrun1.
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.

Sunday, 20 March 2011

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.