Philip Guildford - project control and implementation

My job as Director of Research and Engineering is to first of all help people secure their funding for their research, understand what research they want to do and who might fund it, win that funding, get the project up and running and then, if they want, certainly support them with advice along the way. The control and implementation stage is the moment when you’ve got -- the contract has been signed, you’ve been given the green light to go and you’ve got to start your project. It’s important to lay down how everybody’s going to communicate with each other and the project manager shouldn’t just impose a system, he should find out what people’s preferences are, normal modes of working, and work with their advice on what suits them.

Communications have to be mapped out at the beginning to understand how it’s going to work, and if you’ve created the right atmosphere of communication, and the right understanding of the whole objective of the project, then people will feel very comfortable to put their hands up and say “Why don’t we try it this way because I can get my bit done quicker, so-and-so can get their bit done quicker.” And which will be a better end result, and that’s the sort of information you want. The kick off meeting for a project is obviously the crucial first step. If everybody’s sort of shambling into it at different stages and with different ideas, it’s awfully difficult to recover that later on, you have to get them together so that everybody’s chasing the same objective and they know what it means to arrive at that objective. And then you’ll find they’re more likely to help each other along the way.

There’s two ways in which you can misuse a plan, one is to have a plan and just ignore it, the other way is just to adhere to it far too rigidly so that you learn nothing during the project. So the best thing to do is to keep talking about that end point and check “Is that still our objective? Are we happy with that?” And then when you arrive at the end, even if it’s shifted, everybody’s still happy because they’ve got the whole history in their heads of how that objective moved, why it moved and why it’s still a great outcome. Inevitably problems do occur on projects, they occur on absolutely every project. So if you deal with things right when they’re arising, you’ll find it much much easier.

I used to drive my team members nuts by insisting that we worked really hard to hit interim deadlines, and they’d say “well why are we doing this because the client can’t see it and if we’re a few days late what does it matter?” Well actually interim deadlines, even if they’re invisible outside the project team are incredibly important if you believe that your plan meant anything in the beginning. So if you’re coming up to a deadline and you realise “I’m not going to hit every aspect of this particular milestone, I can do XY but I can’t do Z.” Well do the report anyway, tell everybody about it and let’s see where we stand, is the report on the status on exactly the date you wanted it? That’s a very positive and good message because you can combine that with advice on how to shape the project, to correct, maybe shift objectives a little bit for the future and bring it all back on track.