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
[Link]
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
• [Link] 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
