Managing changes to the project scope and schedule

5 Oct No Comments

Managing Changes to the Project Scope and Schedule






Risk Identification process

  • Based on the unique characteristics of your project, develop a change control process for addressing changes to the project scope and the project schedule

During the technical phase, it was reported to the shareholders that the application software installed in the computers of the organization was working or operational on most computers but not to all of them as planned.

Risk Assessment

According to (Lock, 2017), risk assessment involves doing an evaluation on the risks identified and categorising them or criticising them. The evaluation or assessment done by the project team was that the organization failed to give out its report on the operating software that was being used by the employees.

Risk mitigation plan

The project team came up with a mitigation plan by risk sharing where they incorporated the information technology staff of the organization to solve the problem. (Lock, 2017)

Contingency plan

The contingency plan that the project manager came up with was that the organization to install the computers with a 64 bit operating software for the application software to work.

PERT Chart

  • Submit an updated Gantt chart and network/PERT diagram based on fast tracking one activity and crashing one additional activity. Include an explanation to your sponsor and key stakeholders describing the requirements and impact of these two adjustments and any schedule compression risks that should be addressed based on the unique characteristics of your project.

Gantt chart

TASK NAME Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7
Risk identification              
Risk Evaluation              
High risk impact              
Risk Mitigation              
Contingency plan              

It was essential to fast track the activity on risk identification because there was an already existing checklists that was present from previous projects. As shared by (Marchewka, 2014), crashing risk evaluation while fast tracking risk identification is impossible because while analyzing or looking for potential risks of the software, one is able to come up with risks and their probability of occurrence. It was important that we crash risk evaluation while fast tracking risk identification so that we could establish the high impact risks and the low impact risks. This would help us in sorting out specific risks and find ways of solving it before it adds more harm to the project. If such was not done, the organization would have failed to buy the application software and would have brought financial loss.


D Lock. (2017), The essentials of project management

JT Marchewka. (2014), Information technology project management

Click following link to download this document

Managing changes to the project scope and schedule.docx