Project Scope and Its Importance

You know how you sometimes overhear a snippet of conversation – on a train, in a shop or restaurant – and it gets you thinking about a subject close to your heart. You want to join in the discussion – you can feel a heated debate arising – but the people in conversation have moved on.

You may well have misunderstood them and, given that you didn’t hear the whole conversation, they may well have come around to your way of thinking. But you can’t help churning it over in your mind (well not if you are anything like me anyway).

The topic of conversation I overheard recently was about project scope and its importance in the success of a project. This is basic project management that is taught on every PM training course from the APM Project Fundamentals course right through all levels of professional PM study, but it’s importance to project success was not being debated here but rather fundamentally how to define project scope.The type of project (or activity or product) was irrelevant to the discussion – it could have been any business or personal project.

One of the protagonists believed that not only should the scope be clearly defined but what was NOT in scope should also be clearly defined. The antagonists thought that documenting (or indeed thinking or worrying about) what was not in scope was a waste of time. There could be a million things that are not in the scope of a project, they argued. But I believe they missed the point completely.

If, like me, you have worked as a project manager on many projects during your career (IT projects in my case) then you are certain to have come across situations like these:

• There’s a mismatch between what is delivered and what was wanted by the client
• Requests for major changes are made halfway through a project
• Different clients on the same project have different requirements
• Changes are requested immediately after the project is completed

These are all signs that the scope of the project was not clearly defined or, more likely, what was not in scope was not discussed or documented. So the antagonists in the argument I overheard can continue to believe it is unimportant to define what is not in scope, if they wish, but the end results of their projects are likely to have some, if not all, of the above problems.

If you don’t define what is NOT in scope then people involved in a project – be they project managers, team members, end users or stakeholders will make assumptions. Their expectations will then be unlikely to match the expectations of those delivering the work. It is vital, in my opinion, to clearly state what is not in scope in order to successfully manage the expectations of the client or customer.

In fact, managing expectations is a skill that every good project manager should develop early on in their career – it takes no more than an ability to communicate clearly with all those involved in a project. Although this sounds easy it is a skill that many project managers fail to master. The reasons for this are varied – it might be a fear of questioning those in senior positions, it might be a failure to talk to those at the coal face or any number of other reasons. Whatever the reasons, fully defining the scope of a project and managing customer expectations are inextricably linked.

And the solution is simple – talk, talk openly, listen and listen without prejudice. The customer may have a role far removed from yours but they are the ones who will ultimately define the success of your project. Foster good relationships with them right at the outset and you will be rewarded with good communications that will not find you on the BIG DAY discovering that everyone “assumed” that such-and-such would be delivered and it was not.

Good Luck! And here’s to your project success – Remember Scope Matters.

For those of you who want to learn more about how to define scope then find one of the many project management courses that cover business requirements analysis. This is the process of finding out, analysing, writing down and agreeing on the requirements of a project. It is the most successful technique for defining in detail the scope of a project.