Information Technology
Project Management
By Jack T. Marchewka
Northern Illinois University
Copyright 2009 John Wiley & Sons, Inc. all rights reserved. Reproduction or translation of this work beyond that permitted in Section 117 of the
1976 United States Copyright Act without the express permission of the copyright owner is unlawful. Request for further information should be
addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back-up copies for his/her own use only and not for
distribution or resale. The Publisher assumes no responsibility for errors, omissions, or damages caused by the use of these programs or from the
use of the information contained herein.
The Nature of Information
Technology Projects
Chapter 1
IT and Modern Day Project Management
1940s
First
Electronic
Computer
1950s
1960s
EDP
Era
1970s
PC
Era
1980s
1990s
Network
Era
2000s
2010s
Globalization
3
IT and Modern Day Project Management

EDP era began early 1960S


Purchase of centralized mainframe by large organizations
IT projects focused on automating key organizational functions –
accounting, inventory, production scheduling




Improve efficiency and reduce costs of manual and clerical tasks
Structured approach used for managing these projects as the requirements
were stable and well understood
Created information silos
DP manager reported to head of accounting or financial manager
4
IT and Modern Day Project Management

Micro era began early 1980s



Proliferation (sometimes uncontrolled) of PCs challenged centralized
control that was in place
Led to user-developed, decentralized, independent systems that
replicated data throughout the organization and vied for IT support
Role of CIO is created to ensure that IT is used strategically



Reported to CEO to show importance of the CIO position and critical role
to be played by IT
PCs needed to coexist and integrate with mainframes
IT projects now crossed functional lines and requirements were
changing at a faster pace

Software development methodologies introduced to manage the less stable
requirements and shorten the development life cycle
5
IT and Modern Day Project Management

Network era began mid 1990s due to the advances and
growth of the ARPANET /Internet.




Projects focused on the challenge of creating an IT infrastructure to
support many partners, strategic alliances, vendors and customers.
Network architecture has to be scalable to support thousands of
networked computers in a timely and efficient manner
Digital convergence of data, voice, graphics and video allowed for
new and innovative ways to deliver new products and services to
customers
Micro era projects focused on creating an internal network within
the organization, network era focused on extending the network
externally



Support a dynamic business strategy and new organizational structures
IT project members need to understand the technology, but more
importantly, the organization and its competitive environment
Benefits and risks much higher than the previous two eras
6
IT and Modern Day Project Management

Globalization era – we’re in the beginning stages now

Thomas Friedman “The World is Flat”


The combination of technology and lowering of political barriers has flattened
the world so that it is now possible for people and organizations to work
with almost anyone in any place at any time
The global competitive playing field has become level for everyone


See his talk at MIT http://mitworld.mit.edu/video/266
Projects today are more dynamic, geographically dispersed, and
ethnically or culturally diverse as ever before

IT personnel require a solid set of technical, non-technical and project
management skills based on past experience but adapted to this new
environment
7
Introduction



Information Technology (IT) projects are organizational
investments that require
 Time
 Money
 And other resources such as people, technology, facilities,
etc.
Organizations expect some type of value in return for this
investment
IT Project Management is a relatively new discipline that
attempts to make IT projects more successful and combines
traditional Project Management with Software
Engineering/Management Information Systems
8
An ITPM Approach


Organizational resources are limited, so organizations
must choose among competing interests to fund specific
projects
This decision should be based on the value a competing
project will provide to an organization
9
Which Situation is Worse?
Successfully building and implementing a system that
provides little or no value to the organization?
Or…
 Failing to implement an information system that could
have provided value to the organization, but was
underdeveloped or poorly managed?

10
Modern Project Management



Often credited to the U.S. Navy as an outgrowth of the
Polaris Missile Project in the 1950’s.
Focuses on reducing costs and product cycle time.
Provides an important link between an organization’s
strategy and the deployment of that strategy.

Can have a direct impact on an organization’s bottom line and
competitiveness.
11
Why Do IT Projects Fail?

Larger projects have the lowest success rate and appear
to be more risky than medium and smaller projects


Technology, business models, and markets change too rapidly
so projects that take more than a year can be obsolete before
they are completed
The CHAOS studies also provides some insight as to the
factors that influence project success
12
The Software Crisis

The CHAOS study published in 1995 by The Standish
Group found that although the U.S spent over $250
billion on IT projects, approximately…


31% were cancelled before completion
53% were completed but over budget, over schedule, & did not
meet original specifications


For mid-size companies, average cost overruns were 182%, while
average schedule overruns were 202%!
Disagreement with the CHAOS report


The Rise and Fall of the Chaos report Figures http://www.cs.vu.nl/~x/chaos/chaos.pdf
Projects failure rate – the conventional wisdom is wrong!
http://quantmleap.com/blog/2009/11/projects-failure-rate-%E2%80%93-the-conventional-wisdom-is-wrong/


The “Chaos Report” Myth Busters http://www.guerrillaprojectmanagement.com/the-chaos-report-myth-busters
New IT project failure metrics: is Standish wrong?
http://www.zdnet.com/blog/projectfailures/new-it-project-failure-metrics-is-standish-wrong/513
13
Has the Current State of IT Projects
Changed Since 1994?


The Standish Group has continued to study IT projects
over the years.
In general, IT Projects are showing higher success rates
due to





Better project management tools & processes
Smaller projects
Improved communication among stakeholders
More skillful IT project managers
But there is still ample opportunity for improvement!
14
Figure 1.1 - Summary of the Chaos Studies from 1994 to 2008
Sucessful
32%
2008
1998
26%
1996
27%
16%
18%
51%
28%
2000
19%
53%
34%
2002
24%
46%
29%
2004
Failed
44%
35%
2006
1994
Challenged
15%
49%
23%
46%
33%
53%
28%
40%
31%
15
Table 1.1 Summary of CHAOS Study Factor Rankings for Successful Projects
Sources: Adapted from the Standish Group. CHAOS (West Yarmouth, MA: 1995, 2010) & http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
Rank
1994
2001
2006
2008
1
User Involvement
Executive Support
User Involvement
User Involvement
2
Executive Management
Support
User Involvement
Executive Management
Support
Executive Support
3
Clear Statement of
Requirements
Experienced Project
Manager
Clear Business
Objectives
Clear Business
Objectives
4
Proper Planning
Clear Business
Objectives
Optimizing Scope
Emotional Maturity
5
Realistic Expectations
Minimized Scope
Agile Process
Optimizing Scope
6
Smaller Project
Milestones
Standard Software
Infrastructure
Project Management
Expertise
Agile Process
7
Competent Staff
Firm Basic
Requirements
Financial Management
Project Management
Expertise
8
Ownership
Formal Methodology
Skilled Resources
Skilled Resources
9
Clear Vision &
Objectives
Reliable Estimates
Formal Methodology
Execution
10
Hard-working, focused
team
Other
Standard Tools and
Infrastructure
Tools & Infrastructure
16
Table 1.2: Project Performance and Internal/External Customer Satisfaction.
Source: Marchewka, J.T. (2008). n = 114.
Much
Worse
Worse
Same
Better
Much
Better
0.0%
12.3%
40.4%
41.2%
6.1%
1.8%
10.5%
44.7%
37.7%
5.3%
2.6%
7.0%
41.2%
41.2%
7.9%
Overall
satisfaction
of the
customer
1.8%
13.2%
34.2%
39.5%
11.4%
Perceived
value of the
delivered
product to
the customer
0.0%
9.6%
39.5%
38.6%
12.3%
Potential for
future work
with the
customer
0.9%
3.5%
42.1%
38.6%
14.9%
Ability to
meet project
schedules
Ability to
meet
project
IT Project
budgets
Performance
Over the
Past 3 Years
Ability to
complete
project scope
or system
requirement
s
Customer
satisfaction
over the past
3 years
(Customers
can be
internal –
e.g., HR
department
or external –
e.g., a
particular
client)
17
Table 1.2: IT Project Success Criteria
Source: Source: http://www.drdobbs.com/architecture-and-design/202800777.
Criteria
Schedule
Response
61.3% said it is more important to deliver a system when it is
ready to be shipped than to deliver it on time.
Scope
87.3% said that meeting the actual needs of stakeholders is more
important than building the system to specification.
Money
79.6% said that providing the best return on investment (ROI) is
more important than delivering a system under budget.
Quality
87.3% said that delivering high quality is more important than
delivering on time and on budget.
Staff
75.8% said that having a mentally and physically healthy
workplace is more important than delivering on time and on
budget.
18
Table 1.3: Summary of Factor Rankings for Challenged and Failed (Impaired) Projects
Source: Adapted from the Standish Group. CHAOS (West Yarmouth, MA: 1995)
Rank
Factors for Challenged Projects
Factors for Failed (Impaired) Projects
1
Lack of user input
Incomplete requirements
2
Incomplete requirements
Lack of user involvement
3
Changing requirements & specifications
Lack of resources
4
Lack of executive support
Unrealistic expectations
5
Technology incompetence
Lack of executive support
6
Lack of resources
Changing requirements & specifications
7
Unrealistic expectations
Lack of planning
8
Unclear objectives
Didn’t need it any longer
9
Unrealistic time frames
Lack of IT management
10
New technology
Technology illiteracy
19
Tata Consultancy Services 2007 Report

Included 800 senior IT managers from the UK,
US, France, Germany, India, Japan, & Singapore:




62% of the IT projects failed to meet their
schedules
49% experienced budget overruns
47% experienced higher-than expected
maintenance costs
41% failed to deliver the expected business value
and ROI
20
Figure 1.2 - When IT projects have gone wrong, what has been
the reaction from the business managers and the Board of
Directors?
Don't know
None
Looked for a scapegoat among IT staff
Sought compensation from IT vendors
Reluctant to fund new IT projects
Reduced IT budgets
Tend to accept problems as the norm (i.e., a
necessary evil)
Continued to provide support to improve IT
1%
2%
9%
13%
19%
21%
43%
69%
21
Improving the likelihood of success


A Value-Driven Approach
 Plain & Simple: IT Projects must provide value to the
organization not just completed on time and within budget
Socio-technical Approach
 It’s not just about the technology or building a better
mouse trap. Must bring value to the organization.
Clients/stakeholders must take an active, participatory role
22
Improving the likelihood of success

Project Management Approach

Success depends not just on the team but more on the methodology
(the set of processes and infrastructure) in place


Step-by-step activities, processes, tools, quality standards, controls and
deliverables
Knowledge Management Approach

Systematic process for acquiring, creating, synthesizing, sharing and
using information, insights, and experiences to transform ideas into
business value


lessons learned
best practices
23
Improving the likelihood of success

Why project management should support IT projects




PM enables a company to make the best use of limited resources.
Projects can drain or divert resources away from other projects
and areas of the organization so investing them wisely is critical.
To best meet client’s expectations, PM provides the means to
deliver quality products and services in a professional manner
(status reports, communications).
Facing competition from outside vendors, good PM practices can
enable internal IT departments to remain competitive in acquiring
new business and talent.
Enables an organization to be more efficient (do the right thing)
and effective (do the thing right).


PM enables shorter development time, lower costs and higher quality
PM must be supported and accepted at all levels of the organization.
24
The PMBOK® Guide’s Definitions for Project
and Project Management
A project is a temporary endeavor undertaken to create
a unique product, service, or result.
 Project Management is the application of knowledge,
skills, tools and techniques to project activities to meet
project requirements. Managing a project includes:






Identifying requirements
Establishing clear and achievable objectives
Balancing the competing demands for quality, scope, time, and
cost
Adapting the specifications, plans, and approaches to the
different concerns and expectations of the various stakeholders
A project manager is the person assigned by the
performing organization to achieve the project
objectives.
25
The Context of Project Management
Project Attributes









–
Time Frame (definite start and end)
Purpose (project needs a specific and measurable goal in order to
provide value)
Ownership (sponsor)
Resources (the triple constraint)
Roles (different skill sets needed on a project)
 Project Manager
 Project Sponsor
 Subject Matter Expert (domain & technical)
Risk & Assumptions (internal and external risks)
Interdependent Tasks
 progressive elaboration – steps & increments
Planned Organizational Change
Operate in Environments Larger than the Project Itself
 Company culture, environment, politics, etc.
26
The Triple Constraint
Figure 1.3
27
The Project Life Cycle and IT Development

Project Life Cycle (PLC)



A collection of logical stages or phases that maps the life of a
project from its beginning to its end in order to define, build, and
deliver the product of the project – i.e., the information system
A deliverable is a tangible and verifiable product of work
Projects are divided into phases to increase manageability
and reduce risk


Phase exits, stage gates, or kill points are decision points at the end
of each phase to evaluate performance or to correct problems or
cancel the project
Fast tracking is the overlapping of phases to reduce the project’s
schedule

Can be risky!
28
The Project Life Cycle

Define Project Goal



Plan Project



Focus on providing business value to the organization
Gives the project team a clear focus and drives the other
phases of the project
What is to be done, why is it being done, how will it be done,
who is going to do it, how long will it take, how much will it
cost, what can go wrong and what can be done about it, how
will we know if the project is successful given the time, money
and resources invested?
Deliverable is the initial or baseline project plan
Execute Project Plan


Put the plan in action – build whatever product has been
decided based on plan specifications
A continuous monitoring of the actual vs baseline is needed
29
The Project Life Cycle

Close Project



A formal closure of the project ensures that all work is
completed as planned and agreed to by the team and sponsor
Final report and presentation to the client
Evaluate Project


Evaluating whether a project met its goals (providing business
value) is best done after implementation when it is in
production
Lessons learned – document experiences and best practices
for future projects


What went right and what went wrong
Evaluate the project manager and team members
30
Generic Project Life Cycle
Figure 1.4
31
Systems Development Life Cycle (SDLC)

Although projects follow a project life cycle, information
systems development follows a product life cycle.



The most common product life cycle in IT is the systems
development life cycle, which represents the sequential phases
or stages an information system follows throughout its useful
life.
The SDLC establishes a logical order or sequence in which the
system development activities occur and indicates whether to
proceed from one system development activity to the next
Planning

The planning stage involves identifying and responding to a
problem or opportunity and incorporates the project
management and system development processes and activities.

A formal planning process ensures that the goal, scope, budget,
schedule, technology, and system development processes, methods,
and tools are in place.
32
Systems Development Life Cycle (SDLC)

Analysis

The analysis phase attempts to delve into the problem or
opportunity more fully.



For example, the project team may document the current system to
develop an "as is" model to understand the system currently in place. ,
Systems analysts will meet with various stakeholders (users, managers,
customers, etc.) to learn more about the problem or opportunity.This
work is done to identify and document any problems or bottlenecks
associated with the current system.
The "as is" analysis is followed by a requirements analysis where the
specific needs and requirements for the new system are identified and
documented.


Requirements can be developed through a number of means—
interviewing, joint applications development (JAD), conducting surveys,
observing work processes, and reading company reports.
Using modeling techniques, the current system, user requirements, and
logical design of the future system called the "to be" system are
represented and documented
33
Systems Development Life Cycle (SDLC)

Design

The project team uses the requirements and "to be" logical
models as input for designing the architecture to support the
new information system.


Implementation

Includes the development or construction of the system, testing,
and installation.


This architecture includes designing the network, hardware
configuration, databases, user interface, and application programs.
In addition, training, support, and documentation must be in place.
Maintenance and Support

Once the system has been implemented, it is said to be in
production and becomes a legacy system

Changes to the system, in the form of maintenance and enhancements,
are often requested to fix any discovered errors (i.e., bugs) within the
system, to add any features that were not incorporated into the original
design, or to adjust to a changing business environment.
34
Systems Development Life Cycle (SDLC)
Figure 1.5
35
Implementing the (SDLC)

A structured approach to systems development has been around
since the 1960s and 1970s, when large mainframe applications
were developed.



The waterfall model illustrated was developed as a simple and
disciplined method that follows the SDLC closely in a very sequential
and structured way.
The idea of a waterfall is a metaphor for a cascading of activities from
one phase to the next where one phase is completed before the next
phase is started.
The waterfall model stresses a sequential and logical flow of software
development activities.




Design activities or tasks begin only after the requirements are defined
completely.
The building or coding activities will not start until the design phase is
complete.
Although there is some iteration where the developers can go back to a
previous stage, it is not always easy or desirable.
One characteristic of the waterfall model is that a great deal of time and
effort is spent in the early phases getting the requirements and design right
because it is more expensive to fix a bug or add a missing requirement in
the later phases of the project.
36
Implementing the (SDLC)



An advantage of the waterfall model is that it allows us to plan
each phase in detail so that the project schedule and budget can
be computed by summing the time and cost estimates for all the
tasks defined in each phase.
This approach is still used today, especially for large government
systems and by companies that develop shrink wrap or
commercial software packages.
A structured approach is suitable when developing large, more
complex systems where one assumes, or at least hopes, that the
requirements defined in the early phases do not change very
much over the remainder of the project.
37
Putting the SDLC into Practice

Structured Approach to Systems Development


Waterfall Method
Iterative Development




Rapid Applications Development (RAD)
Prototyping
Spiral Development
Extreme Programming
38
Iterative Systems Development


Critics of the structured approach to systems development
argue that it takes too long to develop systems and that it does
not embrace the idea that changing requirements are inevitable.
Inexperienced developers often have the false belief that if they
ask the users what they want, they will be rewarded with a set
of clear, accurate, and complete requirements.


In truth, most users do not know or are unable to articulate their
needs early on in the project. If they do, those requirements will most
likely change later on.
The main idea behind iterative systems development is
shortening the SDLC and embracing the idea that requirements
are difficult to define and will change.
39
Iterative Systems Development

Rapid applications development (RAD ) was proposed by James
Martin in the early 1990s as a less formal way to expedite the
SDLC.

RAD attempts to compress the analysis, design, build, and test activities
of the SDLC into a series of short iterations or development cycles.

For example, a small team of users and developers would work closely
together to develop a set of system requirements during a workshop.
 Using tools such as computer- aided software engineering (e. g., CASE) or

visual development environments (e. g., .NET), the developers would then
work with the users to develop a functional or usable version of the system
that might include only 25 per- cent of the total requirements.
The development cycle would continue with a second usable version that
would include the next 25 percent of the requirements. Subsequent
iterations would continue until all of the requirements are included in the
system.
40
RAD
41
Iterative Systems Development

Prototyping, similar to RAD, is an iterative approach to systems
development where the user and developer work closely together to
develop a partially or fully functional system as soon as possible.

Often, however, a prototype may be developed to discover or refine
system requirement specifications that can be used as a model for
developing a real system.

A team may develop a nonfunctional user interface on a personal computer as a
model to define the look, feel, and features of a large, multi-user system.
42
Iterative Systems Development

Spiral development approach first proposed by Barry Boehm (1988),
breaks up a software project into a number of mini-projects that address
one or more major risks until all the risks have been addressed.





A risk, could be a poorly understood requirement or a potential technical
problem or system performance issue.
The basic idea is to begin development of a system on a small scale where risks
can be identified.
Once identified, the development team then develops a plan for addressing
these risks and evaluates various alternatives.
Next, deliverables for the iteration are identified, developed, and verified before
planning and committing to the next iteration.
As a result, the completion of each iteration brings the project closer to a fully
functional system.
43
Spiral Development
44
Iterative Systems Development

Agile systems development methods are becoming an increasingly popular
approach to systems development and include various methodologies such as
SCRUM, dynamic systems development method (DSDM), and adaptive software
development (ASD).

One of the most commonly known agile methodologies is eXtreme programming (XP),
which was introduced by Kent Beck in the mid-1990s.


Under XP, the system is transferred to the users in a series of versions called releases.
A release may be developed using several iterations that are developed and tested within a
few weeks or months. Each release is a working system that includes only one or several
functions that are part of the full system specifications.





XP includes a number of activities where the user requirements are first documented as a user story.
The user stories are then documented using an object-oriented model called a class diagram.
A set of acceptance tests is then developed for each user story. Releases that pass the acceptance
tests are then considered complete.
Small teams of developers often work in a common room where workstations are positioned in the
middle and a workspace for each team member is provided around the perimeter.
XP often incorporates team programming, where two programmers work together on the same
workstation.
Developers often are prohibited from working more than 40 hours a week in order to avoid burnout
and the mistakes that often occur because of fatigue
45
Agile Software Development


Agile software development has become popular to
describe new approaches that focus on close
collaboration between programming teams and business
experts
Visit www.agilealliance.org for information
46
Agile System Development
47
SCRUM Software Development

SCRUM breaks a software development into a series of iterations or sprints. Each sprint lasts
at most 30 days. During each sprint, a set of features are incrementally added to the product
under development and a potential release of software is created.

The requirements for the product to be developed are held in a product backlog.

At the start of a sprint, a sprint planning meeting is held. During the meeting, a set of
requirements from the backlog are picked for implementation in the next sprint. The
development team decides which requirements they can commit to developing during the
next sprint.

At the end of a sprint, a sprint retrospective meeting is held to discuss which elements of the
process could be improved.

Further sprints are then performed until the product backlog of requirements is empty.
48
The Relationship Between the PLC &
SDLC



The project life cycle (PLC) focuses on the phases,
processes, tools, knowledge and skills for managing a
project, while the system development life cycle (SDLC)
focuses on creating and implementing the project’s
product—the information system.
The SDLC is really part of the PLC because many of the
development activities occur during the execution phase
of the PLC.
The last two phases of the PLC, close project and
evaluate project, occur after the implementation of the
system
49
The Relationship Between the PLC & SDLC
Figure 1.7
50
Extreme Project Management (XPM)



A new approach & philosophy to project management that is becoming
increasingly popular
Characterizes many of today’s projects that exemplify speed, uncertainty,
changing requirements, and high risks
Traditional project management often takes an orderly approach while,
XPM embraces the fact that projects are often chaotic and unpredictable


XPM focuses on flexibility, adaptability, and innovation
XPM takes a more holistic view of planning and managing projects


Expects requirement changes so planning is an iterative process
Enables people to discover best solutions and self-correct themselves as needed
51
The Project Management Body of
Knowledge (PMBOK®)




The Guide to the Project Management Body of Knowledge (PMBOK®
Guide) documents 9 project management knowledge areas
The PMBOK® Guide is published and maintained by the Project
Management Institute (PMI)
 http://www.pmi.org
PMI provides a certification in project management called the Project
Management Professional (PMP) that many people today believe will be
as relevant as a CPA certification
PMP certification requires that you pass a PMP certification exam to
demonstrate a level of understanding about project management, as
well as satisfy education & experience requirements and agree to a
professional code of conduct
52
Project Management Body of Knowledge Areas
Figure 1.8
53
Project Management Body of Knowledge Areas
54
Project Management Body of Knowledge Areas

Knowledge areas describe the key competencies that
project managers must develop




4 core knowledge areas lead to specific project objectives
(scope, time, cost, and quality)
4 facilitating knowledge areas are the means through which the
project objectives are achieved (human resources,
communication, risk, and procurement management
1 knowledge area (project integration management) affects and is
affected by all of the other knowledge areas
All knowledge areas are important!
55