From time to time on this blog forum, I have talked about PMBOK (Project Management Book of Knowledge) as an industry standard on areas of PM responsibility and best practices. If you are a new PM, this book paints the entire project management field with a broad brush of process and organizational recommendations. (What is PMBOK)
Chapter 3 of PMBOK introduces process groups whose responsibility it is to “ensure the effective flow of the project throughout its existence”. There are five recommended process groups:
- Initiating – defines a new project and obtains authorization to begin
- Planning – establishes scope, refines objectives, defines course of action
- Executing – oversees those processes performed to complete project work
- Monitoring and controlling – all processes required to track, review, regulate the project against the project plan
- Closing – finalize activities and formally close the project
Included within the monitor and control process group lives a responsibility that carries all kinds of hidden risks that can put a project in the ditch if not done well – integrated change management. In Chapter 4 of PMBOK, we are told that any stakeholder can request project changes – and believe me, they will!
Requests to change some or multiple aspects of a project whether its adding a data source, modifying the user interface, or improving performance are as likely as death and taxes. Writing for Evolt, Martin Burns reminds PMs of the many times that sales or senior management respond to a customer change request with, “sure we can do that”. The PM, product manager or process control person receives an email or a phone call that presents the change request as if it were fait accompli. So what do you do?
Tempting as it might be for a PM to declare “no changes”, “no way”, “never”. That approach pleases neither senior management nor the ultimate customer. Instead, Burns suggests not saying “no”, but saying something like, “Your request makes sense, but it raises potential risks, issues and effort that might cost time and money.” (Try to say this without a sarcastic tone)
The Hendon Group suggests that project managers or process control groups need to know the following about a requested change:
- Why is a change being requested?
- Does the change have a direct impact on whether the program/project goals and objectives, as stated in the Program/Project Charter, are met?
- Can the change be implemented in a subsequent project and/or phase?
- What impact will the change have on cost, schedule and/or quality of the currently defined scope?
Change requests must be documented and evaluated
A formal process to manage change is a “PM best practice”. This is even more important when team members are dispersed geographically, are working on a large project with interdependent modules, or when the project includes multiple organizations, according to a report from Forrester Consulting. Most software development companies, and all large companies in the Forrester survey, have formal change management processes. Almost half of the surveyed companies use automated tools to improve the efficiency and effectiveness of all their change management. An additional 36% of the companies use tools to automate some of their change management process.
Now, I want to state for the record that “formal” does not mean expensive, time consuming, or complex. It just means it is documented, socialized, enforced and used. I also recommend using some kind of tool to help with change management. The tool and process needs to be sufficient for your organization so there is NOT one tool that fits all.
Here are a few examples that span the broad spectrum of tools:
- Microsoft Excel (Yes it is probably the most used – especially in smaller organizations)
- An online Database or list such as MS SharePoint – allows multiple people to enter and manage data
- A Change Management tool targeted at software development:
- IBM’s Rational change tool suite
- Borland’s Software Change Management solution
- BMC’s Remedy Change Management Application
- A dedicated tool like SLAM’s Change Management Control
- An industry specific tool like Master Control for use in the FDA industry
- A PPM solution with an integrated change management application like Oracle’s Primavera or MS Project server
This is just a few of the ideas of how you can automate and support your change management process and give yourself more time to actually monitor your project better.
How does your organization management change requests? How successful is your process?
August 16, 2010 at 2:54 am
PMBOK is the basis for organzing activities to plan, do, track and report projects. However, it is not an absolute solution for any kind of project. For example, for IT projects, PMBOK does not best fit.
Thanks for the post.
August 16, 2010 at 6:43 am
Thanks for the observation – I agree the PMBoK is not a standrad but rather a collection of best practices.
Eric what part of the Body of Knowledge do you feel it doesn’t fit IT Projects? I have not had any problem applying and tailoring the guidelines of PMI into anything that was a “project”. I do acknowledge there are activities in the IT world that are really “work” and not projects.
Bruce
September 12, 2010 at 6:24 pm
Excellent post on a topic that is so informal in most organizations. In my experience, change management is much like project documentation – one of those necessary evils that no one wants to invest much time in – until a problem occurs and then they wish they had.
August 8, 2011 at 12:28 pm
This post was excellent! Well written and full of information. change management software is a necessary evil! But what would you do without it?
November 17, 2011 at 3:52 pm
[…] find some helpful hints and practices here: Role of Project Managers in Change Management, Project Management PMBOK – Monitoring and Change Control, and Planning Your Organizational Change. Best practice suggestions for change management […]