Project Management Basics – Chapter 13 – Change Control

Change is inevitable - plan for it!

"It's a bad plan that admits of no modification." Publilius Syrus

"A good plan today is better than a perfect plan tomorrow." Proverb

I've taught thousands of students who were preparing for a variety of different PMI® certifications, and one of the topics that is often a challenge for them is integrated change control.

Let’s see if I can simplify that topic.

Predictive projects have several core principles, but the cornerstone is establishing a baseline. We gather requirements and decompose them. Decomposition is the technique of breaking down the work of the project until we can accurately estimate cost, time, and resources. The level where we can accurately make these estimates is called the work package, and all the work packages are in a document called the Work Breakdown Structure (WBS). The WBS is a hierarchical decomposition of all the work of the project, and once we have completed the WBS estimates we baseline the project.

We baseline the project by getting agreement on the scope (the work to be completed) the cost and the schedule. Changes to the baseline are addressed through integrated change control and are normally driven by preventative actions, corrective actions or customer requests. All changes beyond the delegated authority of the project manager are assessed through a standardized integrated change control process.

A change request is submitted and the impact is assessed across all portions of the project management plan. The impact of the change is documented and submitted to a Change Control Board where the final decision is made. If the change is accepted, the Configuration Management Plan ensures that all impacted documents are updated. With the accepted change request, the plan is “re-baselined” and we manage to the new plan. If the change is rejected, nothing in the plan changes.

Develop the plan and manage to the plan. All changes are assessed and accepted or rejected through integrated change control.

That’s it!

Agile projects don’t have baselines. The requirements are maintained in the product backlog in the form of user stories, and changes to the scope of the project are routinely made by adjusting the backlog. It is the product owners responsibility to ensure the user stories in the backlog align with the business benefits of the project. That is usually accomplished by aligning the user stories to the Product Roadmap which represents a high-level understanding of what features will be delivered and when.

There is no formal change control process in Agile.

Speaking of Agile, there have been some interesting posts about Agile rituals in the LinkedIn feed. I'll weigh in on that next.

Coda

A friend of mine’s daughter went to a local resort area frequented by young people. She was found to be in violation of that jurisdictions “open container” laws while walking on the beach. Here is where it gets interesting. The police officer could have recognized that this was a minor infraction and used it as an educational moment. Instead, they handcuffed her, put her in a transport van and locked her up for over 20 hours! She wasn’t read her rights nor was she allowed her free phone call. After 20 hours she was told that it was a “mistake” that they locked her up and that she was free to go. I couldn’t believe it when I heard the story. As someone who has been involved in civil law enforcement for over 30 years, it strikes me that heavy handed enforcement like this is sending exactly the wrong message to people who would normally be allies of law enforcement. How sad.

#project #projectmanagement #leadership #PMP