♪ Hey ♪
(upbeat music)
- Hey, thanks for taking a break with me.
I've got a piping hot cup
of Hold Fast Coffee Company's Ethiopia brew.
It's really good stuff,
but I need one more sip because I've got a lot
to get through in just a little bit of time.
All right, so in episode four,
I talked about project scopes,
and I said I'd cover scope creep,
so here we are,
scope creep.
(sighs)
No one likes scope creep.
You know what it is, right?
It's when a change is introduce to a project
and it negatively impacts the project's scope.
It's one of those things that we all encounter
in one way or another in projects,
and honestly,
I feel like I've seen the many faces of scope creep.
They're not cute, trust me.
In fact, they can cause stress and confusion.
But I'm here to tell you
that you can totally smack scope creep down,
metaphorically, of course.
Just let me give you one example
of how I've personally managed
scope creep on a project of my own.
All right, so I was working with this really big,
iconic music-related company
who shall remain nameless
while I enjoy my coffee and you enjoy yours.
So anyway, my team was contracted to build
this super cool website to support
a live event that they were producing.
It was a really fun project,
and they loved what my team delivered,
which was exciting,
and it was actually 95% complete
and totally on time and within the budget,
which is just magical.
If you're a PM,
you get me.
So it was magical until they told us
that they needed to whole team on site
at the event to support the new site during the event.
On site, with the site,
sounds a little confusing,
but y'all don't know me.
Going on site to that event,
wow, 16-year-old me was doing back flips in my head
when they asked for this.
And then, the reality settled in,
and ugh.
I think that imaginary teenager
in my head fell flat on his face.
We didn't have airfare, hotel or expenses,
let alone the time for five of us
to travel across the country
and be on site to support this event for a full day.
None of that was included in our project budget.
So at that moment,
I started to calculate the potential costs in my head,
thinking, calculating,
just to see,
could it be possible,
thinking, please let it be possible.
No, it was absolutely not possible.
It didn't fit in.
The scope had creeped out
and I as the PM had to push it back out
or I had to ask my stakeholders to fund the change.
And then I would happily welcome
that scope back into my project into open arms.
And in the end,
that is actually what happened.
Honestly, I got lucky.
Not only did I get to manage this super cool project,
I got to go to the event too.
And it was fun.
I mean, of course it was work,
but it was a lot of fun.
There are so many more details in that project alone
that I would love to tell you about,
but I need to move on.
So anyway, I hope that story of mine gives you
a little bit of an idea of what scope creep is,
or at least one manifestation of what scope creep could be.
I've also experienced other things
like additional unplanned rounds of design change,
changes to requirements,
stakeholder delays,
budget reductions,
deadline changes,
misunderstandings of the scope,
and a lot more, too.
Listen, there is a ton that can happen on projects.
I'm trying to keep this video super short,
so if you do wanna dig deeper on the topic of scope creep,
check out the Art and Science of Leading Projects.
There's a full free class
and even resources on managing scope creep.
Yes, that was a little bit of plug,
but you should check it out.
All right, moving on.
On screen are some things that could cost scope creep.
It's no exhausted list,
but just know that you need to be deep
into the details so that you can make your team
and stakeholders aware of the limits
of your scope before they try to test
those limits because we all know that's gonna happen
and you're gonna know it pretty fast when I does.
Still, you should try to avoid scope creep at all costs.
I've got some ideas to help you.
All right, let's do this.
How to avoid scope creep in five simple points,
and I'm gonna try to be quick.
First, gain alignment with your team and stakeholders.
Be sure that you agree to your project scope and goals.
Doing that will make it so much easier for you
when you have to decline a new idea that isn't in scope.
Or better yet,
it'll help you to steer them in another direction
that's more appropriate for the project's goals and scope.
Yes, this could be your opportunity
to show your strategic side.
Next, always have a plan.
Here I go again,
but seriously,
it's a whole lot easier to avoid scope creep
when you have a clear plan from the get go.
So take time to outline every step
you need to take to get from the beginning of the project
to the end to do it on time and on budget.
Related to that,
be sure to talk about how changes
not only impact your scope,
but also your deadline.
A date's a date.
Introducing a change will most often
cause an impact on your schedule.
That fact combined with a budget increase
related to a change can sometimes
end the scope conversation before it even starts,
and that's pretty cool.
And if that doesn't happen,
then just tell them no,
or sorry, no.
And of course,
explain why,
always explain why you're saying no.
That's the part that will give you the confidence
to actually tell an important stakeholder no.
And of course,
you're gonna do it in your own warm and fuzzy way.
All right, the last thing here, folks,
is important,
is really pretty important, I think.
Be sure to have a process
for managing change in your projects
and in your organization.
This is equal parts setting expectations,
and also creating a little bit of process.
So if you're in a larger organization,
you might already be required
to complete a series of approvals
or even documentation to lock in the fact
that everyone in your project agrees
to a change in a budget or timeline.
That's a great practice to have.
On smaller projects with smaller teams
where things tend to be a little bit loose,
maybe a little more informal,
I found PMs who take everyone's word for it
and keep moving with changes,
and that's honestly not a great practice.
Honestly, you're better off creating a paper trail
and formalizing that agreement.
Call me a skeptic,
but I can't take your word for it even on small projects.
Sorry, it's not personal,
it is what it is.
I would even go as far to say
that it's not a bad thing to write a change request.
Always write change requests, actually,
but write change requests
even for non-scope related changes.
It can be a really good way to cover your bases
and to make sure that no one's gonna go back
on what had been verbally agreed to.
But yeah, write change requests.
Just do it.
Any good change request
is gonna require the things that are here on screen,
a description of the change,
an outlined approach to that change,
the timeline impacts associated,
as well as the risks
and costs associated with the change,
and then a signature field.
Remember, get those signatures,
especially if you're operating under a contract.
It's really important.
All right, friends,
I have to admit I've been going
over scope on these episodes.
I'm aiming for five minutes
and they've gotten longer.
So I am the scope creep now.
All right, I'm a weirdo.
Anyway, I hope you're liking Coffee With Brett.
My hope is that these quick hits are either helping you
or getting you into project management,
or maybe they're just relatable and silly.
That's cool, too.
If you've made it this far,
I'm thinking that you're liking it,
so do me a favor,
give us a like and a subscribe to our YouTube channel
just to get updates on all of the project managing
content we're producing at TeamGantt.
And if you wanna share this video
with your friends and colleagues,
I wouldn't mind that at all.
In fact, tell them I said hi.
All right, see you next time.
Cheers.
♪ Hey ♪
(upbeat music)