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 recognized¹.

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.

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.