Software Project Management

Stepwise Project Planning

 ‘Step Wise’ - aspirations
• Practicality
– tries to answer the question ‘what do I do now?’
• Scalability
– useful for small project as well as large
• Range of application
• Accepted techniques
– e.g. borrowed from PRINCE etc

2
 ‘Step Wise’ - an overview
0.Select
1. Identify project 2. Identify project
project infrastructure
objectives
3. Analyse
project
characteristics

Review 4. Identify products

and activities
Lower
level 5. Estimate effort
detail for activity For each
activity
6. Identify activity
risks
10. Lower level
7. Allocate
planning
resources

8. Review/ publicize
9. Execute plan plan
3
 A project scenario: Brightmouth College
Payroll

• College currently has payroll processing

carried out by a services company
• This is very expensive and does not allow
detailed analysis of personnel data to be
carried out
• Decision made to bring payroll ‘in-house’ by
acquiring an ‘off-the-shelf’ application

4
 Project scenario - continued
• The use of the off-the-shelf system will
require a new, internal, payroll office to be set
up
• There will be a need to develop some
software ‘add-ons’: one will take payroll data
and combine it with time-table data to
calculate the staff costs for each course run in
the college
• The project manager is Brigette.

5
 Step 1 establish project scope and
objectives
• 1.1 Identify objectives and measures of
effectiveness
– ‘how do we know if we have succeeded?’
• 1.2 Establish a project authority
– ‘who is the boss?’
• 1.3 Identify all stakeholders in the project and
their interests
– ‘who will be affected/involved in the project?’

6
 Step 1 continued
• 1.4 Modify objectives in the light of
stakeholder analysis
– ‘do we need to do things to win over
stakeholders?’
• 1.5 Establish methods of communication with
all parties
– ‘how do we keep in contact?’

7
 Back to the scenario

• Project authority
- Brigette finds she has two different clients for
the new system: the finance department and
the personnel office. A vice principal agrees to be
official client, and monthly meetings are chaired
by the VP and attended by Brigette and the
heads of finance and personnel
- These meetings would also help overcome
communication barriers

8
 Back to the scenario - continued
• Stakeholders
– For example, personnel office would supply
details of new staff, leavers and changes (e.g.
promotions)
– To motivate co-operation Brigette might ensure
new payroll system produces reports that are
useful to personnel staff

9
 Step 2 Establish project infrastructure
• 2.1 Establish link between project and any
strategic plan
– ‘why did they want the project?’
• 2.2 Identify installation standards and
procedures
– ‘what standards do we have to follow?’
• 2.3. Identify project team organization
– ‘where do I fit in?’

10
 Step 3 Analysis of project
characteristics
• 3.1 Distinguish the project as either objective
or product-based.
– Is there more than one way of achieving success?
• 3.2 Analyse other project characteristics
(including quality based ones)
– what is different about this project?

11
 Step 3 continued
• Identify high level project risks
– ‘what could go wrong?’
– ‘what can we do to stop it?’
• Take into account user requirements
concerning implementation
• Select general life cycle approach
– waterfall? Increments? Prototypes?
• Review overall resource estimates
– ‘does all this increase the cost?’

12
 Back to the scenario
• Objectives vs. products
– An objective-based approach has been adopted
• Some risks
– There may not be an off-the-shelf package that caters
for the way payroll is processed at Brightmouth College
• Answer?
– Brigette decides to obtain details of how main candidate
packages work as soon as possible; also agreement that
if necessary processes will be changed to fit in with new
system.

13
 Step 4 Identify project products and
activities
• 4.1 Identify and describe project products - ‘what do we have to
produce?’

14
 Products
• 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’)

15
 Products
• 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

16
 Product description (PD)
• Product identity • Relevant standards
• Description - what is it? • Quality criteria
• Derivation - what is it based on?
• Composition - what does it
contain? Create a PD for ‘test data’
• Format

17
 Step 4 continued
• 4.2 document generic
product flows

18
 Step 4.3 Recognize product instances

• 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

19
 4.4. Produce ideal activity network
• Identify the activities needed to create each
product in the PFD
• More than one activity might be needed to
create a single product
• Hint: Identify activities by verb + noun but
avoid ‘produce…’ (too vague)
• Draw up activity network

20
 An ‘ideal’ activity

21
 Step 4.5 Add check-points if needed
Design Code
module A module A

Design Design Code

system Test
module B module B system

Design Code put in a

module C module C
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
22
 Step 5:Estimate effort for each
activity
• 5.1 Carry out bottom-up estimates
– distinguish carefully between effort and
elapsed time
• 5.2. Revise plan to create controllable
activities
– break up very long activities into a series of
smaller ones
– bundle up very short activities (create check
lists?)

23
 Step 6: Identify activity risks
• 6.1.Identify and quantify risks for activities
– damage if risk occurs (measure in time lost or
money)
– likelihood if risk occurring
• 6.2. Plan risk reduction and contingency
measures
– risk reduction: activity to stop risk occurring
– contingency: action if risk does occur

24
 • 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

25
 Step 7: Allocate resources
• 7.1 Identify and allocate resources to activities
• 7.2 Revise plans and estimates to take into
account resource constraints
– e.g. staff not being available until a later date
– non-project activities

26
 LT = lead tester

Week commencing
Gantt charts TA = testing assistant
APRIL
MARCH
5 12 19 26 2 9 16

Survey potential
suppliers Finance assistant
Analyse existing
system Business analyst
Obtain user
requirements Business analyst

Generate test cases Systems assistant

Plan office layouts

Premises office

Calculate volumes
Systems assistant

Business
Draft and issue ITT
analyst
27
 Step 8: Review/publicise plan
• 8.1 Review quality aspects of project plan
• 8.2 Document plan and obtain agreement

Step 9 and 10: Execute plan and create

lower level plans

28
 Key points
• Establish your objectives
• Think about the characteristics of the project
• Discover/set up the infrastructure to support
the project (including standards)
• Identify products to be created and the
activities that will create them
• Allocate resources
• Set up quality processes

29