1. Project issues

A project issue is an event or condition that has negative consequences for a project. The term implies a situation that is recoverable or that can be mitigated in some way.

1.1. Examples of Issues

The bus breaks down on the way to college.
You need to have a meeting with a team member, but they are off sick.
A piece of material costs more than you budgeted, and you don’t have enough money.
A piece of work you thought would take 5 days takes 10 days.

1.2. Resolving issues

Applying a structured process makes it more likely issues will be resolved successfully.

Make sure the issue is identified and understood.
Develop some appropriate action to resolve the issue.
Allocate someone with responsibility for performing this action and so resolving the issue.
Set a date for it to be resolved by.
Manage the task of resolving the issue by the set date.

1.3. Project Issue Type

Track the progress of the resolution with a clear label identifying the issue’s overall status.

Open – The issue has been identified, but no action has yet been taken.
Investigating – The issue, and possible solutions, are being investigated.
Implementing – The issue resolution is in process.
Escalated – The issue has been raised to management or the project sponsor/steering committee, and directions or approval of a solution is pending.
Resolved – The resolution has been implemented, and the issue is closed.

Tip:

Use ‘traffic lights’ when reporting issues.

Red – Cannot proceed before issue is resolved.
Yellow – Resolution in process, and you’ll be able to proceed soon.
Green – Resolution implemented, and issue no longer exists.

1.4. Project Issue Log

Issues – otherwise known as problems, gaps, inconsistencies, or conflicts – need to be recorded when they happen.

When you create an issues log, you provide a tool for reporting and communicating what’s happening with the project. This makes sure that issues are indeed raised, and then investigated and resolved quickly and effectively. Without a defined process, you risk ignoring issues, or not taking them seriously enough – until it’s too late to deal with them successfully.

The importance of Issue Log:

Have a safe and reliable method for the team to raise issues.
Track and assign responsibility to specific people for each issue.
Analyze and prioritize issues more easily.
Record issue resolution for future reference and project learning.
Monitor overall project health and status.

1.5. Project issue and a Project risk

An issue differs from a risk in that a risk hasn’t occurred yet.
Issues and risks are not quite the same thing. However, the exact nature of both is largely unknown before you begin.
With risks, you usually have a general idea in advance that there’s a cause for concern. An issue tends to be less predictable; it can arise with no warning.

2. Project Risks

2.1. Definition

Thinking about potential issues is called predicting risks.

For some risks you can take action early to prevent them becoming issues.
The list of possible risks is almost infinite, so you need a way of focussing only on the most important risks. This can be done by looking at the likelihood that the risk will happen, and the impact on the project if it does.

2.2. Risk Matrix

A risk matrix is a matrix that is used during risk assessment to define the level of risk by considering the category of probability or likelihood against the category of consequence severity.

2.3. Categories of risk

Strategic risk. These are risks to the strategic objectives and goals of the project. They affect areas of the project life-cycle such as planning and finance. Mitigation of these risks requires the commitment of senior management.
Operational risk. These risks generally have a short-term impact, affecting daily operations and activities of the project team.
Compliance risk. These concern the need to comply with the documented statements and regulations.
Financial risk. These are associated with the financial structure of the project.
Knowledge risk. These refer to the effective control of knowledge resources. It includes abuse of intellectual property, loss of key staff and technical inefficiency.

2.4. Risk mitigation

Ignore it all together
Monitor the risk
Reduce the likelihood of it occurring
Reduce the impact if it does occur
Have some contingency plan in place

2.5. Risk status

Open. Risk identified but no actions agreed.
Actioned. Actions have been agreed and responsibility allocated.
Closed. Risk no longer a threat to this project.
Increasing. The likelihood and/or impact has increased since the last review.
Decreasing. The likelihood and/or impact has decreased since the last review.
Issue. The risk has become reality and is now an issue for direct management.

2.6. Changes in project

A common occurrence in a project is the customer asks for a change in the deliverables. This will affect the project plan and could impact on the timeline and cost of the project.

A structured approach to managing change:

Have a change control process in place and make sure changes do not happen without it.
Assess every change in terms of the impact on the project. Does in increase the time, budget or level of risk of the project?
Accept the change only once the customer has agreed to any additional cost, time or risk.