Pages

Friday, December 17, 2010

Is there a need to follow plans?

Just yesterday I quoted Eisenhower: "Plans are worthless, but planning is everything". If you use the PMBOK as guide this may come as chock for you. But then again, it was Eisenhower who said it not John Doe or some mad man. So should you take this seriously? Was Eisenhower a mad man? Or was he trying to make a point being provocative? Is there something to learn from this?

A small story to begin with
I used to work as a trainer and back then I was really proud that I didn't usually follow any of the plans I carefully did for my sessions. It seems I have often been able to find a way to do something better than what I had initially planned. On one occasion I had to deliver a programming training course to designers. As you can imagine, programming is not on a designer's top list of interests so I put the problem to the class. To my surprise, someone in the class suggested that if they worked on a game that would make things a lot more interesting for them. So in the end, I managed to deliver all the contents I was supposed to deliver, each group of students on that class had a working Tetris game and we all had a lot of fun alongside with some stressful moments. Net result? A really positive experience for us all. With no plan to follow or measure performance against - yes, you read it right...

Now the question that must be in your mind is: can you do this on a “regular” project? Can you deliberately ignore your initial plan and redo the planning as you go?

Sorry, I don’t have an answer for you

I always stick to my planning - with some necessary adjustments along the way. But I have never redone the project plan. In my case, this has been true for "regular" projects - no training or presentations included.

So I’d love to hear from your experience on this one. My best guess is that the following can help if you want to have any good results:

Is it a short term project?

Is it a dynamic project?

Do you have a real team?

Do you have a small team?

Do you have a built in trust relationship with your client?

Is it a short term project?
What makes a training session different from your "regular" project? The first big difference is that training sessions are very short (one week tops?). I don't know exactly why but this makes me feel much more comfortable working without a safety net.

Is it a dynamic project?

Meaning, are you working on a project where you actually don’t know what the end result will be? Imagine a marketing campaign. It often happens that you have a certain amount of money and time to promote a product but no one has the faintest idea how to do it, sometimes not even what media to use. So I’d imagine it’s easier to re-plan along the way if you have such a project to manage. If you start planning to have some outdoors and end up with a TV commercial, I’d say that redoing the plan is an option.

Do you have a real team?

If you’re lucky enough to have a group of people working on your project that (i) have been working together for some time, (ii) work happily together, (iii) are highly productive and (iv) value the project deliverables more than their individual deliverables... well, if this is your case, I congratulate you (and I maybe even envy you).

Anyway, if this is your case I’d imagine it’s much easier to change course in the middle of the project. But then again, having a real team makes everything much easier...

Do you have a small team?

If you redo your plan you have to let your project team know about it, to say the very least. So with a project team of 10 people you’ll have a communication problem. If you have a project team of 50 people you’ll have a big problem and probably a constant head ache. If they are 100 you’ll live in a nightmare for a while. The larger the team the harder the communication, right? So it looks like small teams can help you pulling out something like this.

Do you have a built in trust relationship with your client?
Suppose you hire someone to this project for your company and when you ask him “When will you deliver?” and you get “I don’t know...” for an answer. Unless you really trust that person you’d probably find someone else right away to do the project.

How right was Eisenhower?
Planning is everything - it lets you go through all your options, it forces you to think about what you have to do in order to get things done and makes you think about your options. And if you think a bit, that's a kind of an Agile approach so it isn't all that far fetched - but that is for another post.

Ok, but don’t do it on a regular basis

If you do it on a regular basis you will probably end up just doing stuff that you think it contributes to the project success instead of redoing your plan because you found a much better way to deal with the project.

Call for comments

So what do you think? Are plans really necessary? Can you redo a project plan in the middle of the project? What kind of benefits would you have to get to consider redoing a project plan? Please speak your mind, I’d love to hear from you.

6 comments:

Really nice post.In my experience, we can get success without a plan. Plans are necessary if the environment (team, organization, quality environment) need it. And also if the project manager need it to drive his project.For those who don't need a pln, it's not because they are lazy or selfish but they see it as a constraint.For me a plan, like other tools in PM, must be used as a help.

Thank you comment Sara_broca.I don't think a could ever do a project without a plan but I'm very glad to see that there are such radical ways to approach Project Management.If you go for a Project with a plan, how do you deal with expectations? And report progress?I'm really curious on this.

I think that you do need a plan for any project, however it's vital that the plan is flexible and responsive to change. With many projects user requirements change as time goes by, so I think that a scrum sprint approach is best. Decide what's really important to deliver in the next release, plan it, and execute. I don't think there's much point planning in any detail much further out than 1 month as a rule of thumb though.

Finally, I dont think plans should be highly prescriptive. I prefer to set the team a short term goal and let them decide how to get from A to B.

This is a bold statement that challenges our conventional thinking about project plans. It serves as a good reminder about what is important about planning. It is not necessarily the plan. What is more important is for a group of people to work together to develop a clear picture of what needs to be done and when it needs to done and by whom. This working together creates a shared thinking that engages the participants and creates and sense of ownership of the plan and outcome. Without such engagement and sense of ownership, which is only possible when people engage each other in an environment of trust and respect, can we as project managers deliver successful projects.

Thank you very much for your comments Jon.I agree completely, plans have to include change. The changes that can occur in a construction project are much different than the ones that can occur on software development and so the plans should be different as well. Your plan can be limited to just a backlog like in Agile - but it is a plan. Or maybe a rolling wave plan could do. Or even no plan at all, I have learned with Sara’s comment.The same goes for how much prescriptive your plan should be. If you have a highly qualified team like you do in software development, you could just let them go like you said. However, that would be difficult to work well on a construction project: if you don’t tell your painters what to paint, with what paints and where to start you’ll probably end up with a unpleasant surprise.So I’d say both questions should always be considered before deciding which way to go.

Thank you very much for your comment Samad.There are many aspects related to planning that this post didn’t cover and you just pointed out one. One thing that came to mind reading your comment is how best practices prevent you from excel at whatever you do (the post Team Players focus that point). In short, it goes like this: if you do things like everyone else does the best you can expect is to do it as good as them, but no better. This is true about anything you can think of – may that be the PMBOK, Scrum or whatever. So yes, you should question why you’re doing your planning the way you are and if you could do it any better.And I must tell you that I’m really glad for the comments on this post, it shows how people are taking something relatively simple like the project plan and acting very differently according to their particular context.