As a project manager working in a customer/vendor environment, and if you’re experienced enough, I believe you faced a situation where the customer shifted the discussing of a change request into a concern about the final benefits of the project. You start hearing statements like “I don’t want to discuss a change here or there…”, “We wouldn’t started this unless we want the final value to be realized”, “We hired your so that we’ve a change, hence value”…etc
Be careful! this is what I call “Benefits Realization Trap!”
Though this seems logical from a customer perspective where project success is achieved when expected benefits are realized. After all this should be the driver for any endeavor. However, from the vendor perspective is something different.
The real scope of any change is actually beyond the scope of any single project or endeavor. And the project is no more than a single piece in a bigger puzzle that is intended to achieve “benefit”.
Theoretically benefits are achieved from a result or outcome that resulted from an output. For example Improving the performance of the accounting team (benefit) was achieved by adopting and using (outcome or result) a new accounting system (output) that was developed recently.
Going back to the basics, PRINCE2 Define a project as
A temporary organization that is created for the purpose of delivering one or more business products (output) according to an agreed business case
PMBoK uses a close definition. Though it expand it to include the result (outcome), it still did not consider benefits as a responsibility of the project.
a temporary endeavor undertaken to create a unique product, service, or result.
Understanding this is extremely important for a project manager and mandates exclusive focus on delivering the expected output within the project constraints of scope, quality, time,cost, resources and risks. Still, the project manager should understand the expected benefits as part of understanding the project context and contribution to support the big picture.
That’s said, realizing benefits is definitely outside the project scope and should not be driving the project.
Managing this is easier said than done. Howe3ver I believe doing the following should help:
- Set Customer expectations in terms of the project goals i.e. meeting the defined scope within the constraint.
- Pay attention to human related and adoption activities and make sure they are well-scoped, clearly defined and easily measured for completion i.e. limit activities to training sessions and workshops limited by time and number rather than a general adoption activities
- Define clear and measurable acceptance criteria with tolerances, if needed, so that completion of work is governed by meeting a measurable acceptance criteria rather than customer expected benefits
- Agree on acceptance methods in addition to acceptance criteria to close all possibilities for not getting sign off on completed work.
- Don’t over-commit to customer and avoid doing “relationship management” in favor of scope. This will open a door you will not be able to lock later Focus on delivering your project within constraint.
Ala' Yasin Abuhijleh 