Download Chapter 1

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