It’s nearly impossible to scope a project with total accuracy from the outset, and this video explains how to deal with the inevitable changes that arise across a project’s life cycle.
- It's generally pretty difficult to scope a project with total accuracy at the start of a project. As products move through their life cycles, chances are you'll need to make some changes to deal with risks, issues, and stakeholder feedback. In this video, we'll go through the sources of change, the cost implications of change, the change control process, as well as the benefits and disadvantages of a formal change control. While scopes can change projects should always start with a well-defined scope baseline that all relevant parties agree to. This will help the project avoid scope creep and will allow legitimate change to happen in a well-reasoned and reliable way. With that said, what are the sources of change in a project? Well, there are two main sources of change, internal and external. Internal sources of change include things like technical errors, where something has gone wrong and needs to be dealt with and funded by the baseline budget. Incorrect estimates, which might've come from not fully understanding the effort required to complete the deliverables and resourcing issues. If, for instance, resources are reprioritized for other work. External sources of change on the other hand, come from outside the organization. Things like the business justification for the project might be impacted by external factors. The requirements for the project might change due to external pressures or the technology you're using and the market you're in might shift. As you can tell, there are loads of potential things that could create a need for change, and if you find yourself in a situation where you need to move into a formal change control, you'll need to understand what the potential costs of this are. To begin with, and as a rule of thumb, change at the start of the project tends to be cheaper and it becomes exponentially more expensive throughout the project life cycle because of the potential needs for major rework. This means you should consider refusing any changes in the deployment phase given the potential large costs. The change control process itself is relatively simple as you can see here. Initially, a change will be requested and whoever is requesting it should provide you with all the necessary information that you need. This should be captured in a change request or change log. Next, the request will be reviewed, which should take into account the potential impact on the project outputs and benefits, and determine whether a full assessment is needed. If it isn't the next step in the process would be to make a go or no go decision. However, if you do need to do an assessment, then all of the options for change need to be evaluated in detail, to get an idea of the new costs, time and quality implications of the change. This will then go to the sponsor for their decision and if approved will be implemented. All implemented changes need to be registered in an updated version of the baseline plan. So, that's the standard process of formal change control. For the last part of this video, let's quickly go through a few of the benefits and disadvantages of change control. As I mentioned at the start of the video, change control is great for minimizing scope creep. However, it can create a change adverse culture in an organization, too. It can help create better communication channels between the project team and sponsors, but at the same time can be quite bureaucratic. Lastly, it can help reduce the chances of a project over running its schedule or budget. But, if it's done slowly change control can stop the implementation of a change being done quickly. And that's it for this video. Change control is an important process you'll need to use in most projects you do. In this video, we've covered what it is, how it works, and some of the benefits and disadvantages that come with it.