The Art and Science of Defining Scope
They say that one of the most common reasons for project failure is poorly defined project requirements. How do you go about defining a vision for a project, a scope, and requirements? What's the difference between those things, anyway? And how do you effectively communicate them to make sure everyone is on board?
Notetaker: Laura Defining and confining scope Michael & Eric Leland
Definition of scope, what does scope mean to you Michael: From a vendor side - 90% of our job is to manage scope. Important to recognize that
scope will always grow and to manage this growth across budget and time
Eric: Consultant side. Scope started out as a big liability. Interested to hear when scope
became an opportunity
Scope increasing at a scary rate. What are the best ways to manage that? Important to be as specific as possible up front. Make a plan for the whole project (or as
much as you can). Feeling of not knowing what tools are needed to make good estimates. Want
to know Ways to track time really well and being able to match it up to estimates. Want an
at-a-glance look to know how close you are to estimates. Being able to deal with situations
where we've agreed to go out of scope with a client when we shouldn't have and without
talking about budget -- how do you deal with and move forward from these situations?
Interested in defining scope. Typically, most people don't internalize what the scope is.
People start a project without a real understanding of scope. Very difficult because very
few people really understand a requirements document. Progressive visualizations that help
people go from step to step in understanding what we're doing. Used requirements documents
with vision diagrams, which takes different forms depending on medium. For a website,
wireframes of a few key pages. Something that seems to encompass a collective feeling of
what we want to build. Progressive meaning user flow through the website (funnel idea).
Tying scope to understanding.
"Start up" mode. Everything is great. Everything goes into the pot. After 6 months going
into "sustainable" mode. "Sustainable" mode being where the team has a budget and a timeline
and a very detailed scope is defined. It was very painful because that was how the team had
been operating before. It was hard to stick to the "sustainable" mode spec docs.
Tradeoffs exist. Trying to keep people aware of that.
Want more experience defining scope from a developer background. Spec is for techies and
developers and scope is for end users.
Don't like to say no to client requests. This is the cause of my scope problems.
Does scope have a fear factor? Afraid to say no? Afraid to upset the client? Afraid to lose
the client? Underestimating in the first place because afraid of sticker shock? Afraid of
bait and switch? Important to battle the assumption of "they need this". A way to not say
no, is to say put it in the parking lot. Define types of features early on: Must haves,
wishes, and don't really needs.
Internally, scope is a much fuzzier concept. Which can make it even scarier. It's easier as
a developer / consultant to use a stick to say no.
Important to keep no saying productive and constructive.
If you are going to go above and beyond, make sure you expose the real effort. Show the
client what you doing for them. Let clients claim their own tradeoffs. Be careful not to be
A tool to use: write down every change order. Put down official change hour without putting
in hours. Make everyone aware of the amount of work that is being done.
Signatures are key.
Scoping is a nice thing to have, but there are different interpretations. Along the way the
client might say this is not what I think. The question is how to interpret the scope. How
detailed do you need to go? Does "three wireframes" mean three with revisions or you must
choose one from the three? It is important to be flexible in your scope. Pick someone
competent with good customer service.
Design and scope. Break down a large design project into phases. I will give you three
rounds of wireframes and the first round will be based on our conversations and you get a
chance to look at all three and give feedback. I'll do a few more rounds and then we'll
start the final design process. Several opportunities to let clients give meaningful
feedback. After hitting budget, let client know and talk about wanting to revise an estimate
or cut it off. Expectations managed in a written contract. Try to present three fairly
different and be able to respond to elements of each that work and elements of each that
don't. Have an extensive questionnaire that the clients fill out ahead of time. So have
something to point to if they have changed their mind.
Very difficult to deal with clients that just say "when I see it I'll know". What do you do
if you miss entirely?
It is really a good thing to have a project manager around to represent the developers and
designers. Able to shield the actual work. Like having a manager represent a celebrity.
But that depends on the specific consultants and workers. Having a schedule that you create
concrete steps with some flexibility within these steps.
Defining scope as a tug of war between client on one side and the vendor on the other.
Clients are sometimes very aware that vendors should not just be dishing out favors and that
this is a vendors livelihood. Tension is due to misunderstanding which is often caused by
not sharing a common language. Important to ask the vendor when a question (especially about
terms) comes up instead of asking coworkers or friends because the vendor you are working
with might have a different understanding of the term or question.
Scope has a negative connotation to it. All vendors come with a story of being burned.
Vendors try to control scope in order to protect themselves. You can never estimate
everything. Functional changes in design is a terrrible thing. Good vendors will try to the
best thing for you but also cover themselves.
Clients often fall into this idea where they want more, more, more for free on a very
instinctual level and so clients need to be aware of this instinct and that it's very
difficult for consultants to do that.
Expectation management happening on the client side. Clients are often middle people -
having to report to their bosses.
What can we do if we don't ahve the privileges that consultants have? Talk in terms of
capacity. If we want this, how can we support this without high level expertise on staff?
Managing who listen to who within an organization. A manager might see you as an expert in
an area you weren't hired in. Finding a champion. Are they on my team? Expanding concept of
stakeholders. Finding an internal tech team, the people who will be using it.
Treat internal projects like client projects. Scope, budget, timeline. Have tools to
integrate it. If there's something we're doing, but it's not a project, that's messed up.
Everything is a project and everything has a scope and if not, you've got a project.
All these commitments that have been predetermined. A good example are grant and donor
funded projects. A client has been given x amount to make a social networking tool.
A red flag is that a client already has funding for this project already. Usually offer the
client something when the client is in the grant application process.
Slamdunk projects are known by vendors. Sign off on this scope. It's hard for some vendors
to recognize that clients might not know what slamdunk projects. If there is an educational
component, raise that with your vendor. The lets them know to budget for education.
Change order process. This is what triggered that. Make sure you know your client and your
client's knowledge base. Walking through scope with a client. At the end of the project
(post-morteum), go back through the scope and use it as a checklist.
Make sure you speak in terms and details that the client understands. Don't just say "write
content". Clients don't know what exactly what that means. Clients meeting their deadlines
late and feeling badly about that because they needs to be defined clearly.
At an agency where no one has done a scope. No one pays attention or reads it. Just ignored.
How do you fight that?
The majority of our session was about open, honest communication about their needs and
expectations. It's about a relationship and a partnership. A document is useless if no one
reads it or pays attention to it. Sometimes it's essential to go through page by page and
make clients initial every page. It comes down to vocabulary and taxonomy. Contain the scope
and scope creep isn't a bad thing, it just has an impact.
Regular clear communication is really key. Using shared language. Not just the terms but the
tools you're using. Making sure you're using the right tools for the right audience. Visio
might not make sense to some people.
Visual communication might be a good tool to use. Written or verbal communication might not
work for everyone.
If people don't understand the scope then you don't have one. It doesn't count. Even if
technically you are right, everyone is just unhappy. If you have to pull out the signature,
then you've failed.
It's really important to invest in planning. A collaborative brainstorm where everyone gets
detailed thoughts out on paper. You need to sell clients on planning.
It's important to have a lot of consultant transparency.
Clients are very loyal and love good consultants and vendors. When they do their job well,
they make the client look good.