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.
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.