Project Control
Projects are controlled by actively managing the issues, risks, and changes during the full project lifecycle. This is an extremely important area for the Project Manager to understand and manage. The following section details these areas.
Project issues are any questions, problems, changes to scope, concerns, or unexpected events that occur during the project implementation that may impact the project. These can be raised by anyone at any time during the project.
Each issue should be recorded separately in the Issue Log by anyone in the project team with the Project Manager having overall management of these. The following key items recorded:
- Unique Number
- Date Opened
- Current Status - Open, Closed, Transferred to Risks
- Issue - Brief description of the issue
- Priority - High, Normal, Low
- Actions to resolve - this should also detail the resolution when closed to allow review at the end of project.
- Owner of issue - person responsible for investigating issue
- Due date
- Date Closed
- Status - Open, Closed or New
Due Date and Date Closed should be the same however if not then this needs to be recorded and reviewed at the Project Implementation Review.
If an issue is deemed a risk or a change, the issue should be closed, the action column updated and the Risk or Change log updated with the appropriate details.
By maintaining an issue log throughout the project and regularly reviewing it, the Project Team and Board can be confident that all issues to the project are being tracked and actively managed.
Issue Management coupled with Risk Management prevents a reactive environment in the project by promoting pro-activeness and communication.
Risk Management is vital to the success of any project. Without Risk Management, a project can be likely to fail as risks will spiral out of control along with the timelines, cost and quality of the project.
Risk can be defined as "any chance of exposure to the adverse consequences of future events". Within a Project, risk is anything that causes an adverse impact onto a product which may affect the defined targets and milestones.
The impact of risks will be greatly reduced by proper analysis and planning prior to the project starting and then regular reviews by the Project Team and Project Board alongside the management of risks during the implementation of the project.
For further information refer to:
Risk Analysis
During the feasibility and planning phase of the project, all risks should be identified by the team and logged in the Risk Register. Review of lessons learned logs and brainstorming exercises should be used to identify all risks to the project, along with suggestions for the mitigation of the risk. Even if one team member thinks it may be a risk but unlikely to occur it must always be documented. Murphy's Law states that this one risk will be the one that goes wrong and has not been planned for.
Each risk should be evaluated, assessed and appropriate action implemented accordingly. All risks should be documented in the Risk Register. The following are suggested risk management strategies:
- Eliminate risk
- Reduce likelihood
- Reduce consequences
- Mitigate the risk
- Transfer risk
- Investigate further
- Accept risk
Denial of risk is not a strategy that should ever be used!
Risk Register
As mentioned, previously, Risks can be raised by anyone in the project team then in discussion with the Project Manager the Risk should be added to the Risk Register with the Project Manager having overall management of these. The Risk Register should contain the following key items:
- Unique Identification Number
- Date Opened
- Current Status - Open, Closed, Transferred to Risks
- Risk - Brief description of the risk
- Risks Category - Budget, Data, Management, Resources, Schedule
- Raised by
- Risk Owner
- Risk Comments/Mitigation - this should also detail the mitigating actions used to reduce the risk, plus when closed to allow review at the end of project
- Risk Likelihood - how likely the risk will occur in the Project
- Risk Impact - what the severity will be to the Project if the risk does occur
- Risk Score - Risk Likelihood x Risk Impact = Risk Score
The table below details the categorisation used by Edinburgh Napier University in defining the status of a Risk.
- Escalated to the Project Board
- Date Escalated to the Project Board
- Project Board Decision
- Date Closed
All Risks that are amber and red should be monitored and discussed at the Project Board.
There are various ways to identify Risks for your project; these can be carried out with your Project Team through discussion as this also helps with ownership of the Risk.
● Lessons Learned ● Records
● Personal Experience ● Logs
● Interviews ● Assumptions
● Checklists ● Experts
● Brainstorming ● Intuition
Change Management
No matter how well planned a project is at the outset, change is an inevitable part of the project implementation process. If there is no control over these changes, the project will begin to degenerate which will result in the project schedule slipping and cost overruns, more importantly - frustration. People like to know what they are doing and when, they do not like their work load changing or being added to without good reason.
Changes can happen for a number of different reasons:
- Poorly defined scope at outset
- Request by Project Sponsor/ Board
- Business Requirements change
- Technical issues
- Previously unknown issues
- External influences
- Off-specification
It is the management and control of these changes that ensures a successful project.
Prevent Scope Creep - Ensure that the scope of the project is well documented at the outset and agreed by all. The biggest problem of any project is scope creep due to poorly defined requirements at the outset. If the scope is still unclear, ensure the project has stages where the project can be stopped, re-scoped, reviewed and agreed again.
Identify Change - The project team is responsible for highlighting any changes to the project. Any change will be initially documented in the change log. The owner responsible for investigating the change should then fill out a change request form which will include details about the change, the resulting impact to the overall project, priority plus the cost and hours for the change.
Control - Once the change form has been completed, the Project Manager must review this and agree the changes to the project. The Project Manager should ask the following questions
• What is the cost and who is funding it?
• Is it essential or desirable?
• What are risks?
• What is the impact to timescales, cost and scope?
• Does it match the business case?
Any major changes must be escalated to the Project Board and agreed. These changes and resolutions should be recorded in the status report and noted for the Project Implementation Review Report.
Schedule - Only once the change has been agreed, should the work be added to the Project Plan and the appropriate resource tasked with completing the project. These changes should be actively monitored by the Project Manager to ensure progress is continuing and there is no further impact to the project.
Please note that NOT all changes suggested need to be implemented for a project. The Project Board along with the Project Manager can decide that a project does not require the change and thus the project will be implemented without the "nice to have" feature or reduced functionality. These "nice to have" features can be added to a requirements list for a future Project.