The Project Life Cycle refers to a logical sequence of activities to accomplish the

project’s goals or objectives. Regardless of scope or complexity, any project goes through a
series of stages during its life. There is first an Initiation or Birth phase, in which the outputs and
critical success factors are defined, followed by a Planning phase, characterized by breaking down
the project into smaller parts/tasks, an Execution phase, in which the project plan is executed, and
lastly a Closure or Exit phase, that marks the completion of the project. Project activities must be
grouped into phases because by doing so, the project manager and the core team can efficiently
plan and organize resources for each activity, and also objectively measure achievement of goals
and justify their decisions to move ahead, correct, or terminate. It is of great importance to
organize project phases into industry-specific project cycles. Why? Not only because each industry
sector involves specific requirements, tasks, and procedures when it comes to projects, but also
because different industry sectors have different needs for life cycle management methodology.
And paying close attention to such details is the difference between doing things well and excelling
as project managers.

Diverse project management tools and methodologies prevail in the different project cycle phases.
Let’s take a closer look at what’s important in each one of these stages:

1) Initiation
In this first stage, the scope of the project is defined along with the approach to be taken to
deliver the desired outputs. The project manager is appointed and in turn, he selects the team
members based on their skills and experience. The most common tools or methodologies used in
the initiation stage are Project Charter, Business Plan, Project Framework (or Overview), Business
Case Justification, and Milestones Reviews.

2) Planning
The second phase should include a detailed identification and assignment of each task until the
end of the project. It should also include a risk analysis and a definition of a criteria for the
successful completion of each deliverable. The governance process is defined, stake holders
identified and reporting frequency and channels agreed. The most common tools or methodologies
used in the planning stage are Business Plan and Milestones Reviews.

3) Execution and controlling

The most important issue in this phase is to ensure project activities are properly executed and
controlled. During the execution phase, the planned solution is implemented to solve the problem
specified in the project's requirements. In product and system development, a design resulting in
a specific set of product requirements is created. This convergence is measured by prototypes,
testing, and reviews. As the execution phase progresses, groups across the organization become
more deeply involved in planning for the final testing, production, and support. The most common
tools or methodologies used in the execution phase are an update of Risk Analysis and Score
Cards, in addition to Business Plan and Milestones Reviews.

4) Closure
In this last stage, the project manager must ensure that the project is brought to its proper
completion. The closure phase is characterized by a written formal project review report containing
the following components: a formal acceptance of the final product by the client, Weighted Critical
 Measurements (matching the initial requirements specified by the client with the final delivered
product), rewarding the team, a list of lessons learned, releasing project resources, and a formal
project closure notification to higher management. No special tool or methodology is needed
during the closure phase.

Other resources
• Project templates and Project forms to help you successfully deliver your projects
Method123 provides a suite of powerful and affordable Project Management Templates focused
on making your project more productive and profitable as well as achieve Project Management
Objectives.
Read more: Method123 templates

• PDCA cycle (Deming wheel)

The PDCA Cycle (Plan, Do, Check, Act), commonly known as the Demming wheel, is a well
known model for CPI, or continual process improvement.

Project Management Life Cycle

The Project Management Life Cycle has four phases: Initiation, Planning, Execution and
Closure. Each project life cycle phase is described below, along with the tasks needed to complete
it. You can click the links provided, to view more detailed information on the project management
life cycle.

• Develop a Business Case

• Undertake a Feasibility Study
• Establish the Project Charter
• Appoint the Project Team
• Set up the Project Office
• Perform Phase Review

• Create a Project Plan

• Create a Resource Plan
• Create a Financial Plan
• Create a Quality Plan
• Create a Risk Plan
• Create an Acceptance Plan
• Create a Communications Plan
• Create a Procurement Plan
• Contract the Suppliers
• Define the Tender Process
• Issue a Statement of Work
• Issue a Request for Information
• Issue a Request for Proposal
 • Create Supplier Contract
• Perform Phase Review

• Build Deliverables
• Monitor and Control
• Perform Time Management
• Perform Cost Management
• Perform Quality Management
• Perform Change Management
• Perform Risk Management
• Perform Issue Management
• Perform Procurement Management
• Perform Acceptance Management
• Perform Communications Management

• Perform Project Closure

• Review Project Completion

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in
systems engineering, information systems and software engineering, is the process of creating
or altering systems, and the models and methodologies that people use to develop these
systems. The concept generally refers to computer or information systems.

In software engineering the SDLC concept underpins many kinds of software development
methodologies. These methodologies form the framework for planning and controlling the
creation of an information system[1]: the software development process.
Contents
[hide]

• 1 Overview
• 2 History
• 3 Systems development phases
o 3.1 System analysis
o 3.2 Design
o 3.3 Testing
o 3.4 Operations and maintenance
• 4 Systems Analysis and Design
• 5 Systems development life cycle topics
o 5.1 Management and control
o 5.2 Work breakdown structured organization
o 5.3 Baselines in the SDLC
o 5.4 Complementary to SDLC
• 6 Strengths and weaknesses
• 7 See also
• 8 References
• 9 Further reading

• 10 External links

[edit] Overview

Software Development Life Cycle (SDLC) is a process used by a systems analyst to develop
an information system, including requirements, validation, training, and user (stakeholder)
ownership. Any SDLC should result in a high quality system that meets or exceeds customer
expectations, reaches completion within time and cost estimates, works effectively and
efficiently in the current and planned Information Technology infrastructure, and is
inexpensive to maintain and cost-effective to enhance.[2]

Computer systems are complex and often (especially with the recent rise of Service-Oriented
Architecture) link multiple traditional systems potentially supplied by different software
vendors. To manage this level of complexity, a number of SDLC models have been created:
"waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and
"synchronize and stabilize".[3]

SDLC models can be described along a spectrum of agile to iterative to sequential. Agile
methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid
changes along the development cycle. Iterative methodologies, such as Rational Unified
Process and Dynamic Systems Development Method, focus on limited project scopes and
expanding or improving products by multiple iterations. Sequential or big-design-up-front
(BDUF) models, such as Waterfall, focus on complete and correct planning to guide large
projects and risks to successful and predictable results[citation needed]. Other models, such as
Anamorphic Development, tend to focus on a form of development that is guided by project
scope and adaptive iterations of feature development.
In project management a project can be defined both with a project life cycle (PLC) and an
SDLC, during which slightly different activities occur. According to Taylor (2004) "the
project life cycle encompasses all the activities of the project, while the systems development
life cycle focuses on realizing the product requirements".[4]

[edit] History

The Systems Life Cycle (SLC) is a type of methodology used to describe the process for
building information systems, intended to develop information systems in a very deliberate,
structured and methodical way, reiterating each stage of the life cycle. The systems
development life cycle, according to Elliott & Strachan & Radford (2004), "originated in the
1960s,to develop large scale functional business systems in an age of large scale business
conglomerates. Information systems activities revolved around heavy data processing and
number crunching routines".[5]

Several systems development frameworks have been partly based on SDLC, such as the
Structured Systems Analysis and Design Method (SSADM) produced for the UK government
Office of Government Commerce in the 1980s. Ever since, according to Elliott (2004), "the
traditional life cycle approaches to systems development have been increasingly replaced
with alternative approaches and frameworks, which attempted to overcome some of the
inherent deficiencies of the traditional SDLC".[5]

[edit] Systems development phases

This section needs additional citations for verification.
Please help improve this article by adding reliable references. Unsourced
material may be challenged and removed. (September 2010)

The System Development Life Cycle framework provides a sequence of activities for system
designers and developers to follow. It consists of a set of steps or phases in which each phase
of the SDLC uses the results of the previous one.

A Systems Development Life Cycle (SDLC) adheres to important phases that are essential
for developers, such as planning, analysis, design, and implementation, and are explained in
the section below. A number of system development life cycle (SDLC) models have been
created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and
synchronize and stabilize. The oldest of these, and the best known, is the waterfall model: a
sequence of stages in which the output of each stage becomes the input for the next. These
stages can be characterized and divided up in different ways, including the following[6]:

• Project planning, feasibility study: Establishes a high-level view of the

intended project and determines its goals.

• Systems analysis, requirements definition: Defines project goals into

defined functions and operation of the intended application. Analyzes end-
user information needs.

• Systems design: Describes desired features and operations in detail,

including screen layouts, business rules, process diagrams, pseudocode
and other documentation.
 • Implementation: The real code is written here.

• Integration and testing: Brings all the pieces together into a special
testing environment, then checks for errors, bugs and interoperability.

• Acceptance, installation, deployment: The final stage of initial

development, where the software is put into production and runs actual
business.

• Maintenance: What happens during the rest of the software's life:

changes, correction, additions, moves to a different computing platform
and more. This, the least glamorous and perhaps most important step of
all, goes on seemingly forever.

In the following example (see picture) these stage of the Systems Development Life Cycle
are divided in ten steps from definition to creation and modification of IT work products:

The tenth phase occurs when the system is disposed of and the task performed
is either eliminated or transferred to other systems. The tasks and work products
for each phase are described in subsequent chapters.[7]

Not every project will require that the phases be sequentially executed. However, the phases
are interdependent. Depending upon the size and complexity of the project, phases may be
combined or may overlap.[7]
[edit] System analysis

The goal of system analysis is to determine where the problem is in an attempt to fix the
system. This step involves breaking down the system in different pieces to analyze the
situation, analyzing project goals, breaking down what needs to be created and attempting to
engage users so that definite requirements can be defined.

Requirements analysis sometimes requires individuals/teams from client as well as service

provider sides to get detailed and accurate requirements; often there has to be a lot of
communication to and from to understand these requirements. Requirement gathering is the
most crucial aspect as many times communication gaps arise in this phase and this leads to
validation errors and bugs in the software program.

[edit] Design

In systems design the design functions and operations are described in detail, including
screen layouts, business rules, process diagrams and other documentation. The output of this
stage will describe the new system as a collection of modules or subsystems.

The design stage takes as its initial input the requirements identified in the approved
requirements document. For each requirement, a set of one or more design elements will be
produced as a result of interviews, workshops, and/or prototype efforts.

Design elements describe the desired software features in detail, and generally include
functional hierarchy diagrams, screen layout diagrams, tables of business rules, business
process diagrams, pseudocode, and a complete entity-relationship diagram with a full data
dictionary. These design elements are intended to describe the software in sufficient detail
that skilled programmers may develop the software with minimal additional input design.

[edit] Testing

The code is tested at various levels in software testing. Unit, system and user acceptance
testings are often performed. This is a grey area as many different opinions exist as to what
the stages of testing are and how much if any iteration occurs. Iteration is not generally part
of the waterfall model, but usually some occur at this stage. In the testing phase, the whole
system is tested one by one

Following are the types of testing:

• Defect testing
• Path testing
• Data set testing
• Unit testing
• System testing
• Integration testing
• Black box testing
• White box testing
• Regression testing
• Automation testing
• User acceptance testing
 • Performance testing

[edit] Operations and maintenance

The deployment of the system includes changes and enhancements before the
decommissioning or sunset of the system. Maintaining the system is an important aspect of
SDLC. As key personnel change positions in the organization, new changes will be
implemented, which will require system updates.

[edit] Systems Analysis and Design

The Systems Analysis and Design (SAD) is the process of developing Information Systems
(IS) that effectively use of hardware, software, data, process, and people to support the
company’s business objectives.

[edit] Systems development life cycle topics

[edit] Management and control

SDLC Phases Related to Management Controls.[8]

The Systems Development Life Cycle (SDLC) phases serve as a programmatic guide to
project activity and provide a flexible but consistent way to conduct projects to a depth
matching the scope of the project. Each of the SDLC phase objectives are described in this
section with key deliverables, a description of recommended tasks, and a summary of related
control objectives for effective management. It is critical for the project manager to establish
and monitor control objectives during each SDLC phase while executing projects. Control
objectives help to provide a clear statement of the desired result or purpose and should be
used throughout the entire SDLC process. Control objectives can be grouped into major
categories (Domains), and relate to the SDLC phases as shown in the figure.[8]
To manage and control any SDLC initiative, each project will be required to establish some
degree of a Work Breakdown Structure (WBS) to capture and schedule the work necessary to
complete the project. The WBS and all programmatic material should be kept in the “Project
Description” section of the project notebook. The WBS format is mostly left to the project
manager to establish in a way that best describes the project work. There are some key areas
that must be defined in the WBS as part of the SDLC policy. The following diagram
describes three key areas that will be addressed in the WBS in a manner established by the
project manager.[8]

[edit] Work breakdown structured organization

Work Breakdown Structure.[8]

The upper section of the Work Breakdown Structure (WBS) should identify the major phases
and milestones of the project in a summary fashion. In addition, the upper section should
provide an overview of the full scope and timeline of the project and will be part of the initial
project description effort leading to project approval. The middle section of the WBS is based
on the seven Systems Development Life Cycle (SDLC) phases as a guide for WBS task
development. The WBS elements should consist of milestones and “tasks” as opposed to
“activities” and have a definitive period (usually two weeks or more). Each task must have a
measurable output (e.x. document, decision, or analysis). A WBS task may rely on one or
more activities (e.g. software engineering, systems engineering) and may require close
coordination with other tasks, either internal or external to the project. Any part of the project
needing support from contractors should have a Statement of work (SOW) written to include
the appropriate tasks from the SDLC phases. The development of a SOW does not occur
during a specific phase of SDLC but is developed to include the work from the SDLC process
that may be conducted by external resources such as contractors and struct.[8]

[edit] Baselines in the SDLC

Baselines are an important part of the Systems Development Life Cycle (SDLC). These
baselines are established after four of the five phases of the SDLC and are critical to the
iterative nature of the model .[9] Each baseline is considered as a milestone in the SDLC.

• Functional Baseline: established after the conceptual design phase.

• Allocated Baseline: established after the preliminary design phase.
• Product Baseline: established after the detail design and development
phase.
 • Updated Product Baseline: established after the production construction
phase.

[edit] Complementary to SDLC

Complementary Software development methods to Systems Development Life Cycle (SDLC)

are:

• Software Prototyping
• Joint Applications Design (JAD)
• Rapid Application Development (RAD)
• Extreme Programming (XP); extension of earlier work in Prototyping and
RAD.
• Open Source Development
• End-user development
• Object Oriented Programming

Comparison of Methodology Approaches (Post, & Anderson 2006)[10]

Open Prototyp End

SDLC RAD Objects JAD
Source ing User

Standard
Control Formal MIS Weak Joint User User
s

Time Frame Long Short Medium Any Medium Short Short

One or
Users Many Few Few Varies Few One
Two

Hundred One or
MIS staff Many Few Split Few None
s Two

Transaction/ Transacti
Both Both Both DSS DSS DSS
DSS on

Interface Minimal Minimal Weak Windows Crucial Crucial Crucial

Documentati
In
on and Vital Limited Internal Limited Weak None
Objects
training

Integrity and In
Vital Vital Unknown Limited Weak Weak
security Objects

Reusability Limited Some Maybe Vital Limited Weak None

[edit] Strengths and weaknesses

Few people in the modern computing world would use a strict waterfall model for their
Systems Development Life Cycle (SDLC) as many modern methodologies have superseded
this thinking. Some will argue that the SDLC no longer applies to models like Agile
computing, but it is still a term widely in use in Technology circles. The SDLC practice has
advantages in traditional models of software development, that lends itself more to a
structured environment. The disadvantages to using the SDLC methodology is when there is
need for iterative development or (i.e. web development or e-commerce) where stakeholders
need to review on a regular basis the software being designed. Instead of viewing SDLC from
a strength or weakness perspective, it is far more important to take the best practices from the
SDLC model and apply it to whatever may be most appropriate for the software being
designed.

A comparison of the strengths and weaknesses of SDLC:

[10]
Strength and Weaknesses of SDLC

Strengths Weaknesses

Control. Increased development time.

Monitor Large projects. Increased development cost.

Systems must be defined up

Detailed steps.
front.

Evaluate costs and completion

Rigidity.
targets.

Hard to estimate costs, project

Documentation.
overruns.

Well defined user input. User input is sometimes limited.

Ease of maintenance.

Development and design

standards.

Tolerates changes in MIS

staffing.

An alternative to the SDLC is Rapid Application Development, which combines prototyping,

Joint Application Development and implementation of CASE tools. The advantages of RAD
are speed, reduced development cost, and active user involvement in the development
process.

[edit] See also

• Application Lifecycle Management

[edit] References

1. ^ SELECTING A DEVELOPMENT APPROACH. Retrieved 27 October

2008.
2. ^ "Systems Development Life Cycle". In: Foldoc(2000-12-24)
3. ^ Software Development Life Cycle (SDLC), Power Point, - Powered
by Google Docs
4. ^ James Taylor (2004). Managing Information Technology Projects.
p.39..
5. ^ a b Geoffrey Elliott & Josh Strachan (2004) Global Business
Information Technology. p.87.
6. ^ QuickStudy: System Development Life Cycle, By Russell Kay, May
14, 2002
7. ^ a b US Department of Justice (2003). INFORMATION RESOURCES
MANAGEMENT Chapter 1. Introduction.
8. ^ a b c d e U.S. House of Representatives (1999). Systems
Development Life-Cycle Policy. p.13.
9. ^ Blanchard, B. S., & Fabrycky, W. J.(2006) Systems engineering
and analysis (4th ed.) New Jersey: Prentice Hall. p.31
10. ^ a b Post, G., & Anderson, D., (2006). Management information
systems: Solving business problems with information technology. (4th
ed.). New York: McGraw-Hill Irwin.

[edit] Further reading

• Blanchard, B. S., & Fabrycky, W. J.(2006) Systems engineering and

analysis (4th ed.) New Jersey: Prentice Hall.
• Cummings, Haag (2006). Management Information Systems for the
Information Age. Toronto, McGraw-Hill Ryerson
• Beynon-Davies P. (2009). Business Information Systems. Palgrave,
Basingstoke. ISBN 978-0-230-20368-6
• Computer World, 2002, Retrieved on June 22, 2006 from the World Wide
Web:
• Management Information Systems, 2005, Retrieved on June 22, 2006 from
the World Wide Web:
• This article was originally based on material from the Free On-line
Dictionary of Computing, which is licensed under the GFDL.

The Project Life Cycle

Module by: Merrie Barron, Andrew R. Barron. E-mail the authors

User rating (How does the rating system work?)

Ratings
Ratings allow you to judge the quality of modules. If other users have ranked the module then
its average rating is displayed below. Ratings are calculated on a scale from one star (Poor) to
five stars (Excellent).

How to rate a module

Hover over the star that corresponds to the rating you wish to assign. Click on the star to add
your rating. Your rating should be based on the quality of the content. You must have an
account and be logged in to rate content.

(0 ratings)

The project manager and project team have one shared goal: to carry out the work of the
project for the purpose of meeting the project’s objectives. Every project has beginnings, a
middle period during which activities move the project toward completion, and an ending
(either successful or unsuccessful). A standard project typically has the following four major
phases (each with its own agenda of tasks and issues): initiation, planning, execution, and
closure. Taken together, these phases represent the path a project takes from the beginning to
its end and are generally referred to as the project life cycle (Figure 1).

Figure 1: The four phase of the project life

cycle. Adapted from J. Westland, The Project
Management Lifecycle, Kogan Page Limited
(2006).
Initiation phase

During the first of these phases, the initiation phase, the project objective or need is
identified; this can be a business problem or opportunity. An appropriate response to the need
is documented in a business case with recommended solution options. A feasibility study is
conducted to investigate whether each option addresses the project objective and a final
recommended solution is determined. Issues of feasibility (“can we do the project?”) and
justification (“should we do the project?”) are addressed.

Once the recommended solution is approved, a project is initiated to deliver the approved
solution and a project manager is appointed. The major deliverables and the participating
work groups are identified and the project team begins to take shape. Approval is then sought
by the project manager to move on the detailed planning phase.

Planning phase

The next phase, the planning phase, is where the project solution is further developed in as
much detail as possible and you plan the steps necessary to meet the project’s objective. In
this step, the team identifies all of the work to be done. The project’s tasks and resource
requirements are identified, along with the strategy for producing them. This is also referred
to as scope management. A project plan is created outlining the activities, tasks, dependencies
and timeframes. The project manager coordinates the preparation of a project budget; by
providing cost estimates for the labor, equipment and materials costs. The budget is used to
monitor and control cost expenditures during project execution.

Once the project team has identified the work, prepared the schedule and estimated the costs,
the three fundamental components of the planning process are complete. This is an excellent
time to identify and try to deal with anything that might pose a threat to the successful
completion of the project. This is called risk management. In risk management, “high-threat”
potential problems are identified along with the action that is to be taken on each high threat
potential problem, either to reduce the probability that the problem will occur or to reduce the
impact on the project if it does occur. This is also a good time to identify all project
stakeholders, and to establish a communication plan describing the information needed and
the delivery method to be used to keep the stakeholders informed.

Finally, you will want to document a quality plan; providing quality targets, assurance, and
control measures along with an acceptance plan; listing the criteria to be met to gain customer
acceptance. At this point, the project would have been planned in detail and is ready to be
executed.

Execution phase

During the third phase, the execution phase, the project plan is put into motion and performs
the work of the project. It is important to maintain control and communicate as needed during
execution. Progress is continuously monitored and appropriate adjustments are made and
recorded as variances from the original plan. In any project a project manager will spend
most of their time in this step. During project execution, people are carrying out the tasks and
progress information is being reported through regular team meetings. The project manager
uses this information to maintain control over the direction of the project by measuring the
performance of the project activities comparing the results with the project plan and takes
corrective action as needed. The first course of action should always be to bring the project
back on course, i.e., to return it to the original plan. If that cannot happen, the team should
record variations from the original plan and record and publish modifications to the plan.
Throughout this step, project sponsors and other key stakeholders should be kept informed of
project status according to the agreed upon frequency and format. The plan should be updated
and published on a regular basis (Figure 2).

Figure 2: One year in a project – Day 19.

Status reports should always emphasize the anticipated end point in terms of cost, schedule
and quality of deliverables. Each project deliverable produced should be reviewed for quality
and measured against the acceptance criteria. Once all of the deliverables have been produced
and the customer has accepted the final solution, the project is ready for closure.

Closure phase

During the final closure, or closeout phase, the emphasis is on releasing the final deliverables
to the customer, handing over project documentation to the business, terminating supplier
contracts, releasing project resources and communicating the closure of the project to all
stakeholders. The last remaining step is to conduct lessons learned studies; to examine what
went well and what didn’t. Through this type of analysis the wisdom of experience is
transferred back to the project organization, which will help future project teams.

Bibliography

• J. Westland, The Project Management Lifecycle, Kogan Page Limited

(2006).