The Quick Look

I am often in the position of having to take a quick look at a project plan to determine the likelihood that the end dates reflect the reality of the project. While there are hundreds of parameters that people look at, I want to share a few of my favorites.

I have picked these up over the years not because they provide a complete assessment, but because they rapidly indicate the maturity of the plan and the maturity of the team. In most cases it is not the quick yes/no that I look for in the answers but the discussion that the questions precipitate and how the project team might defend that they do not meet the standard. For in-depth assessments, I extend these to my list of 150 criteria – but this is where I start.

All the Plan

There should be plans in place to cover all of the project activities. Often I see planning limited to engineering, outside contracts, or a single department. Plans should include all aspects of what is required to deliver including spec preparation, marketing readiness, manufacturing, project and product cost estimating, documentation and training development, and linkages external to the core team.

If these associated tasks are not covered in plans and reviewed as intensely as the 'main' project, predictability suffers.

Show All Tasks Over 2 or 3 Days Duration

I don't want you to micromanage (usually), and don't want to lose project control by not seeing enough plan detail, so I look for the project tasks to be divided down into durations of two or three days.

The number is hardly ever accepted by clients. Their exceptions abound – senior employees with proven track records, tasks with excessive slack, external tasks that have long queue times and many others.

What I assess here is the conversation as much as the facts. The discussion quickly gets into one of philosophy and reveals much about the quality of the planning and the experience of the team.

When all of that discussion is over, my answer is still two or three days.

Name the Resources

I look for resource names. All of the tasks need to have names of real people attached. Here I'm searching for phantom resources – those names that are placeholders – employees not hired, contractors not engaged, or employees still assigned to another project.

Are the costs and headcount additions for the phantom resources in the budget? Are the personnel requisitions approved? Is the line management committed to sign the hiring letter when the people are needed? Is there time available in the plan to interview and hire them?

I am looking at reality and for a team that considers this a 'today' problem and has not put this off to the future.

Resources Buy In

Simply, the resources have to agree to and with the amount of effort and the runtime of the tasks they are assigned. That commitment covers so many aspects of their understanding, skills, availability, and commitment that it is one of the most powerful things that a project leader can do to assure predictability.

Yes, for repetitive work, a manager can usually estimate pretty well, but we are looking for knowledgeable commitment by the person who will do the work.

Tasks Dependencies

Project tasks need to be linked to their dependent tasks. When the previous criteria are met and the tasks and resources are well aligned, the team needs to understand how they depend on each other's work –  the linkages in the project plan meet that need.

This seems logical, but I will tell you that most project plans I see look like spreadsheets – lists of unconnected tasks. With resources in place and  requirements clear, the linkages are what determine the schedule. No linkages? No predictability!

Floating End Dates

Some project managers have their planning software constrain the project end date. I want the end date to float in the planning software – but I don't want your actual project end date to float! The reason is that I have seen too many project teams constrain the end date and then feel safe in the fact that it doesn't move. Sounds illogical? Yes it is.

This causes confusion based on how difficult it can be to trace down the source of a schedule conflict if the end date is constrained, and especially if the end date and several of the internal milestones are constrained.

So let the software float the end date. When the date moves out, use the plan to find the issue and find new ways to modify your project to solve the end-date problem.

Subcontractors Too

You need to ask your subcontractors to follow the same planning guidelines that you use. Most experienced subcontractors will have similar guidelines, but you need to find out what their guidelines are, and if they are less than complete, ask them to do what is needed.

That Was Quick

As I said, this is a rapid assessment. There are other ways to do a rapid assessment, but this set has served me well. Both the planning information and the discussions that gather the planning information speak volumes about the project, the plan, the team, the leaders, and project predictability.

Home | Privacy