BE THE FIRST TO KNOW
Subscribe to the SPOCE newsletter to receive timely updates about new courses, venues and discounts!
Change is where your original approved (baselined) plans and products need to be altered for one reason or another. Due to the nature of projects, changes to what the customer had originally specified as being their desired requirements/solution are highly likely to occur. In fact, pretty much everything you plan to do in life tends to change, even with simple things like going shopping. Let’s face it, how often do you write up a shopping list and then only come back with the items that were on the ‘original’ list? Come on, be honest, not often I’m sure and of course, as a result, your time out shopping is increased, as does the cost of your shopping bill!
Here’s an example of a typical and possibly frequent shopping list amendment:
• Milk
• Fruit
• Vegetables
• Bread
• Eggs
• Milk
• Fruit
• Vegetables
• Bread
• Eggs
• Wine
• Cake
Ok, that’s just an example for a bit of fun, but be aware that making such changes to your products/requirements will often have a knock-on effect to your ‘original’ plans, as well as other products and activities. For example, purchasing and consuming the wine and cake may prevent you from watching a TV programme that you’ve planned to watch because you end out falling asleep! Hey ho, not a big deal I guess, but you should certainly consider what impact any proposed changes may or will have on other aspects of project-related work. You should also be mindful that some changes, even very small ones, can make things radically different, for example making just a single letter change to the word ‘chance’, makes ‘change’!
With that in mind, don’t try to ‘chance’ it that change won’t happen, because it almost certainly will…so expect it, accept it and be prepared to manage it!
So, change control is certainly an aspect of project management that unquestionably applies to projects and it can be said that if there’s no change control, then there’s no control at all! A project’s original specification/scope (shopping list) is highly unlikely to remain the same throughout the life of the project and consequently your project’s original planned timescale and cost targets are likely to change (most likely leading to an increase in cost and time). This is mostly because projects are the way by which business change is introduced. Changes applied to a business will be something ‘new’ and sometimes highly innovative, and therefore we are unlikely to know absolutely everything about what’s required to make that business change right for the business, right at the beginning of a project. Hence changes to the initial project requirements and scope is very likely.
Another reason for change occurring though is often down to good old ‘human nature’. We simply like to throw new ideas into the mix as we tend to feel quite satisfied and motivated when an idea has been accepted and implemented, for which you can then say “that was my idea…I suggested that”! With that in mind, we can rather confidently say that changes are pretty much inevitable during the life of a project, particularly where the solution is evolving and certainly so in larger, more complex projects.
Pulling on the ‘human nature’ factor, people within the customer’s environment (i.e. where the products created by the project will be used), in particular those who will of course be using the products, are likely to have ‘lightbulb’ ideas whilst they see the solution evolving and subsequently ask for changes to what they had originally specified, such as changes in a product’s specification and/or additional products being requested. This of course is absolutely fine, as long as any proposed changes are properly assessed for the impact they would have on the project’s objectives (i.e. you should consider what impact any proposed changes will or may have on your planned performance targets of timescale, cost, quality, scope, risk and benefits (particularly on the benefits being sought and the viability of the project).
Some changes can of course be bad ideas and may well have a negative impact on the project’s performance targets, such as timescale and cost and particularly the benefits being sought, but other changes can be good for both the project and indeed the end solution, although you won’t know this unless you properly assess the impact of a proposed change. Like I’ve said, don’t take the ‘chance’ that change won’t happen. And, as tempting as it might be as a Project Manager, certainly don’t try to prevent changes to what was originally agreed/planned, as some changes can lead to a far better solution with increased benefits, essentially strengthening the viability of the project.
Basically, what I’m saying is…
...change can be GOOD”!
Here are a couple of examples of how to make the impact of change a successful one. In part 2 of my blog next week I will be expanding on this list further and giving you an excellent example of an issue and change control procedure.
Apply Document / Version Control.
Changes to products and the different versions of products need to be properly managed. Your procedures, tools and responsibilities for capturing and managing issues and changes, including the tracking, protecting and version controlling of the project’s products, should be agreed and documented right at the beginning of your project. It’s also important to understand the ‘relationships’ between products, so you can clearly see whether a proposed change to one product would mean making changes to any other related products. In some cases, changing a product without considering what else would also have to be changed (perhaps to keep things consistent across different products and/or to ensure the solution will still be fit for purpose and indeed in some cases be a ‘safe’ solution) is absolutely critical. For example, imagine making a design change to the brake pads of a car, without considering the potential changes which may be required to the brake discs….putting it quite simply, the car may not be capable of stopping!
When any required changes have been made, any changes in versions of products should be recorded and ‘linked’ to the issue which caused the product version to change. If you don’t make a note of this, you won’t be able to answer important questions such as “what caused a product to change”, or “what is it that’s changed exactly?…what’s the difference between version 1 and version 2”…etc. You should also ensure that, where relevant, any copyholders of a changed product are given the latest changed version, otherwise you’ll have people working from different versions of the same product. Also make sure any old versions are ‘archived’ away, NOT discarded.
Restrict Unauthorised Changes
It should also be agreed as to ‘who’ is permitted to authorise changes (known as a Change Authority) and indeed to make changes to the approved products. You shouldn’t allow everyone to have access and make ‘willy-nilly’ changes to the products whenever they feel fit. Document management systems/software can be used to help restrict access and prevent unauthorized changes being made.
Click here to find out dates for change management on our Change Management training page
Richard is the lead PRINCE2 trainer at SPOCE Project Management and runs many of our classroom and virtual classroom courses.
Call; 0800 177 7623 / 0800 17 SPOCE
Email: Clients@spoce.com
Comments