Three Scope Change Management Techniques

There are a lot of interesting scope change management techniques that can be easily applied to your project. Here are three that will keep you out of trouble.

Make Sure Only the Sponsor Approves Changes

A typical problem on a project is that the team does not understand the roles of the sponsor, client and end users in the area of change management. In general, the project sponsor is the person who is funding the project. If the client were embodied in one person, it would be the project sponsor. The people that the project team tends to work with most often are users. These are the people that use the solution that the project is building. The end users are the ones that will generally make requests for changes to deliverables. However, no matter how important a change is to a user, they cannot approve scope changes. The sponsor (or their designee) must give the approval. If the change is important enough the sponsor will approve it, along with the appropriate budget and duration changes. If the change is not important enough, it will not be approved. 

Saying 'Yes' to Change Requests May not Show Good Client Focus

The project manager and project team sometimes think that they are being client-focused by accepting scope change while still trying to deliver the project within the original commitments. However, if the project is delivered late or over budget, it is usually not good enough to point out all the additional work that was included because of this 'client focus'. 

The sponsor is the primary client representative. Allowing the sponsor (or their designee) to make scope change decisions shows good client focus. If the project team or project manager approves scope changes, he is not showing good client focus from the sponsor's perspective.

An Engaged Sponsor Will Often Say 'No' to Scope Change Requests

One of the neat things about enforcing the discipline of having the sponsor approve scope change requests is that, unless the change is very important, the sponsor will often say 'no'. The sponsor is usually someone high in the organization. He normally doesn't want to hear about requests for small changes. He wants the original project fulfilled within the original commitments for cost, effort and duration. Even though it may be hard for the project manager to say 'no', the project sponsor usually doesn't have any problem saying 'no' to the people in sponsor's own organization.

Everything You Wanted to Know About Action Items

An action item is work that requires follow-up execution. By their nature, action items normally cannot be planned for in advance. They arise on an ad-hoc basis during meetings or as a by-product of working on something else. An action item is assigned because there is not enough knowledge, expertise or time to resolve the item at the time it originally surfaced.

In many cases, action items are trivial in nature, but in other cases they can require substantial work to complete. Action items need to be assigned, worked on later and completed. (If they are not going to be completed, they should not be called action items. Instead, simply note that the item will not be followed up on and then forget about it.) Examples of action items include forwarding information to someone, arranging a meeting and providing a quick estimate on a piece of work. 

Sometimes an action item is established to investigate an area where there may be a potential problem. Because of this, action items are sometimes mixed in with issues. However, this is not right; an action item should not be confused with an issue. An issue is a problem which will have a detrimental impact on the project if left unresolved. An action item may lead to the discovery of an issue or a risk (a potential issue in the future), but the action item itself is not an issue.

There are two common approaches used to manage action items. The best approach is to document the items as activities in the project schedule. A resource and end-date are assigned as well, and the activity is then managed and tracked as any normal activity on the schedule. In general, this is the better approach to follow, because it keeps the work items in one place and allows the project manager to enforce the discipline of knowing ‘if it’s not on the schedule, it will not be worked on.’ This approach also allows the project manager to see the impact of the action items on the schedule. For instance, you may have a small action item that is 3 hours of work. If you assign this action item to a person on the critical path, you may see the resulting delay to your project. This may result in you assigning the action item to someone else instead.

The second approach is to create a section on your meeting minutes for action items. Action items can be placed here if they are trivial (less than two hours) and they are scheduled to be completed by the next meeting. If you use this technique you can start each meeting with a review of the prior action items to validate that they are completed and then cross them off the list.

Don't Mix Issues and Action Items on the Same Log

In many cases, project managers are not using the Issues Log to identify and track true issues. Many items that are classified as issues are really risks (potential problems) or just action items. If you find that your Issues Log has dozens of items on it, you are probably tracking action items instead. Because issues are large problems, there should not be many items open at any one time. If you find that your Issues Log is full of action items, chances are that your true issues are hidden and not worked on as they should.