Saturday, September 24, 2005
Pragmatic view of Project management
Does a project charter need to be constructed for every project that is small and usually executed by the organization?
Although a project is a unique endeavour there are in some organizations certain project types that are always executed (for example in a telecommunication industry the expansion of capacity of communication nodes is always seen as a good business opportunity and the proposal work is always done).
The charter in this case is a pretty standard document stating the business opportunity and the usual constraints that the project must take into consideration. Only a certain level of review needs to be done by the sponsor to acknowledge that the unique characteristics of this project are stated in the charter. This is a very quick task but with a very high return since at this phase the sponsor can alert the project manager for risks that must be accounted for during the planning phase.
As we all know as soon as a potential problem is uncovered more likely is that the cost of treating it will be lower. In the software industry the cost at the early phases can be from 10 to 5 times less the cost of handling a problem when it is too late.
J
Although a project is a unique endeavour there are in some organizations certain project types that are always executed (for example in a telecommunication industry the expansion of capacity of communication nodes is always seen as a good business opportunity and the proposal work is always done).
The charter in this case is a pretty standard document stating the business opportunity and the usual constraints that the project must take into consideration. Only a certain level of review needs to be done by the sponsor to acknowledge that the unique characteristics of this project are stated in the charter. This is a very quick task but with a very high return since at this phase the sponsor can alert the project manager for risks that must be accounted for during the planning phase.
As we all know as soon as a potential problem is uncovered more likely is that the cost of treating it will be lower. In the software industry the cost at the early phases can be from 10 to 5 times less the cost of handling a problem when it is too late.
J
Comments:
Links to this post:
<< Home
What do you mean by very small? If something is very small it may be better to treat it as a task rather than a project. One of the criterias when considering whether an undertaking shoudl be a project or a task is the size of the budget, resource requirement and complexity. Essentially if it is a tiny thing it's most likely a task in which case there's no need for proj.chrtr. Otherwise proj.chrtr is advisable
Your point is well taken. Never the less the idea is if you do a certain type of project repetitively then probably it’s not a project but a process and the charter is not to be produced.
The situation that I'm currently into is that the sponsor doesn't produce the charter since all the constraints are very similar between projects but there are subtle differences. Since the project managers handling those projects are a small team and are very accustomed to this kind of projects, the charter is never executed and is seen as a haste of time. In my opinion this is a mistake (refer to my previous post about the cost of handling risks downstream).
J
Post a Comment
The situation that I'm currently into is that the sponsor doesn't produce the charter since all the constraints are very similar between projects but there are subtle differences. Since the project managers handling those projects are a small team and are very accustomed to this kind of projects, the charter is never executed and is seen as a haste of time. In my opinion this is a mistake (refer to my previous post about the cost of handling risks downstream).
J
Links to this post:
<< Home
