Posts Tagged ‘stakeholders’

Scope expansion, or scope creep

Saturday, August 29th, 2009

Scope can be the most difficult thing to control in a project. We all want to make sure we meet expectations, and, often it takes a long time to define the expectations. So, where does scope definition end and scope creep begin?

Scope on target or off target

Scope on target or off target

I have drawn the line for scope clarity at the point when the charter is signed. At that point, you should have had sufficient discussion around scope, using the WBS and the scope statement, to get the right scope. The right scope for every project is different. It can expand and contract through the planning process. The important thing to remember is that you need to spend the time in the scoping and planning process. If you rush to get sign off, you’ll be making scope changes as you execute – and your project will look and feel out of control.

When you have achieved sign off, and you have the right scope for your project, then you enter the scope management process. Scope creep can happen now. All scope creep means is that you have allowed – yes, you the PM – the project scope to increase without analysing the impact on the triple constraint, and getting an approval. You need to start scope management as soon as the ink dries on the charter.

Where does scope creep usually come from? In my experience, your sponsor is actually the least likely to contribute to creep. The sponsor is usually more aware of the costs of adding scope than other people, and if between you, you’ve diligently identified scope, they won’t need to add anything. I think there are 3 sources of scope creep.

Stakeholders, some may not understand the goals of the project and some disagree with the goals.  They ask to add in the little things that will take the project off course, and closer to what they need. How to deal with this? I’ve found success in a two-step process. First, review the goals and scope with them to identify where there may be alignment between the project goals and the changes. Then, unless they agree to withdraw the request, go through the agreed scope management process.  If the sponsor signs off, you change the scope and no creep exists.

Project team workers are a second source. This usually comes in the form of enhancements during design. This source of scope creep is probably easiest to prevent and the hardest to control. Prevention comes in the form of early and clear communication of the scope and the process to change scope on the project.  Control is difficult because the changes are generally small but the cumulative effect can be significant. Often you are playing catch up and managing after the fact.  When this happens, discuss the consequences of the change with the person who made it; remind them of the process, but be careful not to stifle creativity by over reacting.

The final source of scope creep, you the PM. Some time you’ll have a great idea to incorporate a strategic change into the project, or a new technology, or a budget savings, or any number of great ideas. It is critical that you follow the process of scope change; your sponsor is counting on you to manage the team and yourself.  I remember the time that I dropped in on a new PM at the end of the day. She was staring at the charter; it didn’t take a lot of perception to know something was wrong. She confessed that she’d gone ahead with her project and incorporated some great ideas. The problem was when she checked the charter in preparation for meeting with her sponsor, she had moved away from the original purpose of the project. Your best tool for keeping yourself on track is to check your great idea against the charter, just the way your handle stakeholders, you need to asses the impact of the change, and follow the change management process.

Here are a few good articles relating to scope creep.

Collegiate project

Project Perfect

Tech Republic

Stakeholders are your friends, really

Sunday, July 26th, 2009

Why is it that stakeholders seem to come out of the woodwork as soon as your project either gets really successful or runs into some hard challenges? Well, I really believe it’s because they care.

At the beginning of your project you go through the process of developing your list of stakeholders, some of us even go to the next step and analyse the strategy for managing stakeholders. What doesn’t always happen is a refresh of the stakeholder list and plan as things change in a project.  So, no wonder you suddenly feel like stakeholders are popping up every time you turn around as soon as something changes.

I can think of a lot of examples where this has happened to me.  Any number of projects looked like they had little or no impact on the Marketing team, for example, until the scope changed to include not only regular customer updates, but also a special communication about a new project deliverable. The Marketing team did a great job but I needed to make sure they didn’t feel ambushed with the change. I’ve had the Technology team suddenly get excited about changes to the infrastructure or architecture areas long before the sponsor signed off on a scope change.  I’m sure you can come up with your own examples of stakeholder triggers beyond scope change and rumour mill.

Putting aside the fact that some stakeholders don’t pay attention until the project has a real impact on them; I call it organizational denial when people don’t recognize how interrelated everything is in a company. Here are some tips to minimize the surprise.

Set up a meeting with your team leads and specifically review the stakeholder management plan, just the same way you do with the risk management plan. You do review the risk management plan don’t you?

When there is potential for a change in stakeholders, set up a meeting with the person who leads that team. This can be a new stakeholder or an existing one where the impact has changed substantially.  Remember the new stakeholder will need to be brought up to date from the beginning of the project – don’t assume everyone knows what your project is about. I’ve had major cross-divisional projects that people were not aware of when I met with them.

Don’t assume you’ve always identified the stakeholders by going through a scope statement. Use your organizational knowledge to think about the people who might make themselves stakeholders. There are always people in the organization who don’t agree with the use of resources for your project; sometimes they have a project they think takes precedent and sometimes it’s a principle thing. Think about who might be threatened by the success of your project – is there any area that might lose staffing levels. Is there someone who’s pet project was declined, will they start putting up obstacles for you?

The important skill to remember with these stakeholders is you have one mouth and two ears. These people are usually not out to get you, they have something important to contribute. If you listen and clarify any misunderstanding, you might gain an ally from a potential blocker.

Here are a few links that might be interesting:

Mind tools – an article on stakeholder management and a tool to use – a good community to join

Project Smart – a UK site with great information on stakeholder management

Wikipedia – definition

Max Wideman pm guru, it’s not the prettiest site but it’s practical