Managing the Schedule Variance

You see that your schedule is slipping. The gap between the planned and actual schedule metrics is growing. If you are the project manager, what will you do?

Start with a causal analysis. Inspect your process. Managerially, you could find scope for resource optimization i.e., there may be idle resources that could be allocated to tasks. Consider reallocation for better optimization. Look at tasks, draw network diagram and see if parallelism could be identified and thus schedule could be optimized. See if the project could be crashed by increasing the cost. See if the process could be tailored such that some of the activities could be eliminated from the plan and yet the product quality remains not compromised. It’s hard, but may be you unearthed some earlier mistake and thus ended up reducing the schedule. Re-estimate. Perhaps, now you are at a better position to estimate. Your new estimate may suggest that you could catch up! Establish backward traceability to see if there is no gold-plating attempted. Consider prioritizing your requirement and discuss with your architects if these requirements could attract a solution that could be developed sooner. Do some risk analysis and see if the activity on the critical path that is of very high risk could be sub-contracted. If you are too down in your schedule that it is now impossible to look back at changing the solution, consider meeting your architects and discussing the option of using COTS components. However, be warned that use of COTS components has lots of risks associated with it. For example, how will you accommodate future changes in functionality or what if there are legal implications? Or, organizational reuse library could contain some useful components to save your time. If your architecture and design could allow better work decomposition and reduced dependency, you may save some time there. Preparing ahead and getting some templates and checklists ready may reduce time spent on all phases. For example, ensure you have all review checklists ready and test case templates in place. Documentation becomes more consistent, easier and faster when there are templates and checklists in place. You could reduce testing time if you focus on reviews. In fact, review yield has become one of the major elements in the quality goal statement. Proper design may save time during coding and adhering to good coding standards may ease testing. In short, following the best practices can save you lot of time and make you repeatable with respect to success. However, if after doing a causal analysis, you find that it is impossible to shrink the schedule any further, the last option is to beg to your customer for more time or allow re-scoping. Sometimes, just asking may be a bad option to negotiate. As Tom Gilb says, you may do some brilliant minor releases, win the customer’s trust and try then to negotiate tactfully (offering more low risk features) to buy some time. Understand that not all the above may work for all the projects. You have to make the right trade-offs between resources, cost, effort and relationships (with both employee and customer). Of course, hopes are to keep quality uncompromised.