Re: The DANGER of Scope Creep

Love it. The question is, how do you prevent it. Some clients are actually good at it, like they practice it or do it intentionally. Even with accepted requirements and a clear goal, they seem to start with a minor tweak and work it into an added feature.

How do you know when to say "that's doable but not in the contract."?

Especially when the added feature, rather than ruining a project, is perhaps a good idea. I try to look ahead and make suggestions, give options and foresee the possibilities but sometimes the project has to take shape before the feature suggests itself.

What are the words you use?

Keep on Coding!Mark Cicchetti - There are 10 kinds of people... those who understand binary and those who don't.

Re: The DANGER of Scope Creep

Prevent a skid before it happens (avoid these common issues)

• Driving too fast for the conditions• Braking too hard for the conditions• Accelerating too hard for the conditions• Steering too harshly for the conditions• Taking a curve or a turn too fast for the conditions• Falsely believing that SUVs and pickup trucks somehow have better grip which allows them to be driven faster in snow and ice conditions

If your rear wheels skid...

• Take your foot off of the accelerator.• Steer in the direction you want the front wheels to go. For example, if your rear wheels are sliding left, steer left. If they're sliding right, steer right.• If your rear wheels start sliding the other way as you recover, ease the steering wheel toward that side. You might have to steer left and right a few times to get your vehicle completely under control. If you have standard brakes, pump them gently.

If you get stuck...

• Do not spin your wheels. This will only dig you in deeper• Turn your wheels from side to side a few times to push snow out of the way• Use a light touch on the gas, to ease your car out• Use a shovel to clear snow away from the wheels and the underside of the car• Pour sand, kitty litter, gravel or salt in the path of the wheels, to help get traction• Try rocking the vehicle. (Check your owner's manual first — it can damage the transmission on some vehicles.) Shift from forward to reverse, and back again. Each time you're in gear, give a light touch on the gas until the vehicle gets going.

Oh, wait. That's how to avoid a skid. I thought I was posting in a different forum but it still applies. Like driving with project management you have to remain vigilant, be gentle and progressive when steering, accelerating and braking, pay attention to the conditions, avoid hazards, take extra care when approaching a bend, slow down, know the direction to which you want to go, be quick to respond and be agile (pun intended).

Remember you are the expert, you know the end goal and you know best how to get there. You know pitfalls and hazards your clients are not aware of and they are relying on you to guide them to the best outcome. What we try to do is produce a product better than they asked for and better than they imagined. You are the driver, don't let your passenger be in charge of the steering acceleration or braking.

roy darling *my posts seem a lot shorter in my head...turns out that my two cents is worth less or more depending on the current exchange rate

Re: The DANGER of Scope Creep

Great topic! (And sensible when taking on any project, be it for yourself or for a client.)

Back when I was doing agency work we'd always refer back to the budget. The budget is based on available resources (i.e. time invested), so if you change the scope you're changing the time required, which means the budget will change.

So then the conversation shifts to keeping the budget on track, because the client doesn't want to spend more money.

This opens up a few different opportunities:

One, you can put new deliverables on the backburner as additional work for a future phase. This gets everyone thinking long term (when something will be done versus if something will be done). Generally a good thing.

Two, you can re-prioritize project deliverables. If the client wants to do something new, they'll need to remove something that was previously agreed on. Less good, but helps keep things under control.

Three, increase the budget, meaning more time and more money. The project deliverables are re-defined, inclusive of the new scope, and the launch date is pushed back. The least good of all three options, since it can impact other projects, but at least you're being compensated for the work you're doing.

Re: The DANGER of Scope Creep

Ditto what @andymci says: make it about the budget and your respect for it. A balance between the two makes you look like a customer's hero (you're advocating for their success and looking for ways to make it happen) rather than being the bad guy who overpromises, underdelivers.

Re: The DANGER of Scope Creep

Where possible I use the SCRUM methodology to run projects. Scope creep is dealt with pretty easily with scrum. Whenever the customer wants to shove something in, he needs to convince the product owner and if the prio is high enough, it will end up in the next sprint. I highly recommend scrum for open-ended projects and project-teams of more than three people. For fixed price projects, if a customers asks for something that is not in the specs, I usually answer like "Sure I can add that, it will take about X hours to implement and is not included in the specs". And let them confirm if they want to go ahead or not. Be willing to do anything the customer asks for, but be clear and straight about the additional budget and time it will cost.

For good clients, I let them create a simple (Word) backlog and make the deal that - IF there is some time/budget left at the end, I will pick-up the additional requirements.

Re: The DANGER of Scope Creep

The WONDERFUL thing about working in the corporate world was that it was a professional environment filled with people who understood and believed in workflows. The familiarity with process meant that they were generally more accepting and understood the level of inputs that could and could not be included and at what value. Even then, if your VP was like mine there were still things crammed into every project and that was from a person who understood (in theory) the working method.

I don't always have the convenience of having a client that is a Project Management Professional or is versed in Scrum, Waterfall, Crystal, Agile, DSDM, JAD, RAD, RUP... This means that we are the drivers, you would never get into the passenger seat and let someone with no familiarity steer so don't do it for your projects. We show the client the way and are happy to guide them.

We also have clients who are proficient with project management when they come to us but though they are an experienced "driver" we are still behind the wheel. A good project manager will be a bit flexible with regard to the plan. I think what @DFurlong71 said we often are in the place when we can under promise but overdeliver. We all know those "nice to haves" that are easy to do that we can sneak into the deliverable. Balance is absolutely the key.

It is also perhaps important to note that the Bradley Personnel Carrier Bradley Fighting Vehicle is a real life example.

roy darling *my posts seem a lot shorter in my head...turns out that my two cents is worth less or more depending on the current exchange rate

Re: The DANGER of Scope Creep

For those unfamiliar with the SCRUM methodology could you provide us with a bit more information about what it is, when to use it, and where to get more information on it? For modern day web developers and project managers it is indeed a good framework from which to work!

Re: The DANGER of Scope Creep

For those unfamiliar with the SCRUM methodology could you provide us with a bit more information about what it is, when to use it, and where to get more information on it? For modern day web developers and project managers it is indeed a good framework from which to work!

Thanks,

James

Scrum is a type of "agile methodology" - there are terrific books on it as well as tons of material online.

Start at scrum.org (although it's a certification site now it's got some great original resources).

Re: The DANGER of Scope Creep

Here's what's fascinating about this topic of scope creep:

When building personnel carriers (or tanks) you're making a physical object. So the decisions you make on what is in or what is out have huge repercussions. That's why you keep seeing these plans being printed to validate the look of the object. But what you did not see are any of the trade offs communicated in any real way.

When working with digital, the handcuffs of creating physical items are unshackled. There are practically an infinite amount of ways to deal with a request of a customer. But it is critical to set out some objectives up front about what you'd like it to do and then check back when the scope creeps. Scope creep on its own is a psychological way to validate that what you're doing is "getting better." It's not a bad thing in and of itself.

It's only bad when it goes off target of your objectives. When you wanted to hold 11 soldiers and now you're holding 6 (almost half!) then are you achieving your target? What if you ended up holding 10? That seems within reason. What's the least number of men you want to carry before it's not a speedy personnel carrier but a tank? How do you determine this number? That magic of working towards business objectives and collaborating around whether those objectives are being met is the stuff of great project managers (not just good ones). The colonel in the video starts out well, but he's never really identified what the objectives were and never re-validated them at all. He never asked "forget about the 'look and feel' and 'munitions', but rather how many personnel do you want this thing to carry?" Getting buy in on the number would create a pretty clear scope and be able to easily loop back when that's not being met.

Re: The DANGER of Scope Creep

Hello @SumBuddyNutty, I don't think anyone is saying that the Bradley doesn't work? The issue here isn't the result but the process. I should hope that Generals are aware of what they are doing. Customers undoubtedly know what they want in their business but as the subject matter expert so do you in your area.

Just so you know I am of the impression that a customer cannot always get what they want. In my projects I feel like I am the one who determines what can and cannot be done, my role is that of the subject matter expert. Further I know that what can be done should not always be done. Just because it works in the end doesn't mean that the project process didn't go sideways.

Lastly, @SumBuddyNutty it sounds like you have some seat time in the M2/M3? The important thing to note here is no one is suggesting that the result of any process is flawed. I think the real thing of note is that the making sausage is sometimes a difficult process to watch and one that needs to be monitored carefully to insure a quality result.

roy darling *my posts seem a lot shorter in my head...turns out that my two cents is worth less or more depending on the current exchange rate

Re: The DANGER of Scope Creep

There are lots of times when a solution is "made to fit" even though it was not meant to be. Duct tape is a great example. In Canada it's used for EVERYTHING.

As @rd says it's the process and journey that we can make better. And of course there something to be said that the process, when done as described in the video, takes too long and COSTS too much. So while the end result may accomplish the goals, it didn't really have to go that way. That's really what I think we are saying.