Effective Project Management

Barbara Stone & Jodie MathiesSeptember 20, 2007

2

Agenda• Review Charter / POS assignment• What is an Elevator Speech?• Requirements Gathering - overview• Requirements Gathering – class

exercise• Prioritizing and iterating requirements• Alternative Analysis

3

Review Charter / POS Assignment

4

Back to Lifecycles for a moment

Phase 1

IDENTIFY AND ASSESS

OPPORTUNITY

Phase 5

OPERATE AND EVALUATE

Initiation

Analysis

Close-outExecutionPlanningA simple generic model:

Initiation Close-outExecutionDesignMore Common:

A real-world example:Phase 2

GENERATE & SELECT

ALTERNATIVE(S)

Phase 3

DEVELOP PREFERRED

ALTERNATIVE

Phase 4

DEVELOPMENT EXECUTION & IMPLEMENT

PlanningDefining Close-outMonitor / Control

LaunchingWysocki TPM:

5

You created the Charter / POS in the Initiation / Definition Phase

The Charter / POS document contained the level of detail needed to approve the project

With your Charter / POS, you should be able to give an elevator speech

6

Elevator speeches You are: Standing

InformalInformativeBrief

Include: Business issue you are tacklingHow company benefitsWhy you are excited to take partWhat the listener can do*

* if you need something

7

Elevator speech• http://www.creativekeys.net/Powerful

Presentations/article1024.html• Prepared presentation• Articulates in 3-4 minutes

• Who are you helping• With what problem• How company benefits

• Practicing is a good idea

8

Requirements Gathering is part of the Planning phase

You are now creating a Requirements specification document

This document elaborates the scope to the level of detail and specificity needed to:• Evaluate and decide between alternatives

for design of final project deliverable• Plan the execution phase

9

Requirements Gathering – a Business activity

How does what is being described meet the business need?

Include enough detail to know success.

Project Deliverable

Cust. Accept. Criteria

Customer need

Project Deliverable

Customer Requirements

10

Requirements Gathering – a Business activity

Try to separate Requirements from Design (specifically technical design)

Requirement: ‘I need to be able to view this chart within 2 seconds’

Design: ‘Pre-calculate this chart on a nightly basis’

11

Who is involved?

Customer(s) Provide RequirementsProject Manager / Business Analyst

Work with Customers to elaborate and document the requirements in the customer’s language

Sponsor Approves Requirements

Execution team

Accepts Requirements doc

Operations Accepts Requirements doc

12

Broadest view of sources• Requirements / deliverables from previous

projects• RFP, RFI, etc.• documents used to gain project approval• feasibility study, assessment documentation• customer documentation• customers themselves• relevant third party or external media• etc.

13

Forms of Requirements documentationBusiness Business process, metrics, etc.

Functional What the solution can actually do

Technical Performance, scalability, etc.

Implementation Who rolls out, user training, documentation

Project Test environments, administrative help, etc.

14

Requirements Quality GatewayHow do you know when a Requirement is

accurate enough? All requirements – separately, and as a

whole – pass through a review to determine if they meet pre-determined criteria:• Completeness• Clarity• Measurability• etc

15

Requirements Gathering approaches• Facilitated Group Session• Interviews• Observation• Requirements Reuse• Business process diagramming• Prototyping• User Stories• Use Cases

These are not mutually exclusive!

16

Traditional & Agile Methods• Brainstorming • Card Sorting • Competitor Product

Analysis • Concept Testing • Contextual Research • Customer Needs

Analysis • Customer

Segmentation • Customer Stakeholder

Analysis

• Environment Profiling • Ethnographic Research • Focus Groups • Success Criteria

Metrics • Surveys • Task Modeling • Use Case Development • User Profiling • User stories

17

HP – generic (traditional)• Current state

Existing processes

• Solution Detail • Functional• Data• Inputs/outputs• Screen requirements• Report requirements• User community• Security requirements• gaps

Future stateRequired processes

• Quality specifications• Audit• Process performance• Application

performance• User acceptance

18

SIPOC

19

User stories – card, conversation, confirmation (Agile)• A written description of the story used

for planning and as a reminder• Conversations about the story that

serve to flesh out the details of the story

• Tests that convey and document details and that can be used to determine when a story is complete

20

Example: job board• Card - A user can search for jobs• Conversation

• What values can users search on? State? City? Job title? Keywords?

• Does the user have to be a member of the site?

• Can search parameters be saved?• What information is displayed for

matching jobs?

21

Guidelines for good stories• Consider each user role & identify the

goals that user has for interaction• Slice the cake – but not on technical

lines• Write closed stories• Put constraints on cards• Size the story to the horizon• Keep the UI out as long as possible

22

Refining goal in stories – ‘find a job’ • Search for jobs she’s interested in

based on skill, salary, location, etc.• Automate the search process so she

doesn’t have to search manually each time

• Make her resume available so companies may search for her

• Easily apply for any job she likes

23

Acceptance test (confirmation)• Try it with an empty job description• Try it with a really long job description• Try it with a missing salary• Try it with a six-digit salary

24

Prioritize

25

Prioritization 2 – identify ‘minimum requirements’“One of our most common problems is taking on too much work – attempting to exceed requirements rather than addressing the minimum requirements to meet real needs.

Thus, meeting minimum requirements is in the customers’ best interests. It helps avoid the problems of late deliveries, budget overruns, low morale, and poor quality.”

Dr. Ralph R. Young, Recommended Requirements Gathering Practices

26

Traceability log• Requirements cross-referenced to

deliverables• Funnels to change management

matrix

27

Requirements Gathering exerciseGoal: Provide I-School students with

information they will need if they are at South Hall during the next ‘big one’

• Who provides requirements?• Categories of requirements • How will they be documented / shared?

28

Our list

29

Reality check 1: Is your Business Case still valid?

The 4 criteria for testing the business case:• Business Needs that justify the project• How project supports Organization strategy• How project will improve Organization• Benefits the Organization will realize through project

Has Requirements Gathering uncovered information that would necessitate changes?

If so, what do you do?

30

Reality check 2: Do your Constraints stand?Circle back to high-level estimates for:

• Scope • Budget • Deadline

And any written criteria for:• Resources• ‘Quality’

Has Requirements Gathering uncovered information that would necessitate changes?

If so, what do you do?

31

Think about your project for this class

• How linear / iterative is your Requirements Gathering process (or will it be)?

• How will Requirements be documented and who signs off on them?

32

Requirements gathering vs requirements negotiation• The problem with gathering requirements is right

there in the word gathering. What images does it conjure? • Projects rarely start out with clear objectives or

requirements; they begin in confusion and ambiguity.

• The other problem with gathering requirements is that it suggests subservience or disinterested passivity on the part of the IT group. It gives the impression that the job of a technical team is to take orders like a waiter who couldn't care less what you eat and then deliver the cooked meal.

33

Requirements negotiation• Think of a set of requirements as being like a

multilateral treaty among a group of nations. • Negotiate requirements among the many stakeholders:

• the business interests of executives who fund projects• the utility needs of the users who will work with the

systems every day• the technical needs of those who build, deploy and

support those systems• the list can go on and on.

• Successful projects begin not with a harvest, but with a difficult set of discussions on what should be done.

34

Anecdotes – what worked, what didn’t• Sticking to ‘business’ • Know your hierarchy – some requirements

(eg. Regulations) trump others• ?• ?

• Examples from the class?

35

Alternatives review & decisionThere may be multiple ways to fulfill the

Requirements1. Eliminate alternatives that don’t meet

external constraints• For example, does your company restrict

technical alternatives?

2. Evaluate remaining alternatives against selected criteria:• time/budget requirements• Team skillset and interests• Other criteria as team requires

36

SWOT – descriptive analysis• I have a CTGL template that includes SWOT

and decision matrix that I could show

37

Numeric scoring

38

Assignments for next class

• Read Effective Project Management, chapter 4

• Be prepared to give an elevator speech on your project