Chapter

Chapter 11
11
Project Management

1
 The need for project management
• Standish group: 73% of all software projects
are delivered late or fail to meet performance
criteria
• Critical for companies today: the ability to
adapt existing business processes faster than
the competition
• Typical adaptation projects include:
• “Rightsizing” the organization
• Reengineering business processes
• Adopting more comprehensive, integrative
processes
2
 IT Project Management Failings
Due to:
• Failure to assess implementation risk of
project at funding time
• Failure to consider aggregate
implementation risk of a portfolio of
projects
• Failure to recognize different projects
need different management approaches

3
Ignoring project risk leads to…
• Anticipated benefits not obtained
• ↑ implementation costs
• ↑ implementation time
• Systems with sub-par technical
performance
• System incompatibility with hardware and
software

4
 The IT component of projects
• Virtually all projects involve an information
technology component, including a
computer and information flow
• The amount of resources to complete IT-
intensive projects is increasing as these
have increased in complexity
 Skilled IT project management is fundamental
to business success.

»But first, what is a project?

5
 What Defines a Project?
• “[A] project is a temporary endeavor
undertaken to create a unique product or
service. Temporary means that every
project has a definite beginning and a
definite end. Unique means that the
product or service is different in some
distinguishing way from all similar products
or services.”
• -Project Management Institute (1996)

6
 Project Elements
4 components essential for any project:
– Common vocabulary: so all team members can
communicate effectively
– Teamwork: to insure all parts of the project
come together effectively and correctly
– Project cycle plan: method and schedule to
execute the project
– Management of the project is needed so that
it is coordinated and executed appropriately

7
Determining the Complexity Level (risk)

Factors influencing a project’s complexity:

1. How many products will this website sell?
2. Will this site support global, national, regional, or
local sales?
3. How will this sales process interface with the
existing customer fulfillment process?
4. Does the company possess the technical
expertise in-house to build the site?
5. What other corporate systems and processes
does this project impact?
6. How and when will these other systems be
coordinated?
8
 Project Dimensions Affecting
Implementation Risk
• Project size
– $$$ (relative to other budgets in org), staffing levels,
duration, departments affected, team members (=
number of man months),

• Experience with technology

– with h/w, s/w, operating systems, database systems

• Project structure (clarity)

– High structure (task clearly defines project outputs) vs.
low structure (requirements difficult to determine and
evolving)

9
 Risk Level
• Large, highly complex projects that are
usually low in clarity are very risky
• Small projects that are low in
complexity and high in clarity are
usually low risk
– Everything else is somewhere in between
• The level of risk determines how
formal the project management system
and detailed the planning should be
10
 WHAT IS PROJECT MANAGEMENT?

• The application of knowledge, skills, tools,

and techniques to project activities in order
to meet or exceed stakeholder needs and
expectation from a project.

• It always involves continual trade-offs; and

it is the manager’s job to manage them

11
 Typical Project
Management Trade-offs
• Scope vs. Time
• Cost vs. Quality Time Cost

QUALITY

Scope

• Identified requirements vs. Unidentified

requirements
• User needs vs. User expectations
• Differing needs and expectations vs. diverse
stakeholders
12
 Project Cycle Plan
• Most projects contain three phases:
1. Requirements definition
2. Development
3. Production/distribution
• Managers must also attend to the
following during each phase:
– Technical aspects of the project
– Budget aspects of the project
– Business aspects of the project
13
 Project Measurement
• Some metrics used for IS projects are the
same as those used for all business projects:
– on-time, on-budget, and met specifications

• IT projects are difficult to estimate and most

fail to meet their schedules and budgets
• Software systems often involve highly
interactive, complex sets of tasks that rely on
each other to make a completed system and
most projects cannot be made more efficient
simply by adding labor
14
 Business versus System Functionality

• Metrics for functionality are typically divided

along lines of business functionality and system
functionality
– The first set of measures are those derived
specifically from the requirements and business
needs that generated the project
– The second are related to the system itself such as
how well the individual using the system can and
does use it, or system reliability

15
 Pulling the Plug
• Often projects in trouble persist long after they
should have been abandoned
• The amount of money already spent on a project
biases managers towards continuing to fund the
project even if its prospects for success are
questionable
• When the penalties for failure within an
organization are also high, project teams are often
willing to go to great lengths to insure that their
project persists
• Or if there is an emotional attachment to the
project by powerful individuals within the
organization 16
 IT Project Development Methodologies
• The choice of development methodologies and
managerial influences distinguish IT projects
from other projects.
• Four main methodologies IT professionals use
to manage the technology projects:
– Systems Development Life Cycle (SDLC)
– Prototyping
– Rapid applications development (RAD)
– Joint applications development (JAD)

17
Systems Development Life Cycle (SDLC)

SDLC typically consists of seven phases:

1. Initiation of the project
2. The requirements definition phase
3. The functional design phase
4. The system is actually built
5. Verification phase
6. The “cut over” where the new system is put in
operation and all links are established
7. The maintenance and review phase

18
 Limitations of SDLC
• Traditional SDLC methodology for current IT
projects are not always appropriate:
– Many systems projects fail to meet objectives
because of the difficulty in estimating costs and
each project is often so unique that previous
experience may not provide the necessary skills
– Objectives may reflect a scope that is too broad or
two narrow so that the problem the system was
designed to solve may still exist, or the opportunity
that it was to capitalize upon may not be
appropriately leveraged.
– If the business environment is very dynamic, there
may not be enough time to adequately do each step
of the SDLC for each IT project 19
Alternatives to SDLC Approaches:
Prototyping and RAD

• SDLC may not work for all situations

• SDLC often requires a lot of planning
• Difficult to implement quickly
• Communications to establish
requirements may be problematic
• Prototyping and RAD are alternative
approaches…

20
Iterative Development
System
Concept

Version
“1”
Version
“2”

Version
Software “N”
Development
Process
21
 Prototyping
Proposed Advantages Disadvantages in Practice
• Improved user • Prototypes are used “as
communication is”
• Users like it – Integration often
difficult
• Low risk – Design flaws
• Avoids over-design – Poor performance
• Experimentation and • Difficult to manage
innovation process
• Spreads labor to user • Creates unrealistic
department expectations
• Documentation is
difficult

22
 Rapid Applications Development and
Joint Applications Development
• RAD, like prototyping, uses iterative
development tools to speed up development:
GUI; reusable code; code generation;
programming, language testing and debugging

• JAD uses a group approach to elicit

requirements in a complete manner by
interviewing groups of users

23