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.
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.