Friday, September 2, 2011

One way to lower the project overall risk is... divide the project into phases! Have you ever thought about it? I didn’t until recently, just let me tell you all about it and maybe you can challenge this idea. Or come up with another idea.
This is no big breakthrough in Project Management but it was a great reminder that no matter how much experience you have there is always a way to learn something. I know I just did but...

...But first, some definitions
Let’s start stating the obvious for some but with a necessary definition first anyhow to make sure we're all on the same track. Sub-projects or project phases consist of the division of a project into smaller chunks where each chunk is managed as a project itself. This last bit is the key to this: if you can manage a phase as a project itself, then this phase must be quite independent from the other phases in the project. And a project phase should always match a branch of your Work Breakdown Structure (WBS).
Programs are different but easily mistaken for projects with sub-projects or phases. In theory, a program is a set of related projects and it has outcomes outside of the scope of each project. And usually some of the work within a program doesn’t belong to any project in it.
In practice, a program is focused on business value and project on deliverables.

Why use phases in a project
You can use project phases for several reasons. In my particular case, I’ve used them either to:
  • introduce a critical decision point in the middle of a project (like deciding if it’s worth to go ahead with the project after a feasibility study)
  • outsource part of the project work in the form of another project (which is a sub-project of the initial project)
  • and give the responsibility of that branch of the WBS to someone else (because part of the work must be done in a different geographical location)
In general, and it is also stated in the Project Management Book of Knowledge (PMBOK), you divide a project into phases when you need some extra control to effectively manage it.

But about risk?
I was recently working on a complex project involving 3 other organizations and in that project no one believed that we would be able to get one of the deliverables within the required timing (which would be a bummer). Now this guy comes up with the idea of phasing the project putting this particular deliverable into a different project phase. Well, first we checked if we could actually do it and in fact that deliverable was kind of extra functionality and there was nothing in the project that depended strongly on it, so we all bought the idea and went for it. And we sold it to senior management that we would be safe if all the rest was delivered on the required timings. This particular extra functionality was then seen as a bonus, no bummer anymore!
So in short, we took the tree branch of the WBS that we expected to crash somewhere in time and isolated the problem. This may sound like escaping from one's responsibilities, but it isn't. It's about keeping the damages under control on one side (reducing the risk impact) and on the other side providing more means of management (reducing risk probability).

If you take another look at the reasons I presented earlier for phasing a project and the PMBOK definition, they also imply the possibility of lowering the risk associated with the project. In the case of the PMBOK definition, if you have more control over the project you have less probability of things going wrong, right?
So in fact this is not a new concept at all, but it was the first time I’ve seen it and applied it clearly: phases as a means to lower the overall project risk.
Now I’m a curious person: in your case, why have you used project phases? Have you ever done it to reduce the project overall risk?

Images from,

Posted by

No comments: