Ongoing project schedule validation – can it happen?
Last week we talked about running project schedule validation checks on a schedule that has few completed tasks. As your project continues, there are checks you can run to insure your schedule is still valid.
If you missed the first part, visit here.
Invalid dates check
If you reviewed the schedule when it was new, you should have found these before getting started. Sometimes, as new tasks are added and the project progresses, tasks with invalid dates seem to sneak in. There should not be any tasks that start before the project start date. It is common sense that there should be no actual start or actual finish dates after the current project status date. In essence, a task can’t actually start in the future.
The future isn’t now
By the same token, your start and finish forecast dates should all be in the future. If you have a forecast date in the past, it should have an actual state or actual finish date. If it does not, then you need to update that date with a new forecast start or finish in the future.
Resources check
According to DCMA, all tasks in the schedule should have resources and budge assigned. In my experience, I always manually managed human resources – MS Project doesn’t do this very well. If you have software that handles this well for you, go for it. Aside from the master schedule for a major satellite program I worked on for a while, I’ve always managed the budget outside of the schedule as well.
Your organization may have its own processes for managing resources and budgets.
Missed tasks
This metric measures how far off you are from your baseline. You did baseline the plan, right? If you’ve got last tasks completing after the baseline finish date, you’ll want to realign the plan to the baseline.
There are instances when you get permission to have a finish after the baseline. If your project has a change that pushes out the final date, you may want to consider rebaselining the schedule. In my experience, every company and sometimes each project has different rules regarding rebaselining. I’ll try to schedule a post about baselines in the future.
Calculations for the analytical
Critical Path check
You’ll want to run a critical path check periodically throughout your project. It will help to catch those mistakes and errors that sneak into a schedule over time. See the post on New schedule validation for the instructions on how to do this.
Critical Path Length Index (CPLI)
For those of you who love formulas, this one is (Critical Path Length + Total Float) / (Critical Path Length). This index should be greater than 1.0. This index is measuring whether it’s reasonable to expect the project to finish on the forecast finish date.
Baseline Execution Index (BEI)
This one tells you whether you’re executing to your baseline. This calculation compares the number of completed activities to date to the number of tasks planned to be completed by the project status date. The formula is similar to the Earned Value Schedule Performance (SPI). Use Calculated # of Complete Tasks / BEI Baseline Count. The index should be above 1.0.
Using the tools
These checks can be very useful when you’re creating a schedule. No matter how many schedules you create, always try to validate. In most of the organizations I’ve worked in, the calculations were never necessary and in fact, the critical path check was only done a few times. We got everything done on time and within budget just fine. But it’s always nice to know that if you need additional tools, they are there.
Do you have other validation checks you do? Tell us in the comments.