Information Technology Project
Management – Fifth Edition
By Jack T. Marchewka
Northern Illinois University
2-1
Copyright 2015 John Wiley & Sons, Inc.
Project Methodologies and Processes
Chapter 2
2-2
Copyright 2015 John Wiley & Sons, Inc.
Introduction

Project Methodology





A strategic-level plan for managing and controlling the
project
Game plan for implementing project and product lifecycles
Recommends phases, processes, tools, and techniques for
supporting an IT project
Must be flexible and include “best practices” learned from
experiences over time.
Can be


2-3
Traditional (e.g., Waterfall)
Agile (e.g., XPM, SCRUM)
Copyright 2015 John Wiley & Sons, Inc.
Project Methodology


The step-by-step activities, processes, tools, quality
standards, controls, and deliverables that are defined
for a project.
Provides a systematic way to plan, manage, and
execute the work to be completed by prescribing
phases, processes, tools, and techniques to be
followed.
2-4
Copyright 2015 John Wiley & Sons, Inc.
Advantages of using a methodology

Provide the project team with a game plan for implementing
the project and product life cycles



Focus on the tasks at hand, instead of always worrying about what
they are supposed to do next.
Provides a common language that allows the project team,
project sponsor, and others within the organization to
communicate more effectively.
Enables management to compare different projects more
objectively so they can make better-informed and more
objective decisions with respect to which projects get selected
and whether funding should continue to support a particular
project.
2-5
Copyright 2015 John Wiley & Sons, Inc.
The Project Life Cycle
Collection of logical stages or phases that
 maps the life of a project
 from its beginning, through its middle,
to its end,
 to define, build, and deliver the product.
2-6
Copyright 2015 John Wiley & Sons, Inc.
Project Phases

Phase Exits, Stage Gates, Kill Points




Projects should be broken up into phases to make the project more
manageable and to reduce risk.
Kill points are the phase-end review of key deliverables
Allows the organization to evaluate project performance and take
immediate action to correct errors or problems or not proceed to the
next phase
Fast Tracking



Starting the next phase of a project before approval is obtained for
the current phase
Can be used to reduce the project schedule
Can be risky and should only be done when the risk is acceptable
2-7
Copyright 2015 John Wiley & Sons, Inc.
Figure 2.1 – A Generic Project Life Cycle
2-8
Copyright 2015 John Wiley & Sons, Inc.
Project Life Cycle – Define and Plan

Define Project Goal


The project goal should be focused on providing business value to
the organization
 Provides a clear focus and drives the other phases of the project
 Tells us how we will know if this project is successful given the
time, money, and resources invested
Alternatives that would allow the organization to meet its goal are
identified.
 The costs and benefits, as well as feasibility and risk, of each
alternative are analyzed.
 A specific alternative is recommended for funding.
 The project’s goal and the analysis of alternatives that support the
goal are summarized in a deliverable called the business case.
2-9
Copyright 2015 John Wiley & Sons, Inc.
Project Life Cycle – Define and Plan

Plan Project

Project Objectives



Resources


Include scope, schedule, budget, and quality.
Define what work needs to be completed, when it needs to be completed, how
much it will cost to complete, and whether the work is acceptable to specific
stakeholders.
Resources are needed to complete the project work and include such things as
people, facilities, and technology.
Controls


A great deal of managing a project includes ensuring that the project goal and
objectives are being met and resources are used efficiently and effectively.
Risk, change, and communication among the project stakeholders must be
proactively managed throughout the project.
2-10
Copyright 2015 John Wiley & Sons, Inc.
Project Life Cycle – Execute, Close, and Evaluate

Execute Project Plan





Manage the project scope, schedule, budget, and people to ensure the
project achieves its goal
Progress must be documented and compared to the baseline plan
Project performance must be communicated to all of the stakeholders
At the end of this phase, the team implements or delivers a completed
product, service, or information system to the organization.
Close and Evaluate Project




Ensures that all of the work is completed as planned
Final project report and presentation to the client
Postmortem review
Lessons learned and best practices documented and shared
2-11
Copyright 2015 John Wiley & Sons, Inc.
Figure 2.2 – The PMBOK® Guide – The
10 Project Management Knowledge Areas
2-12
Copyright 2015 John Wiley & Sons, Inc.
PMBOK® Guide – The 10 Project Management
Knowledge Areas
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
2-13
Project integration management
Project scope management
Project time management
Project cost management
Project quality management
Project human resource management
Project communications management
Project risk management
Project procurement management
Project stakeholder management
Copyright 2015 John Wiley & Sons, Inc.
The 10 Project Management Knowledge Areas

Integration Management


Focuses on coordinating the project plan’s development,
execution, and control of changes.
Scope Management


Provides assurance that the project’s work is defined
accurately and completely and that it is completed as
planned.
Includes ways to ensure that proper scope change
procedures are in place.
.
2-14
Copyright 2015 John Wiley & Sons, Inc.
The 10 Project Management Knowledge Areas

Time Management



Important for developing, monitoring, and managing the
project’s schedule.
It includes identifying the project’s phases and activities and
then estimating, sequencing, and assigning resources for each
activity to ensure that the project’s scope and objectives are
met.
Cost Management

Cost management assures that the project’s budget is
developed and completed as approved.
2-15
Copyright 2015 John Wiley & Sons, Inc.
The 10 Project Management Knowledge Areas

Quality Management


Human Resources Management?


Focuses on planning, developing, and managing a quality
environment that allows the project to meet stakeholder needs
or expectations.
Focuses on creating and developing the project team as well
as understanding and responding appropriately to the
behavioral side of project management.
Communications Management

Entails communicating timely and accurate information about
the project to the project’s stakeholders.
2-16
Copyright 2015 John Wiley & Sons, Inc.
The 10 Project Management Knowledge Areas

Risk Management


Procurement Management


Concerned with identifying and responding appropriately to
risks that can impact the project.
Projects often require resources (people, hardware, software,
etc.) that are outside the organization. Procurement
management makes certain that these resources are acquired
properly.
Stakeholder Management

Focuses on identifying project stakeholders to better understand
their expectations or interests, and then developing appropriate
strategies for communication and managing potential conflicts.
2-17
Copyright 2015 John Wiley & Sons, Inc.
Figure 2.3 – PMBOK® Project Management
Process Groups
2-18
Copyright 2015 John Wiley & Sons, Inc.
The Five PMBOK® Project Management
Process Groups

A process is “a set of interrelated actions and activities performed
to achieve a pre-specified product, result, or service”.


Processes are an integral component of projects



In other words, a process is something you do to achieve a result.
They support all of the activities necessary to plan, create, and manage
all of the projects activities
Project management processes are different from the PLC phases
because they are actions or tasks to initiate, plan, execute, monitor and
control, and close a project as well as interact with the project
management knowledge areas.
PMBOK outlines five process groups

The groups overlap within and between the phases of the project as the
output of one process group within a phase becomes the input for a
process group in the next phase
2-19
Copyright 2015 John Wiley & Sons, Inc.
The Five PMBOK® Project Management Process Groups
Initiating processes
1.

Defining and authorizing a project or project phase
Planning processes
2.

Devising and maintaining a workable scheme to ensure that the project
addresses the organization’s needs
Executing processes
3.

Coordinating people and resources to carry out the various plans and
produce the products, services or results of the project or phase
Monitoring and controlling processes
4.

Regularly measuring and monitoring progress to ensure that the project
objectives are met
Closing processes
5.

Formalizing acceptance of the project or phase, closing out contracts,
documenting lessons learned
2-20
Copyright 2015 John Wiley & Sons, Inc.
PRINCE2® PRojects IN Controlled Environments

Nonproprietary PM methodology developed for
government projects in the UK



Now used worldwide by 20,000 public and private organization
Follows the PLC and provides stakeholders with a common
language and approach to managing projects of all sizes and types
Key features of PRINCE2





Focus on business justification
Defined organization structure for the project management team
Product-based planning approach
Emphasis on dividing the project into manageable and
controllable stages
Flexibility that can be applied at a level appropriate to the project.
2-21
Copyright 2015 John Wiley & Sons, Inc.
PRINCE2®

Aim of PRINCE2®?


Ensure that projects are well-thought out in the beginning,
well-managed throughout, and organized until the end.
Role of the Project Board



2-22
A Project Board is created and is accountable and
responsible for managing, monitoring, and controlling the
project activities to ensure that the project achieves the value
envisioned in the business case.
It also makes important decisions such as change requests
and whether the project should continue.
The Project Board is accountable for the project’s success or
failure.
Copyright 2015 John Wiley & Sons, Inc.
PRINCE2®

The Project Board may have up to eight people and includes
three important roles: a customer, a senior user, and a senior
supplier



2-23
The customer can be a customer, client, or executive sponsor who
represents the business interests of the organization.
The senior user represents the interests of the users or
stakeholders who will use the project’s product in order to bring
the expected value or benefits to the organization.
The senior supplier represents the suppliers or specialists who
provide the skills or resources needed to deliver the project’s
product.
Copyright 2015 John Wiley & Sons, Inc.
PRINCE2® – The Seven Processes
2-24
Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Seven (7) Processes
1.
Start Project

2.
Initiate Project

3.
This is a relatively short process that is focused on developing a
project brief or document that provides business justification for
the project.
Develop the project brief into a more detailed business case,
which is a key document that lays a foundation for all important
project decisions.
Direct Project

2-25
The Project Board’s overall activities are defined so that it can
direct the project successfully throughout each stage up through
the project’s closure.
Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Seven (7) Processes
4.
Control Stage

5.
During this process, the project manager’s day-to-day activities
are defined as well as how the project tasks will be controlled
and monitored.
Manage Product Delivery

2-26
This process ensures that the work packages are developed,
delivered, and approved as planned.
Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Seven (7) Processes
6.
Manage Stage Boundaries

7.
This includes the information or reporting mechanisms the
project manager will give to the Project Board in order to review
the status of the project and to determine whether continued
business justification for the project exists.
Close Project

2-27
This ensures that the project is completed in a controlled manner
if the project work is completed as planned or if it is no longer
viable. More specifically, activities are defined for the
acceptance of the project, as well as for the project manager to
archive documents and release project resources.
Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Themes
(guidelines to aid project goal achievement)
1.
Business Case


2.
Although the business case is an important PRINCE2® process,
its importance is also underscored as a theme that asks the
questions, “Why should this project be funded?” and “Why
should this project continue to be funded?”
It is a key document that not only justifies the initiation of a
project, but also ensures that the project can deliver its intended
value.
Organization

The organization theme attempts to answer the question, “Who
is involved with the project?” Under this theme, roles,
responsibilities, and accountabilities are defined.
2-28
Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Themes
(guidelines to aid project goal achievement)
3.
Risk

4.
All projects entail elements of risk, and the risk theme attempts
to manage uncertainty by answering the question, “What if . . .
.?” The approach to managing risk under PRINCE2® includes
identifying, assessing, and managing risk systematically and
proactively.
Quality

The quality theme attempts to ensure that the project is not only
completed on time and within budget, but that it also is
completed within standards so that the product fits its intended
use or purpose
2-29
Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Themes
(guidelines to aid project goal achievement)
5.
Planning

6.
The planning theme provides clear communication by attempting
to answer the questions, “Who does what?” and “When will it get
done?” Plans also provide control for the delivery of the project’s
product and to determine whether the cost, time, quality, risk,
work performance targets are achievable by providing a reference
point to measure progress against.
Change
Often changes are required to the project’s plans and target
objectives. Requests for changes can come from any of the project
stakeholders, so a systematic way to document, manage, and
decide whether proposed changes are necessary is warranted.
Subsequently, the change theme attempts to manage and control
changes to the project as they occur.
2-30

The PRINCE2® – Themes
(guidelines to aid project goal achievement)
7.
Progress

Metrics provide a means to measure a project’s achievement and
forecast whether the project’s progress is going according to the
approved plan. The progress theme attempts to answer the
questions, “Where is the project now?” and “Where will it end
up?”
2-31
The PRINCE2® – Principles
(Universal guidance for all projects)
1.
Business Case Driven

2.
The business case is a key document that is developed
at the beginning of the project and must be continually
justified throughout. Therefore, it is a key driver for
starting the project and for continued funding of the
project.
Product Focus

2-32
Projects are not just a series of activities or tasks, but
rather are undertaken to produce a product. PRINCE2®
projects emphasize the design and delivery of a quality
product.
Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Principles
(Universal guidance for all projects)
3.
Lessons Learned

4.
PRINCE2® is based on proven best practices.
Therefore, documented experiences in terms of lessons
learned are an important component for the PRINCE2®
methodology that are sought throughout the life of the
project.
Manage the Stage

2-33
At each stage of the project, the Project Board reviews
the project’s progress in comparison to the business
case. Each stage is planned, monitored, and controlled.
Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Principles
(Universal guidance for all projects)
5.
Adapt to the Project

6.
Manage by Exception

2-34
The PRINCE2® methodology can be tailored to
projects large or small. The methodology can be scaled
to the size of the project and should be flexible in
terms of the risks and environment unique to the
project.
Tolerances are defined and used to empower project
stakeholders by allowing them to make decisions
without having to ask for approval from the next
higher level of authority.
Copyright 2015 John Wiley & Sons, Inc.
The PRINCE2® – Principles
(Universal guidance for all projects)
7.
Accountability




2-35
PRINCE2® projects should have clear roles and
responsibilities.
Stakeholders need to know their role as well as everyone
else’s.
The Project Board includes executive sponsorship that
defines the project’s objectives and ensures that the project
remains viable.
Internal or external suppliers provide resources, skills, or
the knowledge to deliver the project’s products, while users
represent those stakeholders who will benefit from the
delivery of the final product.
Copyright 2015 John Wiley & Sons, Inc.
PMBOK vs PRINCE2

PRINCE2 and PMBOK are not conflicting or competitive or
mutually exclusive.



PMBOK’s strength is in teaching the knowledge base of the project
management profession
PRINCE2’s strength is in setting out a standard approach to running a
project.
Both PRINCE2 and PMBOK fall short of doing both of these to the
same degree. In this sense they are complementary and should and
can be used as such;



36
PRINCE2 as a supplement to the body of knowledge \
PMBOK as a knowledge base upon which to implement PRINCE2
There should be a continuous tailoring of your approach based on the size,
type and complexity of the project, and any existing organizational project
management methodology.
Copyright 2010 John Wiley & Sons, Inc.
PRINCE2 vs PMBOK
PRINCE2`
PMBOK
A process based project
management methodology
A knowledge based approach to
project management
A series of management processes
defining what must be done, when
and how it must be done and by
whom over the life of a project
Describes core practices and a wider
range of techniques that can be
applied to manage a project
Prescriptive, but tailorable
Descriptive
Defines the roles of everyone
involved in a project
Focuses on the project manager's
role
37
Copyright 2010 John Wiley & Sons, Inc.
Figure 2.5 The Systems Development Life Cycle
2-38
Copyright 2015 John Wiley & Sons, Inc.
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.
39
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
40
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.
41
Implementing the SDLC

Defines all of the subphases and deliverables
associated with the Execute and Control Project
Management Life Cycle phase.

Structured Approach to Systems Development


Waterfall Method
Iterative Development




Rapid Applications Development (RAD)
Prototyping
Spiral Development
Extreme Programming
2-42
Copyright 2015 John Wiley & Sons, Inc.
Figure 2.7 – The Waterfall Model
2-43
Copyright 2015 John Wiley & Sons, Inc.
Waterfall Method

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.
44
Waterfall Method

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.
45
Waterfall Method - Disadvantages


Critics of the structured approach to systems
development argue that it takes too long to develop
systems and that this approach 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.
And if they do, those requirements will most likely
change later on.
46
Waterfall Method - Advantages


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.
Provides a solid structure that can minimize wasted effort,
the Waterfall model may work well when the project team
is inexperienced or less technically competent.


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.
47
Waterfall Method - Disadvantages


Users tend to be involved at three main points during a
Waterfall project: 1) when they are needed to define the
requirements (i.e., features and functionality) of the
software, 2) when users ask for changes to the
requirements, and 3) at the end of the project when the
software is delivered.
Many times this has resulted in strained relationships
between users and developers.

Users may not have articulated everything they want, and
developers become resistant to making any changes later on.
48
Waterfall Method - Disadvantages


Adding new requirements or changing software that has
already been written adds to the schedule and cost of
the project. As a result, a new system may be delivered
that does not meet the users’ needs.
Another issue is that the potential value of the project
can only be attained at the end of the project when the
system with all its defined requirements is delivered.
For many projects, this could be months or years.
49
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.
50
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.
51
RAD
52
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.
53
Iterative Systems Development
54
Iterative Systems Development

Spiral development approach first proposed by Barry Boehm
(1988), breaks up a software project into a number of miniprojects 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.
55
Spiral Development
56
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.
57
Iterative Systems Development

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.
58
Iterative Systems Development
 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
59
Agile Software Development



The term Agile today is an umbrella term that
includes a number of approaches, methods, or ways to
develop products or systems. Agile approaches focus
on speed and flexibility rather than a rigid
development structure.
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
60
Agile Software Development
61
The Agile Manifesto
2-62
Copyright 2015 John Wiley & Sons, Inc.
Agile System Development
63
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.
64
SCRUM Software Development
65
The Relationship Between the PLC & SDLC




The project life cycle (PLC) focuses on the phases,
processes, tools, knowledge and skills for managing a
project
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
66
Figure 2.6 – The Project Life Cycle (PLC) and
the Systems Development Life Cycle (SDLC)
2-67
Copyright 2015 John Wiley & Sons, Inc.
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
68
Agile Systems Development Themes




Four Themes – Customer, Product, Project Team and
Performance
An Agile team should include business people and technical
people who are motivated, self-organizing, and mutually
accountable.
A team should be given the support and resources it needs
and then trusted to get the job done.
People who work long hours may burn out, get tired,
become less motivated, and tend to make more mistakes.


Therefore, the team should be able to work at a pace that is
constant and sustainable.
The team should have the authority to make adjustments when
needed.
Copyright 2015 John Wiley & Sons, Inc.
2-69
Learning Cycle

Learning cycles are a useful tool that can be
used throughout the project life cycle
regardless whether the project team follows
Waterfall or Agile.
 More specifically, they provide a way to
resolve ambiguous situations through the
repeated pattern of thinking through a
problem.
 A team learning cycle has four phases
2-70
Copyright 2015 John Wiley & Sons, Inc.
Figure 2.10 – A Learning Cycle
2-71
Copyright 2015 John Wiley & Sons, Inc.
Understand and frame the problem

At the beginning of a project, the team members’
understanding may be quite general, or they may feel that
they really do not understand the challenge assigned to
them.


Unfortunately, few people are willing to admit that they do not
have all the answers or that their understanding of the team’s
challenge is limited.
On the other hand, other members of the team may approach
the project with a high degree of certainty—that is, they may
act as though they know what the solution is and, therefore, the
team just needs to work out the details of how to go about
implementing the solution.
2-72
Copyright 2015 John Wiley & Sons, Inc.
Understand and frame the problem



Opinions are often accepted without question and can result in
erroneous assumptions that lead the project team in the wrong
direction or keep the team from getting at the real problem.
Moreover, there is often pressure for the team to take immediate
action so that the project can be completed on time and within
budget.
Example: A plan sponsor tells the project team that the
company has too much inventory on hand and the cost is
becoming exorbitant. He suggests that an information system
will solve his problems.

Team members can accept the plan sponsor’s solution or question it
and look for alternative solutions which may provide a better result.
2-73
Copyright 2015 John Wiley & Sons, Inc.
Team Learning Cycles over the Project Life Cycle
An entire project can be viewed as a series
of learning cycles.
Each cycle provides the opportunity to
challenge framing assumptions, create new
understanding & find radical solutions
2-74
Copyright 2015 John Wiley & Sons, Inc.
Purpose of Lessons Learned

An entire project can be viewed as a series of learning cycles.





Understand & Frame: An initial team meeting can examine the
original problem or challenge assigned to the team.
Plan: During that meeting, the team can develop an initial action
plan.
Act: Between meetings, the members of the team can then carry out
their assigned tasks for testing assumptions or gathering
information.
Reflect & Learn: At the next meeting, the team can reflect on what
it has learned, document the lessons learned, and then start the
beginning of a new cycle.
Each cycle should be used to challenge the framing of the problem
and create new opportunities for learning.
2-75
Copyright 2015 John Wiley & Sons, Inc.
Purpose of Lessons Learned



For example, the team may find out that the high inventory
levels are due to an obsolete product or one no longer in style.
No information system will help reduce such inventory
By not questioning the plan sponsor, the wrong course of
action would have been taken and no real reduction in
inventory would have occurred despite the investment of time
and money.
2-76
Copyright 2015 John Wiley & Sons, Inc.
An Example of a Team Learning Record
What we know
(Facts)
What we think we know
(Assumptions)
What we don’t know
(Questions to be Answered)
Company has too much
inventory on hand
It may be an efficiency
problem
Why are inventory levels so
high?
Cost of maintaining current
inventory is becoming
prohibitive
Management believes a new
information system will
improve efficiency and
therefore lower inventory
levels
What are the current levels of
inventory?
Inventory turnover needs to
be increased
2-77
What is the desired level of
inventory?
Copyright 2015 John Wiley & Sons, Inc.
An Example of an Action Plan
Who?
Does What?
By When?
Shedelle and Steve
Interview sales team to understand
past, current, and future trends for
the company’s product.
Tuesday
Provide a detailed count of the
current physical inventory on
hand.
Thursday
Research potential inventory
management system commercial
packages
Thursday
Myra
Corean
Steve
2-78
Research average inventory levels
for the industry
Copyright 2015 John Wiley & Sons, Inc.
Wednesday
Assessing Team Learning

Teams do not always begin and end learning cycles at
each meeting
 Some learning cycles can take more than one
meeting and some can be accomplished in a shorter
time if face-to-face meetings are not needed, thus …
 Three dimensions can be used to assess team
learning

79
Speed – the number of learning cycles completed
 The opportunity to learn can be increased if a team
can complete more cycles in a given amount of time
Copyright 2010 John Wiley & Sons, Inc.
Assessing Team Learning

Depth – the number of learning cycles does not
guarantee learning; it must be accompanied by a
deepening of understanding


Breadth – the impact the project has on the organization


80
How well the team can dig beneath the surface in order to
get at the root of the problem
Also, does the learning that has taken place within the
team stay within the team or is it shared and used
throughout the organization
The “inventory problem” could turn out to cross several
functional or departmental boundaries
Copyright 2010 John Wiley & Sons, Inc.
Assessing Team Learning
2-81
Copyright 2015 John Wiley & Sons, Inc.