How to run better projects

Published 8th October 2019

Our Professional Services Director, Chris Sands, has over 25 experience as a Consultant and knows a thing or two about running a successful project.  In this blog he looks at the questions that need to be posed before, during and after a project to ensure that issues are anticipated, addressed and so that lessons learned can be applied to the next project.

What Will Happen?

The process starts at the production of an estimate for a client.  This is broken down into the tasks needed to complete. This sounds relatively straightforward. However, we have had to work with our consultants to get them to do this without building in hidden ‘padding’, which they put in intuitively. We want a quote based on everything going well. This enables us to compare similar projects for a sense check. We then add in risk, which we split into 2 simple factors. Likelihood that something will go wrong and impact if something does go wrong. We then use this as an uplift. This enables us to give a budget figure and it highlights the areas that we need to work on with the client to reduce the likelihood of problems and mitigate the impact if they do go wrong. Focussing on these prior to cutting the first piece of code has had, by far, the biggest impact.

What Actually Happened?

Sometimes at the end of a project there is a mixed feeling of euphoria and relief that that’s all over and we can move onto the next new thing. What we have found extremely beneficial is a forensic de-brief. We get the reports from our time recording system and map these to our estimates and look for the variations, both plus and minus. If there are minuses, we can ask whether we are bloating the estimates. If there are pluses, were they covered by the risk factors and if so, what prevented us mitigating those risks better.

Our experience is that there is a Pareto effect, with 80% of the variation resulting from 20% of the tasks undertaken.

This examination must be done in a spirit of no blame and that includes not blaming the client. This stops the mentality of us Vs them. By emphasising this we have massively increased our foresight with simple things, like checking that access will be available prior to going on-site.

What Did the Client Think Happened?

This insight is harder to get than you would think because clients are usually happy that the project has completed, and they don’t want to hurt anyone’s feelings. Drilling down here though gets important understanding of how you can improve the front end of the engagement. Things that we thought were obvious tend not to have been understood. Why, for instance, is it clear that the client needed to have backed up his data or allowed Administrative access to the system if we haven’t explicitly told them.?Was it clear the level of testing that would need to be undertaken and by whom?

What Will We Change?

By keeping a simple database of lessons learnt and future actions from all pieces of work undertaken it is amazing how easy it is to produce checklists for future pieces of work. We keep these centrally and ensure that they are available for future use.

By monitoring our time more closely we have found that it is easier to spot any runaway items as they are happening and put in the remedial action straight away.

It also gives us more self-assuredness in discussing with the client the sorts of problems and issues that they may face in a grown up and professional manner.

We have found that by combining all these steps we have incrementally been able to improve all our business processes.