Difference between revisions of "NewYork2008:The Art and Science of Defining Scope"

From Managing Nonprofit Technology Projects Wiki
Jump to navigation Jump to search
m (1 revision imported)
 
 
(6 intermediate revisions by the same user not shown)
Line 11: Line 11:
  
 
=== Session Notes ===
 
=== Session Notes ===
 
Project Scope
 
  
  
 +
'''Project Scope'''
  
 
The work that must be performed to deliver a product with specified features and functions
 
The work that must be performed to deliver a product with specified features and functions
Line 22: Line 21:
 
Objectives:  both internal, and external - what we're hoping to do, what users want
 
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 hierachical fashion
+
Work Breakdown Structure (WPS):  a way to break down the work that's to be done in a an hierarchical fashion
  
  
  
Project
+
'''Project'''
  
-Legacy Integration
+
*Legacy Integration
  
 
   - Filemaker Database
 
   - Filemaker Database
Line 40: Line 39:
  
  
- Graphic Design
+
*Graphic Design
 
 
 
 
  
- Site Architecture
+
*Site Architecture
  
  
  
Can use it for tradeoff decisions
+
Can use it for trade-off decisions
  
  
Line 60: Line 57:
  
  
Visual stuff is an important compontent 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
+
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
  
  
Line 68: Line 65:
  
  
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"
+
Developers like this because it forces the staff to give them high level needs rather than specific "How's", but often the staff want to give the "How's"
  
  
  
How do you get the list of requirements?
+
'''How do you get the list of requirements?'''
  
- Thinking through the user needs can help - workshops in thinking through.
+
*Thinking through the user needs can help - workshops in thinking through.
  
- Feature workshops - workshops are really key
+
*Feature workshops - workshops are really key
  
- Drive to the high level need, not feature desires
+
*Drive to the high level need, not feature desires
  
- Important to have think through priority vs complexity
+
*Important to have think through priority vs. complexity
  
- Wireframing
+
*Wireframing
  
- Arthimetic is really useful - it really sways people  
+
*Arithmetic is really useful - it really sways people  
  
- Can vote with a finite budget - sticky dots voting for  
+
*Can vote with a finite budget - sticky dots voting for  
  
- Ask people what the minimum features things are that critical for the vision
+
*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?
+
'''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.   
+
*It's tricky.  Break out a core team.   
  
- One-on-one interviews can be really useful - people will say more
+
*One-on-one interviews can be really useful - people will say more
  
- Give them something to react to
+
*Give them something to react to
  
- Try to make sure things move forward and it's not a sinkhole
+
*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 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)
+
*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 faciliator.
+
*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
+
*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 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 signoff from fatigue.  What can you do?
+
'''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?
+
*Refocus on the priorities?
  
- Bring up the timeline and budget
+
*Bring up the timeline and budget
  
- MoSCoW can be useful - Must Have, Should Have, Could Have, Not Now
+
*MoSCoW can be useful - Must Have, Should Have, Could Have, Not Now

Latest revision as of 18:21, 15 January 2016

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 "How's", but often the staff want to give the "How's"


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