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. Trade-offs 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.

Physiological.

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 trade-offs. 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 co-workers 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 terrible thing. Good vendors will try to do 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 have 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. Vision 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.