Information Systems Project Management

1. Information Systems Project Management Lecture 5 Scope Management

2. Scope Scope is the sum of the products and services to be provided as a project A concise and accurate description of the end products or deliverables of the project That meet specified requirements As agreed between the project stakeholders

3. Scope Management Project Scope Management includes the processes required to: Ensure that the project includes all of the work required And only the work required to complete the project successfully

4. Scope management consists of Initiation Planning Definition Verification Change Control

5. Scope Initiation The phase where the organisation commits to beginning a project or commits to moving to the next phase of the project Normally occurs as management�s response to the recognition of a problem, business need or opportunity

6. Scope initiation - inputs Product description Strategic plan Project selection method Historical Information

7. Scope Initiation � Tools and Techniques Project Selection Methods e.g. quantitative cost measurement, scoring models Expert judgement e.g. expert panel, objective brain storming

8. Scope Initiation - Outputs Project charter Project manager identified / assigned Constraints Assumptions

9. Project Charter After deciding what project to work on, it is important to formalize projects A project charter is a document that formally recognizes the existence of a project and provides direction on the project�s objectives and management Key project stakeholders should sign a project charter to acknowledge agreement on the need and intent of the project It obtains management approval for the work to be done and obtains a commitment for the resources to do the work

10. Project charter contents Objectives: What the desired outcomes are Function: Major features and/or processes Performance: Generalised specifications Constraints: limits of the environment Scope: boundaries of the project Cost/benefits: Rough order of magnitude estimates

11. Sample Project Charter

12. Sample Project Charter

13. Scope planning Inputs include: the product description, project charter, constraints and assumptions Methods include: product analysis, benefit/cost analysis; identifying alternatives and expert judgment Outputs include: scope statement, supporting detail and scope management plan.

14. Scope planning Involves developing a written scope statement that includes the project justification, the major deliverables and the project objectives

15. Scope Statement Forms the basis for an agreement between the project team and the project customer by identifying project objectives and the major project deliverables Normally written by project manager in conjunction with the project team

16. Scope statement Justification � business reason Product description � a summary of the product description Deliverables- a summary of all deliverables whose full and satisfactory delivery means the project is complete Objectives � time, cost , quality

17. Scope management plan A subsidiary element of the overall management plan Describes how project scope will be managed Describes how scope changes will be integrated into the project Should also include a clear description of how scope changes will be identified and classified

18. Scope Definition Involves decomposing the major deliverables into smaller, more manageable components to provide better control WBS

19. What is WBS WBS is the name given to a technique in project management in which the project is broken down into manageable chunks A WBS provides a central organising concept for the project. That is a common framework for Planning, Scheduling, cost estimating, budgeting, configuring, monitoring and controlling the entire project

20. Partitioning the Project You need to decompose the project into manageable chunks ALL projects need this step Divide & Conquer Two main causes of project failure Forgetting something critical Ballpark estimates become targets How does partitioning help this?

21. Project Elements A project has : Functions Activities Tasks

22. Function Management activity Often Spanning the life of the project Examples: Change Management, Risk Management and project Management

23. Activity An element of work with expected duration, cost and resources Can be subdivided into other activities or tasks

24. Task Lowest level of activity on the project Typically not shown on preliminary WBS ( too granular) Smallest unit of work in the real schedule

25. Typical WBS

26. Work Breakdown Structure: WBS Hierarchical list of project�s work activities 2 Formats Outline (indented format) Graphical Tree (Organizational Chart) Uses a decimal numbering system Ex: 3.1.5 0 is typically top level Includes Development, Mgmt., and project support tasks Shows �is contained in� relationships Does not show dependencies or durations

27. WBS Contract WBS (CWBS) First 2 or 3 levels High-level tracking Project WBS (PWBS) Defined by PM and team members Tasks tied to deliverables Lowest level tracking

28. A Full WBS Structure Up to six levels (3-6 usually) such as Upper 3 can be used by customer for reporting (if part of RFP/RFQ) Different level can be applied to different uses Ex: Level 1: authorizations; 2: budgets; 3: schedules

29. WBS Chart Example

30. WBS Outline Example

31. WBS Types Process WBS a.k.a Activity-oriented Ex: Requirements, Analysis, Design, Testing Typically used by PM Product WBS a.k.a. Entity-oriented Ex: Financial engine, Interface system, DB Typically used by engineering manager Hybrid WBS: both above This is not unusual Ex: Lifecycle phases at high level with component or feature-specifics within phases Rationale: processes produce products

32. Product WBS

33. Process WBS

34. WBS Types Less frequently used alternatives Organizational WBS Research, Product Design, Engineering, Operations Can be useful for highly cross-functional projects Geographical WBS Can be useful with distributed teams NYC team, San Jose team, Off-shore team

35. Ways to develop a WBS By geographically separated areas whether for activity or product By major chronological time periods By structure, process, system or device components By intermediate deliverables required in the production of the end deliverables By separated areas of responsibility i.e. functional, discipline trade or service

36. Remember Different people view the technique differently The techniques can be applied in different ways The results must reflect the project strategy No single way is best for all projects

37. Work Packages Generic term for discrete tasks with definable end results Typically the �leaves� on the tree The �one-to-two� rule Often : 1 or 2 persons for 1 or 2 weeks Basis for monitoring and reporting progress Can be tied to budget items (charge numbers) Resources (personnel) assigned Ideally shorter rather than longer Longer makes in-progress estimates needed These are more subjective than �done� 2-3 weeks maximum for software projects 1 day minimum (occasionally a half day) Not so small as to micro-manage

38. Work Package Is the lowest level in the WBS Has a deliverable result Should have one responsible part called the WP owner May be considered by the WP assignee as a project in itself May include several milestones Should fit organisational procedures and culture The optimal size of a WP may be expressed in terms of labour hours, calendar time, cost, report period risks

39. Contents of a work packages may include Description of the work product expected -- product to be produced The staffing requirements � who or how many people will do this activity Name of responsible individual(s)- who is reponsible for seeing what is completed The scheduled start and send dates � when the activity is expected to start and end The budget assigned � the effort estimate for the activity The acceptance criteria for the work � defect level or other quality measure

40. WBS Dictionary The labels and shape of our WBS is fine. But how are we to know what work is in each work package On larger projects it is usual to provide what is known as a WBS dictionary for each package This provides A statement of work describing the work content of each package And often a description of what is not included

41. WBS and WPEvolution As a project progresses through its lifecycle and planning becomes more detailed it may be necessary to further subdivide existing work packages This will push them to the next lower level

42. WBS List of Activities, not Things List of items can come from many sources SOW, Proposal, brainstorming, stakeholders, team Describe activities using �bullet language� Meaningful but terse labels All WBS paths do not have to go to the same level Do not plan more detail than you can manage

43. WBS & Methodology PM must map activities to chosen lifecycle Each lifecycle has different sets of activities Integral process activities occur for all Planning, configuration, testing Operations and maintenance phases are not normally in plan (considered post-project) Some models are �straightened� for WBS Spiral and other iterative models Linear sequence several times Deliverables of tasks vary by methodology

44. WBS Techniques Top-Down Bottom-Up Analogy Rolling Wave 1st pass: go 1-3 levels deep Gather more requirements or data Add more detail later Post-its on a wall

45. WBS Techniques Top-down Start at highest level Systematically develop increasing level of detail Best if The problem is well understood Technology and methodology are not new This is similar to an earlier project or problem But is also applied in majority of situations

46. WBS Techniques Bottom-up Start at lowest level tasks Aggregate into summaries and higher levels Cons Time consuming Needs more requirements complete Pros Detailed

47. WBS Techniques Analogy Base WBS upon that of a �similar� project Use a template Analogy also can be estimation basis Pros Based on past actual experience Cons Needs comparable project

48. WBS Techniques Brainstorming Generate all activities you can think of that need to be done Group them into categories Both Top-down and Brainstorming can be used on the same WBS Remember to get the people who will be doing the work involved (buy-in matters!)

49. WBS � Basis of Many Things Network scheduling Costing Risk analysis Organizational structure Control Measurement

50. WBS � foundation of the project Involve all players when using WBS May be used as a project organisational chart Establishes cost/schedule estimates Feeds into network diagram Risk appraisal tool Identifies contract strategy Coding structure for reporting

51. Defining Project Scope Other Work Preparation of training material Delivery of training Business Process documentation Business Process Re-engineering Rework Project management and administration Vendor management Security

52. Defining Project Scope Other Work Disaster recovery plans Business continuity plans Provision and setup of equipment Software Communication Support after go-live Recruitment of permanent or contract staff Staff performance management and evaluation Hardware upgrade or purchase Hardware installation Data preparation for transfer System documentation

53. Scope definition summary Represents content not execution sequence Scope Baseline Use of WBS ensures completeness Verifies Scope Validates change to scope Interfaces with contracts Approve prior to proceeding further Basis for further decisions

54. Scope Change A scope change may be defined as any change in the project deliverables from what was originally intended A scope change almost always requires an adjustment to the project cost and schedule

55. Scope Change Very few projects are executed as per the original design and execution plan. Need to look at: Types of change Sources of change Impact of changes Change authorisation

56. Scope Control Scope control involves controlling changes to the project scope Goals of scope control are to: Influence the factors that cause scope changes Assure changes are processed according to procedures developed as part of integrated change control Manage changes when they occur Variance is the difference between planned and actual performance

57. Scope Verification This is the process of obtaining formal acceptance of the project from the stakeholders (sponsor, client, customer etc. ) Input: work results, product documentation, WBS, project plan, scope statement Tools and techniques: Inspection Outputs: Formal Acceptance

58. Scope Verification � Typical Test program List components to be tested Define the test measures Test location Who will test Test procedures Test support equipment required

59. Scope management and project failure Many IT Project suffer from scope creep and poor scope verification FoxMeyer Drug filed for bankruptcy after scope creep on a SCM system McDonalds binned $1 billion project to link its operations in a real time network

60. Best Practices for Avoiding Scope Problems 1. Keep the scope realistic: Don�t make projects so large that they can�t be completed; break large projects down into a series of smaller ones 2. Involve users in project scope management: Assign key users to the project team and give them ownership of requirements definition and scope verification 3. Use off-the-shelf hardware and software whenever possible: Many IT people enjoy using the latest and greatest technology, but business needs, not technology trends, must take priority 4. Follow good project management processes: As described in this chapter and others, there are well-defined processes for managing project scope and others aspects of projects 60

61. Suggestions for Improving User Input Develop a good project selection process and insist that sponsors are from the user organization Have users on the project team in important roles Have regular meetings with defined agendas, and have users sign off on key deliverables presented at meetings Deliver something to users and sponsors on a regular basis Don�t promise to deliver when you know you can�t Co-locate users with developers 61

62. Suggestions for Reducing Incomplete and Changing Requirements Develop and follow a requirements management process Use techniques such as prototyping, use case modeling, and JAD to get more user involvement Put requirements in writing and keep them current Create a requirements management database for documenting and controlling requirements 62

63. Suggestions for Reducing Incomplete and Changing Requirements (continued) Provide adequate testing and conduct testing throughout the project life cycle Review changes from a systems perspective Emphasize completion dates to help focus on what�s most important Allocate resources specifically for handling change requests/enhancements like NWA did with ResNet 63