Top Ten Reasons Why Projects Fail – Reason #9
Posted on: April 25th, 2012 by admin
Reason # 9 – Team Planning Sessions
As I mentioned before, PMI devotes fully twenty processes in the PMBOK just to planning. And they will be devoting even more in v5. Point being, planning on a project is extremely important. That seems like a fairly obvious statement. But in my travels, as I go into and out of companies either as consultant or trainer, I find that team members are either not given enough time or very little time to plan. The mantra in these companies is execute, execute, execute. When I ask people if this causes them problems down the road, I always get an unqualified ‘yes.’ So they see errors, waste, and find they have to go back and plan anyway while they execute. So from my point of view, planning is not only important but is in fact, mandatory. And if that were the only thing worth mentioning, I would end right here. But it’s not. I would in fact argue that over and above just having the project manager and/or a core team plan, the initial planning should be done as much as possible by the larger team.
Over the past ten years of my twenty-year career, I have spent a fair amount of time as a consultant going into companies (with a colleague) and helping them plan their projects. Our typical engagement lasts two days. (With usually some one-on-one follow up). The good news is that these companies have gotten the message that planning is important. The reason we’re called in is that they don’t exactly know what topics should constitute these meetings nor do they know how to facilitate them. There is some prep work by team members for the meeting and they are expected to come not only prepared to talk about their functional area, but also to roll up their sleeves and work hard for two days. What kind of hard work? Well, without going into all the detail, we typically aim towards producing three deliverables – a work breakdown structure, a schedule and a risk register. Very often, team members in these sessions are not familiar with all three artifacts. They have likely worked with a schedule before – and perhaps a risk register – but very often not with the WBS.
Now it may seem fairly obvious what the benefits of this type of session are. But even if so, I think it’s worth enumerating here. First and foremost, it is often the case that many on the team have actually never met before. Many of them are distant geographically and have “met” only be email or by phone. So this gives them a chance to get together and discuss issues at a level of depth that they previously have not been able to enjoy. (Many of these discussions are off-line and/or over dinner). Another benefit is that the very act of creating these artifacts together introduces a level of team-building among the members that’s difficult to accomplish in any other way. The very creation of, say, a WBS means that team members will have to argue (constructively one hopes) and debate the deliverables that should and should not be on it. What work are we really doing and conversely, not doing? What’s in-scope and out-of-scope?
Once the WBS is created, the next step is to create a schedule. Very often, team members will be seeing the schedule for the very first time. Granted, at this point, the schedule is very much in its beginning stages and needs to be further fleshed out. But the team can begin to see the parameters of the project: dates, tasks, resources, costs, deadlines, milestones. And they begin to understand what their commitment is expected to be as well as whether there are any conflicts which will prevent them from meeting those dates. This usually leads to a healthy (but necessary) discussion, very often revolving around resources.
The last task is the creation of a risk register. As noted previously, some will have been involved in this process before, some not. Regardless of background, this tends to be an eye-opening exercise for all involved, especially given what they’ve learned over the past few days. So they better understand the bad things that may befall the project and how they propose to react under those circumstances.
The last thing I’ll say on this topic is that having done many of these sessions, it never fails that I find one person at the end of the two days, walking around the room looking at WBS’s on the wall, examining the schedule and risk register quietly. I’ll often walk up to the person and ask what they’re thinking. And they’ll invariably say something like, you know, I have been working here for twenty years and until now, never saw my projects before with such depth and clarity. And I would maintain that that is perhaps the biggest bonus of these sessions.
(Up next – Monitoring and Controlling)
Comments are closed.