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.