Change Management (Practical Project Management Series). This time the subject is ‘change management’
First of all I would like to make a clear statement: not properly executing change management during a project is a guarantee for problems.
I would like to use building a house as a metaphore in this context to explain change management.
You have decided to build a house (‘business case’). Starting with some ideas you build a house in your mind and you decide to contact an architect to make a concrete picture of your ideas.
The architect makes a drawing and calculations based on your ideas and requirements and a design is being produced. The baseline of your house is set.
Then next step is to hire a contractor who is actually going to build the house. The contractor works based on the design and budget as agreed.
During the construction of the house you find out that the location of the bathroom upstairs is not handy. Two bathroom walls are shared with bedrooms. You want to have the bathroom at a different location.
This is a change and depending on the stage of construction the impact might be small or big. In case all piping has already been installed in the concrete you might face a big change. The contractor needs to determine how much extra work is involved, what additional material is required and how much additional time is required (and the impact on the total planning).
The contractor needs to document the whole process (in case you agree of course), replan the work and starts only after formal approval by you.
Let’s make the step to the ICT world.
In principe change management is similar to the story above. However, a number of items is different:
- Project size. The development of a significant software application requires much more financials than building a house.
- Contractors have quite often plans available of similar houses so they have also gained knowledge and experience with these types of houses. Within the ICT world this is very seldom the case so each project is really unique.
- In the construction world a lot has been standardised resulting in lower and less risks. This is rather different in the ICT world.
- Physical versus abstract. A house is easy to imagine. This is much harder for a software application which is abstract.
What are the pittfalls regadring change management? Think about items such as:
- The developers don’t want to disappoint the client and things are being ‘arranged’ on the fly. This might not be visible for the Project Manager. Beware of this type of issue when the developers are working at the client’s premises and the client has direct contact with the developers.
Make your team members very aware of this and that all changes need to be routed via you as Project Manager according to the change management procedure.
- In the same line is additional work that the client tries to arrange informally. Don’t deliver a Rolls Royce while an Opel Vectra has been sold.
- A change might have impact on design, baseline and contract. Contractual changed require normally quite some time which will have an impact on your planning as well.
- The ‘waterfall’ model in software development is being replaced more and more by the ‘agile’ model. The Agile model works with short time periods of weeks (‘sprints’) and is intended to deal with changes easily
A different approach nowadays is required in order to have a quick time to market and to deal easily with changing requirements.
The next time I’ll describe ‘financial management’.
This is a ‘blog’ article by Lex van der Heijden regarding practical Project Management. For questions/remarks I’m available via [email protected] or via LinkedIn (nl.linkedin.com/in/lexvanderheijden/).