Wednesday, October 27, 2004
Project templates
Yesterday I was speaking with a potential customer of our Project Management solution. There was a great deal of discussion around developing a suitable project template. It seems that their current project template had about 200+ tasks in it. This conversation was very similar to others I've had over the years.
Are we making this too hard? Overall, I think we as project managers make template building too hard by attempting to capture every possibility in the plan. My take is that this is a starting point and thus, you should make your project templates lightweight and process driven. I think only tasks and milestones that are needed for reporting and standard process checkpoints belong in the template. If you have 200 tasks that are just those items, you may want to reexamine your processes. Are they all applicable for all projects? If not, take them out of the core template. Typically, our templates are between 35 to 55 tasks including summary tasks.
What shapes the plan? There are really two issues here with complex templates. First, not every project needs to look exactly alike as external forces typically shape the specifics of the plan. Larger templates make it harder to customize appropriately. Secondly, it is extremely difficult to design a project template that will apply to every situation. Since there's no built-in logic in Microsoft Project for conditional tasks, you are dependent on the Project Manager to make the right decisions as to which tasks are applicable. This decision making is harder as the number of tasks to decide goes up.
External influences. Let's look closer at the external forces that shape a plan. I'll speak to software development since that's my background. I find that the delivery model you choose at the beginning of the project drives the structure of the project plan more than anything else. If you've read Steve McConnell's Rapid Development, he outlines 7 models for delivery. If you think about each of those models, you can see how the project plan would differ greatly. I've used waterfall, evolutionary delivery and prototyping models and each plan was radically different. The waterfall was extremely detailed since it followed a standard process. The ED plan started small and grew as it was a great fit for rolling wave planning. The prototyping plan was the smallest since I only put the checkpoints in it. It was really impossible to outline the work given the nature of the approach.
I find this mix of approaches fairly common in organizations. This is why I would rather see a skeleton of a project template of tasks that are common to all projects but allow substantial leeway for customization.
Flexibility. Now, let's look at the flexibilty issue. There are several ways to allow for flexibility in a standardized fashion. For example, we have the concept of a work package. A work package is a process that may impact or be required of your project and has standard, repeatable steps. An example would be a risk assessment or server procurement.
So we implemented these packages as offline project templates that has very few or very specific tasks. We then insert this into the core project at the correct point as needed. BTW, Microsoft, it would be great if we could insert projects from a SharePoint site instead of a file share only. :-)
Advantages. This "lego" style approach provides several advantages. First, the project manager no longer has to become a process expert in each of these processes so that the relevant tasks can be captured in their plan. Secondly, the packages provide a feedback mechanism to the process owners. If they have preestimated the work based on typical case and have pre-resourced it, the process owners can then look back at actuals to see how well their predictions came out. If they are significantly off, they can incorporate the feedback into the template. Lastly, it allows the process owners to maintain their own packages so that the next PM to use it always has the latest process.
Lastly, templates should be living documents with set review points. I think this makes it easier for people to let go and not put so much overhead in their templates if they know they will review them again in 3 months.
Are we making this too hard? Overall, I think we as project managers make template building too hard by attempting to capture every possibility in the plan. My take is that this is a starting point and thus, you should make your project templates lightweight and process driven. I think only tasks and milestones that are needed for reporting and standard process checkpoints belong in the template. If you have 200 tasks that are just those items, you may want to reexamine your processes. Are they all applicable for all projects? If not, take them out of the core template. Typically, our templates are between 35 to 55 tasks including summary tasks.
What shapes the plan? There are really two issues here with complex templates. First, not every project needs to look exactly alike as external forces typically shape the specifics of the plan. Larger templates make it harder to customize appropriately. Secondly, it is extremely difficult to design a project template that will apply to every situation. Since there's no built-in logic in Microsoft Project for conditional tasks, you are dependent on the Project Manager to make the right decisions as to which tasks are applicable. This decision making is harder as the number of tasks to decide goes up.
External influences. Let's look closer at the external forces that shape a plan. I'll speak to software development since that's my background. I find that the delivery model you choose at the beginning of the project drives the structure of the project plan more than anything else. If you've read Steve McConnell's Rapid Development, he outlines 7 models for delivery. If you think about each of those models, you can see how the project plan would differ greatly. I've used waterfall, evolutionary delivery and prototyping models and each plan was radically different. The waterfall was extremely detailed since it followed a standard process. The ED plan started small and grew as it was a great fit for rolling wave planning. The prototyping plan was the smallest since I only put the checkpoints in it. It was really impossible to outline the work given the nature of the approach.
I find this mix of approaches fairly common in organizations. This is why I would rather see a skeleton of a project template of tasks that are common to all projects but allow substantial leeway for customization.
Flexibility. Now, let's look at the flexibilty issue. There are several ways to allow for flexibility in a standardized fashion. For example, we have the concept of a work package. A work package is a process that may impact or be required of your project and has standard, repeatable steps. An example would be a risk assessment or server procurement.
So we implemented these packages as offline project templates that has very few or very specific tasks. We then insert this into the core project at the correct point as needed. BTW, Microsoft, it would be great if we could insert projects from a SharePoint site instead of a file share only. :-)
Advantages. This "lego" style approach provides several advantages. First, the project manager no longer has to become a process expert in each of these processes so that the relevant tasks can be captured in their plan. Secondly, the packages provide a feedback mechanism to the process owners. If they have preestimated the work based on typical case and have pre-resourced it, the process owners can then look back at actuals to see how well their predictions came out. If they are significantly off, they can incorporate the feedback into the template. Lastly, it allows the process owners to maintain their own packages so that the next PM to use it always has the latest process.
Lastly, templates should be living documents with set review points. I think this makes it easier for people to let go and not put so much overhead in their templates if they know they will review them again in 3 months.
© 2004-2005 Treb Gatte Any re-publishing of my content without my permission is illegal. The feed from this site is for personal use only.

