risk management and scope creep

How do you define your scope? Is it the domain (area of a market or knowledge area) you are working in or the products and outcomes you must deliver? The second option is the safest to protect against scope creep. However, to monitor or change the project’s vulnerability to risk, remembering the first option helps awareness of the context for risk identification.

Project Managers, should not stop project teams identify risks that are related to their work but out of the project scope. All risks identified should be recorded and escalated through either the project management team or the line management of the area concerned. The project needs to actively and frequently manage its risks and this must be part of the planning process. 

Suggesting that some risks are not worth recording will undermine that and restrict the thought processes you need to dig out the less obvious but related risks that do apply to the project.  Understanding the domain and related system interfaces that are close to your project’s area of work can reveal areas where risks and  unexpected threats may emerge from.

When you have identified risks that are applicable to your project, have you assessed the impacts and looked for possible actions to resolve them? If there are actions arising from risk management, they have added work to your project schedule? Are the actions proportionate to the risk?

Often no action is proportionate, the possibility of a risk occurring is low and the impact on the project is marginal – but if there is risk to elsewhere in the organisation, the risk cannot simply be hidden under the carpet. This is when a defined scope and escalation approach will help a project manager hand over responsibility for managing the risk while contributing to lowering the risk profile of the portfolio of projects.

You could be badly injured crossing the road but building a bridge is rarely a sensible option: simply watching traffic and choosing your time to cross is enough.  Similarly, monitoring risks and careful scheduling can avoid the need for expensive risk actions.

Are the actions work that would normally be within the project scope? If not, have you spare resources to do them within the project team and will you be able to keep track of how much of the project’s resources are used on them? Is there time in the schedule to do the actions or are you causing a bottle neck?  As the actions are out of scope, can you enlist resources elsewhere to help?

Protecting your project from scope creep is as important as every other risk and needs to be managed too: don’t let risk management be the cause of the creep.

About 3triangles
Helping organisations make change happen in 3 key areas: strategic change, deliver tactical impacts, efficient and effective processes. All blog content (c) 2009 - 2012 Carol Long and Three Triangles Performance Ltd

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: