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.


Program Management – When should a project become a program?

Projects, on an individual basis, exist throughout any organization. They can be part of an overall product deliverable, an internal initiative, a process change effort or a tiger team working on R & D.

Whenever any project is instantiated, it has roughly the same constituent pieces: a project manager, a team, a set of stakeholders and most likely a project sponsor. The term ‘project’ is used rather liberally in all circles nowadays, including modern lexicon. We often here of neighbors or colleagues talk about their home ‘projects’, such as painting a room or redecorating a section of their house. Clearly, projects themselves have become a staple fixture within personal and professional arenas alike.

But this begs the question: when does it make sense to enact a program? What aspects of an overall organizational goal necessitate the need for a larger, broad-based program to be created and maintained? Under what circumstances is a program warranted and what precisely is the difference between running multiple, simultaneous projects and a single program?

In most cases, one fundamental question needs to be asked when determining if a program is necessary: are the multiple projects being worked on inter-related in a tangible way and if so, do they have common milestones and inter-dependencies?

As a project manager, when managing several projects and trying to determine if a ‘program’ is needed, a good frame of reference is to consider real world examples and cases where programs were enacted by other organizations. For example, consider something like the Microsoft XBox360 console.

The console itself, when completed, is a singular unit for purchase. Customers will buy the console as a whole (with potentially some additional peripherals) and take it home. But if one examines the console itself, how many individual pieces and components does it contain? As an exercise, we will itemize them:

  • Motherboard and CPU
  • Hard drive or memory card
  • Graphics Card
  • Ancillary access ports
  • Game controllers
  • Operating system
  • Ethernet capability

Now as many might surmise, it is likely not the case that all of these components are being worked on by the exact same people or even in the same location. It is also possible that some of these constituent components are ‘farmed out’ to third-party vendors. Or some aspect of those components is farmed out.

In any sense, what is clear is that in order to produce the end product, there are several pieces that need to be created and maintained and that all of these pieces are part of the whole. And being that the release cycle of the console necessitates the need for the pieces to be delivered in the same timeframe, this is an obvious example of the need for a program.

In a similar sense, as a project manager, the best way to determine whether a program is warranted or not in your particular case is to look at all the individual pieces and dependencies. Determine how they inter-relate and get a gauge of who is working on what and where. As a rule of thumb, as the complexity of the deliverable increases, the need for a program (or even multiple programs) goes up.

The choice to create a program will often become self-evident as the project manager begins to take ownership of various projects. Once a determination is made of the overall set of projects and how they inter-relate, a more informed decision can be made.