Why revenues?
It must be noted that the triple constraint is still the
most important threesome in a project. Scope, Resources, and Time are still the
triple dilemma for any PM. However in a PSO, a fourth goal is added: revenue.
You see, PSOs are consultative organizations that deliver consulting or implementation
services. So, along with the constraints in a normal project, a PM is given
revenues as a goal. Now, some would consider revenue a constraint, but unlike scope,
resources, and time, where the word constraint is properly used, revenue is not
a constraint. With every project, certain costs will be associated with each of
the constraints. However with revenues, a PM is not limited within that number.
You see a PSO that delivers a service or implements a product can also deliver
additional value to the client by adding onto the project. Now, I know what you
are thinking; you are thinking that I am advocating scope creep. Nothing could
be further from the truth in this case. If in fact a PM sees an opportunity to
add onto a PSO project, that PM will deliver a change request or a new
Statement of Work (SOW) spelling out the additional work AND the additional
costs to the client. So you can see the
difference between scope creep and the extension of a project in a PSO.
Generating revenues is why a PSO is in existence in the
first place. An organization sees the benefit of implementing a PSO for its
product, or an organization is formed that delivers consulting services. So a
PM that is in this PSO understands that the bottom line is to keep the expenses
at a pace that is consistent with the revenues. If the project team delivers
the project within scope, then keeping revenues on track and expenses in check
should not be an extraordinary task for the PM.
What are the obstacles?
Just like a project in a regular Project Management Office
(PMO), a project in a PSO can have scope creep. If the delivery of the
implementation of the product or the delivery of the desired result of the
consulting project is “extended” in scope by the client and the PM goes along
with it, then scope creep becomes a reality. Another reason why projects experience
scope creep is because the scope of the project is not understood by the
project team. What I have come across many times is that the individuals placed
on a project at the client’s end often have a different perception of what is
in scope. So I strongly suggest that the PM start the project with a kickoff
and review the SOW that has the scope statement within it. When the PM does
that, there is no doubt what is in scope and what is not. If the team members
from the client object, there is only one place for them to go and that is
their management.
Next…
My next article is about motivation and how to keep it in a
project with your team.
I am open to discussion at any time on these blogs or anything else related to project management you would like to explore. If you would like to comment about this blog, please do so by posting on this blog or by responding in an email at Benny A. Recine.You may inspire a blog article. I look forward to your comments.
No comments:
Post a Comment