Here’s something interesting, in Gartner’s IT Glossary there is no entry for “Scope”.
Now, there could be two reasons for this.
It could be that its scope is such an obvious thing that Gartner feels there is no need for a definition. Or it could be that scope is such a movable concept that it actually defies definition.
If your career has been anything like most Project Management professionals, your definition probably hovers somewhere between the two – obvious yet indefinable.
A Guide to the Project Management Body of Knowledge, 2008, defines Project scope as “The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.” TechTarget say Project scope is “the part of project planning that involves determining and documenting a list of specific project goals, deliverables, tasks, costs and deadlines.”
I often refer to scope as the DNA of an IT Project. The point is, it matters.
So who is responsible for safeguarding it? The Project leader? The CIO? The PM team?
It’s a question that I’m often asked and ultimately it’s the Project Leader with whom the scope buck stops. Increasingly, though, I believe, the answer is everyone!
It’s crucial that your whole project team understand the scope of your IT project. You want them to know what they have to do, naturally, you don’t want to have to be looking over their shoulder the whole time – no one enjoys working like that.
It’s more than knowing what’s expected, though.
When your whole team buys into the scope – the “list of specific project goals, deliverables, tasks, costs and deadlines” – you develop an extra line of defence against scope creep.
I shiver even as I write the words ‘scope creep’. All those little changes that add up, like a snowball rolling down a mountain and gathering mass as it descends until you’re left with an IT Project over budget and delivered late. How often have you wished if only someone had noticed…?
Scope creep is a risk for most projects and it has no respect for size of project or experience of the project manager. The bigger they are the more susceptible they can often be but there could be a safeguard.
Empower your team to put their hand up and shout if, along the way, something changes that they believe is not in keeping with their ability to deliver the project as originally detailed.
Your project team are at the business end of your IT Project. They are the ones with their sleeves rolled up working on the day to day and crucially talking with stakeholders. If your team have digested the scope of the project they will be best placed to notice when it has veered off course and either alert you to the issue or in some cases take corrective measures themselves.
Either way, when responsibility for scope is shared across project teams, corrections are made sooner rather than later and that can be the difference between a successful outcome and a project fail.
One Project Leader I know sees such benefit from shared responsibility for scope that she actively trains project teams on the concept. She told me that it’s like having eyes in the back of her head. “It’s like an early warning alarm. Projects change. Sometimes, when a stakeholder request shifts scope it can be really subtle but have a huge impact on the outcome.”
As a Project Leader sometimes you’re not made immediately aware of these subtle changes but training your team to spot them and report them to you can really pay off.
To empower your team in this way you have to really open up communications.
Communication and Scope
Project Managers who consider communication to be a two-way thing are getting the best out of this right now.
Traditionally, communication was a single track. You would tell your team what to do and they would go off and do it. You expected their full attention when you were dishing out the jobs and if they did as you asked the project would succeed (sometimes).
Now project managers are training themselves to give the same full attention to feedback from their team and stakeholders and it is giving them greater insight into the day to day performance of their projects. The most successful PMs are in constant communication with their team, their stakeholders, their end users and the result is like listening to the beating heart of the project – and when it skips a beat you know much more quickly than in the past.
Remember, your project’s goals are ‘set’ by its stakeholders, but they’re never set in stone. Things change and as a project manager, it is your job to make sure that any changes are aligned with the original vision. If they alter the mission it is your job to make sure that both you and your stakeholders are aware of any impact upon the costs of the project and delivery date.
You can’t do this if you do not know what the changes are and who is orchestrating them.
Consider the enhanced role that the whole of your team can play in project scope, encourage collective responsibility and you will have fewer problems moving forward and more successful outcomes.
I accept that some teams are not at the maturity level required for this responsibility yet so external Project Management Assessments can help identify what ‘in life cycle’ changes are being made and the impact that they are having. Governance and processes that eliminate many issues can be bought in from the Project Management as a Service market.
The point is that project scope is no longer the responsibility of just the project manager … and shared responsibility makes toasting shared success all the sweeter.
Contact us to learn more about how Stoneseed’s Project Management as a Service can give you access to project management staff, resources and tools at a flexible and predictable cost via a fully structured managed service.
Find out more about Project Management as a Service from Stoneseed
