Why Project Scope Is So Important

Every type of project, whether it is a global project for a multi-national corporation, a local government project or a personal project such as building a house, will have a project scope. It could be defined at length in a Business Requirements document or simply be written as a list of things to do for a personal project but in every case it is important that it is understood at the outset and that it does not change over the course of the project lifecycle. Or, if it does change, that the reasons why are clearly understood and accepted.

But what about the tasks that are very specifically NOT in scope? Should these also be documented? There are often two very opposing schools of thought – some believe it is just as important to state what will not be delivered as what will be delivered. This avoids the common situation where a stakeholder assumes that a certain task/product/activity will be done because in their minds it is so closely associated with another task/product/activity and the two are inseparable. Others believe that to expend effort discussing and documenting what will not be done is simply a waste of time and the process of documenting the requirements will root out all the assumptions that may be being made.

But anyone with real-world experience as a project manager will have come across problems that suggest that, no matter how well documented you think the requirements are, if you don't specifically state what is omitted then you will have issues like these:

• The client wanted something different to what was delivered
• Significant changes are requested throughout the project
• Different stakeholders on the same project have different needs
• A list of future enhancements is being compiled before the project is finished

Problems like these indicate that the scope of the project was not well defined or what was not in scope was not defined.

If you fail to define what is NOT in scope for a project then the people involved such as project managers, team members, end users or stakeholders WILL make assumptions. This will lead to a failure to meet their expectations which, essentially, means a failed project. It is, therefore, essential to clearly document what is not in scope if you want your project to be a success.

Managing stakeholder expectations is a key skill that is becoming more important as projects become larger and more complex. Every project manager should aim to develop this capability early on in their career – it may mean finding the confidence to question senior management or important clients, but failure to do so will only lead to project failure.

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.