NewYork2008: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. There are many approaches to scope definition, but before we dive in, what do we need to do first? And once we've done those things, how should we proceed?

In this session we will:

• Talk briefly about scope generally – define and discuss it, discuss related terms
• Look at and discuss the usefulness of an age-old scope definition tool – the WBS
• Look at an agilist technique for defining requirements or "stories"
• Use the rest of the time available to share and discuss scope definition best practices

Session Notes

Project Scope

The work that must be performed to deliver a product with specified features and functions

All projects have objective, deliverables, requirements, constraints

Objectives: both internal, and external - what we're hoping to do, what users want

Work Breakdown Structure (WPS): a way to break down the work that's to be done in a an hierarchical fashion

Project

-Legacy Integration

  - Filemaker Database

     - X

     - X

  - Static HTML

- Graphic Design

- Site Architecture

Can use it for trade-off decisions

Agile project management is designed to respond to changing requirements, quickly iterative. For instance, for a complex interface, you would quickly get something up so people could react to it. For instance, put up a working prototype.

Some Agile PMs don't like the WPS structure- they find it too static. But it can be a living document, and that helps.

Visual stuff is an important component for agile projects. But for many projects, both visual and text based information is important - many stakeholders can react more effectively to visuals, but programmers often prefer things to be carefully defined in text

In the Agile methodology, you create your requirements in the form of "stories", using the syntax "As a <user name> I would like <what I would like> so that <why I would like it>. Rob used these on a project and generated about 150 different stories, and prioritized them all. "As a content administrator, I would like to be able to create content without knowledge of HTML, so that I can save time by not having to look up the syntax"

Developers like this because it forces the staff to give them high level needs rather than specific "hows", but often the staff want to give the "hows"

How do you get the list of requirements?

- Thinking through the user needs can help - workshops in thinking through.

- Feature workshops - workshops are really key

- Drive to the high level need, not feature desires

- Important to have think through priority vs. complexity

- Wireframing

- Arithmetic is really useful - it really sways people

- Can vote with a finite budget - sticky dots voting for

- Ask people what the minimum features things are that critical for the vision

How do you effectively get input but still manage the time involvement? For yourself and for the stakeholders?

- It's tricky. Break out a core team.

- One-on-one interviews can be really useful - people will say more

- Give them something to react to

- Try to make sure things move forward and it's not a sinkhole

- Make sure you're really transparent in the process, tell what feedback you want

- Make sure people feel like you're listening (so try to make sure the things they say are things you can use)

- Be really transparent about what hat you're wearing - "now this is me as a user", when you're the facilitator.

- It's important to prioritize the features

- Sometimes you need to put your foot down and say that more staff time is needed in order to do an adequate job

Sometimes you can talk about things so much that you lose sight about why it's important. And get sign off from fatigue. What can you do?

- Refocus on the priorities?

- Bring up the timeline and budget

- MoSCoW can be useful - Must Have, Should Have, Could Have, Not Now