14

Addressing Scope with the Sponsor

THERE ARE TWO undeniable truths in project management:

1.Scope of the project must be well-defined for a project to be successful.

2.Scope seems to always change during the course of the project.

Working effectively with your executive sponsor can be critical in handling the scope changes that will inevitably occur during a project—particularly one with a longer duration.

Defining the Scope

Over the years in delivering projects, I have rarely had a disagreement with a sponsor on what is in scope for the project. Various documents, such as the Business Case, usually provide input on the scope and shape the project scope.

However, I have often been at odds with my sponsor on what is out of scope. That is why I am suggesting that you work with your sponsor on scope definition. Let me provide an example of what I mean.

Several years ago, my team was implementing a new back office system. The client had learned a lesson about customization from an earlier implementation of an ERP¹ (enterprise resource planning) software, so they chose to do minimal customization for my project. As we were refining the scope of the project, I specifically stated in our Scope Statement that the project team planned to use the standard training package provided by the vendor.

As part of my engagement with my sponsor, I was reviewing the Scope Statement that included what was in scope and what I believed to be out of scope. Imagine my surprise when my sponsor told me that he expected customized training as part of preparing people for the go-live. As you can imagine, this was a big deal for the project.

As you probably know, training for a system implementation generally comes near the end of the project as you are preparing to go live. In this case, after a few classes, my sponsor and I had to sit down to discuss how unhappy our stakeholders were at receiving only generic training on the system. Given the timing, the project team would have been scrambling to build and deliver customized training right near the end of the project. As you can imagine, it would not have been pretty!

To complicate things even more, I had not identified people on my project team who could build customized training on the system. I did have business analysts who I believed could deliver generic training because they knew the system and had the basic platform skills.

So when my sponsor expressed his expectation about training, I was able to have a conversation in which I expressed my opinion that the budget for the project did not seem to include enough money to cover more people—those I would need to build customized training. After I presented an estimate on what the additional cost would be, my sponsor went to the other key executive stakeholders to find out if they would support additional money to build the customized training. As it turned out, the executives decided that the generic training would be enough after all. Basically, they wanted customized training but were not keen on paying for it.

After this process, if stakeholders were to complain about the generic nature of the training, my sponsor could defend the decision and call on his other executives to confirm that they had indeed decided that generic training was enough.

Other Assumptions

The training example is just one situation where an assumption was made about the project. You need to work with your sponsor to ferret out other assumptions so that you can include them in your Scope Statement.

These assumptions can come both from the project and from the business side. For example, recall the system upgrade my project team was doing for installation on oceangoing ships that could be done only when the vessels were in port. To complicate things a little more, the installation could happen only in certain ports around the world, not all of them.

An assumption that the project team had to make was that the customer would give us an accurate schedule of when certain vessels would be in the selected ports. As you can probably imagine, the schedule was fluid. Remember that the company that owns or operates these vessels makes money only when they are in transit, not sitting in port. I worked with my sponsor to set the right expectations with the customers about how their actions might create schedule delays for the project.

Some in our project management community might consider this example as a constraint on the project and could make a strong case for using that term. However you view the situation, as an assumption or a constraint, the important point is that you are working with your sponsor to ensure you are on the same page.

By creating alignment with your sponsor on issues like this, you are far more likely to get the support you need, when you need it, as the project moves forward. And all of these discussions need to happen either before you begin your planning for the project or during the planning phase. Either way, you do not want to begin the execution phase if you have not had these conversations.

Affected by the Project but Out of Scope

In my experience, what I have seen time and time again is that the project exposes poor business practices that are out of scope. I firmly believe that one of the biggest factors that creates scope creep in projects is when the project decides or is forced to address these poor practices.

It is not always possible to know that these poor practices exist until you are in the middle of the project execution. Therefore, I have a discussion with my sponsor during the planning phase about how to handle such situations. I try to get agreement from the sponsor that we will handle these practices in one of two ways:

1.My sponsor will work with her executive colleagues to convene a working group whose purpose is to address the poor practice that the project uncovered. In this scenario, the work is completely outside the scope of my project. It is often the case that the recommendations from the working group will impact the project, but we agree to go through the scope change process if that happens.

2.The project is tasked with making the changes required to correct the poor business practice but with an appropriate increase in scope, budget, and schedule for the change.

No matter which way the issue is handled, the scope of the project is being managed. We are not falling into the scope creep problem because the process has created visibility at all levels.

How to Manage Changes in Scope

All of these situations create a need to change or alter the scope of the project. Here are some ways that I have involved my sponsors in this very important process.

In working through changes in scope, I have found that getting agreement from my sponsor to use the RAPID decision-making model is very helpful. It is particularly valuable when the key stakeholders cut across organizational and/or functional boundaries. RAPID is an acronym (as most model names are):

R = recommend: This is a person who can actually recommend an action or solution based on his line of authority within the company.

A = agree: This person must agree with the recommendation to change scope. In other words, this person has veto power over scope changes and must agree before a change in scope can occur.

P = perform: This is the person or group who will actually perform the work related to the scope change. This is usually the project team but not always.

I = input: This person or group usually has information, data, or some other attribute that allows the scope change to actually occur

D = decide: This is the part I really like about this model. It clearly identifies who has the authority to make decisions on a scope change issue. Particularly in projects where key stakeholders are of equal rank in the organization chart, this identifies which one actually makes the decision on a particular scope change.

Figure 14.1: The RAPID Method

See Figure 14.1. I find that working through this model with my sponsor makes the whole process of managing scope changes so much quicker—not necessarily easier, but quicker.

Authorization Levels

I discuss who has the authority to approve changes in the scope of my project. In most cases, my sponsor will want to have the final authority but not always. For example, if a change is required because of a regulatory issue, my sponsor might hand off the authorization to legal or to health, safety, and environmental (HSE) to make the call.

Assessing Change Requests

Anytime there is a request for a change, it should come in an official way. An e-mail or short conversation in the hallway should not be how change requests come in. A request may certainly start there, but always have a change request document and a formal set of information elements, including:

A description of the proposed change.

Your team’s assessment of the impact to the schedule and budget.

Any impact on the quality of the deliverables.

Any consequences if the request is rejected.

The real purpose of this prescribed process is not to create unnecessary bureaucracy but to allow you to review the information with your sponsor. I know it may seem cliché, but requiring someone to actually describe in a written request what she wants—and why—requires a rigor of clarity that just talking back and forth can never provide. In most situations, the request will come to you, and you must then package it for a review with the sponsor. And this circles back to one of my earliest comments about not allowing your sponsor to be surprised. With the type of detail you are requesting, the sponsor continues to appear in control and the project well managed.

The nature of the request may also cause your sponsor to convene a change control meeting with key stakeholders. He may want them to consider the request and provide input before a final decision is made. By having all the fundamental information documented, your sponsor can send out the request in advance so that the stakeholders may review it prior to attending a meeting.

In summary, making a conscious effort to collaborate with your sponsor on specifics related to scope definition and scope change will allow you to receive the support you need when you need it. Your sponsor will be in a much stronger position to defend the project from the inevitable assaults that come when a project is under way.

Points to Remember

Ensure that the scope is clearly defined at the beginning of the project.

Challenge any assumptions.

Separate items affected by the project but out of scope.

Manage changes in scope carefully and formally.