Monitoring the Project – How are changes to scope handled?

Scope creep is one of the most common things that a project manager must contend with during the life-cycle of a project or program. Even in the best of circumstances, there will likely be conditions that warrant a change to an existing project mid-way through its life-cycle. And more often than not, this could occur several times during the project’s timeline. Concurrently, there will also be situations where a particular feature is revisited and deemed ‘out of scope’ based on new factors, such as a re-evaluation of user sentiment, problems in implementation or just simple deferment. Scope changes can and do occur.

With that being said, how should the project manager handle these types of situations? What sort of process should one have in place to be able to readily accommodate situations where a change in scope has been requested?

While it is often tempting for a project manager to take a rigid stance and decree that no new changes are permitted during a project’s timeline, this is not likely to be well received by stakeholders or management. As such, a project/program manager needs to instead take the stance of evaluating the change request and determining its feasibility and inherent risk.

If one refers to the PMBOK (Project Management Body of Knowledge), one of the process groups is ‘Monitoring and Controlling’. It is within that area that scope changes are likely to be catalogued and processed. Any stakeholder is permitted to request changes. These may be based on their own sentiment or driven by either an end user request or a business decision. Regardless of source, changes need to be addressed and it is important to have an action plan in place for these situations.

When performing the initial evaluation of the change request, some of the following questions should be asked by the project manager:

  • What exactly is the change and why is it being requested?
  • What impact does the change have on the overall project schedule and deliverables?
  • Is it possible to defer the change to a later iteration of the project?
  • What might be the downside risk of not implementing the change? Will it make the end project deliverables less marketable?

Whatever the change request, it MUST be documented, even if not implemented in the initial phase of the project. When addressing the change request, it is absolutely imperative that the project manager involves all stakeholders and addresses the change with the team members to ensure that all points of view regarding the change are effectively logged. There may be situations where the stakeholders agree to the change, but the team requests a deferment due to technical or resource issues. Concurrently, not all stakeholders may agree with the change request as is and may ask for it to either not be implemented or modified in some way to make it more palatable to all members.

Ultimately, whether the change is implemented or not will be something decided by the project manager with input from all stakeholders and team members. The type, complexity and feasibility of the change will be the mitigating factors in determining how or when the change will be implemented within the project’s life-cycle.

Advertisements

The Power of the PMO – Part 2

This is part 2 of the discussion pertaining to the benefits of instituting a PMO within an organization.

As mentioned in the previous post, a PMO or ‘Project Management Office’ is a centralized resource within any organization that serves the broader purpose of defining and maintaining standards for project(program) management within that organization.

As statistics in the aforementioned post have alluded to, effective project/program management is absolutely vital to the success of the deliverables. To reiterate the statistic, 69% of project failures are directly attributed to a lack and/or improper implementation of project management methodologies.

So when it comes to the PMO itself, many may ask the question: how should an organization set up their own particular PMO?

As explained in the previous post, organizations are generally structured in three different ways:

  1. Functional – Direct line management of teams
  2. Projectized – Common pools of resources with project/program managers filling both the functional manager and project manager roles
  3. Matrix – A mixture of the functional and projectized structures with further granularity depending on whether the set up is a strong, balanced or weak matrix.

What is most paramount when attempting to set up a PMO for the first time within any organization is to ensure that the PMO adheres to the general culture and organizational structure of the company or business. For example, trying to set up a PMO with the notion of a projectized organization when in fact, the structure is functional will cause mis-alignment between the two entities. This will lead to further confusion and probably cause the whole PMO to become dead on arrival when it comes to trying to follow its mission statement.

Now there may be instances where the organization is making a conscious effort to re-align its corporate culture and internal structure. As such, it may adopt a more radical PMO style as a pre-amble to a broader re-organization effort. However, this is generally ill-advised. Reorganizations in general are often disruptive and stressful for employees within the company. By trying to essentially set up a PMO under the assumption of what you ‘think’ the organization might be is also a recipe for problems. It’s akin to trying to change too many things in a computer program at once and then attempting to debug. Smaller, incremental changes that validate the concept are far more effective. As is often said, baby steps before learning to run.

In general, a PMO within a projectized structure is usually the easiest to set up. In fact, most of the particulars will already be in place since the organization has made a conscious effort to be project based. As such, instituting a PMO that will serve in its core capacity will generally be relatively straightforward. There may be issues if the organization is broken down into areas with different projectized structures reporting into different lines of business. (More of a matrix) What may be prudent within that structure is smaller PMOs that align against the functional areas. A common PMO can be instituted that all the constituent PMOs will report into. This is not an uncommon set up and exists in many organizations that follow a functional structure. Ultimately, as stated before, do NOT attempt to structure the PMO against the grain of the corporate culture or internal structure. That will waste a large amount of time creating an agency within the company that will be treated as little more than an afterthought.

So once instituted, what exactly will the PMO be doing? In general, that can be itemized as follows:

  • Perform project support and guidance to project managers in business units (occurs mostly in functional structure)
  • Develop and institute a consistent project management methodology and standardized process
  • Provide training and consulting services as needed and/or collect requirements from external sources
  • Act as a ‘home’ for project managers that can be loaned out to projects as needed
  • Provide common project management tools to business units and maintain tools as needed
  • Provide portfolio management and ensure a staff of program managers is available to manage multiple projects that are related

When one thinks of a PMO, one should look at it in the same way they look at other ‘common’ resource entities within a company, such as a group that does integration testing, common document writers or a set of architect level engineers that are utilized as internal consultants for projects. It is a common resource designed to assist the organization in meeting its project deadlines efficiently and consistently.

So how does one gauge the effectiveness of their PMO? What benchmark(s) are used that can quantify the success or failure of the PMO?

While many in the business sphere love to focus on strictly monetary tangibles, these can often be mis-leading. Cost reductions or increased revenue can certainly be the result of a well setup PMO. But distinguishing between which attributes contributed to cost savings or revenue increases can often be vague. The PMO may have helped, but it may not have been the only factor.

As such, the following success criteria is usually considered the ‘best’ method to quantify the success of your PMO:

  1. Accuracy of cost estimates – Are the target costs and resultant costs of projects well aligned?
  2. Accuracy of schedule estimates – Are projects being completed at the milestones set by the project managers?
  3. Project stakeholder satisfaction – Does the PMO have a good reputation based on its service?

One final note before closing out this post: many business leaders often look for instant gratification when it comes to instituting any changes within their company. They will often look only to the next few quarters as justification for moving ahead with any initiative. But make no mistake, a properly done PMO is a long-term strategy. It ‘can’ produce short-term gains. But in the end, it will take some time to fully implement the concept and ensure it is aligning itself well with the company internals. There will always be some tweaking necessary and business leaders should not be dissuaded or disillusioned from moving ahead if a few bumps are met along the way. Over the long-term, studies have shown that a properly structured and efficient PMO will lead to improvements in all the aforementioned metrics. As an example, Sun Life instituted a new PMO in its organization during the Y2K timeframe. The resultant improvements were as follows:

  • Accuracy of cost estimates: 25% increase
  • Accuracy of schedule estimates: 31% increase
  • Project stakeholder satisfaction: 9% increase

Similar improvements have been noted at other companies who chose the PMO as a viable entity within their organization.

In closing, a PMO can be a valuable asset to any organization. When instituted correctly and effectively, the company or business can be assured of seeing large improvements to their internal project success rates, translating into better productivity and efficiency across its lines of business.