630 likes | 901 Views
Scope . Scope is the sum of the products and services to be provided as a projectA concise and accurate description of the end products or deliverables of the projectThat meet specified requirements As agreed between the project stakeholders. Scope Management . Project Scope Management includes t
E N D
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