Planning for Success
With my project manager hat on I write many project plans (gantt charts, to be precise). There is always a danger when writing these plans that they represent nothing more than wishful thinking on my part on how an engagement will evolve. There is a simple reason for this. Project plans represent deliverables of a project team, and indicate the activities, resources and time required to make these deliverables a reality. Fine in principle, but meaningless unless the plan has customer buy-in and is resourced for success. Meaningless, too, if the deliverables are not recognised by the customer for the value and benefit they provide.
Project plans, therefore, may be more meaningful if they begin as an outline describing just the major deliverables of an engagement and nothing more. In the case of Tideway Foundation, where the implementation of our product hopefully results in business benefit for the customer, there is an important period of learning where customers should be given time and support to help them understand the impact of each project deliverable, and the benefit that each one enables.
Experience and previous estimation work can provide a useful indication of the effort expected in order to achieve these deliverables. In conjunction with continuous communication with all project stake-holders about the project’s desired business benefits and technical dependencies, the activities behind each major deliverable become clearer. With meaningful detail added to the plan at each stage of the project, the engagement moves a step closer to success.
What can bring further success is the encapsulation of previous experience, estimates, knowledge about dependencies, and realistic expectations around customer capabilities and resource availability. As examples, dealing with security issues and raising change requests invariably results in long lead-times to key activities, but perhaps more importantly, having the right knowledge and technical detail to raise the change request can greatly increase the customers understanding of what is required of them.
Having a plan, then, and supporting the plan with ‘how to’ guides, pre-prepared template documentation and boiler-plate text becomes an integral part of helping Tideway customers understand the impact an engagement will have on them. This planning and implementation collateral enables customers to understand their span of control for the engagement, which in turn, may well drive a better joint commitment to project success. Used in this way, the plan moves from being a simple project management tool, and instead plays an important role in communicating and binding the customer’s requirements to tangible deliverables.
RSS
I’m always surprised when people use gantt charts in projects – the things always strike me as miracles of optimism over experience. They’re too granular and too fragile. In my experience they (like battle plans) rarely survive the first contact with reality.
The agile movement that has swept across the computer industry has injected a valuable dose of realism, I think. The whole iterative approach, refining estimates and progress indicators as your thinking clarifies, is so much closer to the way that a project actually evolves.
Of course, I speak here from the perspective of somebody that writes software, not somebody who implements it. I would imagine that in implementations there are fewer grey areas than we find when we’re trying to figure out how to solve a problem.
What are your thoughts? Would an iterative, “agile” approach be effective in your sorts of project?
——-
By Simon Woodward on 16 Apr 2007
By Tim Coote on 27 Apr 2007