Project Management

Agile Integrated Change Control

From the Agility and Project Leadership Blog
by
A contrarian and provocative blog that goes beyond the traditional over-hyped dogma of "Agile", so as to obtain true agility and project leadership through a process of philosophical reflection.

About this Blog

RSS

Recent Posts

Has Scrum outlived its usefulness? Should Scrum just go away?

The rise of Agile’s SAFe is like a bad episode of the movie Groundhog Day

Marcel Proust’s recursive novel: Why the concept of iteration in Agile is shortsighted

Forecast for 2015: The beginning of the end of Agile?

Google considered the best US company to work for due to HR agility

Categories

Date

linkedin twitter facebook Request to reuse this  


Change happens and is a fact of life for anyone involved in a project.  How a project manager deals with changes throughout a project determines whether a project succeeds or fails and this needs to be integrated throughout the lifecycle of the project.  According to the PMBOK 4th edition, integrated change control "is the process of reviewing all change requests, approving changes and managing changes to the deliverables, organizational process assets, project documents and the project management plan."

For the project manager who has to work within a traditional process driven environment and/or desires to incorporate Agile practices to align with the PMBOK driven one, must keep in mind that integrated change control is not much different in Agile and the PMBOK.  Agile at heart is always driven by the desire to run the minimalist process that achieves the most value, thus the change control process must be streamlined and integrated into the daily routine of team members, e.g., the daily stand-up meeting.  Process changes must be owned by the team, whereas product changes are owned by customer represented by the Product Owner as is typically done in Scrum.
 
These changes are documented in the ordered product backlog.  During release and iteration planning, these higher ordered items move from the backlog to actually being coded, tested and accepted by the customer at the end each iteration.  The customer feedback at the end this iteration become the integrated change process that enable the team to make the necessary adjustments.  The product backlog may get re-ordered and re-shuffled for the next iteration.  Seen in this light, all members involved with the project become the equivalent of a change control board (CCB) outlined in the PMBOK.
 
One major change in this practice is how the Agile PM acts more as a "go-between" with the customer and the team.  In a traditional PMBOK driven process, the PM would be responsible for driving and managing the changes in the project management plan, whereas in an Agile driven one, he/she acts more as a facilitator for the customer and team to reach a collaborative decision regarding changes to the product backlog items.  The process of re-ordering and re-shuffling items in the product backlog with customers and team, make it easier for all concerned to see the tradeoffs involved when something that needs to get added causing something else to get dropped.  For very malleable products like software, it would be more flexible to use this then a rigid change control list.

Posted on: November 29, 2011 11:50 PM | Permalink

Comments (1)

Please login or join to subscribe to this item
avatar
Alaa Hussein Program Manager| MEMECS Baghdad, Iraq
Thanks for sharing

Please Login/Register to leave a comment.

ADVERTISEMENTS

"Sacred cows make the best hamburger."

- Mark Twain

ADVERTISEMENT

Sponsors