Fast Projects

Fergus O'Connell: Yeah, very much so. It's kind of interesting that in the, sort of, 30 or so years that I've been involved in project management nothing really seems to have changed and that the mistakes people were making 30 years ago are the same mistakes they're making now. So, I probably have a top ten but, because we only have half an hour, let me give you the, you know, any three from that list. And so I think the single most common one is the business of people just taking on impossible projects. You know, the boss has a, kind of, an aggressive deadline or a stretch goal or something like that and he tells the troops, this is what they've got to do, and everybody just says, "Okay." And I think that's the most common reason why projects fail and, you know, we can talk more about that later on.

The second one then is that the goal of the project isn't precisely defined and if the goal – so you can think of the goal, a precisely defined goal, as being like a box around the project, so people talk about, you know, 'within the box', so 'in scope' and 'outside the box, out of scope'. But many projects start out, not with a box, but with a cloud, you know, where it's really not clear what the project is about, and I'll give you just a very interesting example from a couple of years ago. The biggest civil engineering project ever carried out in Ireland was something called the Dublin Port Tunnel and it's a project that eventually ran nearly a billion Euro over budget and a year and a half late, and that was a project where for about two years the height of the tunnel hadn't been decided by the Government. I don't know much about civil engineering, but I would have thought if you're building a tunnel the height of the tunnel is an important parameter and being unclear about it for such a long time has to be a problem.

And then the third reason is people don't estimate projects properly so, you know, you get these stories that pop up every week of projects that were meant to last six months or a year and last four years, five years, ten years. And those would be just three reasons, but – and probably three of the most common ones.

Rachel Salaman: And we'll be talking more about those a bit later because they play quite a large part in your book Fast Projects. But before we get onto that, how easy is it for people to change their ways when it comes to managing projects? Isn't it a bit like a leopard changing its spots: some people are just good at project management and some aren't?

Fergus O'Connell: I agree with parts of that. I mean, I think not everybody is a good Project Manager, for sure. But I think many people are instinctively Project Managers, that when we plan something like a holiday or a wedding or a house move, or something like that, we do many of the things that make for good project management, you know, we write lists, we give jobs to people, we have contingency in our plans. And I think certainly in, sort of, technology-type projects what seems to happen is that people think that because it's a technically complex project then the management of it is technically complex, and it really isn't. I mean, the same techniques and the same skills that apply to managing a house move or a wedding are the skills that apply to managing a technology project. And I think it is difficult for people to change their spots or to become better at project management because it requires behavior change. It's difficult for people to change any habits and in a sense project management is just a series of habits or a series of behaviors. So, yeah, it's difficult, but it isn't impossible and the techniques to be learnt aren't complex, they're very simple.

Rachel Salaman: And your book Fast Projects really helps with that. Now it lays out eight steps to planning and executing successful projects, which can be applied even to the smallest project and projects like moving house just as much to large business projects. The first is a warning and is what you mentioned right at the beginning of this interview; don't commit to something that's completely impossible. Why do people say "yes" to impossible tasks?

Fergus O'Connell: Oh, you know, I think this is a rich area for study by psychiatrists really because I think, on the one hand, you have bosses and company cultures which are, you know, cultures like 'We can't say no', 'Don't bring me problems, bring me solutions', 'If you don't do it I'll find somebody who will'. You have people doing that kind of stuff. I mean, I once heard a boss say to a group of people – they had just presented their project plan and he said, "Okay, now" he said, "I want you to do it twice as good in half the time." And there are people thinking that this is, kind of, good – a good management practice. Now, I have no problem bosses or companies setting stretch goals, but there's a difference between stretch goals and just being stupid, and something like that, the boss saying something like that, which, I don't know, is meant to sound macho or inspirational or something, just to me sounds stupid. And so I think it's a combination of maybe bosses or company cultures not knowing any better way. They think that this whole, you know, "Let's be macho", you know, "Follow me through the fires of hell" kind of thing, they think that that's the only way to manage, and then the troops just feel that they have no choice but to become part of that culture. That's as good a theory as I can muster, but maybe I have no theory, you know, people just do it. People do things which in other industries would be bizarre. Imagine you went to the doctor and you said to the doctor, "Doctor, I'm not feeling very well. Fix me now." And imagine the doctor said, "Yes." I mean, there's no Doctor on earth would do it. And so things that are weird in other industries are routine in, sort of, the kind of, knowledge and technology industries that many of us operate in.

Rachel Salaman: It sounds like it's up to the bosses to be more realistic when they ask people to take on a project to manage, but it's also up to the people being asked, to set some parameters. What should they do instead of saying "yes" to an impossible project?

Fergus O'Connell: Well, I think it is up to the boss, but I think it's – I come across a lot of Project Managers who see themselves as the world's greatest victims, you know, everybody does things to them, the boss, the company, the culture of the company, and I think ultimately it's up to people, the Project Managers, to do something different. That if the boss continues to ask for impossible missions and they continue to say "yes", then the culture is going to continue, so I think the onus is on the Project Managers not to be a victim, but to see that there are things they can do. And the thing they can do is, firstly, when they're asked to do a project, the only thing they should say, the only response they should have is, "I'll have a look at it" and if that means that the boss is hitting the table and saying, "I need an answer now" they say, "No, I can't give you an answer now. I'll have a look at it." Somebody comes running in and says, you know, "We need an answer by four o'clock today, sales need to know," and somebody just says, "Look, I'll have a look at it." In exactly the same way as the doctor says, "I'll have a look at you" or you take your car to the garage, the guy says, "I'll have a look at it." So that's the first thing.

And then the second thing to do is that the Project Manager must build a proper plan for the project. And then the third thing is that the Project Manager must use that plan to make sensible decisions about what's possible and what's not possible. So at a high level it's those three things.

Rachel Salaman: The second step that you lay out in your book is figuring out the goal of your project. This is another point that you mentioned earlier: you say that it's a three stage process. Can you talk us through that?

Fergus O'Connell: I will. The first piece of it, the first thing to be conscious of is the thing I mentioned already, that we have to put a boundary around the project and say these things are part of this project and these things are not. So like I said earlier, we've got to have boxes, if you like, and not clouds, so we know what's within the box. It's almost like we have a checklist of the things that the project will deliver or the benefits it will bring or the results it will achieve. So that's the first part of it. The second part is we have to be conscious that, no matter how precisely we define the goal, once the project starts the goal will change, you know, people will ask for other things, extra things, or there will be things that we should have seen but we missed it, or there will be things that they should have told us about but they didn't, or the business climate will change or, you know, all sorts of things. And there's no problem with that provided we control the changes, but a huge mistake that Project Managers make is that they assume that the people for whom they're doing the project, the customer if you like, can change their minds any way they want and that the original, you know, commitments, the original plan and deadline, must still stand. And this is clearly ridiculous, but Project Managers do that, they basically take the view that the customer is always right, and so the people for whom they're doing the project can, you know, chop and change as they like, so we've got to stop that, and that's known in project management jargon as change control. So it means that, you know, when somebody does change their mind, when somebody says, for example, "I want some extra stuff in the scope," the Project Manager is then entitled to say, "Well okay, but that's going to cost you extra or take more time or require more resources." And again, this is a behavior change thing because, you know, bosses like to think they can ask for whatever they like or customers like to think they can ask for whatever they like. And again, I think the onus is on the Project Manager to push back on that and say, "Well look, yes we can do that, but here's the price associated with it." And then the third thing, the third step in this process is, if you ask what's a successful project, I mean, you can say things like 'within the deadline' and 'meets the budget' and 'satisfies the stakeholders', but if you really want it in two words, a successful project is about happy stakeholders and the stakeholders are the people affected by the project. If we can end a project where our stakeholders are happy then we've had a successful project. And the first step to finding out – to happy stakeholders is to find out what's going to make them happy. We have to first of all figure out who the stakeholders are, who are the people affected by the project, and there tend to be the conventional ones, you know, me, my team, my boss, but usually if we throw the net a bit wider we can come up with other stakeholders, people in other departments, people in other organizations and then each of those stakeholders has what you can think of as win conditions and win conditions are what would make a successful project for that stakeholder. And it's up to the Project Manager then to say, "Well now, given that we have all these different win conditions, can we come up with a, sort of, a composite set that will keep everybody happy?" If, for example – I'll give you an example of a couple of win conditions. Let's say I'm the boss who's given the team the impossible deadline then my win condition may be that they hit the deadline. But if I'm a team member who's been working, you know, a hundred hours a week for the last six months then maybe my win condition is I just want to work a 40 hour week on this project. So compromising the win conditions is about trying to find something that will work for everybody. Those are the three steps in the process, and in my book I describe then some tools to enable people to do that process.

Rachel Salaman: The third step is figuring out what work has to be done. Now this might be a good time for you to explain the difference between work and duration and how understanding that is key to successful project management.

Fergus O'Connell: Yeah. These are things that people mix up all the time, these two quantities. So I'll do it and if it sounds a bit labored I make no apologies for it 'cause it's really important. There's a quantity called duration, which is also sometimes known as elapsed time and it's also sometimes known more simply as, "How long is it going to take?" So if, for example, we have a task in our project which is to review a document, let's say, then the duration of that is the time from when it starts to the time when the review ends. So let's say the review lasts four hours then the duration is four hours and duration is measured in the normal units of time in hours or days or seconds or weeks. But then there's another quantity, which is called work or effort. If we have, say, four people reviewing the document then the duration might be four hours, but the work involved is four people times four hours, which is 16 person hours. People mix these up all the time. Every time they mix them up they make their estimating even more inaccurate, you know, because if you say something was four and it should have been 16, then that obviously introduces errors into the process. And if we want to know how long the project is going to take, then it's the duration is what we're primarily interested in. But if we want to know how big a project is then duration gives us no sense of that; it's the work tells us that. This is part of the problem with people drawing, you know, Gantt charts, you know, the traditional, sort of, who does what, when, chart. They often don't give any indication of how much work is involved so we can draw one of these charts with all these nice, pretty bars on it, so they show how long everything is taking, but they don't give any sense of how much stuff has to be done and therefore how much people we need to do that stuff. So it's a real important difference between the two things.

Rachel Salaman: And getting that difference wrong is that the biggest problem that people run into when they try to estimate how long a project will take or are there other things as well?

Fergus O'Connell: There are other things. I mean, the primary problem is that we can't do estimating that's 100% right. I mean, sometimes on my training courses I'll hold up a copy of a plan and a lottery ticket and I'll say, "What do these have in common?" And the answer is that they're both predictions of the future. The odds on the plan might be better than the odds on the lottery ticket, but I've certainly seen plans where you'd have to put your money on the lottery ticket. Nobody can predict the future, okay, and in project management what we're asked to do is a) make a prediction of the future, in other words do estimating, and then b) have that prediction come true. How do we keep the error as small as possible? And the answer to that is that there are only two things we can do. One is to put lots of detail in the plan, and I think in general that's not done, and the other is to record what actually happens on projects and use that to improve our estimating. And again, you know, in a lot of, sort of, hi-tech industries particularly, that's not done at all. You know, for example in construction, which is a very mature industry, people can tell you, you know, they have rules of thumb like how long it takes to lay, for example, a hundred bricks or to put up a hundred tiles or something like that. In technology industries in general we don't have those rules of thumb. There are exceptions, but in general we don't. It's almost like we regard every new project as a brand new venture. In general that's not true, in general there are things that can be carried over from previous projects, but whether we have that previous information or not I think the real problem is the detail, that people don't do enough detail in plans. Because a plan is basically a detailed sequence of events, and if we don't figure that out properly then we're in trouble.

Rachel Salaman: Your fourth step is one that will present challenges for a lot of managers of large projects: getting people to do the work. Now one of the problems that managers run into is that their team members think they're available to do the tasks when they're actually not that available and you have a concept in your book that you call dance cards. Can you explain that?

Fergus O'Connell: Hmmm, I will. The concept comes from, I guess, the 18th and 19th centuries where – when women went to dances they were given a little card with a list of the tunes that the band or the orchestra were going to play, and if a gentleman wanted to dance with a woman he went and he wrote his name against a particular dance, so it was a booking system if you like. In my work, for example, one of the things I do is I sell my time and if I book, for example, today to do this interview with you I clearly can't book it to do that work with somebody else. I can't book the same day twice in other words, but many people in jobs do book the same day twice. It's like they allocate the same day to two different projects or two different pieces of work. And there's an exercise we do on our courses where we get people to calculate for, say, a given period how much work they have to do and how much time they have available to do it, and routinely now, absolutely routinely, I mean, out of ten people I would expect five or six people to exhibit this; we find people who are more than 100% overloaded, so that, for example, in 20 days available they have 40, 50, 60 days' work to do. And I've seen this become worse over the years that I've been doing dance cards, I mean, 15 years ago it was quite unusual to come across this and now it's so routine that you almost yawn when you see it. But if people don't know how much time they have available and if they don't know when they've become fully booked then what will happen is that I'll go along to somebody and I'll say, "Look, can you give me a couple of days of your time on my project?" They'll say, "Sure," and they end up doing us both a disservice because for themselves they've overloaded themselves even further with all the, kind of, stress and difficulties that that implies, and for me they've promised me something which I then build into my plan and which probably isn't available and will mess me up in the long run when I try to, you know, call in that piece of work from them. So...

Rachel Salaman: So what can you do about that?

Fergus O'Connell: Well, like I say, if people use some tool like a dance card then they can figure out – or any kind of booking system basically, I mean, if they can figure out how much of their time has been used up and how much of their time is still free, that's the first step towards trying to understand this and get a handle on it. I have – I think – I don't know if I mention it in that book, but I have a little spreadsheet called an availability calculator and, you know, if anybody wants that they can send me an email and maybe you can stick my email address on your site or something like that.

Rachel Salaman: We can mention it at the end certainly, yeah.

Fergus O'Connell: Yeah, yeah, because it helps – it's just to fill in the blank spreadsheet that enables people to figure out how much work they have to do in a particular period of time. And I get people to do this, like I say, on training courses and almost invariably they get very unpleasant surprises when they do it.

Rachel Salaman: Well the fifth step in your book is making the plan bullet proof, which is largely about building contingency into your project plan. What are the various ways people can do this?

Fergus O'Connell: Well, I teach people two techniques and they're very well known techniques. One is, you know, I'll basically teach them what I think of as the Projects Manager's Prayer, and it goes like this: "Unexpected stuff happens on projects. Most of it is bad, unexpected stuff, and for the inevitable bad, unexpected stuff you need to have contingency in the plan"; you need to have some extra time or some extra budget or some extra resources available. And I say this against a background of, basically, I don't know how many plans I've seen where bosses have said, "Look, we'll have to take the contingency out." And it's crazy because there's no plan has ever worked out like its author said, and for somebody to think they won't need contingency is nuts. So I try to firstly convince people of this and then on training courses I teach them how to put it in explicitly into plans or how to hide it so that their boss can't find it. And while somebody may think this is very immoral I think it's okay because, you know, I think it's more immoral to run plans that have no contingency. So that's one technique and it basically doesn't try to understand anything about the project; it just says bad stuff happens.

Now the other technique then is risk analysis where you try to identify the, sort of, weak points in the project 'cause – so that's kind of nice first of all if you can say, "Look, here are the points at which it could fail." And then an even better thing is to say, "Well now could we do something about these risks? Could we reduce or eliminate them?" And basically then as a Project Manager you hope that, you know, the combination of the things we've described, like knowing precisely what you're trying to do, a detailed estimate which tries to keep the error as small as possible, contingency to cover stuff we know will happen and risk analysis to try and stop some stuff from happening, we hope that the combination of all those things will be enough to get the project done safely. If you heard me say hoping, hoping was what I said, because it seems to me that's about as scientific as this gets, if you accept the basic idea that project management is predicting the future and having it come true.

Rachel Salaman: Well step six is selling the plan to both the stakeholders and to your team and, I suppose, this is most appropriate if you're managing a large project rather than a smaller one. You suggest holding a kick off meeting at the start of the project. What should that meeting cover and who should attend?

Fergus O'Connell: Yeah, I mean, the parallel I like to draw is with some of these 1940s and 1950s movies about Bomber Command in World War Two, for example The Dam Busters. And, you know, there's always that scene where the bomber crews file into the briefing room and somebody talks them through the mission then about all the things that they're meant to do, what their objective is, the sequence of events, what might happen along the way. And that's basically what a kick off meeting should be and I think there should be one with the team for definite, so that they understand how the project is going to unfold and the part that each of them has to play in it, and then there should be one for the stakeholders, probably a separate one, where again it's explained to them how the project is going to unfold and the part they have to play, because stakeholders often take the view that, "Well it's the project team have to deliver the project." And sure they do but, you know, almost always the stakeholders have things they have to do in the project, and they have to understand particularly the implications of them not doing those things or doing those things late. If you can run a kick off meeting like that, that's a good – well it's an essential way to start the project, I think.

Rachel Salaman: And in step seven you offer some advice about what to do if your project becomes impossible and it's this idea of the impossibility of the project again. Can you share that advice with us?

Fergus O'Connell: Yeah, I will. I mean, basically as a Project Manager there are four things that you can play with and those are the scope of the project, so in other words what's in the box if you like, when the project is going to be done, how much work is involved, how much resources you have to work on it and the quality. And by the fourth one I mean that there are jobs in the plan which ensure the final quality of what gets delivered, so I'm thinking of things like reviews, sign offs, testing, stuff like that. Now, if then you build a plan and according to your plan what the boss or the stakeholders are asking for is impossible, these are the four things that you can adjust to come up with other variants of the plan, so you can reduce the scope for example, so that's using the first parameter. The second one, the when parameter, you can say, "Well look, what's the importance of the date, you know, can we change the date?" Because often as Project Managers we treat dates that we're given by bosses as though they had been handed down from, you know, God to the – to Moses, to the boss, to us, kind of thing. And while some dates have massive significance, many dates have no significance, you know, they're just picked by bosses or promised by sales people or something like that, and often if we question the date we may find that there's some give in it. The third thing we have to play with is the resources so we can ask the question, "What happens if we add more people?" And finally then, you know, in terms of the quality, well, are there, okay maybe we can't compromise on quality, but maybe there are things we can do in terms of speeding up review cycles or finding smarter ways to test things or things like that. And so, either separately or in some kind of combination, we can use these four parameters to come up with variants of the plan that will work as opposed to promising the stakeholders something that was never going to work in the first place.

Rachel Salaman: So then finally we come onto execution, and your book offers some great tips on managing your team, if the project requires a team, and also on the importance of having a daily routine. Could you briefly talk us through a typical daily routine for a Project Manager?

Fergus O'Connell: I will, yeah. You take your plan, you look at the plan and you see, is there any job on the plan that requires some action by you today? So you identify then from that your To Do list for today. You then take that list and you go do the things on the list. Now, your plan may have 500, 600 jobs in it, but you don't have to do 500 or 600 things, you just have to do whatever things require some action by you today. So there may be a large number of things, there may be a small number of things. Some days there may be nothing to do and if there's nothing to do then that's fine, you don't have to worry about it, but all of this presupposes that you've put a lot of detail in the plan. If the detail isn't in the plan then this whole routine doesn't work. Now, having done the jobs on your To Do list then you record what actually happens, you know, so, I estimated something would take three days, it actually took three days. So now you start to gather your estimated versus actual data. The other thing you do then is you check to see whether there has been any changes to the scope of the project during the day and, as a result of that, you end up updating the plan. And then, you know, having updated the plan, the delivery date for example will either have stayed put, in which case it means you're on target, it will have moved to the left, in which case you're ahead of target and – or it will have moved to the right, in which case you've run a bit over, but whichever happens you can then take some actions. I mean, if there is some slippage you can take some actions to deal with it, and at a high level that's the daily routine. Now it's a little more detailed in the book because I've tried to make it very prescriptive and, dare I say it, idiot proof. But essentially that's it; you get the plan to tell you what to do, you do those things, you update the plan and you just do cycles of that.

Rachel Salaman: And when the project's over you say that post mortems can be useful for highlighting learning points. How and when should a Project Manager carry out a post mortem on a project?

Fergus O'Connell: Yeah, I mean, I don't think they're just useful, they're really essential, and they're again one of those things that aren't done all that often because it's almost like if the project was a success everyone's so surprised they just run on to the next great thing, and if it was a disaster everybody just wants to forget about it. So that's the first thing, that often post mortems aren't done, and often when they are done they end up like these, sort of, government reports with a hundred recommendations, you know, so they lie on somebody's shelf and nobody does anything about them. So again, what we teach on our courses is a, sort of, a light post mortem and it has three elements in it. And they are, first of all, can we recover from the project the plan containing the actuals? You know, so here's the plan as – here's the project as it actually worked out, you know, no estimates, no assumptions, here's how it happened, warts and all. And if people have been doing the daily routine that I described then as a byproduct of that, on the day the project ends they just have the plan with the actuals. So that's the first thing. Post mortems tend to focus on, "What did we do badly?" And yeah, sure, but I think it's really worth asking, "What did we do well?" You know was there something we did or some little template we came up with or tool we developed or something that really made a difference? And rather than coming up with a hundred recommendations, let's come up with one or two things. Maybe it's the number one thing that we did that made a difference. And let's share that with all our colleagues, you know, because then we may get these little incremental improvements which we don't get if we write these big post mortem documents that nobody ever reads 'cause they don't have time, or nobody implements. And then finally, "Yeah, you know, what did we do badly?" What's the thing which, if we could put the clock back, we shouldn't have done or didn't do well? And again, let's share it with our colleagues, if we have the courage to do that, because, again, we might stop people falling into traps that we fell into and, again, we might get some incremental improvements. So I think that's a, sort of, a light post mortem that can be done very quickly, that can be done in 20 minutes, you know, even for a big project.

Rachel Salaman: Now your book is called Fast Projects, do you have any particular tips for speeding up the project management process?

Fergus O'Connell: I do. The single most important thing if somebody wants to speed up a project, you know, last year I was speaking at a conference on shortening time to market and at the beginning of my talk I said, "This problem, the problem of shortening projects, has been solved." And somebody put their hand up and they said, "Oh, when was it solved, you know, I hadn't heard that it had been?" And I said, "It was solved about a century ago." And it has been solved by the people who make movies because the people who make movies – I mean, I know there are famous stories of movies that have gone over budget, but these days very, very large, expensive movies get run with a precision that could keep any accountant happy, and the key to shooting a movie on time and on budget is something known as the shooting schedule, and a shooting schedule is a project plan, but it's a day by day project plan. It's that idea of the day by day project plan. I'll give you an instance. About four months ago I heard the woman who had directed the movie Mama Mia, she was talking about that movie and she was talking about the shooting of it, and she said, "It was an 89 day shoot." Now, when's the last time you heard a Project Manager say, "It was an 89 day project?" You know, because what happens on our projects is, kind of, Friday comes and we say, "How could it be Friday and where did the week go?" And so movie people are very focused on accounting for all the days, and there's a very simple reason for this, it's because movies are so expensive to shoot that they want to make sure they know where each of the days goes. And if we want to shorten our projects or shorten time to market the single most useful thing we can do is to build a day by day plan, so to build the plan at that level of detail, and if we do that we will get the project done in the shortest possible time. You know, and again, this idea's not my idea, like movie people do this because it works, construction people do it 'cause it works, like all the industries where people are good at project management they do very, very detailed plans and if there was only one idea I wanted people to take away from this it would be that idea, that detail is the key to getting this right.

Rachel Salaman: Fergus O'Connell, thanks very much for joining me.

Fergus O'Connell: Thanks Rachel, it was a pleasure.

Rachel Salaman: The name of Fergus' book again is Fast Projects, subtitled Project Management When Time is Short. And, as I said at the start, he's written eight other books, many of them also about project management.

You can find out more at www.etpint.com. And if you'd like to contact him to get a copy of that availability calculator template he mentioned his email address is fergus.oconnell@etpint.com.

I'll be back in a couple of weeks with another Expert Interview. Until then, goodbye.