14 Aug Process oriented project team
This week I was discussing the need for milestone visibility. Strange topic to be discussing, but it happened! The conversation begun as I was making a point to allow the PM tool (in this case MS Project) to calculate the milestone date based on the tasks dependencies and how easy it was to have this information available and updated. My audience questioned why should the project team need milestones!
Better to have questioned why do we need to breath.
Milestone visibility to the project team was view as a side issue. The team needs to focus on the technical work and not on the management issues like budget and dates!!!
This out-dated view of the world is still alive.
Currently not to have any kind of process (like milestone updates) on a project so the project team can have as much time as possible to make the technical work can lead only to one outcome. Soon or later the time spend on the correction of error/quality problems is going to increase due to errors made early on the project making the project end-date to be missed.
Imagine this, only the project end-date is set. The team starts to work and it actually releases the product on time but with many problems due to low quality control so the end date can be reached. Because no intermediate control points where established no prediction of this situation was made.
As we all know errors are easier and cheaper to correct early on the project than later, for this reason processes as milestone control can help visualize schedule variances and make the team more accountable for there performance early on the project.
Compare the no process approach with a team that early in the project establishes a set of milestones and control it early. The team will follow up any variances and take any corrective action so the target dates are accomplished not only the end date. This will in the long run increase quality and project visibility to the outside stakeholders.