Overview

• Project Methodologies and Processes introduces the concepts of

lifecycles, methodologies, and processes for managing and
developing the project’s product, service, or system. Overviews of
knowledge areas and processes associated with Project
Management Body of Knowledge (PMBOK®), as well as the core
principles, processes, and themes of the PRINCE2® methodology
are provided. This chapter also describes the waterfall method
and two common Agile approaches for developing the project’s
product or system. In addition, the concept of Learning Cycles is
introduced and can be used throughout the end of chapter case
assignments.
Objectives
• After completing this unit, you’ll be able to:
• Define what a methodology is and the role it serves
• Describe the Project Life Cycle (PLC)
• Describe the Project Management Body of Knowledge (PMBOK®) and be
familiar with its knowledge areas and process groups
• Describe PRINCE2® and be familiar with its core principles, processes,
and themes
• Describe teh Systems Development Life cycle (SDLC)
• Describe the Waterfall method for developing the project’s product or
system as well as two commonly used approaches called eXtreme
Programming (XP) and Scrum
• Describe and apply the concept of Learning Cycles and lessons learned
Contents
• Introduction
• The Project Life Cycle
• The Project Management Body of Knowledge (PMBOK®)
• Project Processes
• PRINCE2®
• The Systems Development Life Cycle (SDLC)
• Learning Cycles and Lessons Learned
Introduction
• Project Methodologies - plan, manage, execute the work to be
completed by prescribing phases, processes, tools, and techniques
to be followed.
• The advantages:
• focus on the product or system
• understand a stakeholders role
• documented experiences
• Compared past, present, and future project
• Saving time
The Project Life Cycle

Figure 1. A Generic Project Life Cycle

The Project Life Cycle
1. Define Project Goal
• Project is initiated – new idea
• Explicit the project’s envisioned business value
• Answer the question:
• “How will we know if this project is successful given the time, money, and
resources invested?”

2. Plan Poject
• Project Objectives - scope (the project work), schedule, budget, and
quality
• Resources - people, facilities, and technology
• Controls - ensuring that the project goal and objectives are being met
The Project Life Cycle
3. Execute Project Plan
• Approval of the project plan is required before moving to the execution
phase - design, development, and delivery
• Control planning phases

4. Close and Evaluate Project

• ensure that all of the work is completed -agreed to by the team, the
sponsor, or other stakeholders
The Project Life Cycle
• In addition, most projects seem to share the following characteristics:
• The effort - cost and staffing levels
• Risk and uncertainty
• The ability for stakeholders to influence the product’s features or
functionality
The Project Management Body of
Knowledge (PMBOK®) and PMI®
• What is a PMBOK®?
• What is a PMI®?
The Project Management
Knowledge

Figure 2. PMBOK® Knowldge Areas

Project Processes
• The PMBOK® Guide defines a process as “a set of interrelated
actions and activities performed to achieve a pre-specified
product, result, or service.
• Processes are an integral component of projects. They support all
of the activities necessary to plan, create, and manage a; of the
project activities.
Project Management Groups
Initiating

Closing Planning

Project
Management
Processes

Controlling Executing

1 2 3 4 5
Conceptualize Develop Execute and Close project Evaluate project
and initialize project charter control project success
and plan
Figure 3. PMBOK® Project Management Process Groups
Project Management Groups
• Initiating –define how the project and the methodology
• Planning –scope, activity, resource, cost & schedule (estimating), and
procurement.
• Executing –focuses on integrating people and resources to carry out
the planned activities of project plan or phase. During the execute and
control phase, the SDLC and associated project methodology play an
important role in developing the product or system.
• Monitoring and Controlling –managing and measuring progress
toward the project’s goal and planning. Supporting project
management processes include scope control, change control,
schedule control, budget control, quality control, and a
communications plan.
• Closing –accepting the project’s product, service, or system so that
the project or phase can be brought to an orderly close
PRINCE2®

•What is (PRINCE2®) ?
The PRINCE2® Methodology
The Systems Development Life
Cycle (SDLC)
Planning

Maintenance
Analysis
and Support

Implementa-
Design
tion

Figure 4. SDLC
The Systems Development Life
Cycle (SDLC)
• Planning –ensures that the goal, scope, budget, schedule,
technology, and system development processes, methods, and
tools are in place.
• Analysis –problem or opportunity more fully. Here the specific
needs and requirements for the new system are identified and
documented.
• Design –uses the requirements and “to be” logical models as input
for designing the architecture to support the new information
system - network, hardware configuration, databases, user
interface, and application programs.
The Systems Development Life
Cycle (SDLC)
• Implementation development or construction of the system,
testing, and installation - training, support, and documentation
must be in place.
• Maintenance and Support – Although maintenance and support
may not be a true phase of the current project, it is still an
important consideration. Once the system has been implemented,
it is said to be in production.
The PLC and SDLC
• The project life cycle (PLC) - focuses on the phases, processes,
tools, knowledge, and skills for managing a project
• Systems development life cycle (SDLC) - focuses on creating and
implementing the project’s product – the information system.
The PLC and SDLC

Figure 5. The PLC and SDLC

Implementing the SDLC
• The chosen method or approach depends on the size and
complexity of the project as well as the experience and skills of
the project team.
• Today, an IT project will follow a structured development
approach like Waterfall or an iterative development approach
called Agile.
Waterfall
• A structured approach to systems development has been around
since the 1960s and 1970s, when large mainframe applications
were developed.
• 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.
Waterfall

Figure 6. The Waterfall Model

Waterfall
• 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.
Waterfall
• 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.
• 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.
Waterfall
• 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.
• 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.
Agile Systems Development
• The term Agile today is an umbrella term that includes a number
of approaches, methods, or ways to develop products or systems.
• In 1986, Hirotaka Takuechi and Ikujiro Nonaka’s paper suggest
that how organizations create new products needs to change
because quality and low cost is not enough to remain competitive.
Organizations must focus on speed and flexibility. A number of IT
experts saw this as a new way to develop software. While a
structured approach fit many engineering projects like the
construction of buildings or early computer applications, it was
clearly no longer the only way to build systems in a modern world.
Systems had to built in weeks, instead of months or years.
• In 2001, seventeen IT experts gathered for a conference in
Snowbird, Utah to discuss new way to develop software. The
group came up with Agile Manifesto and twelve principles to
describe how teams can transition to Agile.
Agile Systems Development
• The Agile Manifesto value:
• Individuals and Interactions over Processes and Tools – As stated in
manifesto, it’s not that processes and tools are important, it’s that people
and interactions are more important. Under Agile, the development team
is given autonomy to choose the best way to do the work for a given
project. This requires multidisciplinary teams that are motivated, self-
organizing, and able to communicate effectively.
• Working Software over Comprehensive Documentation – if a project has
ten requirements and five of the highest ranked requirement are
designed, tested and documented as a working product, then you could
say the project is 50 percent complete. Moreover, project team members
are often required to document the work they complete as a way to track
the progress of the project.
Agile Systems Development
• Customer Collaboration over Contract Negotiation – A subtle but
important change from previous approaches to developing software is
that products are developed for customers. While the term “user” still
applies as in “people who use the product or system” practitioners of
Agile tend to use the richer term “customer” instead. These requirements
can be viewed as a contract for the design of software features that are
subsequently, coded, tested, and documented.
• Responding to Change over Following a Plan – Under a more structured
approach to software development, change is viewed as something that
must be managed and controlled; otherwise, the project spins out of
control.
Agile Systems Development
• The principles can be summarized into four themes or categories:
• Customer – Agile takes a strong customer focus, and the customer could
be internal or external to the organization.
• Product – Only working software brings value, but it must be delivered in
the shortest time.
• Project Team – An Agile team should include business people and
technical people who are motivated, self-organizing, and mutually
accountable.
• Performance – The team should have the authority to make adjustments
when needed.
Waterfall Versus Agile
• First, many projects have been successful and many have failed
following Waterfall.
• Second, many projects have been successful and many have failed
following Agile.
• There are times when Waterfall will be the right choice, just as
there will be times when the project should follow Agile. The old
saying to choose the right tool for the job is appropriate.
• On the other hand, it’s important to know what you’re doing.
Many project teams have started out “doing Agile”, but didn’t
follow it fully or reverted back to what they’re used to when faced
with a stressful challenge.
• The short answer is that no approach works in all situations.
Learning Cycles and Lessons
Learned
• 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
1. Understand and frame the problem
2. Plan
3. Act
4. Reflect and learn
 Learning Cycles and Lessons
Learned

Figure 7. A Learning Cycle

1. 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.
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. Plan
• This is include what team members are trying to accomplish and
how they are going to go about it.
• The team can brainstorm what if knows (the facts), what it thinks
it knows (assumptions), and what it doesn’t know (questions to
be answered). Early in the project, a team may have more
questions and assumptions than facts. This is to be expected
because the team may not fully understand the problem or
challenge.
• The table in next slide shows an example of team learning record.
After meeting with the sponsor and touring the warehouse, the
team may list the facts, assumptions, and questions to be
answered.
 2. Plan
What we know What we think we know What we don’t know
(Facts) (Assumptions) (Questions to be Answered)

Company has too much
inventory on hand
Cost of maintaining current
inventory is becoming
prohibitive
It may be an efficiency Why are inventory levels so
problem high?
Management believes a new What are the current levels of
information system will inventory?
improve efficiency and
therefore lower inventory
levels

Inventory turnover needs to What is the desired level of

be increased inventory?
3. Act
• Once the project team identifies what it knows, what it thinks it
knows, and what it needs to find out, it can create a plan of action.
• Team members can volunteer or be assigned to specific tasks that
require testing assumptions or learning answers to questions.
• Documenting who does what by when also provides a tool for
accountability.
• The purpose of these actions is to confirm or disconfirm
assumptions and learn answers to questions the team does not
know.
• Redding suggests that what teams do outside of meetings is just
as important as the meeting itself because only by acting do teams
have the opportunity to learn.
3. Act
Who? Does What? By When?

Shedelle and Steve Interview sales team to understand Tuesday

past, current, and future trends for
the company’s product.

Myra Provide a detailed count of the Thursday

current physical inventory on
hand.

Corean Research potential inventory Thursday

management system commercial
packages

Steve Research average inventory levels Wednesday

for the industry
4. Reflect and Learn
• To be effective, this reflection must take place in an environment
of openness, honesty, and trust.
• Once the team has a chance to meet and reflect on the information
it has acquired, the team can document what it has learned.
• Redding suggest that the team answer the following questions:
• What do we know now that we didn’t know before?
• Have we encountered any surprises? Have we gained any new insights? If
so, what were they?
• What previous assumptions have been supported or refuted by what we
have learned so far?
• How does the team fell the project is progressing at this point?
• How effective has the team been so far?
Learning Cycles and Lessons
Learned
• An entire project can be viewed as a series of learning cycles.
• An initial team meeting can examine the original problem or
challenge assigned to the team.
• During that meeting, the team can develop an initial action plan.
Between meetings, the members of the team can then carry out
their assigned tasks for testing assumptions or gathering
information.
• At the next meeting, the team can reflect on what it has learned,
documented 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.
Learning Cycles and Lessons
Learned

Figure 8. Team Learning

Unit Summary
• You should now be able to:
• Define what a methodology is and the role it serves
• Describe the Project Life Cycle (PLC)
• Describe the Project Management Body of Knowledge (PMBOK®) and be
familiar with its knowledge areas and process groups
• Describe PRINCE2® and be familiar with its core principles, processes,
and themes
• Describe teh Systems Development Life cycle (SDLC)
• Describe the Waterfall method for developing the project’s product or
system as well as two commonly used approaches called eXtreme
Programming (XP) and Scrum
• Describe and apply the concept of Learning Cycles and lessons learned