You are on page 1of 55

12/06/11 1

DEFINITIO
NS:
“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
objectives 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
Examp e Activities

PHASES

Initiating/Def ning - State the problem(s) / goal(s)


--Identify the objectives
Secure resources
-Explore costs/benefts in feasibility study
Planning -- Identify and sequence activities
Identify the “critical path”
- Estimate time and resources needed for comp letion
- Write a detailed project plan
Executing - Start with the actual project work
- Commit resources to specifc tasks
Controlling -- Establish reporting obligations
Create repinogrttools
- Compare actual progress with baseline
- Initiate control interventions if necessary
Closing -- Finalize all obligations/commitments
Meet with stakeholders
- Release project resources
- Issue fnal 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 an d 10
 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
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
Types of Stakeholders
• The project manager
• The project team
• The project sponsor
• The performing organizations
• The partners
• The client
• The “rest”: anyone who might be affected by the
project outputs
Key Stakeholders
• Internal:
– Project team members: the group performing the work
– Project management team: the members of the team directly
involved in project management
• In between:
– Customer/User: person or organization that will use the results
of a
project. There may be multiple layers of users
– Sponsor: person or group providing the financial resources
– Performing Organization: the organization mostly involved in
the
project
• External:
– Influencers: people or groups not directly related to the project
who
could influence the course of a project
20
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
 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

21
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

22
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
Objective –GOAL, BUT NOTwith
user satisfaction THEsoftware
OBJECTIVE ON
product
THEIR OWN E.G.
Analyst goal – accurate requirements

Developer goal – software that is reliable 20


THE mnemoic SMART is used to describe well defined objectives
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

T ime constrained : there should be a defined point in time by which


the objective should have been achieved

18
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


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:

◦Repeatbusiness – they buy further products


from us
◦Number of complaints – if low etc etc

21
BENEFITS OF DELIVERED PROJECT MUST
OUTWEIGH COSTS

Costs include:
-Development
-Operation

Benefits
-Quantifiable
-Non-quantifiable

25
POOR ESTIMATES

LACK OF QUALITY STANDARDS &


MEASURES  preceding activities not
lack of guidance about making completed on time –
organizational decisions including late delivery of
equipment
lack of techniques to make progress  lack of communication
visible between users and
poor role definition – who does what? technicians
 lack of communication
between users leading to
incorrect success criteria inadequate
dupliction of work
specification work management ignorant
 changing statutory
of IT requirements changing
lack of knowledge of application area  software
lack of standards requirement
 deadline pressure lack
lack of up-to-date information

 of quality control
documentation

 remote man26agement
GAO Study of Government Software Development
Software Engineering Risk Analysis and Management, Robert Charette, 1999

32
STEPS IN PROJECT PLANNING

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 Step 5: Estimate effort for each activity.

Step 6 : Identify activity risks. Step 7 : Allocate resources Step 8 Review / Publicize

pl\an

Step 9 & 10 : Execute plan / lower level of planning


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?’ To ensure the unity of purpose among all persons
concerned


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?’
39
 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 40

◦ ‘where do I fit in?’


 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
41
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?’
42
4.1 IDENTIFY AND DESCRIBE PROJECT 
PRODUCTS

- ‘what do we have to produce?’

43
 System products
 Module products
 Management products

44
45
PRODUCT 

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

46
PRODUCT FLOW 
DIAGRAM

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

48
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

49
Design Code
module C module C
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
50
◦ If an activity involving testing is totake 12w
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

51
 6.3 ADJUST OVERALL PLANS AND
ESTIMATES TO TAKE ACCOUNT OF
RISKS
◦ e.g. add new activities which reduce risks
associated with other activities

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

53
TESTER
TA = testing assistant
Week
MARCH APRIL
commencing
5 12 19 26 2 9 16

Plan testing LT

Select
subjects TA
Design LT
questionnaire
TA
Book machine

Conduct tests TA

Analyse LT

results LT
54

Draft changes
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
55

You might also like