• Step Wise project planning framework

• Preparation of a software project plan

• Planning and scheduling the activities in software project
management
• Various approaches towards activity plan
• Various scheduling techniques such as sequencing and CPM

Software Project
2
Management
 0
Select
project

1 Identify 2 Identify
project scope project
and objectives infrastructure

3
Analyse project
characteristics

Software Project to next slide

3
Management
 from previous slide

4
Identify the
Review products and activities

5
Estimate efforts
Lower for activity
level For each
detail activity
6
identify
activity risks
from next slide
Software Project to next slide
4
Management
 to previous slides from previous slide

10 7
Lower level Allocate
planning resources

9 8
Execute Review/
plan publicize plan

Software Project
5
Management
• Step 0: Select project
• Step 1: Identify project scope and objectives
• Step 2: Identify project infrastructure
• Step 3: Analyze project characteristics
• Step 4: Identify project products and activities

Software Project
6
Management
• Step 5: Estimate effort for each activity
• Step 6: Identify activity risks
• Step 7: Allocate resources
• Step 8: Review/publicize plan
• Step 9: Execute plan
• Step 10: Execute lower levels of planning

Software Project
7
Management
• Step 1.1 Identify objectives and practical measures of the
effectiveness in meeting those objectives
• Step 1.2 Establish a project authority
• To ensure the unity of purpose among all persons concerned

Software Project
8
Management
• Step 1.3 Identify all stakeholders in the project and their
interests
• Step 1.4 Modify objectives in the light of stakeholder analysis
• Step 1.5 Establish methods of communication between all
parties

Software Project
9
Management
 These are people who have a stake or interest in
the project
In general, they could be users/clients or
developers/implementers

They could be:

• Within the project team
• Outside the project team, but within the same
organization
• Outside both the project team and the organization

10
• Project Manager
• Customers
• Sponsors
• Project Team and their families
• Performing Organizations
• Funders
• Sellers/Contractors
• Gov. Agencies and media outlets

11
• Step 2.1 Identify relationship between the project and strategic
planning
• To determine the order of related projects (in the organization) being
carried out
• To establish a framework within which the system fits
• To ensure the hardware and software standards are followed
• The hours spent by team members on individual tasks are recorded on
time sheets.
• Controls and checks are implemented.

Software Project
12
Management
 Design Code
module A module A

Design Design Code

system Test
module B module B system

Design Code
module C module C
put in a
check point
Design Code
module A module A

Design Design Code

system Check-point Test
module B module B system

Design Code
module C module C
13
• Step 2.2 Identify installation standards and procedures
• more appropriate name: “Identify standards and procedures related to
the software project”
• Step 2.3 Identify project team organization

Software Project
14
Management
• Step 3.1 Distinguish the project as either objective-
driven or product-driven
• Step 3.2 Analyze other project characteristics
(Embedded, Information system, critical)
• Step 3.3 Identify high level project risks
• Step 3.4 Take into account user requirements
concerning implementation

Software Project
15
Management
– Step 3.5 Select general lifecycle approach in the light of the
above(waterfall? Increments? Prototypes?)
• Step 3.6 Review overall resource estimates
Up to this stage,
–the major risks of the project are identified
–the overall approach of the project is decided
So, it is a good place to re-estimate the required effort and
other resources for the project

Software Project
16
Management
• Step 4.1 Identify and describe project products
• Identify all the products related to the project
• Account for the required activities
• Step 4.2 Document generic product flows
• To document the relative order of the products
• Step 4.3 Recognize product instances

Software Project
17
Management
• The PBS and PFD will probably have identified generic products
e.g. ‘software modules’
• It might be possible to identify specific instances e.g. ‘module A’,
‘module B’ …
• But in many cases this will have to be left to later, more
detailed, planning

18
• Step 4.4 Produce an ideal activity network
• Activity network shows the tasks that have to be carried out
as well as their sequence of execution for the creation of a
product from another
• Step 4.5 Modify the ideal to take into account need
for stages and checkpoints
• To check compatibility of products of previous activities

Software Project
19
Management
• Product Breakdown Structure (PBS)
• To show how a system can be broken down into different products for
development
• Product Flow Diagram (PFD)
• To indicate, for each product, which products are required as ‘inputs’

Software Project
20
Management
 A Product Breakdown Structure (an extract)

Inventory
Control

Inventory Item Management

Databases Processing Reporting

Item Vendor Item Item Item Sales

Database Database Purchasing Sales Reporting Reporting

Item Item Item Invoicing Sales Order

Addition Deletion Modification subsystem Processing

Software Project
21
Management
• The result of an activity

• Could be (among other things)

• physical thing (‘installed pc’),
• a document (‘logical data structure’)
• a person (‘trained user’)
• a new version of an old product (‘updated software’)

22
• The following are NOT normally products:
• activities (e.g. ‘training’)
• events (e.g. ‘interviews completed’)
• resources and actors (e.g. ‘software developer’) - may be exceptions
to this

• Products CAN BE deliverable or intermediate

23
• Use Work Breakdown Structure (WBS) to generate a task list
• WBS involves
• identifying the main tasks
• break each main task down into subtasks
• The subtasks can further be broken down into lower level tasks.

Software Project
24
Management
 Work Breakdown Structure (an extract)

Software
project

Requirements System Coding Testing

Analysis Design

Data Process
Design Design

Software Project
25
Management
• Work-based: draw-up a Work Breakdown Structure listing
the work items needed
• Product-based approach
• list the deliverable and intermediate products of project – product
breakdown structure (PBS)
• Identify the order in which products have to be created
• work out the activities needed to create the products

26
A Work Breakdown Structure (WBS for short) is a (deliverable-
oriented) hierarchical decomposition of the work to be executed
by the project team to accomplish projects objectives and create
the required deliverable

Software Project
27
Management
• A mix of the activity-based approach and the product-based
approach
• More commonly used approach
• The WBS consists of
• a list of the products of the project; and
• a list of activities for each product

Software Project
28
Management
• IBM in its MITP methodology suggests 5 levels
• Level 1: Project
• Level 2: Deliverables (software, manuals etc)
• Level 3: Components
• Level 4: Work-packages
• Level 5: Tasks (individual responsibility)

Software Project
29
Management
 Software Project

System Installation Software component User manual User Training

Analyse requirements Review requirements Analyse requirements Design course

Detailed design Outline design Design manual Write materials

Integrate system Detailed design Document manual Print course materials

Test system Code software Capture screens Training

Deliver system Test software Print Manual

Software Project
30
Management
• Step 5.1 Carry out bottom-up estimates
• need to estimate staff effort, time for each activity, and other resources
• Step 5.2 Revise plan to create controllable activities
• need to break a task into a series of manageable sub-tasks

Software Project
31
Management
• Step 6.1 Identify and quantify the risks of each activity
• Step 6.2 Plan risk reduction and contingency measures where appropriate
– risk reduction: activity to stop risk occurring
– contingency: action if risk does occur
• Step 6.3 Adjust overall plans and estimates to take account of risks
– e.g. add new activities which reduce risks associated with other activities
e.g. training, pilot trials, information gathering

Software Project
32
Management
• Step 7.1 Identify and allocate resources
• type of staff needed for each activity
• staff availabilities are identified
• staff are provisionally allocated to task
• Step 7.2 Revise plans and estimates to take into account
resource constraints
• staffing constraints
• staffing issues

Software Project
33
Management
• Step 8.1 Review quality aspects of the project plan
• To ensure each activity is completed with a quality product
• Each activity should have ‘exit requirements’.
• This ensures the quality of the product on each activity.

Software Project
34
Management
• Step 8.2 Document plans and obtain agreement
• all parties understand and agree to the commitments in the plan

Software Project
35
Management
• Circulate to all stakeholders
• Stakeholders look from their perspective
• Get their feedback
• Modify plan, if necessary
• Freeze plan ~ called ‘Base Plan’
• Any future modification on this plan only

36
• Kick start activities as per plan
• When proj progresses….more accurate data comes in
• Update base plan judiciously and recirculate to all stake
holders
• Allocate resources
• Skill / competency
• Experience
• Salary
• Requirement availability
• Personal traits

37