1. Project Management
Scope management Requirements management
P. Fitsilis (fitsilis@teilar.gr)

2. Definition
•Scope is the sum of the
–Products
–Services and
–Results
•to be provided as a project

4. Requirements management

5. The requirements problem
•The goal of project development is to develop quality products —on time and on budget—that meets customers real needs.
•Project success depends on good requirements management.
•Requirements errors are the most common type of systems development error and the most costly to fix.
•A few key skills can significantly reduce requirements errors and thus improve quality.

6. What is requirement?
•A requirement is a capability that the system must deliver.
–A capability needed by the user to solve a problem to achieve an objective
–A capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation
–A documented representation of a condition or capability as in (1) or (2).

7. What is requirements management?
•Requirements management is a process of systematically eliciting, organizing, and documenting requirements for a complex system.
•Our problem is to understand users‘ problems in their culture and their language and to build products that meet their needs.

8. Why we need to manage requirements?
•How many requirements has a small product?

9. Why we need to manage requirements?

10. Common questions
•Boeing 777 has to satisfy 300,000 requirements
•The questions are:
–Which project team members are responsible for the wind speed requirement (#278), and which ones are allowed to modify it or delete it?
–If requirement #278 is modified, what other requirements will be affected?
–How can we be sure that someone has written the code in a software system to fulfill requirement #278, and which test cases in the overall test suite are intended to verify that the requirements have indeed been fulfilled?

11. The Life of a Requirement
Concept Phase Business Requirements Need, Problem or Opportunity Justification Project Charter Funding: Business Requirements
Solution Requirements Describes the characteristics that meet the business and stakeholder requirements: - Functional - Non-Functional - Implementation
Stakeholder Requirements: Needs of a stakeholder and their interaction with the system
How
WHAT
WHY
Requirements Phase

12. Problems of requirements management
12
•Stakeholders don’t know what they really want
•Stakeholders express requirements in their own terms
•Different stakeholders may have conflicting requirements
•Organizational and political factors may influence the system requirements
•The requirements change during the analysis process. New stakeholders may emerge and the business environment change

13. The logical gap
customer
End user
contactor

14. Requirements processes
•Enterprise Analysis
•Requirements Planning and Management
•Requirements Elicitation
•Requirements Analysis and Documentation
•Requirements Communication
•Solution Assessment and Validation
Guide to IIB Body of Knowledge, International Institute of Business Analysis http://www.theiiba.org/

15. Requirements processes

16. Enterprise Analysis
•Creating and maintaining the business architecture
•Conducting feasibility studies
•Identifying new business opportunities
•Scoping and defining new business opportunities
•Preparing the business case for new business opportunities
•Conducting the initial risk assessment for new business opportunities.

17. 17
Enterprise analysis Project authorisation
•Projects are typically authorized as a result of one or more of the following:
–A market demand
–A business need
–A customer request
–A technological advance
–A legal requirement
–A social need

18. A market demand (e.g., a car company authorizes a project to build more fuel efficient cars in response to gasoline shortages).
A business need (e.g., a training company authorizes a project to create a new course to increase its revenues).
A customer request (e.g., an electric utility authorizes a project to build a new substation to serve a new industrial park).
A technological advance (e.g., an electronics firm authorizes a new project to develop a video game player after advances in computer memory).
A legal requirement (e.g., a paint manufacturer authorizes a project to establish guidelines for the handling of toxic materials).
A social need (e.g., a nongovernmental organization in a developing country authorizes a project to provide potable water systems, latrines, and sanitation education to low-income communities suffering from high rates of cholera).
18
Project authorisation examples

20. 05
20
CONCEPTION
FEASIBILITY
IMPLEMENTATION
OPERATION
TERMINATION
Define the Project
Design the Project Process
Deliver the Project

21. 05 21
Evaluation of
the Brief
Development
of a range of
options
Definition of
the product or
service
Broad brush
analysis filters
numbers of
options
Project Teams Actions
Simplistic Feasibility studies to
determine range of possibilities
Organisations
mission
Organisations
strategy
Organisations
goals &
objectives
Organisations
need to grow
or survive
Concept of a
new product
or service
Product or
new service
brief
Organisations Actions
Revision

22. 05 22
Evaluation of
the Brief
Development
of a range of
options
Definition of
the product or
service
Broad brush
analysis filters
numbers of
options
Project Teams Actions
Simplistic Feasibility studies
to determine range of
possibilities
Organisations
mission
Organisations
strategy
Organisations
goals &
objectives
Organisations
need to grow
or survive
Concept of a
new product
or service
Product or
new service
brief
Organisations Actions
Revision
Project Authorisation
gateway

23. 05
23
Reminder
•The PM role is to convert or break down the sponsors project brief into a form that everyone understands. OR - From concept into realism.
•Then to allocate resources (teams) to determine if it is possible produce what is needed, if it is feasible and if reality can be achieved within the projects budget costs at the desired level of quality.

24. Generating Scenarios for Feasibility Evaluation
24
A project scenario is a brief description of a proposal, process or a set of procedures that should meet the identified objectives shown in the brief.
For every objective there are a number of possible strategies: e.g. the objective of eating can be met by the preparation of food, BUT, there are a number ways to do this, each is an option.
Developing scenarios can be a brainstorming activity, then each idea generated undergoes critical examination & modification. Then, selected or reject.

25. 25
Feasibility Analysis
Options can be evaluated and scored by using STEEP factors.
S =
T =
E =
E =
P =
Social
Technological
Ecological
Economic
Political

26. 26
Feasibility Analysis
1.Technical Feasibility;
2.Financial Feasibility;
3.Risk & Uncertainty Feasibility.
4.Environmental feasibility
The most frequently used evaluates these three key areas, BUT others might well be used!

27. 27
Process
Project Brief
Generate Scenarios
Undertake Feasibility Studies for Each Scenario
Technical Feasibility Study
Financial Feasibility Study
Risk & Uncertainty Feasibility Study
Collate Results and Select Best Scenario by Weighted Analysis
Comprising of:

28. 28
Project Brief
Generate Scenarios
Feasibility Study
Technical Feasibility
Financial Feasibility
Risk & Uncertainty Feasibility
Feasibility Study
Feasibility Study
Technical Feasibility
Technical Feasibility
Financial Feasibility
Financial Feasibility
Risk & Uncertainty Feasibility
Risk & Uncertainty Feasibility
Select Best Option by Weighted Analysis

29. 29
Technical Feasibility
•A Technical feasibility study can only be based upon current information concerning the product, material, or services life. Information availability stages are:
–Fully mature – considerable data is available for evaluation of new proposal.
–Semi-mature – limited data available to be used in feasibility study.
–New Technology – at prototype stage, limited information available.

30. 30
2. Financial Feasibility
•Questions asked:
–Will the investment of resources in a particular project be worthwhile, then:
–How worth-while?
•Where there is a range of several alternative opportunities for investing resources:
– which one gives the best rewards?

31. 31
Two Sets Finance!
•PM team have to consider:
•Development - The cost of the project to produce the product, some options will consume more resources than others, this reflects onto recovery time and product cost.
•Production -The cost to produce the project after hand-over to the sponsor (post-project).

32. 32
3. Risk & Uncertainty Feasibility.
Risk is an inherent and characteristic of all projects, some even claim that Project Management is really Risk Management.
Essentially there are two aspects of project risk control:
Risk
Risk Management
Risk Identification & Analysis

34. Requirements Planning and Management
•This is necessary to ensure:
–the set of requirements activities undertaken are the most appropriate, given the unique circumstances of the project,
–the requirements work effort is coordinated with the other work being done for the project,
–the whole requirements team on a project has a common understanding of what activities they are undertaking,
–business analysts are able to monitor and react to requirements challenges and slippage,
–the tools, resources and requirements contributors are available as needed for the requirements activities,
–and, changes are captured correctly and consistently.

35. Requirements Gathering

36. Requirements Analysis and Documentation
•Analyze functional requirements
•Analyze non functional requirements
•Process/flow models
–Workflow models
–Flow charts
•Usage models
–Storyboards,
–Use cases
•Requirements attributes
•Requirements traceability

37. Requirements quality

39. •Lightweight
•Availability <99%
•High quality
•Success ration 0.98
•Range >500 mL
•100 reliable
Which of the following are valid requirements ?

40. Enduring and volatile requirements
40
•Enduring requirements. Stable requirements derived from the core activity of the customer organization. E.g. a hospital will always have doctors, nurses, etc.
•Volatile requirements. Requirements which change during project or when the product is in use. In a hospital, requirements derived from health-care policy

41. Classification of Volatile requirements
•Mutable requirements, requirements that change due to the changing of system’s environment
•Emergent requirements, requirements that emerge as understanding of the system develops during the system development.

42. Statement of Needs
Functional Requirements and Statement of Services
Detailed requirements for the system’s functionality and constraints as required as a basis for individual component development/acquisition
Requirements Explosion
Declaration of required miracle
Operational View formulation
Detailed requirements
10 Requirements
100 Requirements
1000 Requirements

43. Level of detail
Α.Cockburn, Writing Effective Use Cases
43

44. Requirements Communication
•Determine the appropriate requirements format
•Create a requirements package
•Conduct requirements presentation
•Conduct a formal requirements review
•Obtain consensus and signoff on the requirements

45. Requirements validation
45
•Concerned with demonstrating that the requirements define the system that the customer really wants
•Requirements error costs are high so validation is very important
–Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error
–Change requirement error means change system design and implementation

46. Requirements checking (types of checks should be carried out on requirements)
46
•Validity. Does the system provide the functions which best support the customer’s needs?
•Consistency. Are there any requirements conflicts?
•Completeness. Are all functions required by the customer included?
•Realism. Can the requirements be implemented given available budget and technology
•Verifiability. Can the requirements be checked? In order to reduce potential dispute نزاع between customers.

47. Purpose of review
•The purpose of the review should be clearly stated and may encompass any of the following:
–completeness of requirements (all requirements have been captured)
–removal of superfluous requirements
–clarity of requirements (removal of ambiguity)
–correctness of requirements (the requirement reflects the business need or business rule)
–scope (the requirement fits within the stated scope of the project)
–conformance to project/organisational quality standards
–feasibility of requirements
–prioritization of requirements

48. Roles in review

49. Requirements Implementation
•Develop alternate solutions
•Evaluate technology options
•Facilitate the selection of a solution
•Ensure the usability of the solution
•Support the Quality Assurance process
•Support the implementation of the solution
•Communicate the solution impacts

50. Effective requirements practice
•A clear understanding of the needs of users, customers and stakeholders
•A collaborative relationship between the users, customers and stakeholders and the technical team
•A strong commitment of the requirements development team members to project objectives
•Use of a repeatable requirements process that is continuously improved
•A system architecture that supports the users, customers and stakeholders current and planned needs
•The ability to accommodate changes in requirements as they are progressively elaborated
•System development cost savings, accurate schedules, customer satisfaction

51. A small Example

52. The Project Brief
•Your only child is turning three on Saturday and is having a big party.
•Caters are arranged but we need a clown to entertain the guests.
•It has been suggested you have contacts in this area.
•Arrange a clown.

53. A clown must wear a bright red and white checked costume with big yellow buttons, a pointed hat with a rainbow coloured pompom. His shoes must be large with curly green ends and he needs a red nose, big red glasses and brown belt with a large gold buckle and if he can talk he must tell jokes otherwise he must be able to juggle balls or hoops.
The Clown Requirement

54. A clown must wear a bright red and white checked costume with big yellow buttons, a pointed hat with a rainbow coloured pompom. His shoes must be large with curly green ends and he needs a red nose, big red TRICKY glasses and brown belt with a large gold buckle and if he can talk he must tell jokes otherwise he must be able to juggle balls or hoops.
The Clown Requirement Verification

55. A clown must wear a bright red and white checked costume with big yellow buttons, a pointed hat with a rainbow colored pompom. His shoes must be large with curly green ends and he needs a red nose, big red OPTICAL glasses and brown belt with a large gold buckle and if he can talk he must tell jokes otherwise he must be able to juggle balls or hoops.
Pants and Jacket
Noses
Belts
Shoes
Hats
Bookings
Transport
Training
Business Rules
pompom
REQUIREMENT DOWNSTREAM DELIVERABLES

56. A clown must wear a bright red and white checked costume with big yellow buttons, a pointed hat with a rainbow colored pompom. His shoes must be large with curly green ends and he needs a red nose, big red TRICKY glasses and brown belt with a large gold buckle and if he can talk he must tell jokes otherwise he must be able to juggle balls or hoops.
Pants and Jacket
Noses
Belts
Shoes
Hats
Bookings
Transport
Training
Business Rules
pompom
TRACEABILITY

57. CHANGE IN LEGISLATION
Green ACT
All Clowns must have GREEN Noses

58. A clown must wear a bright red and white checked costume with big yellow buttons, a pointed hat with a rainbow colored pompom. His shoes must be large with curly green ends and he needs a GREEN nose, big red TRICKY glasses and brown belt with a large gold buckle and if he can talk he must tell jokes otherwise he must be able to juggle balls or hoops.
Pants and Jacket
Noses
Belts
Shoes
Hats
Bookings
Transport
Training
Business Rules
pompom
TRACEABILITY

59. A clown must wear a bright red and white checked costume with big yellow buttons, a pointed hat with a rainbow colored pompom. His shoes must be large with curly green ends and he needs a GREEN nose, big red TRICKY glasses and brown belt with a large gold buckle and if he can talk he must tell jokes otherwise he must be able to juggle balls or hoops.
Pants and Jacket
Noses
Belts
Shoes
Hats
Bookings
Transport
Training
Business Rules
pompom
TRACEABILITY

60. A Clown A clown must: Wear a bright red and white checked costume: The clown costume must have big yellow buttons. The clown must wear a hat: The clowns hat must be pointy; The end of the clowns hat must have a rainbow colored pompom. The clowns must have shoes: The clowns shoes must be large; The end of the clowns shoes must be green; The end of the clowns shoes must be curly. The clown must have a red nose. The clown must have big red TRICKY glasses. The clown must have a brown belt: The clowns belt must have a large gold buckle. If a clown can talk the clown must tell jokes. If a clown cannot talk the clown must be able to juggle balls or hoops.

61. A Clown A clown must: Wear a bright red and white checked costume. The clown costume must have big yellow buttons. The clown must wear a hat: The clowns hat must be pointy. The end of the clowns hat must have a rainbow colored pompom. The clowns must have shoes: The clowns shoes must be large; The end of the clowns shoes must be green; The end of the clowns shoes must be curly. The clown must have a red nose. The clown must have big red TRICKY glasses. The clown must have a brown belt; The clowns belt must have a large gold buckle. If a clown can talk the clown must tell jokes If a clown cannot talk the clown must be able o juggle balls or hoops
Pants and Jacket
Noses
Belts
Shoes
Hats
Bookings
Transport
Training
Business Rules
pompom
TRACEABILITY

62. A Clown A clown must: Wear a bright red and white checked costume. The clown costume must have big yellow buttons. The clown must wear a hat: The clowns hat must be pointy. The end of the clowns hat must have a rainbow colored pompom. The clowns must have shoes: The clowns shoes must be large; The end of the clowns shoes must be green; The end of the clowns shoes must be curly. The clown must have a GREEN nose. The clown must have big red TRICKY glasses. The clown must have a brown belt; The clowns belt must have a large gold buckle. If a clown can talk the clown must tell jokes If a clown cannot talk the clown must be able o juggle balls or hoops
Pants and Jacket
Noses
Belts
Shoes
Hats
Bookings
Transport
Training
Business Rules
pompom
TRACEABILITY

63. A clown must wear a bright red and white checked costume with big yellow buttons, a pointed hat with a rainbow colored pompom. His shoes must be large with curly green ends and he needs a red nose, big red TRICKY glasses and brown belt with a large gold buckle and if he can talk he must tell jokes otherwise he must be able to juggle balls or hoops.
Pants and Jacket
Noses
Belts
Shoes
Hats
Bookings
Transport
Training
Business Rules
pompom
ORPHAN REQUIREMENT

64. A Clown A clown must: Wear a bright red and white checked costume. The clown costume must have big yellow buttons. The clown must wear a hat: The clowns hat must be pointy. The end of the clowns hat must have a rainbow colored pompom. The clowns must have shoes: The clowns shoes must be large; The end of the clowns shoes must be green; The end of the clowns shoes must be curly. The clown must have a GREEN nose. The clown must have big red TRICKY glasses. The clown must have a brown belt; The clowns belt must have a large gold buckle. If a clown can talk the clown must tell jokes If a clown cannot talk the clown must be able o juggle balls or hoops
Pants and Jacket
Noses
Belts
Shoes
Hats
Bookings
Transport
Training
Business Rules
pompom
TRACEABILITY
Automatic Traceability in DOORS

66. 66
Requirements Prioritization

67. The need
•When having tens, hundreds or even thousands of requirements alternatives, decision-making becomes much more difficult
•One of the keys to making the right decision is to prioritize between different alternatives. It is often not obvious which choice is better, because several aspects must be taken into consideration

68. Requirements Prioritization
•Ensures the functionality with the most value is implemented when timelines become short
•Helps to manage competing demands
•Helps PM to manage time, cost and resources and move lower-priority requirements to later phases, releases
TIP: “Avoid ‘decibel prioritization’, in which the loudest voice heard get top priority, and ‘threat prioritization’, in which stakeholders holding the most political power always get what they demand.”

69. 69
Approaches to Prioritization
•Ask questions:
–Is there some other way to satisfy the need that this requirement addresses?
–What would happen if this requirement isn’t implemented right away?
–How would the deferral of the requirement affect the user community?
•Use Priority Scales
–High – Must be in the first release
–Medium – The business needs the functionality however can wait if necessary – can be implemented in the next release
–Low – The user can live without the functionality and it can be implemented in later releases

70. 70
Prioritization – Value, Cost, Risk
You can use a prioritization matrix.
Relative Weights:
1
1
1
1
Feature or Function (don't mix them use either feature or function or use case)
Relative Benefit
Relative Penalty
Total Value
Value %
Relative Cost
Cost %
Relative Risk
Risk %
Priority
<List each feature, requirement, or use case to be prioritized
1
2
3
15.8
50
37.0
1
14.3
0.308
in these cells, one item per cell. Copy and insert additional
3
1
4
21.1
22
16.3
3
42.9
0.356
rows as needed; the formulas will adjust automatically.>
4
1
5
26.3
7
5.2
2
28.6
0.780
6
1
7
36.8
56
41.5
1
14.3
0.661
Totals
14
5
19
100.0
135
100.0
7
100.0
2.104
Source: http://www.processimpact.com/goodies.shtml

71. 71
Prioritization on Basis of Value
•Have the business estimate the benefits that each requirement provides them (e.g. rate 1-9)
•Working with the business and I.T. estimate the penalty if the requirement isn’t included. Assess based on quality issues, legal, compliance, function loss that would affect productivity, harder to add capability later, other issues such as marketing, corporate communications
•Ask the business/I.T. to weight the requirements
•Ask, is the cost a factor?
•Calculate using spreadsheet
Value% (cost% * cost weight) + (risk % * risk weight)
Priority =

72. Or other techniques
•Group voting
•100 dollar method
–What you can buy with 100 dollar
–One should only perform the prioritization once on the same set of requirements, since the stakeholders might bias their evaluation the second time around if they do not get one of their favorite requirements as a top priority
•Top-Ten Requirements
–In this approach, the stakeholders pick their top-ten requirements (from a larger set) without assigning an internal order between the requirements

73. 73
Or You Could Use …

74. Change management

75. Change management
•Any stakeholder of <project> can submit the following types of issues to the change control system:
–requests for requirements changes (additions, deletions, modifications, deferrals) in software currently under development
–reports of problems in current production
–requests for enhancements in current production systems
–requests for new development projects

76. Change
management
process
Submitted
Evaluated Rejected
Approved
Change Made
Verified
Closed
Verifier has
confirmed the
change
Modifier has
installed modified
work products
verification
failed
Modifier has made
the change and
requested verification
no verification
required; Modifier
has installed
modified work
products
CCB decided to
make the change
CCB decided
not to make
the change
Evaluator performed
impact analysis
Originator submitted
an issue
Canceled
change was canceled;
back out of modifications
change was canceled;
back out of modifications
change was canceled;
back out of modifications

77. •The CCB decided to implement the request and allocated it to a specific future product release. The CCB Chair assigns Modifier.
Approved
•The Originator or someone else decided to cancel an approved change.
Canceled
•The Modifier has completed implementing the requested change.
Change Made
•The change made has been verified (if required), the modified work products have been installed, and the request is now completed.
Closed
•The Evaluator has performed an impact analysis of the request.
Evaluated
•The CCB decided not to implement the requested change.
Rejected
•The Originator has submitted a new issue to the change control system.
Submitted
•The Verifier has confirmed that the modifications in affected work products were made correctly.
Verified

78. Change status severities
•Minor
–Cosmetic problem, usability improvement, customer can live with the problem (default)
•Major
–Problem adversely affects product functioning, but a workaround is available; customer will be annoyed; serious usability impairment;
•Critical
–Product does not function at all; the wrong results are generated;
•Emergency
–Anything that requires a change to be made immediately, bypassing the change control process temporarily

79. Project charter

80. Project Charter
•Agreement between the organization providing the product or service, and the customer organization requesting and receiving the project deliverable.
•Tool to obtain commitment from all affected groups and individuals within a specific project.
•Does not change throughout the project life cycle.

81. Project Charter Structure
•The project typically consists of four primary sections:
–Project identification and scope
–Authority and resource need definition
–Project roles and responsibilities
–Project structure and schedule

82. Project Charter - Example
PROJECT SCOPE
•Project name/title: Membership Recruitment Task Force
•Background/Introduction/Purpose:
In the past two years, membership has decreased 5%. This team is being called together to develop a strategy to increase member retention and to add 100 new members in the next two years.
•Scope Statement (Expected results/desired outcomes):
The membership committee will develop a strategy and action plan to increase member retention and add at least 100 new members by June 2005.

83. Project Charter – Example Contd.
AUTHORITY AND RESOURCES
•Who has the authority to make decisions and allocate funds?
The committee has the authority to spend up to $5,000 for this project. The committee is empowered to do what it takes to get the task done.
•What personnel resources are needed?
A consultant who is a specialist on membership retention and recruitment
One pro-active member from each of the regional chapters (8 people)
A marketing specialist from our membership (1 person)
Team leader (1 person)
•What is the budget?
Consultant ($2500), Marketing materials ($1500), Meetings ($1000)
•What is the time needed?
Six months

84. Project Charter – Example Contd.
ROLES AND RESPONSIBILITIES
•Research and select a consultant to work with committee (Tom, Mary and Bill—by Jan 1st)
•Develop membership calling campaign in each region (8 regional committee persons responsible) Membership phone campaign in June
•Develop marketing material (Tom—by April 1st)
•Mail out marketing materials to all present and past members in May
PROJECT SCHEDULE
•January 15th – Consultant retained
•February 10th Survey completed for approval
•March 1st – Survey mailed out
•April 1st – Marketing material completed
•May 1st – Mail out marketing materials
•June – Conduct phone campaign

85. Summary – Project Charter

86. Work break down structure

87. 87
WBS Definition
•A deliverable-oriented grouping of project elements that organizes and defines the total scope of the project work.
•Work not in the WBS is not in scope of the project.
•Each descending level represents an increasingly detailed description of the project elements.
•Often used to develop or confirm a common understanding of project scope.

88. 88
Where the WBS Fits
Initiate
Plan
Execute
Control
Close
Strategic
Tactical
Physical

89. Approaches to Developing WBSs
89
•Using guidelines: some organizations, like the DOD, provide guidelines for preparing WBSs
•The analogy approach: review WBSs of similar projects and tailor to your project
•The top-down approach: start with the largest items of the project and break them down
•The bottom-up approach: start with the specific tasks and roll them up
•Mind-mapping approach: mind mapping is a technique that uses branches radiating out from a core idea to structure thoughts and ideas

90. How I should break down the project?
•Geographically separated areas for product or activities
•Major chronological time periods
•By structural, process, system, or device components
•By “intermediate” deliverables required in the production of the “end” deliverables
•By separate areas of responsibility, departments, or functional areas

91. Benefits of the WBS
91
WBS
Estimates
Schedule
Project Plan
Risk and Contingency Plans
Progress Reports
Activity List
Risk Control
Project Control
Change Control
Communication Control

92. 92
Common Approaches
Brainstorming all work to be done and then grouping into a hierarchy.
Bottom Up
Using a general-to- specific structure to progressively detail the work.
Top Down

93. Bottom up WBS Development
NO
Yes
1. Create the “to-do” list of work.
2. Organize the “to-dos”.
3. Review and Adjust with group.
4. Correct and Complete?
WBS Complete
16

94. Top Down WBS Development
1. Choose your model.
2. Verify highest level Deliverables/Phases.
4. Review, Verify and
or modify the
next subsequent level.
3. Can adequate ests. be made at this level?
WBS Complete
Yes
No
5. Confirm lowest level.
25

95. Top Down
1. Choose your model
• Review various:
life cycle models,
similar project’s WBS, or
life cycle templates.
• Choose a model closest to your specific project.
26

96. 2. Verify highest level phases/deliverables
Top Down
Start at the top of a model - Deliverables
•Verify deliverables represent the major phases of your project,
•Verify purpose/need of each major deliverable or phase,
•Determine if a previous project completed a major deliverable, e.g. Feasibility.
•Choose to: eliminate or modify deliverable after review of previous completed work
28

97. Note* This step’s question means - different levels of decomposition are appropriate for each of the major deliverables/phases.
• Can it be completed within a 2 – 3 week period?
• Adequate may change over the course of the project.
• Estimating a major work package that will be produced 6 – 12 months out may not be possible.
Top Down
“Yes” Decisions Guidelines
3. Can adequate estimates be made at this level?
29

98. Top Down
4. Review, verify and or modify the next subsequent level.
• Verify, from the model, the next subsequent level’s, more specific work detail.
• Choose the appropriate work elements.
elements should be described in tangible, verifiable results in order to facilitate the project progress.
• Repeat step 3 for each work element that you have chosen necessary for the project.
30

99. 5. Confirm lowest level
Can the item be scheduled? Budgeted? Assigned to a specific organizational unit (e.g., department, team, or person)?
If no, combine items, add to, delete, redefine.
If no, revise or expand the descriptions
If no, the item must be modified,split, redefined.
Top Down
Are the lower-level items both necessary and sufficient?
Does the work item description provide a scope?
31

100. 100
Top Down
•Requires more up front discussion.
•Terminology & structure can get in the way.
• Decreases participation.
• Slower to start.
Lesson Learned
Bottom Up
• Easy to start.
• No terminology issues.
• Higher participation.
• What do we do with this?

101. What’s Next?
101
–Briefly describe each item
–Reference by number
–List associated activities
–List milestones
–List other information needed to facilitate work
Further decomposition into a WBS Dictionary

102. WBS Summary
•Defines the hierarchy of deliverables
•Supports the definition of all work required to implement deliverables
•Graphical representation of project scope
•Framework for all deliverables
•Framework for schedule and cost calculations
•Facilitates assignment of resources
•Facilitates reporting
•Provides a framework for project evaluation

103. Example

104. Annotated example

105. WBS representation

106. An exercise
•Create a WBS for creating “brownies”

107. Brownies WBS

108. Example WBS/phase

109. DETAILED WBS EXAMPLECUSTOM SYSTEM DEVELOPMENTDevelop4.0OnlineProcesses4.1IntegrationTesting4.5SystemInterfaces4.3User & TechDocumentation4.6ScreenDevelopment4.1.1ProgramDevelopment4.1.2BatchProcesses4.2ConversionPrograms4.44.1.1.1. Develop & TestScreen A4.1.1.2. Develop & TestScreen B4.1.1.3. Develop & TestScreen C4.1.2.1. Develop & TestProgram A4.1.2.2. Develop & TestProgram B4.1.2.3. Develop & TestProgram C4.1.2.4. Develop & TestProgram D4.1.1.4. Develop & TestScreen D4.3.1. Develop & TestInterface Pgm A4.3.2Develop & TestInterface Pgm B4.3.3Develop & TestInterface Pgm C4.3.4Develop & TestInterface Pgm D4.4.1. DevelopConversion Plan4.4.2. Develop & TestXYZ ConversionPrograms4.5.1. Plan Test4.5.2. Establish TestEvironment4.5.3. Implement TestTools4.6.1. Develop UserManual4.6.2. DevelopProductionDocumentation4.6.3. Develop DisasterRecoveryDocumentation4.5.3. Develop TestReports4.5.3. Execute Test

110. Other tools
•Scope Matrix – Requirements inventory
•Deliverable Tracking Matrix