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