There are many benefits to encouraging the development of a non blame culture.
The obvious one is that it will encourage people to raise issues that they may otherwise have kept quiet.
There is no doubt things will go wrong in a project but the suppression of bad news will only weaken the future efficiency of the project and its individuals.
Good leadership here is essential, all aspects of leadership are covered in more detail in 'The Complete Leadership package'.
It is a good idea, at the start of a project, to state that mistakes will be made, and other issues will appear unexpectedly, and that you will expect people to raise problems.
If possible you want people to raise fears of impending problems to catch them early.
Explain that the aim is to solve issues and ensure they are not repeated with lower emphasis on blame.
That is, you expect a good team to learn from mistakes.
Naturally, there is no excuse for incompetent actions either.
One of the best, and most common, options for resolving a problem is to use a creative thinking technique, for example, by brainstorming.
This will hopefully produce a solution that has minimal impact upon performance, time, cost and quality measures.
It can be time consuming and may be best applied to more complex problems or where the issue has a major impact on the project.
The brainstorm process is discussed elsewhere.
This system will provide options which in turn will need evaluation for their ability to reduce the impact of any issues.
Their cost must not be prohibitive.
A contingency budget is often provided based upon contingency plans.
These will be drawn up having assessed known potential risks.
They will usually be subject to the existence of a ‘trigger’ that leads to their implementation.
This sort of budget does not really cover the need for funding any solutions to ‘new’ issues which may arise.
This is why it is very important to plan well.
However, if the Project Manager does use some of this fund then he or she must be aware that once it has gone there may be no chance of getting approval for additional amounts. This might arise if a potential risk does not occur and there is no chance of it re-occurring.
The use of contingency and tolerance within PRINCE2® is treated differently.
For PRINCE2 2005:
Contingency may be used where a specific risk has been identified.
Any risks (threats or opportunities) to the project will be known and analysed as part of the process Analysing Risks (PL6).
If the risks are such that contingency plans have been prepared the Project Manager should go to the Project Board for a contingency budget.
This would be needed should the risks occur.
For PRINCE2 2009:
Contingency is not used instead tolerances are set.
A PRINCE2 [see ‘The Complete Project Management plus PRINCE2’] principle is that projects are managed by exception, setting tolerances for project objectives to establish limits of delegated authority.
Tolerances define the amount of discretion that each management level can exercise without the need to refer up to the next level for approval.
[see Progress - purpose]
Tolerances are the permissible deviation above and below a plan’s target for time and cost without escalating the deviation to the next level of management.
There may also be tolerance levels for quality, scope, benefit and risk.
[see Progress - Progress defined - Exceptions and tolerances]
A common method is to apply more resource, either personnel (internal or external, usually temporary) working overtime,
or even the use of additional equipment, to make up for any slippage. This will increase costs.
Any impact on other areas of the plan needs to be assessed.
Other resource may not be readily available and the Project Manager may have to consider priorities.
Letting tasks slip is usually frowned upon.
If no solution can be found then the only answer may be to allow the task to slip.
This may affect the end date if the task enters the critical path.
Remember, there should be some contingency within the plan to allow for extra cost and time.
If it is there use it; but once it is gone it is gone. Only use it as a last resort.
If it is critical to meet the deadline and none of the above approaches works it may be necessary to ‘de-scope’ the task.
The completion of any task is measured by its deliverables.
This means give the customer less than what he or she was expecting.
This may apply not only to a task but to the final product of the project.
Naturally, this has to be agreed by the stakeholders.
Some aspect of quality or performance will be compromised by modifying the specifications.
We should always review any issue to make sure it doesn’t happen again.
It is good practice to document issues and actions.
PRINCE2® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.