TOPICS

Project Definition
Contract Management
Activities Covered By Software Project
Management
Overview Of Project Planning
Stepwise Project Planning.

12/06/11 1
Definitions:
“A finite endeavor having specific start and completion
dates undertaken to create a quantifiable deliverable.”
“Unique process, consisting of a set of coordinated and
controlled activities with start and finish dates,
undertaken to achieve an objective conforming to
specific requirements, including constraints of time, cost
and resources”

Key points above are

 planned activities
 start and finish dates
2
‘Jobs’ – repetition of very well-defined and well
understood tasks with very little uncertainty

‘Exploration’ – e.g. finding a cure for cancer: the

outcome is very uncertain

‘Projects’ – in the middle! 3

 Non-routine
 Planned
 Aiming at a specific target
 Work carried out for a customer
 Involving several specialism
 Made up of several different phases
 Constrained by time and resources
 Large and/or complex

4
Similar, but with the following characteristics:

 Invisibility
 Complexity
 Flexibility

Therefore, software projects are more difficult

to build.

5
 Example Activities

PHASES
Phse
Initiating/Defining - State the problem(s) / goal(s)
- Identify the objectives
- Secure resources
- Explore costs/benefits in feasibility study
Planning - Identify and sequence activities
- Identify the “critical path”
- Estimate time and resources needed for completion
- Write a detailed project plan
Executing - Start with the actual project work
- Commit resources to specific tasks

Controlling - Establish reporting obligations

- Create report
ing tools
- Compare actual progress with baseline
- Initiate control interventions if necessary
Closing - Finalize all obligations/commitments
- Meet with stakeholders
- Release project resources
- Issue final report

6
Distinguishing different types of project is
important as different types of task need
different project approaches e.g.

 Information systems versus embedded

systems

 Objective-based versus product-based

7
 Software development
 Package implementation
 System enhancement
 Consultancy and business analysis
 Systems migration
 Infrastructure implementation

8
 Similar to other ‘construction’ projects
 Main difficulty – intangibility of product
 Project managers need:
◦ Flexibility and adaptability
◦ Well-developed interpersonal and stakeholder
management skills

9
 Quicker and cheaper than building a system
 Main difficulties:
◦ Selecting the right package
◦ Tailoring to meet specific needs
◦ Integrating with other systems.
 Main challenges for the project manager:
◦ Managing series of sub-projects
◦ Ensuring suppliers live up to expectations
◦ Keeping users realistic about what they will get
◦ Trade-offs between business needs and
10 package
 Often handled as ‘business as usual’ but can
involve a lot of work.
 Main issues for the project manager:
◦ Keeping existing systems operational while
enhancements are made
◦ Sharing technical staff time between
enhancements and day-to-day support
◦ Regression testing of enhancements.

11
 Main issues:
◦ Intangibility of the ‘product’
◦ Difficult to estimate realistically
◦ Shifting the scope of the project.

12
 Moving existing system to new platform.
 Users judge success by lack of interruptions.
 May involve some retraining of users.
 May also involve some software development
for interfaces.

13
 Installation of hardware and/or
 Communications networks
 Fitting out of computer suites
 General project management principles apply
 Specific issues to consider:
◦ Need to maintain ‘business as usual’
◦ Supplier management vital.

14
This involves the following activities:
 Planning – deciding what is to be done
 Organizing – making arrangements
 Staffing – selecting the right people for the job
 Directing – giving instructions
 Monitoring – checking on progress
 Controlling – taking action to remedy hold-ups
 Innovating – coming up with solutions when
problems emerge
 Representing – liaising with clients, users,
developers and other stakeholders 15
 Answering the question ‘What do we have to
do to have a success?’

 Need for a project authority

◦ Sets the project scope
◦ Allocates/approves costs

◦ Could be one person - or a group

 Project Board
 Project Management Board
 Steering committee
16
Informally, the objective of a project can be
defined by completing the statement:

The project will be regarded as a

success if………………………………..

Focus on what will be put in place, rather

than how activities will be carried out

17
s pecific, that is, concrete and well-defined

M easurable, that is, satisfaction of the objective can be objectively

judged

A chievable, that is, it is within the power of the individual or group

concerned to meet the target

R elevant, the objective must relevant to the true purpose of the

project

18
These are steps along the way to achieving
the objective. Informally, these can be
defined by completing the sentence…

Objective X will be achieved

IF the following goals are all achieved
A……………
B……………
C…………… etc
19
Often a goal can be allocated to an
individual.
Individual may have the capability of
achieving goal, but not the objective on
their own e.g.

Objective – user satisfaction with software product

Analyst goal – accurate requirements

Developer goal – software that is reliable

20
How do we know that the goal or objective
has been achieved?
By a practical test, that can be objectively assessed.

e.g. for user satisfaction with software product:

◦ Repeat business – they buy further products from

us

◦ Number of complaints – if low etc etc

21
 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 22
Figure 18.1 Stakeholders and the exchange relationship
Source: Charles W. L. Hill and Gareth R. Jones, Strategic Management: An Integrated Approach, Fifth Edition. Copyright © 2001 by Houghton Mifflin Company. Adapted with permission

23
Figure 18.2 Mapping stakeholders’ power and interests
Source: Adapted from G Johnson and K Scholes, Exploring Corporate Strategy: Text and Cases, 6th edn, FT/Prentice Hall, 2002

24
Benefits of delivered project must outweigh
costs

Costs include:
- Development
- Operation

Benefits
- Quantifiable
- Non-quantifiable

25
 poor estimates  preceding activities not
 lack of quality standards & completed on time –
measures including late delivery of
 lack of guidance about making equipment
organizational decisions  lack of communication
 lack of techniques to make between users and
progress visible technicians
 poor role definition – who does
 lack of communication
what? between users leading to
dupliction of work
 incorrect success criteria
 changing statutory
 inadequate specification work
requirements
 management ignorant of IT  changing software
 lack of knowledge of application requirement
area  deadline pressure
 lack of standards  lack of quality control
 lack of up-to-date information  remote management
26
Most CIOs fired for missing budgets or time lines
In a brief survey that Janco Associates Inc. completed, they found that:

• 34 % of CIOs are fired for major application failure or mismanaging change -

missing budgets and or initiative time lines

• 29 % are fired for ignoring not being focused on how the operates28 percent get
fired for ignoring customers

• 27 % get fired for key project never gets finished or goes too far over budget

IT Toolkits Newsletter, August 27, 2009, Janco Associates Inc.

27
 GAO Study of Government Software Development
Software Engineering Risk Analysis and Management, Robert Charette, 1999

28
 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?’ 33
 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?’

34
 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?’
35
 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? for
ex.information system
36
 Identify high level project risks
◦ ‘what could go wrong?’

 Take into account user requirements

concerning implementation

 Select general life cycle approach

 Review overall resource estimates

◦ ‘does all this increase the cost?’

37
4.1 Identify and describe project products

- ‘what do we have to produce?’

38
 System products
 Module products
 Management products

39
40
 Product identity  Relevant standards
 Description - what  Quality criteria
is it?
 Derivation - what is
it based on? Create a PD for ‘test
 Composition - what data’
does it contain?
 Format

41
 Product flow diagram

42
 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

43
 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
44
 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
◦ Long activity make a project difficult to control
◦ If an activity involving testing is totake 12w
45
 6.1.Identify and quantify risks for activities
◦ damage if risk occurs (measure in time lost or
money)

 6.2. Plan risk reduction and contingency

measures
◦ risk reduction: activity to stop risk occurring
◦ contingency: action if risk does occur

46
 6.3 Adjust overall plans and estimates to
take account of risks
◦ e.g. add new activities which reduce risks
associated with other activities

47
 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

48
 LT = lead tester
TA = testing assistant
Week
APRIL
commencing MARCH
5 12 19 26 2 9 16

Plan testing LT

Select subjects
TA
Design
questionnaire LT

Book machine TA

Conduct tests
TA
Analyse results
LT

Draft changes
LT

49
 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

50