Stakeholders and the Cost of Change

Any individual or organization whose interests may be affected positively or negatively by the completion of a project is called a Stakeholder (SH). He could be a positive stakeholder such as the customer, the sponsor, the supplier, the project manager himself, and he could be a negative one such as the competitor. But how the involvement of these people affects the success of a project, and how they influence the cost baseline as the project progresses.

When I think of stakeholders in any project I immediately link it to the GIGO phrase (Garbage In, Garbage Out). A project is initiated, planned, executed, and closed around the requirements stated, and implied, by project stakeholders. In other words, the project’s success is heavily dependent on stakeholder’s input and involvement. If their input is weak, little, rare, or late in the project lifecycle the end product or service would be a costly ‘Garbage’ gathering dust on the shelf.

SH influence in a project diminishes over time due to the increasing cost spent as the project progresses. Hence, it becomes more difficult to introduce changes as we spend more in the project. So, the Project Manager (PM) should involve SH as early as possible when the cost spent is low.

The earlier and more intensive SH involvement in a project is, the more likely the project successfully finishes within the Triple Constraints (Scope, Time, and Cost) achieving a high quality end deliverable. SH Analysis is a vital tool to be used by the project manager (PM) throughout the project lifecycle, especially in the planning phase, to guarantee meeting his SH needs. With this tool the PM identifies SH influence, interests, and needs. Then he prioritizes and quantifies the needs and then translates them into project requirements stated in the Scope Statement. This is a repetitive activity that should be done throughout the project and according to the Change Management Plan so as to prevent Scope Creep.

Not only does SH Analysis prevent deviation from project objectives, but also it minimizes the risk of cost overrun. If a key SH’s need was not detected early during planning, it may cause rework as well as going behind schedule. It becomes much difficult and costly to rework some activities during Executing due to a missing key SH requirement. Because of that it is a good, and may be a must-do, practice to spend considerable time in planning processes, especially the Scope Management ones to compile a comprehensive list of SH’s needs.

Another important practice to involve SH and to mitigate cost overrun risk is the use of Phase Exit Reviews or Gates in addition to end-of-phase verification process. At the end of each phase in the lifecycle the PM should validate deliverables of the phase against scope baseline and that the requirements to proceed to the next phase have been met. In addition, the PM should seek documented acceptance from key SH on deliverables at the end of each phase through what is known as Scope Verification process.

I would say that sticking to the SH Analysis tool and to Scope Verification process would minimize probability and impact of cost overrun risk and of having a useless end product or service.