Innovate Vancouver

Change request forms are utilized by the project team. They help 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. A hybrid form is used, 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. This should be done before the project is 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. This requires the schedule to be prolonged. Consequently, the service may be unavailable to the customer(s) when needed.

A case example: Technology design and migration project

The following case example is described briefly. It helps to establish the importance of confirming the requirements up front. It also highlights 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. It now includes having executive leads take on the ‘author’ role for each page. This is 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. They also did not follow the contractor’s feedback, despite the contractor being familiar with 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 participated in the original leadership meeting and business case presentation. They 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. The requirements document was not completed. This 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. Medium/low level questions were managed as Phase Gates. This completely stalled the project for week(s) at a time.

To maintain quality, the project schedule was doubled. Additional resources were brought onboard to accommodate the increased complexity. Extra resources were also added to handle the additional scope.

Generic Change Request Process

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. Stakeholder satisfaction deteriorates.

Unfortunately the challenges described above are all too common. The performance of poorly planned projects is not often blamed on the project owner and sponsors. Instead, blame is placed on the project team. They are responsible for meeting the project’s goal 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.

Travis Barker, MPA GCPM

Innovate Vancouver

[email protected]

Innovate Vancouver is a Business Technology and Information Consulting Service (TBICS) located in Vancouver, BC. Contact Innovate Vancouver to help with your new project.