Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (18)
Similar to Training Scope Creep Linked In
Similar to Training Scope Creep Linked In (20)
Training Scope Creep Linked In
- 1. Scope Creep
- 3. Scope - Ask all the needed questions. Utilize a BA if one is available - Clearly define what is In-Scope and what is Out-of-Scope - Establish clear goals and objectives (Quantitative and Qualitative) - Articulate how Scope ties to the project objectives - Set a Baseline of Scope, Schedule, and Co$t (3Ss)
- 4. Creep - A result of Change - Change will happen - Inevitable - A bi-product of unclear Communication, vague Requirements, or a completely missed Category (like analytics) - Should be identified and Managed - An attempt to Gold Plate (mostly internal) - Often a consequence of Learning
- 5. Scope Definition - Capture Features &/or Requirements - Categorize them and Rank them - MoSCoW (Must, Should, Could, Won’t) - Tie them back to the project goals and objectives - Estimate Time and Cost – Establish your baseline List your Assumptions Identify your Risks (the notion of a Proof of Concept) Allow for Growth Factor in Contingency Propose a phased approach if necessary Offer up a prototype when things are not clear enough
- 6. Creep Management - Clients absolutely hate to be nickle’d and dime’d - Communicate Change Management Process up front - Establish a Change Control Board – if necessary - Use the words: “It depends” where appropriate - Keep a log - Keep the project goal in mind - Ask: “What do you really want?” - Where you can’t wield the hammer of budget, shake the cudgel of schedule
- 7. Summary
- 8. People’s experiences – open for discussion • I always start a new project being very strict about change management. While I learn what to expect from my stakeholders (i.e, do they stand by verbal handshakes? do they waffle a lot? which is most important to them: budget, timeline, quality, featureset? do I need to go into full "cover-my-ass" mode with them?) As I get to know them, sometimes I find I can shortcut some kinda of CRs... but others, I have to stay strict -- either to cover my team from undue blame, or to keep the project from straying too far from the core requirements. • I am willing to accommodate anything, but everything has a price in either time or money. At some point there has to be a reality check. If the original scope is valid, and cost or schedule (or both) is the driver, what are they willing to trade for the extras? If cost and schedule are irrelevant, and they want to push the changes, there isn't an issue in my book. Do the change order and move on.
- 9. People’s experiences – open for discussion • If the requirements process was controversial, it is helpful to explicitly list those items that were discussed, but ultimately NOT included in the final scope. (I have seen this list called "anti-scope" and "non-goals" -- also this is the "W" in MoSCoW). It can be difficult for stakeholders to notice the absence of an item on a list -- particularly if the list is long. That difficulty can lead to big problems if the issue is reopened once the project is underway. • I always try to give the stakeholder at least 2 choices (example: 1) we can do this now, and push the release out 2 weeks late; or 2) we can go ahead with the release without the change, on time, then follow up with a second release, with the change, on date x) If other projects whose schedules would be affected have different stakeholders, then I try to get the stakeholders themselves to come to an agreement about whose is more important, or I send it up the chain to my boss, so he can either make the call, or more likely take it to the stakeholders' first "shared" level -- where someone who has a stake in both projects can make a balanced decision.
- 10. People’s experiences – open for discussion • Scope Creep happens when you think you know the impact of a change so you go ahead, but it turns out that that change leads to another one, and since you are already making the first change, you go with the next. Then another change comes up, and another, and another, until it’s hard to tell what the scope of the project is/was. • In my experience projects that are poorly defined at the inception are ripe for scope creep. Clear problem and goals statements that are (ideally) measurable and time bound help set teams up to succeed. Clearly knowing where you want to go and what you want to achieve, up front, allows you to stay on track and manage scope. It also allows you to know when you have achieved success. • The client wanted a "call centre" - the group got very excited when I said "easy - we can deliver that in 6 weeks" until I also commented that "it would not do what they wanted it to do" - when asked why I said "because you haven't told me what you want" - a clear guided discussion took place afterwards resulting in 4 months of requirements gathering before delivering a "fit for purpose" end product - which did exactly what they wanted - and no scope creep :-)
- 11. People’s experiences – open for discussion • Do you have a justified and contractual leg to stand on? Certainly. Is the customer happy in feeling they already agreed to pay for something they are now not getting? No way. Do they now want to pay more or wait longer for an apparent change in scope that they thought was already included? No, and hand me my flame-retardant suit. Is this a form of scope creep? For sure. Now we can't anticipate every assumption, and a certain level of detail will start to become counter-productive. Like many elements of project management, it starts at the beginning and with lessons learned, best practices, a plan, etc. • In many cases, scope creep is the result of learning. As a project develops, new ideas emerge that could not have been considered earlier. A process of synthesis and evaluation heighten possibility. It is quite possible to hang on to a project too tightly and choke innovation for the sake of dollars, hours and control.
- 12. People’s experiences – open for discussion • One of the most effective 'tools' I've found for managing Project Scope Creep is RAPPORT - with your Clients, your Sponsor, your Stakeholders, and the Contractors or people actually carrying out the work - and all based on mutual respect. If you can get this working well, and be an effective communicator, it simplifies everything else so much. I find it much easier to build and maintain said rapport by being involved - getting off your seat, talking to people face-to-face, physically looking at jobs, etc. Personally, I prefer to get involved as much as possible, rather than just project managing from the computer. Sure, you have to follow things up with the formal documents, but the personal approach (when possible) goes a long, long way. • I've always maintained that project management is about people and not about the various technologies, materials or systems that the project is focused on delivering. Everything that contributors have said is valid and on the mark and highlights the fact that projects are about managing people more than anything else. We should never forget that.
- 13. People’s experiences – open for discussion • The other part of the equation is how in tune with the customer are you as PM? You know the customers who are always trying to get more for the same price even if they did not state it at the start. If he is a valued customer or one that has a lot of trust in your work, then it is easier to let them know that this is above and beyond and if you do it, it is because your doing it as a favor. If it is a bid project and the margin is tight, you may need to state that it is not in the scope you have quoted and you do not have the budget to perform this service. A lot depends on the status of your project. I have found that with most customers, if I can take care of them within my budget and the project is going well, I usually have no problem telling them no to the request. • The success of a project is not judged by only meeting the three pillars but the perception of the customer. If they are happy the project is a success.
- 14. People’s experiences – What not do/say • Can you tell me where in the Statement of Work that is? • There is another option that hasn't been mentioned and that is to allow scope creep from the start. By using Agile project management tools (or anything similar), the initial project scope, time lines and costs are defined. A simple calculation will give you an hourly rate. At this point all items in the project are planned. When a stakeholder requests a change to the project, the cost (time and money) of unplanned items can easily be calculated. Provided the stakeholders are made aware of the implications of unplanned events from the start and they get regular feedback on developments there shouldn't be a problem.
Editor's Notes
- To understand and manage Scope Creep, you need to acknowledge the fact that it’s about managing both scope and creep.These slides talk about what Scope is and what constitutes Creep. Then addresses Scope Definition and Creep Management.
- It is our responsibility to ask all the right questions up front. This is the only way you can get to a complete and comprehensive list of what is in and what is out of scope. The more questions you ask and the more answers you get, the narrower is the gap or grey area in between what is in and out of scope.Start by asking about the business goals and objectives for the project. Clearly understand them and try to get the client to clearly articulate them both qualitatively and quantitavely if possible. If the client can’t quantify their success factors, ask your team to help (Account, Strategy, and Analytics).Ensure that your scope ties back to these objectives. If they don’t, then question the importance of the requirement or the metrics that will measure its success.No matter how elusive scope or the client may be, draw the line as soon as possible and establish a baseline of scope, schedule, and cost. This will help you assess future requests and their impact on your project which may or may not have been kicked-off yet. Failure to set a baseline early will contribute to the confusion of scope. Things that the client thought were in scope may become out of scope, but will go un-noticed if not documented as a change to a previously set baseline. This will result in either scope creep during the project lifecycle, or a dissatisfied client at the time of completion of the project.
- Scope Creep is often the result of change, and change is inevitable. Also change is a consequence of learning. The only way to combat that kind of change is through a prototype.The more questions you ask upfront, the better will your scope be defined. Do not shy away from calling a change, a change. Be tactful in how you communicate it and manage it for the client. Be clear in your communication, before, during, and after a change has occurred. Be clear about what is not in scope, and make sure the grey area is as little as possible. Frankly, if something falls into the grey area, chances are, the agency will have to eat the cost.Beware of internal scope creep as much as changes coming from the client. All our team disciplines are guilty of this. Creatively, we can spend days trying to perfect the way a page looks, we can spend weeks trying to make a flash player way more than what we need, and we could spend months trying to answer a question analytically if we did not ask the right questions upfront, or if someone all of a sudden thinks certain data can tell an interesting story when that story was never to be told as part of our scope.
- Be thorough in capturing the features and requirements. There are no stupid questions. Better ask them rather than assume, but if you do make an assumption, document it.It’s important to go through a ranking exercise with the client regarding the business impact of the requirements (MoSCoW). Once you add the level of effort, then you can repeat this exercise based on the new information. Make sure you start by asking the client to rank their constraints first (Scope, Schedule, and Co$t). Once you know what is the least important, that constraint will have the greatest impact on your ranking methodology.Requirements that need to be taken out of scope due to budget or time can be re-addressed for a future phase. Make sure you state this in your estimate/SOW. Specify what those phases are and which requirements will part of those future releases rather than the immediate one being scoped.Identify how each requirement ties back to the project objectives. If it doesn’t, then it can’t be priority.As you estimate the project effort, ask your team leads to provide you with any assumptions they have made to produce the estimate. Ask them to also outline any risks they foresee. Every project with a significant amount of effort should go through a risk evaluation/management exercise. The key determinations that need to come out of such an exercise:Clearly identify and articulate what the risk isEstimate the level of severity it will have on the project if it happensEstimate the likelihood of the risk happeningAssign an owner to monitorWhen it needs to be monitored (daily, weekly, or on a certain date)Come up with a Mitigation PlanFigure out what your Contingency Plan isEvaluate the impact it will have on the project from a scope, schedule, or co$t perspectiveYour evaluation of the overall impact of the risks and their likelihood should help you assess the amount of contingency you need to add to the project estimate (schedule contingency and co$t)For some projects, you may want to include a growth component. Not to be confused with contingency, this growth bucket will help you manage client expectations and cover some learning induced changes without going back to the client every time for a change order. These are not necessarily used to cover scope changes, but rather slight changes and tweaks to those already identified requirements.If some of high risks identified can be mitigated by a Proof of Concept, try to make that a phase 1 before you commit to the rest of the scope. This should be to the client’s advantage in a Time and Materials type of Contract. It will also be to their advantage in a Fixed Price project, because instead of charging them for the risk up front, you try to eliminate or minimize the impact of that risk. Obviously, the cost of the prototype should be less than what the risk evaluation imposes on the project budget.If a requirement is unclear, or the client cannot make up their minds which way to go, then suggest a prototype. A prototype will help demonstrate the functionality and can assist the client in choosing a direction. A prototype is only necessary if different directions have a different level of effort associated with them.
- Partner with your Client Services counterpart and build a trusting relationship with the client. The client needs to feel that you are looking after their interests, keeping your eyes on the prize, maintaining focus on the bigger picture, living and breathing the objectives of the project.It’s not about taking their money, it’s about delivering our promise.Make sure your client understands what a Change Order is. Sometimes a Change Order is necessary to document a change even if it does not have an impact on either Co$t or Schedule. Provide examples and samples so none of this will be a surprise when it happens.On a large scale project that spans more than 8-12 months, establishing a Change Control Board would be beneficial. Make sure you outline and document the process up front as well. The clearer you are in articulating the process, the easier it will be to follow it and refer back to it for support.When the client ask if they could change or add something, don’t say no. Start with “it depends”, then explain the dependencies and constraints. Always allow the client to make their own decisions. Do not assume you know what they’re thinking or what they want, ask them and let them make an informed decision.You are encouraged to keep a log of all changes. Some will be accepted and some won’t. Keep both documented. You may choose not to charge for some small changes right away. Defer the charge until you’ve had a few that add up. Let the client know you are deferring. Do not surprise them with a Change Order of 5 things over a period of time unless you’ve clearly articulated to them that these are changes that will be deferred until there is enough to justify a Change Order. Keep the client abreast of the log so it’s completely transparent,The change log can contain the following information:The changeWho requested itDate it was requestedDetails of impact to ScopeLevel of Effort (Co$t)Impact on ScheduleStatus (some will be accepted, some may be dropped after they are estimated)When a change is requested, do not be afraid to ask “What are you really after?” or “What are you trying to do?”. Make sure you ask how it ties back to the project objectives.Warning: If project objectives change mid-stream, do not hesitate to ask to re-scope the project, because as we mentioned at the very beginning, scope prioritization was dependent on project goals and objectives. When these change, your entire project needs to be re-evaluated.