This article is based on PMBOK4 & AGILE project management methodology. Change management is very important in agile methodology as scope is managed using frequently delivered increments.I met many people who consider scope change only includes change request from customer. I am writing this blog for those to put view regarding reason of scope changes and control.
1. Project requirement is progressively elaborated from project charter and stakeholder register.
2. Result of progressive elaboration is requirement documentation, project scope statement, WBS and WBS dictionary.
3. Work that will be performed in near term will in defined in greater levels of details and future work will be in defined in high level of WBS.
4. Project scope statement, WBS and WBS dictionary forms the scope baseline.
5. Any changes to scope baseline need to be processed through integrated change control process.
6. Grounds of scope changes:
a. In largely undefined, uncertain environment scope is managed through frequently delivered increments. For example in SCRUM agile methodology scope is identified in greater detail during sprint planning meeting for the selected stories. This is also considering form of progressive elaboration and scope baseline is updated through integrated change control process.
b. Customer provided SOW for the project initiation and during planning we have defined approved scope baseline using project charter for which SOW is key input, it may be discovered later in monitoring processes that some of items present in SOW are not included in scope baseline. Though this is result of poor planning but after all it leads to change in scope baseline so we need to open integrated change control process. How much of these items will be billed will be dependent upon how much in detail it is specified in the SOW. It is important to realize that all change requests are not billed.
c. During Monitoring and Control processes (Like Verify Scope) change request are submitted to repair defects. Means if we need to repair defects and this work will be included in scope baseline, so it should be included through integrated change control process.
d. Monitoring and Control processes may recommended corrective and preventive action, any scope change due to these recommendation should be processed through integrated change control process.
e. All stakeholders are not identified in project initiation. It is also important to realize that identifying stakeholder is an ongoing process. Stakeholder’s identification mainly focused in initiation process i.e. Initiation of each phase. Any late recognition will lead to increase in cost and timeline. For example if legal department as stakeholder is not identified in initiation process, which may result in delays and increased expenditures due to change request to accommodate legal requirements. Incorporating changes less costly if identify early. The ability to influence cost is greatest at the early stages of the project, making early scope definition critical.
f. Customer request changes, we need to harness changes if they are logical, often for the customer competitive advantage. Customer can change their mind about identified requirements or they can request to add scope also. These entire change requests are processed through integrated change control process.
Here we need to identify that scope includes both project and product scope. Project scope means work that need to be performed to deliver product, service or result with specified features and functions and product scope means features and functions of a product, service or result. Any change to scope baseline need to be processed through integrated change control process and only approved changes need to be incorporated in scope baseline to maintain the integrity of baseline. If integrity is not maintained then there will not be any basis to measure scope performance.
Seema Sonkiya
I received following comment on linkedin:
ReplyDelete• Group: PMI Credentialed PMPs
• Discussion: My blog on project scope change control: http://seema-sonkiya.blogspot.in/2012/03/scope-change-control.html
Thanks for sharing your blog, Seema. As you point out the reasons for project and product-related scope change are varied. I'd like to point when leading significant improvements, scope change can also come directly from senior managers by passing change management as discussed in my blog: www.leadfromthebottom.blogspot.com
Posted by Phil Patrick
Yes very true Phil; there could be n number of sources for a change in scope baseline. Important emphasis is here that baselines are important CIs and should be updated only through formal change control process. Any addition, modification or removal in CI is subject to action with integrated change control process. Once we have baselines using iterative planning then most of the times during monitoring & controlling and sometime execution process request changes.
Very informative article Seema.... Thanks for posting and keep posting such articles..
ReplyDeleteThanks Raksha
ReplyDeleteI received following comment on this article through linkedin:
ReplyDeleteGroup: Project Management Gurus
Discussion: My blog on project scope change control: http://seema-sonkiya.blogspot.in/2012/03/scope-change-control.html
I read your article.This very useful for project scope change control.
Posted by Rajnikant Dhamecha
Well spot on Seema Sonkiya. Please keep writing nice articles on project management.
ReplyDeleteThanks Satya
DeleteSeema - good article. Thanks for sharing. I want to offer another consideration. The article appears to be primarily directed at system/software development. The the actual type of project, whether the customer is internal or external, if the product is a physical product or a service,etc. all have an impact on how one should structure their scope management plan. I specialize in implementation project management. This means you have an external customer, your SOW is usually a Purchase Quote that list each item included in the sale (i.e. installation, wiring, hardware, software, training, etc.), stakeholders tend to be more finite and defined, etc. The biggest issue here becomes educating the customer (who is also a stakeholder) on the change control process early in the project and then being vigilant as a gate-keeper to only allow the amount of type of work performed to increase if the customer has submitted the change request and it is approved. Gold plating easily becomes an issue and may only be discovered after the fact. Therefore one should always have the customer sign a statement agreeing to comply with the change process either at or before the kick-off meeting. Then, if additional work is requested and performed without change approval, the PM can legitimately bill the customer for the unapproved work.
ReplyDeleteThanks Cliff for such a good comment.
ReplyDeleteYes you are right. Here my emphasis was only to explain how to comply scope baseline and any change should be processed through integrated change control process. In addition, how we identify sources of change request and to clarify misinterpretation that change request can only come from customer in case of external project. Developing change management plan and its approval from key stakeholders including customer is another part of planning that is normally developed when planning start. Yes sometime clauses to comply to change management process are included in the signed contract.
One more thing Cliff, I said many times that every change request should be processed through integrated change control process. And only approved changes are incorporated in environment, scope or plan. This process is performed as per approved change management plan developed earlier stage of planning. When change management plan is approved it means customer is already educated. I assume in my articles that we are following correct project management.
ReplyDeleteGreate information for Change Management.Thanks for sharing..
ReplyDeleteThanks Daniel!!
Delete