Training Scope Creep Linked In

Scope Creep

Not this kind…

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)

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

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

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

Summary

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.

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.

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 :-)

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.

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.

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.

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.