1. Prof. Roy Levow Sessions 3

2.  Clear statement of what the project is about  Necessary for traditional project management  Deliverable is one-page Project Overview Statement (POS)  Clearly states what is to be done  Signed by developer and client  Agreement marks completion of scoping phase

3.  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

4.  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

6.  Next step is to negotiate Conditions of Closure  What must be done for project to be successfully completed  Negotiation may involve repeating these steps to refine POS

7.  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

8.  Problem / Opportunity  Project goal  Project Objectives  Success Criteria  Assumptions, Risks, Obstacles

11.  Situations that lead to P/O  Known problem / opportunity area  Customer Request  Corporate Initiative  Mandated Requirements

12.  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

13.  Specific  Measurable  Assignable  Realistic  Time-related

14.  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

15.  Normally fall into one of three categories  Increased revenue  Reduced costs  Improved service  Must be  Well-defined  Measurable  Subjective measures will not do

16.  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

17.  Risk Analysis  More detailed  Financial Analysis  Feasibility Studies  Cost-benefit Analysis  Break-even Analysis  Return on Investment

18.  POS serves three audiences:  Senior Management  Customer  Team  Gaining management approval is key event in project!

19.  Core project team  Project team  Project manager  Resource managers  Function/process managers  Customer  Sometimes also project manager  Senior management

20.  Possible outcomes  Approval  Recalibration for resubmission  Resubmission at a later time  Rejection

21.  Adding detail to the project  Very challenging task  Requires more formal approach  What are Requirements?

23.  Functional  Non-Functional  Global  Product / Project Constraints  Formal process required to gather requirements

26.  Facilitated Group Sessions  Interviews  Observation  Requirements Reuse  Business Process Diagramming  Prototyping  User Stories  Use Case

27. METHODSTRENGTHSRISKS 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

28. METHODSTRENGTHSRISKS 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

29. METHODSTRENGTHSRISKS 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

30. ATTRIBUTEQUESTION(S) TO ASK CompletenessAre the requirements essentially complete? Are some requirements missing? ClarityAre the requirements clear? Are they ambiguous or imprecise? ValidityDo the requirements reflect the customer’s intentions? MeasurabilityDoes the requirement have a fit criterion [measurement]? TestabilityCan the criterion be used to test whether the requirement provides the solution? MaintainabilityWill the implementation be difficult or easy to understand or maintain? ReliabilityCan reliability and availability requirements be met? Look and FeelHave all human factors been met [GUI, ergonomics, etc.]? FeasibilityCan the requirements be implemented? PrecedentHas a requirement similar to this been implemented before? ScaleAre the requirements large and/or complex? StabilityHow often and to what degree might the requirements change? PerformanceCan the performance be met on a consistent basis? SafetyCan the safety requirements be fully demonstrated? SpecificationsIs the documentation adequate to design, implement and test the system?

31.  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

32.  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.”

33.  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

34.  Bureaucracy Elimination  Duplication Elimination  Value-Added Assessment  Simplification  Process Cycle-Time Reduction  Error Proofing  Upgrading  Simple Language  Standardization  Supplier Partnership  Big Picture Improvement

35.  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

36.  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

41.  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

42.  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