Project Management

Please login or join to subscribe to this thread

Coaching for Negative Scope

linkedin twitter facebook   Governance   Organizational Culture   Scope Management  
avatar
Mandy Schramm IT Project Manager

I'm in a small public sector IT shop that has not used project management previously. Scope creep is a way of life, largely because there no appreciable requirements gathering. A business area comes in, says "we need a widget," and IT says, "On it." and gets coding. You can imagine how well things get rolled out.

But, Leadership realized that there's a better, less frustrating way, and hired me. Every time I talk about "out of scope" I get comments like, "everything that's not in this app." I've run out of ways to explain the idea that you should identify what you AREN'T going to do as early as possible. Nothing seems to be sticking.

Any suggestions? Do I stop trying to revamp intake, and skip to requirements gathering improvements?
Sort By:
avatar
rene walls United States

I’d start with requirements gathering, but make scope boundaries part of that conversation. People who have never worked with project management may understand it better through examples than terminology. Try explaining it this way: “We’re agreeing on what we’re building, what we’re not building, and what would require another decision before we add it.” For example, if they request a widget, ask whether reporting, https://www.yearbookavenue.com.co mobile support, and automated notifications are included. Those things might be useful, but they shouldn't automatically become part of the original request.
avatar
Abolfazl Yousefi Darestani Manager, Quality and Continuous Improvement| Hörmann-TNR Industrial Doors Newmarket, Ontario, Canada
Requirements gathering improvement is a must. However, I would list out all creeps and all relevant consequences/costs associated to them. then present them to the stakeholders. It may be more beneficial. You should be bale to communicate the benefit of respecting the scope.
avatar
Aaron Porter
Community Champion
IT Director| Blade HQ Payson, UT, United States
Having worked in a couple of small organizations and been the only project manager, I've learned that you can influence the adoption of project management and business analysis practices, but you can't force them. Start small, demonstrate value, and build from there.

My first thought is to listen to your stakeholders. You said it yourself, they have "...not used project management previously." They possibly want something to change without having to do more work. You were hired to get $#!+ done and help them be and, more importantly, feel successful. They don't care how the magic works. They care that it works and how it makes them feel.

This doesn't mean you ignore your training or past experiences, you just can't apply all of them at this time. Your mission, should you choose to accept it, is NOT to introduce the BABOK or PMBOK Guide. Yet. A critical part of your job that will determine your success is your ability to influence, not educate. For that, you need trust, which is earned a little at a time and requires proof.

Instead of talking at them about scope, ask them questions like the following:
- What problem are we trying to solve?
- What does success look like?
- What's the smallest useful thing we could deliver?
- What would be nice to have, but could wait?
- What are we deliberately leaving out for a future version?

Instead of talking about scope creep, have conversations and ask questions. For example, "We can add that. It may mean delivering later, postponing another feature, or adding capacity. Which makes the most sense?"

As you demonstrate success, you can start working in principles and practices. If a bigger/more complex than usual project comes up, ask if you can use some more formal principles and practices that you believe will increase the likelihood of success. Make them part of the decision without feeling like they have to learn how to be project managers or that you think you're smarter than they are. (I'm not saying you're doing this; some people take offense if they think you looked at them sideways when all you're doing is stifling a sneeze)
avatar
Kiron Bondale Retired | Mentor| Retired Welland, Ontario, Canada
Mandy -

This is not an uncommon problem. A lot comes down to what constraint matters most to the decision makers. If they are schedule bound, then it is a question of protecting the release date and letting scope be flexible using a prioritization approach which the decision makers buy into.

Kiron
avatar
Lissette Indhira Pimentel Sosa
Community Champion
Program Manager| HARPER SRL Santo Domingo / Distrito Nacional, Dominican Republic
I wouldn't abandon the intake process, but I would simplify it and connect it directly to requirements gathering. Since the organization is still getting familiar with project management practices, introducing too many concepts at once might create unnecessary resistance.
Instead of asking what is out of scope, I would start with something more practical like: "What are we intentionally leaving for a future phase?" or "What might users expect this solution to do that we are not planning to deliver?"
Sometimes changing the way we ask the question makes a difference. Once people start seeing how these conversations prevent misunderstandings and rework, it becomes easier to introduce more structure.

Please login or join to reply

Content ID:

"There is more to life than increasing its speed."

- Mahatma Gandhi

Sponsors

Newsletters

Nov 4: Fix It Yourself? Maybe You Shouldn’t...
Oct 28: Leadership Isn't a Popularity Contest
Oct 21: Leadership Takes Courage

See all newsletters