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 1950s 1960s 1970s 1980s 1990s 2000s 2010s

First EDP PC Network Globalization

Electronic Era Era Era
Computer

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 Challenged Failed

2008 32% 44% 24%

2006 35% 46% 19%

2004 29% 53% 18%

2002 34% 51% 15%

2000 28% 49% 23%

1998 26% 46% 28%

1996 27% 33% 40%

1994 16% 53% 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 User Involvement Executive Management

Support Support Executive Support

3 Clear Statement of Experienced Project Clear Business Clear Business

Requirements Manager Objectives Objectives
4 Proper Planning Clear Business Optimizing Scope
Objectives Emotional Maturity

5 Realistic Expectations Minimized Scope Agile Process Optimizing Scope

6 Smaller Project Standard Software Project Management

Milestones Infrastructure Expertise Agile Process

7 Competent Staff Firm Basic Financial Management Project Management

Requirements Expertise
8 Ownership Formal Methodology Skilled Resources Skilled Resources

9 Clear Vision & Reliable Estimates Formal Methodology

Objectives Execution

10 Hard-working, focused Other Standard Tools and

team Infrastructure Tools & Infrastructure

16
Table 1.2: Project Performance and Internal/External Customer Satisfaction.
Source: Marchewka, J.T. (2008). n = 114.

Much Much
Worse Worse Same Better Better
Ability to
meet project 0.0% 12.3% 40.4% 41.2% 6.1%
schedules
Ability to
IT Project meet project 1.8% 10.5% 44.7% 37.7% 5.3%
Performance budgets
Over the
Past 3 Years
Ability to
complete
project scope 2.6% 7.0% 41.2% 41.2% 7.9%
or system
requirement
s

Overall
satisfaction 1.8% 13.2% 34.2% 39.5% 11.4%
Customer of the
satisfaction customer
over the past
3 years
(Customers Perceived
can be value of the
internal – delivered 0.0% 9.6% 39.5% 38.6% 12.3%
e.g., HR product to
department the customer
or external –
e.g., a
particular Potential for
client) future work 0.9% 3.5% 42.1% 38.6% 14.9%
with the
customer 17
Table 1.2: IT Project Success Criteria
Source: Source: http://www.drdobbs.com/architecture-and-design/202800777.

Criteria Response

61.3% said it is more important to deliver a system when it is

Schedule
ready to be shipped than to deliver it on time.

87.3% said that meeting the actual needs of stakeholders is more

Scope
important than building the system to specification.

79.6% said that providing the best return on investment (ROI) is

Money
more important than delivering a system under budget.

87.3% said that delivering high quality is more important than

Quality
delivering on time and on budget.

75.8% said that having a mentally and physically healthy

Staff 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 1%

None 2%

Looked for a scapegoat among IT staff 9%

Sought compensation from IT vendors 13%

Reluctant to fund new IT projects 19%

Reduced IT budgets 21%

Tend to accept problems as the norm (i.e., a 43%

necessary evil)

Continued to provide support to improve IT

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

27
Figure 1.3
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
 Focus on providing business value to the organization
 Gives the project team a clear focus and drives the other
phases of the project
 Plan 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
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

32
 Project Management Body of Knowledge Areas

Figure 1.8
33
Project Management Body of Knowledge Areas

34
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!

35