You're relatively new on site, new to this particular project, or perhaps new to project management. Nothing wrong with any of those by the way.
You're of the opinion that as a project manager you should be able to tell the client where he's going to be in 3 months time (reasonable). The client is applying pressure for a project plan so he knows what the next 12 months looks like and there is a requirement to commence resource planning as soon as possible. A common enough set of circumstances.
We can approach project planning in any number of ways, but I'm going to make a useful distinction between two approaches. In doing this I'm going to mis-use a couple of terms - who knows maybe it will catch-on and then it'll be correct use.
We can adopt a 'top-down' planning approach where we define the duration (say 12 months) and then attempt to undertake delivery of the project's scope in this time. Or, we can adopt a 'bottom-up' approach in which we define the PBS and WBS (I discuss these in previous posts), elaborate the work and resources required to deliver the work and let our project planning software tell us when the work will be finished.
For me, the imperatives that serve project sponsors and project management are conflicting, difficult to reconcile and are a re-current source of tension. It should be as simple as enshrining the approach in the PID, mandate or other documentation, but in my experience it isn't.
Let's look a bit more at the various advantages and disadvantages of the two approaches.
In theory at least, I'm all for top-down project planning. Sponsors define the durations (and I might add the scope and budget) and authorise (compel) the delivery of the project's scope within a that duration. All sounds terribly straight-forward doesn't it? But then, I am of course reminded of the words of Commander C. Theo Vogelsang, USN “… in its relationship to strategy, logistics assumes the character of a dynamic force, without which the strategic conception is simply a paper plan.”. I don't think anyone has ever put it better than Commander Vogelsang.
A positive zoo of wise pragmatism on the subject of logistics from military theatres can be found here.
So, while we like top-down planning, we now recognise that it's not the be all and end all.
So - let's have a look at bottom-up. We have a scope, that we're going to elaborate into a product breakdown structure, create a work-breakdown structure that will deliver the product breakdown structure and commence delivery. Well, no, you're not. You probably won't have a detailed project scope at the outset of a project, you won't have any funding to commit resources to the work necessary to deliver the WBS and PBS, let alone enter into the commercial contracts potentially required to deliver the actual work. In fact, you won't even get past funding approval.
Some readers may be falling back on a bit of real world experience at this point and envisioning that we commence project start-up with the top-down plan and successively work towards a bottom up plan and in reality that is not uncommon. However, this too has its problems as funding and cost expenditure profiles are often aligned to the top-down plan, and don't necessarily adapt well to that schedule being destabilised by something as annoying as a plan that actually reflects the work that needs to be done and the duration that it will take.
We can approach project planning in any number of ways, but I'm going to make a useful distinction between two approaches. In doing this I'm going to mis-use a couple of terms - who knows maybe it will catch-on and then it'll be correct use.
We can adopt a 'top-down' planning approach where we define the duration (say 12 months) and then attempt to undertake delivery of the project's scope in this time. Or, we can adopt a 'bottom-up' approach in which we define the PBS and WBS (I discuss these in previous posts), elaborate the work and resources required to deliver the work and let our project planning software tell us when the work will be finished.
For me, the imperatives that serve project sponsors and project management are conflicting, difficult to reconcile and are a re-current source of tension. It should be as simple as enshrining the approach in the PID, mandate or other documentation, but in my experience it isn't.
Let's look a bit more at the various advantages and disadvantages of the two approaches.
In theory at least, I'm all for top-down project planning. Sponsors define the durations (and I might add the scope and budget) and authorise (compel) the delivery of the project's scope within a that duration. All sounds terribly straight-forward doesn't it? But then, I am of course reminded of the words of Commander C. Theo Vogelsang, USN “… in its relationship to strategy, logistics assumes the character of a dynamic force, without which the strategic conception is simply a paper plan.”. I don't think anyone has ever put it better than Commander Vogelsang.
A positive zoo of wise pragmatism on the subject of logistics from military theatres can be found here.
So, while we like top-down planning, we now recognise that it's not the be all and end all.
So - let's have a look at bottom-up. We have a scope, that we're going to elaborate into a product breakdown structure, create a work-breakdown structure that will deliver the product breakdown structure and commence delivery. Well, no, you're not. You probably won't have a detailed project scope at the outset of a project, you won't have any funding to commit resources to the work necessary to deliver the WBS and PBS, let alone enter into the commercial contracts potentially required to deliver the actual work. In fact, you won't even get past funding approval.
Some readers may be falling back on a bit of real world experience at this point and envisioning that we commence project start-up with the top-down plan and successively work towards a bottom up plan and in reality that is not uncommon. However, this too has its problems as funding and cost expenditure profiles are often aligned to the top-down plan, and don't necessarily adapt well to that schedule being destabilised by something as annoying as a plan that actually reflects the work that needs to be done and the duration that it will take.
Recognising that I'm beginning to drone on interminably here, I'd better quick bring the end of this post into view.
Consider the following illustration. Hopefully this is broadly self explanatory. The only note I'll add is that (particularly in my field of technical infrastructure, there will always be an unalterable volume of work required to get a job done. Short term variances arise in the identified or forecast volume of work due to imperfections in diligence and discovery at the start and blunders during the work's execution. Below I refer to this unalterable volume of work as 'K'.
In an ideal world, Kt is about the same as Kb which is about the same as K. in reality you never know K until you've finished your project. However, deciding on how important it is to know Kt or Kb accurately, or the acceptable variance between these and K should be decisions made with full disclosure at the outset of the project start-up. Needless to say - any decision should be data driven and the criteria that might inform this decision might include; cost, criticality, complexity and risk.
I think there's a few more interesting observations to be made for the illustration above - but I'm not going to elaborate that too much. What does it mean for your project's in your organisation?
More yet to come on forecasting.
No comments:
Post a Comment