WestCoast2008:The Art and Science of Defining Scope

Description

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?

Session Notes

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.

Physcological.

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

an enabler.

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.