Managing Change Requests in Your Projects

Change request forms are used to help the project team find, evaluate, and confirm how changes to the project are handled. How change requests are handled can directly impact the cost, quality, and schedule of your project. As a result not all change requests should be approved. Evaluation of whether or not to approve a change request will depend on its impact to the project initial requirements. Effectively managing change is particularly challenged in organizational cultures where specific requirements gathering are hindered as a result of:

• Conflicting priorities


• Conflicting roles


• Non-dedicated team members (multi-tasking, etc.)


• Ineffective product ownership (sponsors, etc.)

A generic requirements document confirms the following:

• Requirements definition


• Output (results)


• Scope (in scope & what falls outside the scope)


• Acceptance criteria (if X does/has Y the deliverable is accepted)

Confirming project requirements faces increasing challenges in environments who meet the following characteristics:

• Experience: Inexperienced with project management methodology.


• Structure: Uncommitted to following the project management methodology (use a hybrid form, lacking focus on the tools, mechanisms, and outputs required throughout the project life-cycle).

The project owner, sponsor, manager, and analyst need to confirm the project requirements during the planning stage and before the project and executed. Project owners (or sponsors) that attempt to delegate this responsibility to the project team are inadvertently adding project risks.

Although some cultures are less likely to use the change request process it is still advised to avoid:

• Scope Creep: This involves project stakeholders requesting new deliverables and goals be added to the project.


• Cost Overruns: This involves more costs as new deliverables are included in the project, and the schedule is prolonged.


• Impact to Quality: This involves decreasing quality as more is attempted with fewer resources (or within the same constraints).


• Impact to Schedule: This involves adding work that requires the schedule being prolonged, potentially being unavailable to the customer(s) when needed.

A case example: Technology design and migration project

The following case example is described in brief but helps to establish the importance of confirming the requirements up front AND using a formal change request process. The project a colleague was working on was the updating and migration of the corporate website. The project sponsor, and consulting representative, had given a presentation to the leadership team two years prior. The PowerPoint presentation was considered a great success, and the plan was approved to move forward.

Now the project is reinitiated two years in the future. A temporary project manager was brought onboard to facilitate the project. Unfortunately the following were observed (and communicated to the leadership team) during the schedule 6 months to complete the project:

1. Sponsor: The project sponsor was not aware of the most recent status update


2. Schedules: The project was also being implemented concurrent with agencies (also updating and migrating their websites)


3. Charter: There was no charter available for the project manager; for the single agency, or the larger project


4. GANTT: There was no GANTT chart available for the project; for the single agency, or the larger project


5. Risk Register: There was no risk register available for the project; for the single agency, or the larger project


6. Scope: The scope creep has increased to include having executive leads take on the ‘author’ role for each page (relative to their departments).


7. Roles: None of the ‘authors’ were interested in the responsibility (<25%) or learning the technology platform.


8. Deliverables: The content on the existing platform was greatly out of date. The previous ‘authors’ were either not assigned (i.e., known) or were no longer with the agency.


9. Deliverables: The ‘authors’ were also not available to migrate their own content to the new site.


10. Roles: A temporary contract staff had to be hired to complete the work. Instead of the agency project manager supervising the contractor’s work, it was assigned to the parent company.


11. Roles: The parent company project manager refused to use the supplied migration plan; or follow the contractor’s feedback (as they were familiar and currently using the migration plan).


12. Schedule: The schedule was to launch the new platform by the end of March. The scope creep, role conflicts, and added role responsibilities required an extended schedule. The launch date was postponed (doubled the original estimation).


13. Culture: Stakeholders who participated in the original leadership meeting (and business case presentation) subsequently felt left out of the consulting and planning process two years later. This group directly challenged the appropriateness of the business case later on, and stalled several efforts.

A change request was required at items #5, 7, 9, 10, 11, and 12. These would not have been needed if the requirements document was completed, which would have impacted items #1, 2, 3, 4, 5, 6, and 13. Instead of confirming the requirements, or facilitating additional requirements gathering efforts (and/or kickoff meetings), additional layers of oversight was introduced. Project complexity escalated as a result, and medium/low level questions were managed as Phase Gates (completely stalling the project for week(s) at a time).

In order for quality to be maintained the project schedule was doubled and additional resources were brought onboard to accommodate the increased complexity and additional scope.

 

The change request process is fairly simple and generally follows these steps:

• Identification of the change being requested (form completed)


• Review of the change being requested (form reviewed)


• Risks and impact of the change identified


• Alternatives identified and reviewed, if necessary


• Decision, or alternative proposals, provided to the project owner

 

• 

Attempts to resolve project barriers, without the aid of a change request process, are also less effective and likely to increase complexity in the following areas:

• Structure: Project structure and governance tools are less likely to be effective


• Roles: Impacts roles and responsibilities (as well as accountability and follow through)


• Requirements: Impacts the requirements gathering and confirmation process (scope creep often results)


• Risks: Risks increase as too many people get involved, risks proliferate (and/or are unresolved), new requirements are introduced, and stakeholder satisfaction deteriorates.

Unfortunately the challenges described above are all too common. The performance of poorly planned projects are often not blamed on the project owner and sponsors but are instead blamed on the project team that are responsible for meeting the project’s goal, albeit without the resources needed to be successful. When this happens the public image and reputation of the project team and company are affected.

Confirming the project roles, responsibilities, requirements, and outputs prior to executing the project is crucial to its success.

How does your team ensure the project requirements are confirmed prior to project launch? Address challenges created when a project sponsor/owner is unavailable to confirm the project requirements? Share your comments below.

Source: B2C