What are some techniques for keeping a project on scope? How do you deal with a client who insists on going beyond scope? How do you redefine scope diplomatically? Saving Changes...
Sort By:
Anonymous
What do you usually do to keep a project on scope? What kind of project are you referring to? Saving Changes...
Joe WynneRetired from BankingCharlotte, NC Area, United States
This situation can certainly be sticky. I'll assume that a stakeholder wants to add something, as in new functionality to an application already well into development, and give you some ideas.
Always use your polite, customer service trouble-shooting behavior. You should be perceived as solving problems, not trying to reduce services to a customer (stakeholder). Make sure the stakeholder realizes they must choose between (1) business/operational benefits at completion of the current project and (2) waiting for any benefits until the new functions are completed. Estimate the extended duration and cost of the modified project. (Do your homework and have realistic numbers ready.) Remember, a stakeholder may have nanve beliefs about what is possible. When you are really under pressure, involve other stakeholders, who may not agree that benefits later will be better than benefits now. Sometimes, bringing up your need to check with other important stakeholders will reduce the urgency of the stakeholder attempting to expand the scope of the project.
This is an important issue, so I will write a related article in the near future.
Joe Wynne gantthead Workforce Management Department Leader Saving Changes...
It helps a lot to have a defined scope in the first place (i.e. a Charter or Scope Statement). Scope should include both the things that will be done and the things that will not be done. Even if your organization does not have a formal method of defining scope (they do, don't they? Of course they do!), you can head off misunderstandings and scope creep by presenting an informal scope statement at the outset. Somewhere on that statement, it should say that scheduling and cost will be based on this agreed-upon scope. When a stakeholder asks for a deliverable that is beyond scope, come back with a change document (again, formal or informal) saying, "okay, that change will cost you X days and Y thousand dollars. Sign here."
While this may seem heavy-handed (esp. in organizations not governed by defined procedures and documents), it is actually very professional and very responsible to both the provider and the recipient. Faced with the increased cost and duration, many stakeholders will say, "That much? Gee, maybe it's not so important after all." That's good for business.
Saving Changes...
Anonymous
The first thing I like to have is a good defined scope of the project - and have the customer (whether internal or external) sign off on it. That way, I know, that they know, a defined scope was accepted.
Then, when scope creep occurs, (which invariably does) I professionally point out the agreed upon scope definition. If I get a 'yes-but' I try to convince the customer that the requested scope change might be handled better in a next version of the project. If that still doesn't do it, then costs (whether they be time, money, or both) are determined for the change, a new scope definition is developed, and signed off upon. I have found that this keeps everyone informed and reduces that chances of 'sticker-shock' at the end of the project. Saving Changes...
Anonymous
During the SDLC the technique we use is to have a well defined Requirements Traceability Matrix. This ensures that artifacts/deliverables can be traced back to the original requirement as defined by the customer. Of course this assumes a well documented scope of what the system will deliver - either during contract signing or during the initial business study sign-off.
Changes in scope are handled through a detailed Impact analysis. What may seem a minor change in scope can have dramatic changes on the work-in-progress and also in the artifacts already delivered. This is where your change management and software configuration management procedures come in. The RTM and SCM help in doing a quick impact analysis and the Change management system will ensure that the changes required are tracked to completion.
Normally a client is open to renegotiating commercials on the basis of the Impact Analysis.
I don't really think there is a way to redefine scope diplomatically. Is there ? Saving Changes...
Anonymous
I agree with the above - do document and agree the scope as soon as possible. Further to this I would recommend that at the same time as defining scope you could introduce the customer to your change control procedures. This way when changes occur (and they usually do) everyone knows what to expect. Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
In my experience, the scope of a project will change the day it is set. The trick is to develop a process that constantly communicates the "TRADE-OFFS" implied by such changes. Never get emotional about scope changes. Simply identify the change and provide the powers at be with the re-cast time lines, budgets and ROI calculations. Be aware, that a very popular tactic by those wishing to sabatoge a project is to continually move the target (add new requirement, change scope). There is no end of good ideas. Phasing can help and change orders are critical. Never get seduced into accepting a scope change without doing the proper "Trade-off Analysis". It is your best protection. Saving Changes...
