Eighth Myth (10 Myth of Software Project Planning)

Eighth Myth
Keeping backup/buffer in project schedule/plan is a bad practice.

It is bad if you make this buffer on fly without any concrete analysis and it is hidden to your clients/ management. Always maintain transparency with your client and each stakeholder of your project.
Please follow different techniques of reserve analysis and make it part of your contingency plan. Keep time and cost buffers/reserves, but after a thorough analysis and not on fly.

It is good to include contingency reserves into the overall project schedule to account for schedule uncertainty. The contingency reserve may be a percentage of the estimated activity duration, a fixed number of work duration or, may be developed by using quantitative methods. The contingency reserve may be used, reduced or, eliminated as per requirements. This should be clearly identified in the schedule document and should be known to each stakeholder of the project.
Reserve analysis compares the amount of the contingency reserves remaining to the amount of risk remaining at any time in the project in order to determine if the remaining reserve is adequate. Following are couple of methods/techniques you can use for your contingency plan:
1. What if scenario analysis
2. Reserve Analysis - Contingency reserves and management reserves
3. Proper use of Leads and lags in schedule
4. Expert Judgment, play a vital role in getting trust from management and stakeholders
5. Risk analysis and risk response planning, it gives better understanding on the reserves you need for your project.
6. Contingent Response Strategies, identifying predefined conditions where the reserves can be used.

Seventh Myth (10 Myths of Software Project Planning)

Seventh Myth
I review/modify my plan frequently and it is up to date, I do not need to baseline my project plan?

Baseline is the point where you finalize your plan and believe that the plan will be used to track variations and slack in your project. We baseline a project plan or, part of project plan so that we can compare the progressive plan with baseline plan at any point of time.
The project can be baseline to compare (at any point of time):
1. The Start and End Date of a project plan or, any particular task.
2. The variance in actual work.
3. The variance in duration.
4. The BCWP (budgeted cost of work performed) or, BCWS (budgeted cost of work scheduled) or, to track the EV (earned value).
5. The schedule variance
6. The Cost Variance
7. The variance in project budget
8. We can also calculate various budget/forecast related variances such as BAC (Budget at Completion), ETC (Estimate to complete), EAC (Estimate at Completion), VAC (Variance at Completion), etc.

As a whole, baseline is used to compare your project plan at various stages of project execution and guide you to take preventive and corrective actions. It is also a kind of exercise where you learn through your mistakes, various scenarios/risks/errors during project execution and can use this knowledge to plan effectively in your future plans.