Upload
kelly-payne
View
212
Download
0
Tags:
Embed Size (px)
Citation preview
Prof. Roy Levow
Sessions 3
Clear statement of what the project is about Necessary for traditional project management
Deliverable is one-pageProject Overview Statement (POS)
Clearly states what is to be done Signed by developer and client Agreement marks completion of scoping
phase
Wants versus Needs What is desired versus what is required
Formalized in Conditions of Satisfaction At start project definition may be
Well defined Vague
Must be well defined at end of phase
Requester -- Provider Request Clarification
Provider restates request Discuss until both agree on understanding
Response Provider states what will be done for request
Agreement Requester restates response Discuss until both agree on understanding
Next step is to negotiateConditions of Closure
What must be done for project to be successfully completed
Negotiation may involve repeating these steps to refine POS
POS is used To secure senior management approval Assure required resources are available
POS also Provides continuity for inherited projects Serves as a reference for project team
Problem / Opportunity Project goal Project Objectives Success Criteria Assumptions, Risks, Obstacles
Situations that lead to P/O
Known problem / opportunity area Customer Request Corporate Initiative Mandated Requirements
There must be one, single goal Clearly stated
No possibility for misunderstanding Short and to-the-point Leave specific dates to planning phase, if
possible
Specific Measurable Assignable Realistic Time-related
More detailed version of goal statement Clarify exact boundaries
Is it clear what is not part of project? May change during project planning Normally contains
An outcome A time frame A measure An action
Normally fall into one of three categories Increased revenue Reduced costs Improved service
Must be Well-defined Measurable
Subjective measures will not do
Focus on most significant issues Meaningful to senior management
General areas of concern Technology Environment (of project) Interpersonal issues Cultural issues Cause and effect relationships
Risk Analysis More detailed
Financial Analysis Feasibility Studies Cost-benefit Analysis Break-even Analysis Return on Investment
POS serves three audiences: Senior Management Customer Team
Gaining management approval is key event in project!
Core project team Project team Project manager Resource managers Function/process managers Customer
Sometimes also project manager Senior management
Possible outcomes Approval Recalibration for resubmission Resubmission at a later time Rejection
Adding detail to the project Very challenging task Requires more formal approach
What are Requirements?
Functional Non-Functional Global Product / Project Constraints
Formal process required to gather requirements
Facilitated Group Sessions Interviews Observation Requirements Reuse Business Process Diagramming Prototyping User Stories Use Case
METHOD STRENGTHS RISKS
Observation
Specific/complete descriptions of actions provided
Effective when routine activities are difficult to describe
Documenting and videotaping may be time consuming, expensive and have legal overtones
Confusing/conflicting information must be clarified
Misinterpretation of what is observed
Requirements Reuse
Requirements quickly generated/refined
Redundant efforts reduced
Customer satisfaction enhanced by previous proof
Quality increase
Reinventing the wheel minimized
Significant investment to develop archives, maintenance, and library functions
May violate intellectual rights of previous owner
Similarity may be misunderstood
METHOD STRENGTHS RISKS
Observation
Specific/complete descriptions of actions provided
Effective when routine activities are difficult to describe
Documenting and videotaping may be time consuming, expensive and have legal overtones
Confusing/conflicting information must be clarified
Misinterpretation of what is observed
Requirements Reuse
Requirements quickly generated/refined
Redundant efforts reduced
Customer satisfaction enhanced by previous proof
Quality increase
Reinventing the wheel minimized
Significant investment to develop archives, maintenance, and library functions
May violate intellectual rights of previous owner
Similarity may be misunderstood
METHOD STRENGTHS RISKS
Business Process Analysis
Excellent for cross-functional processes
Visual communication
Verification of “what is/what is not”
Implementation of improvement is dependent on an organization open to changes
Good facilitation, data gathering, and interpretation required
Time consuming
Use Case Scenarios
State of system described before entering the system
Completed scenarios used to describe state of system
Normal flow of event/exceptions revealed
Improved customer satisfaction and design
Newness has resulted in some inconsistencies
Information may still be missing from scenario description
Long interaction required
Training expensive
ATTRIBUTE QUESTION(S) TO ASK
Completeness Are the requirements essentially complete? Are some requirements missing?
Clarity Are the requirements clear? Are they ambiguous or imprecise?
Validity Do the requirements reflect the customer’s intentions?
Measurability Does the requirement have a fit criterion [measurement]?
Testability Can the criterion be used to test whether the requirement provides the solution?
Maintainability Will the implementation be difficult or easy to understand or maintain?
Reliability Can reliability and availability requirements be met?
Look and Feel Have all human factors been met [GUI, ergonomics, etc.]?
Feasibility Can the requirements be implemented?
Precedent Has a requirement similar to this been implemented before?
Scale Are the requirements large and/or complex?
Stability How often and to what degree might the requirements change?
Performance Can the performance be met on a consistent basis?
Safety Can the safety requirements be fully demonstrated?
Specifications Is the documentation adequate to design, implement and test the system?
Purpose Draft POS Draft resource requirements
Attendees Customer group Core Members of Project Team Facilitator Group
Agenda Deliverables
Conditions of Satisfaction Requirements of Documentation Project Overview Statement
Business Process: “A collection of activities that takes one or more kinds of input from one or more different sources and produces values for the customer.”
Flow – The method for transforming input to output
Effectiveness – How well customer expectations are met
Efficiency – How well resources are used to produce an output
Cycle time – The time taken for transformation from input to final output
Cost – The expenses of the entire process Non-value-added time – The time between
process steps when no work is done on the product/service
Bureaucracy Elimination Duplication Elimination Value-Added Assessment Simplification Process Cycle-Time Reduction Error Proofing Upgrading Simple Language Standardization Supplier Partnership Big Picture Improvement
Eliminate or at least reduce the effect resulting from one or more process activities that are preventing the process from performing up to its potential
Excessive wait time between process steps
Backlog at a process step Idle workstations in the business process Frequent rework Excessive non-value-added work Errors and mistakes Frequent exception situations
Seven step process Document the “As Is” Business Process Envisioning the “To Be” State Defining the “As Is” to “To Be” Gap
Eliminate some tasks Speed up some tasks Introduce parallelism Increase quality
Prototype - A physical mock-up of the proposed solution
Use Cases – Describe the proposed business process from the customer’s perspective Use Case Diagram Use Case Flow of Events