1. Defining and Managing Project Scope

2. MOV Scope Phases Time Estimates Resources Tasks Schedule Budget Sequence Project Planning Framework

3. Scope Management Processes  Scope Planning  The development of a scope management plan that defines the project’s scope and how it will be verified and controlled throughout the project  Scope Definition  A detailed scope statement that defines what work will and will not be part of the project and will serve as a basis for all future project decisions  Create Work Breakdown Structure (More detail in Chapter 6)  The decomposition or dividing of the major project deliverables (i.e., scope) into smaller and more manageable components  Scope Verification  Confirmation and formal acceptance that the project’s scope is accurate, complete, and supports the project’s MOV (Measurable organizational values)  Scope Control  Ensuring that controls are in place to manage proposed scope changes once the project’s scope is set. Must be communicated to all project stakeholders.

4. Scope Planning Scope Definition Create WBS Scope Verification Scope Control Documents how the team will define and develop the project’s scope and WBS, as well as processes for verifying and controlling the project and product deliverables. Builds upon the preliminary project scope statement to define all the project and product deliverables, including the processes and criteria for acceptance. A project planning tool that that decomposes or subdivides and organizes the project’s scope into a deliverable- orientated hierarchy. A formalized acceptance from the appropriate stakeholders that the defined project scope is complete A defined process for managing changes to project and product scope and the impact of those changes to the project’s schedule and budget. Scope Management Plan Detailed Project Scope Work Breakdown Structure Scope Verification Checklist Scope Change Control Process Scope Management Plan

5. Scope Planning Initiating process to begin defining and documenting the project work (i.e., deliverables) needed to achieve the project’s MOV (Measurable organizational values) Extra work that will not help the project achieve its MOV (Measurable organizational values) will only needlessly increase the project’s schedule and budget  This process begins at a high level and will become more detailed as the project progresses and more information becomes available  Attempts to answer the question: What is and what is not to be delivered by this project?  Makes the project sponsor’s needs and expectations explicit  Tools:  Scope Boundary  Scope Statement

6. Scope Boundary

7. Scope Statement 1. Develop a proactive electronic commerce strategy that identifies the processes, products and services to be delivered through the World Wide Web. 2. Develop an application system that supports all of the processes, products, and services identified in the electronic commerce strategy. 3. The application system must integrate with the bank’s existing enterprise resource planning system.

8. Out of Scope 1. Technology and organizational assessment of the current environment 2. Customer resource management and data mining components

9. Project Scope Definition  The scope boundary and scope statement provide a useful first step  The project’s scope must now be defined in more detail in terms of specific deliverables that provide a basis for developing the project’s work breakdown structure (WBS)  Tools:  Deliverable Definition Table  Deliverable Structure Chart  Context Level Data Flow Diagram  Use Case Diagram

10. Scope  Project-Oriented Deliverables  Support the project management and IT development processes defined in the Information Technology Project Methodology (ITPM).  Tools  Deliverable Definition Table (DDT)  Deliverable Structure Chart (DSC)  Product-Oriented Deliverables  Specific features and functionality of the application system  First cut of requirements definition  Tools  Context Dataflow Diagram (DFD)  Use Case Diagram (UCD)

11. DeliverableStructureStandardsApproval Needed By Resources Required Business CaseDocumentAs defined in the Project Methodology Project Sponsor Business Case Team, & office automation (OA) tools Project Charter & Project Plan DocumentAs defined in the Project Methodology Project Sponsor Project manager, project sponsor & OA tools Current System Study DocumentAs defined in the Project Methodology Project Manager & Project Sponsor Systems analysts users, case tool and OA tools Deliverable Definition Table (DDT)

12. Deliverable Structure Chart

13. Context Data Flow Diagram

14. Use Case Diagram

15. Project Scope Verification MOV Has the project’s MOV been clearly defined and agreed upon? Deliverables Are the deliverables tangible and verifiable? Do they support the project’s MOV? Quality Standards Milestones Significant events that mark the acceptance of a deliverable Review and Acceptance Formal Signoff

16. Scope Change Control  Concerned with managing changes to the project’s scope and to ensure that these changes are beneficial when they occur  Mitigates:  Scope Grope  Scope Creep  Scope Leap  Tools/Procedures:  Scope Change Request Form  Scope Change Request Log ScopeSchedule Budget

17. Scope Change Request Form Requestor Name: _______________Request Date: __________ Request Title: __________________Request Number: _______ Request Description: Justification: Possible Alternatives: ImpactsAlternative 1Alternative 2Alternative 3 Scope Schedule Resources Required Cost Recommendation: Authorized By: Date:

18. Scope Change Request Log

19. Benefits of Scope Control  Keeps the project manager in control of the project.  Authorized changes to the project’s scope are reflected in changes to the project’s schedule and budget.  Allows the project team to stay focused and on track  They do not have to perform unnecessary work.

20. Use Case Modeling

21. UML Background  Unified Modeling Language  Collection of 9 Object-Oriented Modeling Tools (one of which is use case diagrams)  Attempt to unify modeling of systems processes and data

22. A definition of Use Case (Ivar Jacobson)  A behaviorally related sequence of interactions performed by an actor in a dialogue with the system to provide some measurable value to the actor.

23. Keywords in the definition  “Behaviorally related” – self contained unit that is an end in itself, with no intervening time delays.  “Actor” must initiate the Use Case, and see it through completion.  “Measurable value” – the Use Case MUST achieve some business goal.  Use Cases are goal oriented (the what, not the how), and cannot be half-done.

24. Use Case Modeling  Use case modeling is the process of modeling a system’s functions in terms of business events, who initiated the events, and how the system responds to the events.  Useful for eliciting requirements and understanding how users interact with the system.

25. Typical questions to find actors  Who/what will be interested in the system?  Who/what will want to change data in the system?  Who/what will want to interface with the system?  Who/what will want information from the system?  Actors can include external databases, time, employees, or any external entity that interacts with your system

26. Rules for Use Cases  Use cases must be simple and easy to read  If a use case threatens to become too complicated, consider breaking it up into different use cases.

27. Use Case Conventions The relationship between an actor and a use case is said to be a “communication relationship”. Other possibilities: verifies, designs, tests, implements

28. Relationships between use cases  > Adds steps to an existing use case. Is optional, unless directly initiated by an actor  > The first use case needs information from another use case to complete its function. Is always completed

29. Use Case Modeling Benefits  As a basis to help identify objects and their high-level relationships and responsibilities.  A view of system behavior from an external person’s (user’s) viewpoint.  An effective tool for validating requirements.  An effective communication tool.  As a basis for a user’s manual.

30. Scope Creep  All requirements originate with the events to be satisfied, and the use cases that satisfy them. If it isn’t defined as an event and satisfied by a use case, then it is a change request that requires some form of change control action.