Requirements Engineering

1
Requirements Engineering

• Lesson 3
• PROJECT MANAGEMENT

2
Project and Project Management

• A project is a temporary sequence of unique,
  complex, and connected activities having one goal
  or purpose and that must be completed by specific
  time, within budget, and according to
  specification.
• Project management is the process of scoping,
  planning, staffing, organizing, directing, and
  controlling the development of an acceptable
  system at a minimum cost within a specified time
  frame.

3
Project versus Process Management

• Project management is the process of scoping,
  planning, staffing, organizing, directing, and
  controlling the development of an acceptable
  system at a minimum cost within a specified time
  frame.
• Process management is an ongoing activity that
  documents, manages the use of, and improves an
  organizations chosen methodology (the process)
  for system development. Process management is
  concerned with the activities, deliverables, and
  quality standards to be applied to all projects.

4
Causes of Project Failure

• Failure to establish upper-management commitment
  to the project
• Lack of organizations commitment to the system
  development methodology
• Taking shortcuts through or around the system
  development methodology
• Poor expectations management
• Premature commitment to a fixed budget and
  schedule
• Poor estimating techniques
• Overoptimism
• The mythical man-month (Brooks, 1975)
• Inadequate people management skills
• Failure to adapt to business change
• Insufficient resources
• Failure to manage to the plan

5
Project Manager Competencies

• Business awareness
• Business partner orientation
• Commitment to quality
• Initiative
• Information gathering
• Analytical thinking
• Conceptual thinking
• Interpersonal awareness
• Organizational awareness

• Anticipation of impact
• Resourceful use of influence
• Motivating others
• Communication skills
• Developing others
• Monitoring and controlling
• Self-confidence
• Stress management
• Concern for credibility
• Flexibility

(Adapted from Wysocki, Beck, and Crane, Effective
Project Management How to Plan, Manage, and
Deliver Projects on Time and within Budget.)
6
Project Management Functions

• Scoping
• Planning
• Estimating
• Scheduling
• Organizing
• Directing      
• Controlling
• Closing

7
Measures of Project Success

• The resulting information system is acceptable to
  the customer.
• The system was delivered on time.
• The system was delivered within budget.
• The system development process had a minimal
  impact on ongoing business operations.

8
The Variables of Project Management

• Can somewhat vary the following factors.
• 1. The total cost of the project,
• e.g., increase expenditures
• 2. The capabilities of the product,
• e.g., subtract from a list of features
• 3. The quality of the product,
• e.g., increase the mean time between failure
• 4. The date on which the job is completed.
• e.g., reduce the schedule by 20
• e.g., postpone project's completion date one month

9
Bullseye Figure for Project Variables
cost
Target 70K
Target 100
capability
duration
Target 30 wks
Target 4 defects/Kloc
defect density
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
10
Bullseye Figure for Project Variables
cost
Target 70K
Target 100
Actual 90K
Actual 100
this project
capability
duration
Target 30 wks
Target 4 defects/Kloc
Actual 20 wks
Actual 1 defect/Kloc
defect density
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
11
A Road Map for Project Management Planning
12
Hierarchical Project Management Organizations
Larger Projects
Smaller Projects
No separate Marketing? No separate QA
organization?
Subdivide QA into testing, ? Subdivide
Engineering into system engineering, ?
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
13
Horizontal Project Management Organizations
Ian Corliss Team member
Gil Warner Team leader
Nel Tremont Team member
Team facilitator?
Fran Smith Team member
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
14
Peer Organizations for Larger Projects
Team of leaders
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
15
Organize a Team

• 1. Select team leader responsibilities
• ensure all project aspects active
• fill all gaps
• 3. Designate leader roles document
  responsibilities
• team leader proposes and maintains SPMP
• configuration management leader ... SCMP
• quality assurance leader ... SQAP, STP
• requirements management leader ... SRS
• design leader ... SDD
• implementation leader ... code base
• 2. Leaders responsibilities
• propose a straw man artifact (e.g. SRS, design)
• seek team enhancement acceptance
• ensure designated artifact maintained observed
• maintain corresponding metrics if applicable
• 4. Designate a backup for each leader

One way to ...
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
16
The Four Risk Activities

• (1) Identification
• Mindset try to continually identify risks
• (2) Retirement (Mitigation) planning
• (3) Prioritization
• (4) Retirement or mitigation

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
17
The Risk Management Mindset
Identification
Retirement
2. Java skills not high enough.
2. Retirement by avoidance Use C
Project finish
Project finish
Risk 2
Risk 2
Risk 1
Risk 1
1. Retirement by conquest Demonstrate image
super- imposition
1. May not be possible to superimpose images
adequately.
Project start
Project start
Graphics reproduced with permission from Corel.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
18
Identify and Mitigate Risks
One way to ...

• 1. Each team member spends 10 mins. exploring
  his or her greatest fears for the projects
  success
• 2. Each member specifies these risks in
  concrete language, weights them, writes
  retirement plans, (see format above) e-mails to
  the team leader
• 3. Team leader integrates and prioritizes
  results
• 4.M Group spends 10 mins. seeking additional
  risks
• 5.M Team spends 10 mins. finalizing the risk
  table
• Designates responsible risk retirement engineers
• 6. Responsible engineers do risk retirement
  work
• 7.M Team reviews risks for 10 mins. at weekly
  meetings
• responsible engineers report progress
• team discusses newly perceived risks and adds them

in advance of first meeting M at
meeting between meetings
19
Choosing development tools and support CASE
Tools -

• To support project management
• schedule
• work breakdown
• To support configuration management
• For managing requirements

• For drawing designs
• functional
• object-oriented
• use-case-based
• Tracing tools
• requirements to designs
• designs to code
• To support testing
• To support maintenance

20
Creating schedules high level planning

• Methods
• Backward Planning
• Forward Planning

21
High Level Task Chart with Fixed Delivery Date
Month 1
Month 2
Month 3
Month 4
Month 5
1
2
3
4
1
2
3
4
1
2
3
4
1
2
3
4
1
2
3
4
SRS Complete
SCMP complete
SQAP complete
Milestones
Delivery
SPMP rel. 1 complete
Freeze requirements
Iteration 1
Iteration 2
Risk identification retirement
Prep. for maintenance
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
22
Create an Initial Schedule

• 1. Indicate the milestones your must observe
• usually includes delivery date
• 2. Back these up to introduce the milestones you
  need
• e.g., begin system testing well before delivery
• 3. Designate a time at which all requirements
  frozen
• The remaining steps depend on the process used.
• We will assume an iterative
  process.
• 4. Show first iteration establishes minimal
  capability
• usually keep it very modest, even trivial, in
  capability
• benefit exercises the development process itself
• 5. Show task of identifying retiring risks
• starting from project inception
• 6. Show unassigned time (e.g., week) near
  middle?
• 7. Complete the schedule

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
23
Level Labor Allocation for Fixed Labor Total
Month 1
Month 2
Month 3
Month 4
Month 5
1
2
3
4
1
2
3
4
1
2
3
4
1
2
3
4
1
2
3
4
Milestones
Complete testing
Freeze requirements
Release to production
Karen vacation
2
2
2
3
2
2
3
Iteration 1
Hal vacation
4
4
4
3
3
4
4
4
4
4
4
4
Iteration 2
2
2
2
1
1
1
4
To be assigned
Risk ID retire
4
4
4
4
4
3
3
4
4
4
4
3
3
4
4
4
4
4
4
4
Given team size
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
24
Project Management Tools Techniques

• A PERT chart is a graphical network model that
  depicts a projects tasks and the relationships
  between those tasks.
• A Gantt chart is a simple horizontal bar chart
  that depicts project tasks against a calendar.
  Each bar represents a named project task. The
  tasks are listed vertically in the left-hand
  column. The horizontal axis is a calendar
  timeline.

25
PERT Chart
Project Initiation
Legend
5-3-2001
N/A
Task
Task
5-3-2001
N/A
Scheduled
Scheduled
Scheduled
Scheduled
intertask
Start
Finish
Start
Finish
dependency
Actual
Actual
Actual Start
Actual Start
Finish
Finish
Preliminary Investigation
5-3-2001
5-12-2001
5-3-2001
5-11-2001
Problem Analysis
Requirements Analysis
Decision Analysis
5-28-2001
7-15-2001
6-13-2001
7-30-2001
5-12-2001
6-12-2001
5-30-2001
7-18-2001
6-13-2001
8-3-2001
5-12-2001
6-14-2001
Construction
Design
7-19-2001
11-13-2001
7-3-2001
9-25-2001
7-20-2001
In Progress
7-5-2001
10-9-2001
Implementation
9-10-2001
12-14-2001
TBD
TBD
26
Gantt Chart
27
Microsoft Project Gantt Chart
28
Microsoft Project PERT Chart
29
Project Management Life Cycle
30
Joint Project Planning Strategy

• Joint project planning (JPP) is a strategy
  wherein all stakeholders in a project (meaning
  system owners, users, analysts, designers, and
  builders) participate in a one-to-three day
  project management workshop, the result of which
  is consensus agreement on project scope,
  schedule, resources, and budget. (Of course,
  subsequent workshops or meetings may be required
  to adjust scope, budget, and schedule.)

31
Negotiate Scope

• Scope defines the boundaries of a projectWhat
  part of the business is to be studied, analyzed,
  designed, constructed, implemented, and
  ultimately improved?
• Product
• Quality
• Time
• Cost
• Resources
• A statement of work is a narrative description of
  the work to be performed as part of a project.
  Common synonyms include scope statement, project
  definition, project overview, and document of
  understanding.

32
Statement of Work

• I. Purpose
• II. Background
• A. Problem, opportunity, or directive statement
• B. History leading to project request
• C. Project goal and objectives
• D. Product description
• III. Scope
• (notice the use of your information system
  building blocks)
• A. Stakeholders
• B. Data
• C. Processes
• D. Locations
• IV. Project Approach
• A. Route
• B. Deliverables
• V. Managerial Approach
• A. Team building considerations
• B. Manager and experience
• C. Training requirements

33
Statement of Work (concluded)

• VI. Constraints
• A. Start date
• B. Deadlines
• C. Budget
• D. Technology
• VII. Ballpark Estimates
• A. Schedule
• B. Budget
• VIII. Conditions of Satisfaction
• A. Success criteria
• B. Assumptions
• C. Risks
• IX. Appendices

34
Identify Tasks

• A work breakdown structure (WBS) is a
  hierarchical decomposition of the project into
  phases, activities, and tasks.
• Milestones are events that signify the
  accomplishment or completion of major
  deliverables during a project.

35
Work Breakdown Structures

• 1 Phase 1 of the project
• 2 Phase 2 of the project
• 2.1 Activity 1 of Phase 2
• 2.2 Activity 2 of Phase 2
• 2.2.1 Task 1 of Activity 2.2 in Phase 2
• 2.2.2 Task 2 of Activity 2.2 in Phase 2
• 2.2.3 Task 3 of Activity 2.2 in Phase 2
• 2.3 Activity 3 of Phase 2
• 3 Phase 3 of the project

36
Estimate Task Durations

• 1.  Estimate the minimum amount of time it would
  take to perform the task. We'll call this the
  optimistic duration (OD).
• 2.  Estimate the maximum amount of time it would
  take to perform the task. We'll call this the
  pessimistic duration (PD).
• 3.  Estimate the expected duration (ED) that will
  be needed to perform the task.
• 4.  Calculate the most likely duration (D) as
  follows
• D (1 x OD) (4 x ED) (1 x PD)
  6

37
Specify Intertask Dependencies

• Finish-to-start (FS)The finish of one task
  triggers the start of another task.
• Start-to-start (SS)The start of one task
  triggers the start of another task.
• Finish-to-finish (FF)Two tasks must finish at
  the same time.
• Start-to-finish (SF)The start of one task
  signifies the finish of another task.

38
Entering Intertask Dependencies
39
Scheduling Strategies

• Forward scheduling establishes a project start
  date and then schedules forward from that date.
  Based on the planned duration of required tasks,
  their interdependencies, and the allocation of
  resources to complete those tasks, a projected
  project completion date is calculated.
• Reverse scheduling establishes a project
  deadline and then schedules backward from that
  date. Essentially, tasks, their duration,
  interdependencies, and resources must be
  considered to ensure that the project can be
  completed by the deadline.

40
A Project Calendar
41
Assign Resources

• Peopleinclusive of all the system owners, users,
  analysts, designers, builders, external agents,
  and clerical help that will be involved in the
  project in any way, shape, or form.
• Servicesa service such as a quality review that
  may be charged on a per use basis.
• Facilities and equipmentincluding all rooms and
  technology that will be needed to complete the
  project.
• Supplies and materialseverything from pencils,
  paper, notebooks, toner cartridges, etc.
• MoneyA translation of all of the above into the
  language of accountingbudgeted dollars!

42
Defining Project Resources
43
Assigning Project Resources
44
Resource Leveling

• Resource leveling is a strategy used to correct
  resource overallocations by some combination of
  delaying or splitting tasks.
• There are two techniques for resource leveling
• task delaying
• task splitting

45
Task Splitting and Delaying

• The critical path for a project is that sequence
  of dependent tasks that have the largest sum of
  most likely durations. The critical path
  determines the earliest possible completion date
  of the project.
• Tasks that are on the critical path cannot be
  delayed without delaying the entire project
  schedule. To achieve resource leveling, critical
  tasks can only be split.
• The slack time available for any noncritical task
  is the amount of delay that can be tolerated
  between the starting time and completion time of
  a task without causing a delay in the completion
  date of the entire project.
• Tasks that have slack time can be delayed to
  achieve resource leveling

46
Direct the Team Effort

• Supervision resources
• The DEADLINE A Novel About Project Management
• The One Minute Manager
• The Care and Feeding of Monkeys
• Stages of Team Maturity (see figure to the right)

47
Monitor and Control Progress

• Progress reporting
• Change management
• Expectations management
• Schedule adjustmentscritical path analysis (CPA)

48
Progress on a Gantt Chart
49
Critical Path Analysis (and Slack Time)

• Using intertask dependencies, determine every
  possible path through the project.
• For each path, sum the durations of all tasks in
  the path.
• The path with the longest total duration is the
  critical path.
• The critical path for a project is that sequence
  of dependent tasks that have the largest sum of
  most likely durations. The critical path
  determines the earliest completion date of the
  project.
• The slack time available for any noncritical task
  is the amount of delay that can be tolerated
  between the starting time and completion time of
  a task without causing a delay in the completion
  date of the entire project.

50
Critical Path
51
Sample Outline for a Progress Report

• I. Cover Page
• A. Project name or identification
• B. Project manager
• C. Date or report
• II. Summary of progress
• A. Schedule analysis
• B. Budget analysis
• C. Scope analysis (describe any changes
  that may have an impact on future progress)
• D. Process analysis (describe any
  problems encountered with strategy or
  methodology)
• E. Gantt progress chart(s)
• III. Activity analysis
• A. Tasks completed since last report
• B. Current tasks and deliverables
• C. Short term future tasks and deliverables
• IV. Previous problems and issues
• A. Action item and status
• B. New or revised action items
• 1. Recommendation
• 2. Assignment of responsibility

52
Sample Outline for a Progress Report (concluded)

• V. New problems and issues
• A. Problems
• (actual or anticipated)
• B. Issues
• (actual or anticipated)
• C. Possible solutions
• 1. Recommendation
• 2. Assignment of responsibility
• 3. Deadline
• VI. Attachments
• (include relevant printouts from project
  management software)

53
PowerPoint Alternative

• Sample initial status report

54

Two Week
Status Report
Integrated Strategic Systems Plan
May 30, 2000
55
The purpose of today's meeting

• Report on first two weeks
• Agree on hypothesis
• Agree of business issues
• Next step - detailed IT assessment

56
The project objective is to
57
The project scope is focused on the processes and
technologies that drive manufacturing capacities,
costs and efficiencies.
58
The study deliverables will be linked to the NMMC
business strategies and processes.
59
The work-plan is aggressive covering fourteen
weeks we are on schedule for 18 August 2000
We are here
60
sTs has committed the following resources to this
project

• Full Time
• Engagement Manager IT Strategist - Tony
  Sullivan
• Process Analyst - Kumar Bhatt
• IT Architect - Stephen Perun
• Part Time
• IT Strategy Carl Straub
• IT Assessment MotorCo IT Support

61
We are working under the following hypothesis

• MotorCo intends to significantly increase it's
  North American production. The current
  information technology base will not allow
  increase in product mix, multiple plants or three
  shift operations
• Systems are old and difficult to change
• Batch operation precludes real time information
• Knowledge of some systems is "retiring"

62
The last two weeks was spent ......

• We collected requirements from all the meetings
  and held a special meeting for your direct
  reports or representatives to gather their
  requirements (5/25)
• completing the current process understanding
• completing the current IT architecture map
• developing business requirements for the expanded
  
• production scope

63
Last week we met with four major areas of
production control to understand the current
process

• Tuesday, 5/23 230-500 Production Planning
• Takeshi (Todd)
• Steve
• Wednesday, 5/24 730-1130 Production
  Scheduling
• Bill
• Roy D
• Bruce
• Mike
• Wednesday, 5/24 100-500 Inventory Control
• Art
• Pete
• Tommy
• Bob
• Terry

64
Problem We do not have a complete understanding
of MotorCo's current Business Objectives to
completely align a new IT Strategy

• To properly align IT plans a complete
  understanding of Business Objectives is
  required........
• Example Increase production throughput
• Optimizing throughput tends to group like units
  (Build to Plan)
• e-business looks at order quantities of one.

65
Over the next two weeks we plan to meet with the
following groups

• PMCS (6/7)
• Bryan
• Dan t
• Earl
• Randy
• Production Purchasing (6/9)

• Financial Systems (6/8)
• Vince
• Bill
• Mary
• Transportation
• Decherd (6/8)
• Brent

66
Issues

• None

67
Questions?