Software Project Management
Download
Report
Transcript Software Project Management
SW Project Management
Nature of IT Projects
INFO 420
Dr. Jennifer Booker
INFO 420
Chapter 1
1
Intro
IT projects are organizational investments
Need
to expect commitment of considerable
time, money, and people
Some aspects of traditional project
management need to be tweaked for IT
projects; take from software engineering
and system analysis & design
INFO 420
Chapter 1
2
Intro
Focus: reducing costs, reducing cycle time
Connect
organization’s strategy to its
deployment, help improve competitiveness
PM and IS evolve in parallel timelines
Three generations of PM strategy
The
INFO 420
EDP era, micro era, and network era
Chapter 1
3
EDP era - 1960’s to early 1980’s
Central mainframe or minicomputer
Automate separate tasks, e.g. inventory
mgmt, accounting, production scheduling
Data processing manager
Similar to early steam power use – same
process, with more power behind it
INFO 420
Chapter 1
4
Micro era - 1980’s to mid-90’s
Introduction of the PC, and soon clientserver computing
Network
is contained within the organization
Lost central control over MIS – IT is
everywhere, changing often
Security,
data integrity, support issues
Fast, cross-area IT projects
INFO 420
Chapter 1
5
Network era - mid-1990s to now
Due to awareness of the Internet
More strategic partners, alliances, vendors
Network
focus is outside the organization
Need scalable network architecture
Digital convergence of data, AV, graphics
Creates
new products and services
Needs new organization and strategy
INFO 420
Chapter 1
6
Globalization
The omnipresence of computers and the
Internet is bringing about a globalization
previously unimaginable
Work
with anyone, any place, any time
Increases both risks and rewards
IT has some budget in both good times
and bad, the question is how to use it best
INFO 420
Chapter 1
7
The key decision
So it boils down to:
Which IT projects are worth supporting?
Which
will provide the most benefit and value
to the organization?
INFO 420
Chapter 1
8
IT project management
So far, we’re not doing well at managing
IT projects
In
1968 the software development crisis
was identified
In 1994, CHAOS study said 16% of IT
projects were successful, 31% cancelled
before completion, and 53% completed badly
INFO 420
Chapter 1
9
IT project management
More recent studies have shown some
improvement
In
2008, 32% were successful, 24% failed,
and 44% were weak
Factors for successful projects included
(2010 CHAOS Manifesto)
User
involvement, executive support, clear
business objectives, and emotional maturity
INFO 420
Chapter 1
10
Why do we fail?
Partly a definition problem – how far from
the plan is a ‘failure’? 5%? 10%? 20%?
Traits of failed or weak projects include
Incomplete
requirements, lack of user
involvement, changing requirements and
specs, lack of exec support, lack of resources,
and unrealistic expectations
INFO 420
Chapter 1
11
Why do we fail?
Communication is a key as well
The
#1 reason for project failure, and a factor
in many other causes
Resource issues also include staffing,
training, tools, and facility issues
INFO 420
Chapter 1
12
How help success?
Four approaches are themes throughout
A
value-driven approach
A socio-technical approach
A project-management approach
A knowledge-management approach
INFO 420
Chapter 1
13
A value-driven approach
Make IT projects prove they provide value
to the organization
The value the project delivers must more
than offset its time, money, and
opportunity costs
INFO 420
Chapter 1
14
A socio-technical approach
Tools, techniques, and methodologies are
not enough
Need
to consider the impact of the project on
its users, and other affected organizations
Does anyone want the new system?
Will they use it?
INFO 420
Chapter 1
15
A project-management approach
Need to follow some methodology during
the IT project
Don’t
just wing it!
What are the processes and infrastructure?
What tools and controls are used?
Plan appropriate resources, manage
expectations (communicate!), consider
outsourcing; efficiency & effectiveness goals
INFO 420
Chapter 1
16
A knowledge-management
approach
Have a systematic process for capturing
and sharing knowledge from past projects
Record lessons learned and best practices
How can we do it better next time?
INFO 420
Chapter 1
17
Project management context
Our approach for project management is
based on the Project Management
Institute (PMI)’s Guide to the Project
Management Body of Knowledge
(PMBOK, 2008)
A project is a temporary effort to
accomplish a product, service, or result
INFO 420
Chapter 1
18
Project attributes
Time frame
Purpose or goal – PM should meet or
exceed stakeholders’ needs and
expectations
Ownership (mainly by sponsor)
Resources; the triple constraints of scope,
schedule, and budget
INFO 420
Chapter 1
19
Project attributes
Roles – project manager, subject matter
experts (SME), technical experts, etc.
Risks and assumptions
Risks
can be internal or external
Interdependent tasks in the project
Organizational change may result
Operating in a larger environment
INFO 420
Chapter 1
20
Extreme Project Management
Extreme Project Management (XPM) tries
to stay adaptable and flexible enough to
handle high speed, high change, high
uncertainty, high stress projects
Requirements
changes are inevitable
Planning is iterative and self-correcting
Innovation in processes or tools are expected
INFO 420
Chapter 1
21
PMBOK
The Guide to the Project Management
Body of Knowledge captures the major
topics within project management
First
defined in 1987
Current version is ISBN 1935589679 (2013)
It has nine “knowledge areas”
INFO 420
Chapter 1
22
PMBOK knowledge areas
Project integration management
Coordinating
changes to the project plan’s
development and execution
Project scope management
Ensuring
complete definition and completion
of the project scope
INFO 420
Chapter 1
23
PMBOK knowledge areas
Project time management
Developing,
monitoring, and managing the
project schedule
Project cost management
Develop
and complete project per its budget
Project human resource management
Create,
INFO 420
develop and manage the project team
Chapter 1
24
PMBOK knowledge areas
Project quality management
Create
a quality environment to help project
meet stakeholder needs and expectations
Project communications management
Ensure
project communicates with
stakeholders
INFO 420
Chapter 1
25
PMBOK knowledge areas
Project risk management
Identify
and respond to risks facing the project
Project procurement management
Manage
procurement of products and
services from outside the organization
INFO 420
Chapter 1
26
System Development Life Cycle
The development of a system has its own
life cycle, which takes place inside the
project
The System Development Life Cycle
(SDLC) defines the phases needed to
create a system, then maintain it
There
are many versions of SDLC to choose
from
INFO 420
Chapter 1
27
Generic SDLC Phases
Planning
Analysis
Design
Implementation
Maintenance & support
INFO 420
Chapter 1
28
Planning
Defines the problem to be solved, or
opportunity to be taken, and outlines the
goal and scope of the system
The plan for developing the system is
defined
Should
include budget, schedule, technology,
development processes, methods, and tools
INFO 420
Chapter 1
29
Analysis
Documents the existing system or
processes (the ‘as is’ model)
Leads to requirements analysis
Might
use Joint Application Development
(JAD), surveys, brainstorming, interviews, etc.
to determine requirements
Define how the new system will work
(the ‘to be’ model)
INFO 420
Chapter 1
30
Design
Define the high level design of the system
(architecture) based on the requirements
Refine the design to produce the low
level design
Designs
include software, hardware, network,
databases, user interface concept, etc.
INFO 420
Chapter 1
31
Implementation
Construct, test, and install the system
Easy
to say, huh?
Also develop the documentation, training
materials, and supporting information
INFO 420
Chapter 1
32
Maintenance & support
Maintenance of a system is often a
separate ongoing project
After installation, the system is in
production mode for most of its life
Still
need to make improvements
(enhancements), and fix bugs (maintenance)
May manage a call center or help desk
INFO 420
Chapter 1
33
Retirement
Eventually, a production system becomes
obsolete, leading to a new project to
replace it
As part of that project, phasing out the old
system will be done, until it’s completely
offline
INFO 420
Chapter 1
34
SDLC Examples
Implementing the SDLC can follow several
types of approaches
The oldest is the structured approach,
better known as the waterfall life cycle
It’s
simple and sequential – do each phase
completely before moving to the next one
Requirements, design, code, test, & deploy
INFO 420
Chapter 1
35
Waterfall SDLC
Some versions of the waterfall model
(DOD-STD-2167a (1988), MIL-STD-498
(1994)) defined very precisely how the
results of each phase were documented
Waterfall
depends on very clearly defined
requirements and well known methodology
and tools – rarely the case for new
development, but may be true for
maintenance
INFO 420
Chapter 1
36
Waterfall SDLC
Still useful for maintenance or small
projects
Also good for inexperienced development
teams
Can be good for shrink wrapped software
development
INFO 420
Chapter 1
37
Iterative system development
Need for faster
development, and
accommodation of
changing
requirements led to a
variety of iterative
SDLC models
INFO 420
Chapter 1
Iterative approaches
include:
RAD
Prototyping
Spiral
Agile
RUP
38
RAD
Rapid Application Development (RAD)
compresses the life cycle using special
software development tools (CASE tools)
Each iteration produces more and more of
the final product in usable form, until it’s
completed
INFO 420
Chapter 1
39
Prototyping
Generally, prototyping is used to refine or
discover system requirements
Prototyping depends on close work
between the developer and the customer
to create a partially functional system
Then full system development takes place
INFO 420
Chapter 1
40
Spiral
The spiral model (Boehm, 1988) is used
to address big risks facing a project
Each
spiral ‘miniproject’ is a short life cycle
devoted to resolving one key risk area
After all the major risks have been
resolved, then another life cycle is
used for full system development
INFO 420
Chapter 1
41
Agile
Agile software development is defined loosely
as:
‘An
iterative and incremental (evolutionary) approach
to software development which is performed in a
highly collaborative manner by self-organizing teams
within an effective governance framework with "just
enough" ceremony that produces high quality
software in a cost effective and timely manner which
meets the changing needs of its stakeholders.’
From http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
INFO 420
Chapter 1
42
Agile
Agile methods include various
methodologies, such as
SCRUM
DSDM
(Dynamic Systems Development
Method)
ASD (Adaptive Software Development)
XP (eXtreme Programming)
INFO 420
Chapter 1
43
RUP
The Rational Unified Process (RUP), now
owned by IBM, is an object oriented,
iterative life cycle methodology
“RUP
promotes iterative development and
organizes the development of software and
systems into four phases, each consisting of
one or more executable iterations of the
software at that stage of development.”
From http://www-01.ibm.com/software/awdtools/rup/
INFO 420
Chapter 1
44
Summary
We’ve introduced the major topics in IT
project management
History
of IT project management
Reasons for project failure and success
Our approach for encouraging success
Define a project
PM body of knowledge
System development life cycles
INFO 420
Chapter 1
45