♪ Hey ♪
(upbeat music)
- Hey thanks for checking out "Coffee with Brett".
I'm pretty caffeinated, second cup.
Ready to go.
I hope you are too,
because I just need to cut to the chase here.
Are you ready?
Don't start any project without a scope document.
Seriously I mean it.
Don't do it.
When I was a freelance project manager,
I agreed to work on a project that had what
they called a loose scope.
Never heard of that.
Now I was an experienced PM at that point
and thought there's no such thing as a loose scope,
but these people seem kind of cool,
and the project's kind of exciting,
so I can usually sort things out.
All right, I'm gonna give it a shot.
Gotta say that was the worst mistake.
And honestly, I knew it was a mistake,
but sometimes you just go with the flow.
But can we all agree that PM's should never ever
just go with the flow.
PM's make the flow.
Anyway as you might imagine,
that project was a mess from the delivery
of the first design.
Immediately there were stakeholder questions.
Like what about this thing?
Or why didn't you do this?
Or can we have?
Those are not the kinds of questions you wanna
be asked in a design review.
And those questions kind of just started
a snowball effect for me.
And I could essentially see a giant avalanche coming to me.
So I stopped the conversation and forced the discussion
about the project and the project scope
or what we could actually accomplish
with the project budget.
Now I'm not gonna tell the whole rest of the story here,
because our time together is limited
and I respect your time,
but I'll say this, we got it done.
It wasn't profitable, but we got it done.
If we had a scope from the beginning,
we never would have been in that situation because
our task estimates, plan, and requirements would all
have matched up leaving no room for scope creep
or whatever you want to call that weird situation
of a project.
So there's an undoubtedly long list of things
that can make projects go sideways.
And I'm sure that you've seen some monsters.
Most PM's have,
but I'm here to tell you that
a poorly defined scope document or worse,
not even having a scope document at all,
is at the top of that list.
So let me stop myself here.
Maybe you don't know what a scope is and that's okay.
That's why you're checking out "Coffee with Brett".
In fact not all organizations require scopes for projects.
So crafting project scope documents might not
be a common practice for you.
A project scope document,
which is also often referred to as a scope of work
or SOW is a statement or document that gets teams
and stakeholders aligned on the components and boundaries
of a project before it even begins.
A well crafted scope document can save you
from major headaches by clearly defining your project
before you've even planned it.
A lot can go into a scope document, including project goals,
requirements, major deliverables, key project milestones,
assumptions, constraints, deadlines, budgets.
There's so much that it can make your head spin.
But trust me,
this is the information that you want out
in the open at all times.
I can not tell you how many times I've referred back
to my scope to help me out of tricky situations
or conversations with stakeholders,
mostly because the details and honestly,
having a common understanding and an agreement
on those details,
will enable you to say no easily
when new out-of-scope requirements pop up.
And let me tell you saying no doesn't feel any better
than when you've got a signed document to back you up.
So I wanna talk about how to create a solid scope here,
but listen, just like everything else in project management,
there are a number of ways to do this.
So you need to consider your organization's policies,
your project work, your team, your stakeholders,
and all of the other things that kind of come along
with running projects in your organization
before you land on what level of scope is going
to work for you for your team and your stakeholders.
I mean I wouldn't be lying if I told you I've seen
a scope documented on a whiteboard.
Yes a whiteboard,
but I've also seen 50 plus page formally
signed scopes in triplicate.
Sounds ridiculous.
Yes.
Necessary?
Double yes.
I've also written scopes.
So I wanna share what have I,
what I have included in them.
So are you ready for this quick adventure?
I'm gonna run through these components
of a scope really quickly here,
after I take a sip.
(gulping)
All right, let's go.
All right, so first is a business case and goals.
Business case and goals are so important.
Every project has them and you want them defined,
written and agreed on.
So outline the reasons the project is being funded along
with a set of business goals or intended project outcomes
for your team to kind of keep in mind while
you're executing the project.
You're gonna point back to those goals
to help make decisions, to inform your plan.
And even to reject that scope creep when it comes up.
Next is the project description and deliverables,
which basically outlines in detail,
what will be delivered for approval through
the course of your project,
as well as what that final deliverable will be.
A good example of that might be if I'm creating an episode
of "Coffee with Brett" for an important person like you
or someone at YouTube or someone at TeamGantt.
I mean wherever you are.
I might say something like this in my scope,
Brett Harned will produce
and deliver one 10 minute educational video
on project scopes in AVI format to be used on the web.
It's a simple description of what
you're working on to deliver,
but it also spells out small details like quantity,
amount, length, or what other,
whatever other aspects accurately describe the project,
or even just parts of the project, right?
All right moving on.
The next is acceptance criteria.
So think about it.
You say you're done, "Cheers,"
and the client says, "Mm nah, don't think so."
That's no fun.
So you wanna avoid that awkward turtle moment, right?
So write a statement that creates agreement
on what will be delivered and leave no question
when the project is complete.
Then think about limitations.
There are probably at least five ways you
can produce any project.
That's not real science or math.
I'm just kind of guessing,
but some projects might take more time and energy
than others or some processes or ways to get
to that final deliverable might take more than others.
So get clear about the limitations that you're working on
and set clear expectations on how you will get there.
Limitations can come in a lot of forms.
One example might be technology.
So for instance,
if you're building an application that depends
on a specific technology,
be sure to mention that.
There may be several ways to code that app,
but if you're boxed into a complicated technology
that only you know, or the stakeholder doesn't know,
you can cover yourself by specifically specifying
those limitations in your scope.
So I've been there and trust me,
this is an important one to think through because yes,
people still try to use Internet Explorer 10 in 2020,
they just don't realize that there are probably one
of a hundred people in that position,
and they don't understand that it would be crazy
for you to waste your time on building something
on an antiquated browser, right?
So think about those kinds of things.
It's an assumption that people could make.
And that leads me to assumptions.
Okay, I've got to do it.
You know what they say about assumptions, right?
And you probably know it's true.
If you don't outline those assumptions,
you'll end up with confusion, and missed expectations,
and probably a lot of project problems.
So take the time to list out all of the assumptions you've
thought about that will affect the work
that you're going to do,
and the outcomes of the work that you're going to do.
Next is exclusions.
When you're working with people who
don't really understand your work,
telling them what they won't get can be just
as important as telling them what they will get.
This would have been really helpful in this situation
that I shared earlier.
So now I'm getting into the territory of kind of could haves
with your scope documents.
And again,
if you're writing scopes that you'll want
to consult with someone on,
make sure that you're actually consulting with the people
in your organization first.
Talk to your company's management or even legal counsel
to review these documents.
None of this that I'm giving you here is legal advice
aside from saying, you should really get some legal advice.
So do that,
especially when you're talking about costs,
which can be directly associated to what you're offering
in your scope.
The clearer you can be about costs
and the work associated with it,
the easier it will be for you to manage it
and to make a case for funds when additional scope
does creep in.
Anytime something involves money,
I get a little nervous and you should to.
Have it reviewed and reviewed again,
and just make sure that you're covering yourself.
All right my last six suggestion here
is another optional one.
Depending on where you work or kind of the types
of projects that you manage,
you're gonna use this.
Scope documents create agreement by nature, right?
But it really means nothing without an actual signature.
So include a signature field in your scope document
and have your lead stakeholder or project funder,
sign that document to create that real agreement.
Again there are more legal ramifications there,
so be sure to have any scope SOW,
or contract reviewed before you get it signed
or before you even sign.
All right folks, that's all the time
and caffeination I have to talk about project scopes.
That was a lot to cram into a short video.
So explore more ways to create scopes and better yet
how to manage them at teamgantt.com.
I'll be talking about scope creep pretty soon here too.
So keep an eye out for that episode.
In the meantime, please give me a like and a subscribe
to our YouTube channel to get all the PM education
we're producing when it's fresh unlike my coffee.
Time to refill.
Have a good one.
♪ Hey ♪
(upbeat music)