by Philip Lop

Created on: April 01, 2011   Last Updated: April 05, 2011

Change request management is a critical part of any project. It is almost impossible to establish customer requirements from the outset of a project that will remain consistent throughout the duration of the project. Robust change management ensures that these changes are tracked properly, that the impact on resource and budget is clearly understood and that the project team is able to deliver the appropriate outcome(s) for the customer.

Agile project management lends itself very well to change request management. Indeed, one of the primary benefits of the agile methodology is to create project teams that are quickly and easily able to adapt to the demands of ongoing change requests.

In a traditional project environment, it can require significant effort to manage new requirements through a change request process. Very often, this leads to waste and/or re-work, as the development path is fixed from an early stage in the project. It is more likely that change requests will be managed separately and distinctly when they arise during this type of project.

Agile projects create an environment where customer requirements, interpreted as user stories, are estimated, prioritized and then managed in distinct, contained phases of development, often referred to as sprints or iterations. Within an iteration, the project team will establish the total number of development hours available and will then slot user stories into a work stack (referred to as the product backlog) to identify which requirements will be delivered within each iteration.

Part of agile working is to introduce a regular series of progress reviews. Development teams review achievements daily, looking for areas of opportunity or dependency and resolving them as quickly as possible. At the end of each sprint (which often lasts no longer than two weeks) the product backlog is reviewed. Additional requirements can be managed at this stage. This means that change requests can be introduced to the development work stack far more quickly than a traditional project would allow. Agile projects look at development resource in totality, understanding that these hours can be spent on new work, dealing with defects or addressing changes.

Under agile, the product backlog would then be reassessed and reprioritized with one of three outcomes:

1 – An additional sprint or iteration of work will be added, assuming that there is no overall increase in budget and that it is acceptable for the work to be scheduled

• 1
• 2
• Next Page >>