What is Project Scope Management

Project Scope Management is a very important topic in Project Management and probably one of the most ignored topic as well. As per a recent survey in last years, the successfully completed projects are only 34% of the total projects, and the major reason of failure is the scope creep. Most of the Project Managers knows the taste of grief which is caused by Scope Creep. Still we get stuck into this trap, as we mostly have to work on assumptions, but we skip to define these assumptions properly or communication gap creates a huge gap in expectation as well.

Scope is bound to change in most of the cases, however that is not the reason of grief if we manage the scope properly. We need to understand the importance of Scope Definition and Scope Control.

Project Scope Management Plan: Scope Management Plan is a plan about, how Scope will be managed throughout the life of project. It defines:

• How and where the scope will be defined
• What approach will be followed to decompose the functionalities.
• What will be the process to accept/reject any new change coming in the scope
• How a new accepted change will be managed and integrated with other part of the project

Scope management is all about Scope Definition and Baseline, Scope Verification, and Scope Control. Here is the description about these.

Scope Definition and Baseline: This part involve the process to define the scope of project in detail. Everything which is included, or not included should be mentioned with the definition. 

In most of the cases, we don't have concrete requirements from client and making these concrete can take a lot of time before project closure. In such cases, we take the assumptions, and document these assumptions in the definition so that these can be followed up at a later stage to verify the scope. If any of the assumption is not true, it may have impact on scope. 

Now the point is that what all should be included in the scope definition. There are different viewpoints for defining the scope, so it can be defined in various form. However the mostly covered information is

• Deliverables
• Deliverables can be internal or external both. External deliverables are, the items which will be delivered to the client like reports, screen, functionality etc. Internal deliverables are like Project Plan, Requirement Specification, Status reports etc. 
• Functionality and Data
• Every functionality of the project should be captured here. The best way is to do functional decomposition up to certain level. We can create a WBS here, which may not be decomposed at very low level. Now the Control Account or Work Package (units of WBS) can be mentioned to define the functionality. Data should be captured corresponding to the functionalities like the input and output data of any functionality. Here the data does not mean the system data, but it is the data which will be entered by user or may be provided to user as an output. WBS is defined in another post.  
• Technical Information and Structure
• We can define the technology set which will be used for the project. 
• We can define other infrastructure information like servers, the required configuration etc
• In case of existing project, we can provide the list of technical components which will be affected by the new implementation
• An high level technical flow diagram can be shared to make the implementation internals clear to the client.
• Out of the scope items, which can be taken as in-scope otherwise 
• Any item which can be mistakenly taken as in-scope, should be defined here explicitly. It is very important part which should be thought upon carefully. 
• Stakeholder analysis
• We should understand the requirements of stakeholder completely. No project can be successful even after defining the complete scope, if we define it without understanding the Stakeholders and their views. For example, it might be possible that client wants something else but when it reaches to us in term of document, it changes its meaning to something else. 
• Product Analysis
• We should understand the product requirements properly. We can not understand the desired output till we analyze the product properly. It also help to contribute in better way while defining the scope and to rectify any error even in client requirement statement. 

The scope definition, and WBS makes the Scope Baseline. It will be used later throughout the project life cycle for Scope verification and control. 

Scope Verification: The focus of scope verification is on inspecting the work done as per Project Scope Definition, and to have a proper customer acceptance. This can be conducted after every phase of project to ensure that we are on right track and customer acceptance won't be an issue later. Project Quality Control and Scope Verification seems to be doing similar kind of work. However the difference is in focus area. Where Quality Control focuses on ensuring the right quality of product, Scope verification focuses on proper customer acceptance. 

Scope Control:  It is about controlling the scope and any change to it. With above steps, we have a defined scope now which can be used as baseline during any verification phase or if there is any change comes in as scope change. Scope control deals with the management of change in scope, and its impact on other part of project. It involves

• What is the source of the changes
• Reason of the changes
• How to limit these changes
• What would be the impact of these changes on Scope Baseline and other part of projects
• Submit the changes to the integrated change control
• Reject or accept the changes as per the response from Integrated Change Control
• If we are going to accept these, update the scope baseline and other related data 

So in nutshell, scope control means the total control over the scope changes, and try to minimize the changes if that is possible. However do remember, that Scope Change is very common and hence a good project manager should analyze the impact of changes first and then should decide that whether these should be taken or not. Deny any change is not a right approach, as some changes can be very important for the project and can waste a lot of efforts later as rework.

Note: A golden rule of scope management is that never give less than promised and never give more than expected. Sometime people believe that giving extra is always good and will bring good will from client. However this thinking can ruin the project as team start focusing on extra rather than the required part and make compromises on quality at last to finish the work on schedule. We get many chances to do favor to our client, so let us use other options. 

People who read this post also read :