project tolerance

Project Tolerance.
Project tolerances define performance limits within which different areas of the project can retain autonomy. It quantifies the deviation from the activity and budget schedule detailed in a formal plan, which is permitted before reference should be made to a higher authority. The resources and timescales detailed in a plan are considered to be desirable; but whilst operating within tolerance limits a project or sub-project is still considered to be 'in control'.

Project Tolerance & Reporting Paths.
The reporting paths associated with project tolerance violations should reflect the organizational structure within which the project operates. It is recommended that the project sponsor passes control to the designated project owner with a predicted cost and timescale schedule. Associated with this will be a margin within which the delivery will be acceptable - the overall project tolerance. If at any point during the monitoring of the project the project owner felt that this limit might be exceeded then they should refer back to the project sponsor. At the next level the project owner together with the project manager assign sub-project tolerance levels, within which each sub-project manager can administer ongoing work. If the project is not sub-divided then the project as a whole is represented at this level. The sub-project manager need only refer back to the project owner; normally via the overall project manager, if they observe or anticipate that this tolerance will be exceeded. Different project tolerances may be allocated to individual sub-projects, than those that apply to the overall project. Any movement away from the plan that may violate the tolerance limits should result in re-planning and the submission of this plan to the next level of authority. This project tolerance is normally between plus or minus 2.5 and 5 percent. Project management staff can only effectively monitor the performance of a project, in relation to tolerance limits, through the provision of accurate performance data. The collation of this data is fundamental to accurate project monitoring - as detailed in the 'Controlling Projects' course.

Sub-Project Planning.
Sub-project plans should have a clear presentation format and should be kept legible at all times. Whatever other plans are produced it is normally this level of plan that is the main source of day-to-day control over the project. This plan should be discussed and explained to the project team as early as possible. If the sub-project plan is supported by detailed plans or individual work plans then the level of detail required in the sub-project plan is likely to be significantly reduced. Conversely, if the sub-project plan is generated as the lowest level of plan relating to a project then it will need to contain sufficient detail to be used at the practical level. It is important that the sub-project plan is kept up-to-date and reflects the actual status of the project. It should also be visible to all relevant members of the project team, enabling them to see planned changes and slippage as soon as possible. For this reason the sub-project plan is often placed in a prominent position on a notice board - or made easily accessible over a network, where software planning and scheduling tools are used.

The Remedial Plan.
Remedial plans represent a mechanism by which the existing plans can be significantly changed - to reflect a change in circumstances or to address the needs of a project that may be going out of control. They should only be produced in situations where costs or timescales have been, or are anticipated to, exceed the tolerance set for the project or sub-project. In these circumstances it is important that the project manager notifies the project owner that a tolerance violation is likely to occur.
The remedial plan should be prepared under the authority of the project manager, with assistance from the appropriate sub-project managers and other team members, as required. The remedial plan will serve as an alternative to the existing project, or sub project plan, which it will replace if it gains approval from the project owner. Therefore it must contain all of the information normally held in the existing plan. In addition, it should contain details of the situation that has arisen and the options that were considered to remedy it.

Avoiding the Remedial Plan.
The remedial plan represents a mechanism for significantly altering the existing plans - should the circumstances of the project change or a tolerance violation be anticipated. However, the production of a remedial plan should not be seen as mandatory in these circumstances. In practice, project management staff would normally consider several alternatives before resorting to the fairly radical process of submitting a replacement plan for a significant area of the project. Where it is felt necessary to produce a remedial plan it is important that the project manager notifies the project owner that this is the case - enabling them sufficient time to convene a meeting at which the plan can be considered. If it is approved it will effectively replace the now out of date project or sub-project plan. Failure to gain approval may have serious implications for the project - which will remain unstable until remedies for the highlighted problems are agreed.

The Detailed Plan.
Detailed plans should be used for day-to-day monitoring of a specific area of the project and should identify all of the products and activities that the area of work is
concerned with. These plans should be produced as and when required to expand the level of detail shown in the sub-project plan. They are derived from the sub-project technical plan, and will normally require the approval of the sub-project manager. The precise level of detail required from this level of plan will be determined by the overall framework of plans that is being used to administer the project. In one project scenario the ideal framework might include a project plan, several sub-project plans and detailed plans - as required. In another scenario, the project may be best served by a project plan supported by several detailed plans - with no need for sub-projects and their associated plans. It is normal to consider the need for detailed plans at the same time as the sub-project plan is created. They should be produced by a designated task leader or the sub-project manager themselves.

Plan Derivation.
Detailed plans enable the team members to see how a discrete area of work relates to the overall project and to identify with its specific aims and objectives. These plans should be discussed and explained to the relevant project staff as early as is possible in order to foster a greater degree of shared ownership and to enable project staff to raise any issues and concerns that they may have. Whilst the detailed plan may comprise numerous separate components, depending on the complexity of the project; the detailed technical plan is the key plan against which the area of work will be managed and monitored. It is this plan that should highlight all of the deliverables and milestone rates that are required. It is important that each detailed plan is kept up-to-date; reflecting the situation as it is and not just as it was originally planned to be.

The detailed technical plan shows a detailed breakdown of the relationships between activities relating to a discrete area of work being analyzed. The detailed resource plan shows a detailed breakdown of the resources required for a specific major activity or related group of activities and is derived from the detailed technical plan. Together these plans support a more detailed task analysis, typically where cost or timing may be a critical or contentious issue. They are used to show a level of detail that would be a distraction on the higher level plans.

The Individual Work Plan.
The individual work plan represents a refinement of the information normally portrayed in the detailed plans. However, the flexibility of the plans architecture may mean that whilst no detailed plans are required individual work plans are nearly always required. Where this is the case, they can be derived directly from either the sub-project plans or even the project plans, in the case of small and straightforward projects. The individual work plan is the lowest level of technical plan and defines the tasks and responsibilities of a specific team member and therefore has no corresponding resource plan.

Plan Derivation.
Individual work plans should be derived from the lowest level technical plan that already exists - a detailed technical plan, if one has been created. Typically the individual work plan should cover only a short period, for example, the production of a single product or a series of activities - typically spanning between 2 and 4 weeks. The precise level of detail required from this level of plan will be influenced by the overall framework of plans applied to the project. However, this level of plan should document the day-to-day targets and expectations for individual members of the project team. The individual work plans should be discussed with the relevant project team member as early as is possible. These plans can also serve as the basis for interaction between the individual team member and their task leader, or manager, in relation to their progress and personal performance.

TOP <PREVIOUS NEXT>