Effective Project Management
description
Transcript of Effective Project Management
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