The project life cycle (PLC) is 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 a project—that is, the information system. Each phase should provide one or more deliverables. A deliverable is a tangible and verifiable product of work (i.e., project plan, design specifications, delivered system, etc.). Deliverables at the end of each phase also provide tangible benefits throughout the project and serve to define the work and resources needed for each phase.
Projects should be broken up into phases to make the project more manageable and to reduce risk. Phase exits, stage gates, or kill points are the phase-end review of key deliverables that allow the organization to evaluate the project's performance and to take immediate action to correct any errors or problems. Although the deliverables at the end of a stage or phase usually are approved before proceeding to the next stage, fast tracking or starting the next phase before approval is obtained can sometimes reduce the project's schedule. Overlapping of phases can be risky and should only be done when the risk is deemed acceptable.
Like all living things, projects have life cycles where they are born, grow, peak, decline, and then terminate (Gido and Clements 1999; Meredith and Mantel 2000). Although project life cycles may differ depending upon the industry or project, all project life cycles will have a beginning, a middle, and an end (Rosenau 1998; Gido and Clements 1999). Figure 1.2 provides a generic life cycle that describes the common phases or stages shared by most projects.
Defining the project's overall goal should be the first step of the project. This goal should focus on providing business value to the organization. A well-defined goal gives the project team a clear focus and drives the other phases of the project. In addition, most projects seem to share the following characteristics:
• The effort, in terms of cost and staffing levels, is low at the start of the project, but then increases as the project work is being done, and then decreases at the end as the project is completed.
• Risk and uncertainty are the highest at the start of a project. Once the goal of the project is defined and the project progresses, the probability of suc cess should increase.
Define project goal
Define project goal
Execute projeci plan
Execute projeci plan
Project Time Line
■ The ability for stakeholders to influence the scope and cost of the project is highest at the beginning of the project. The cost of changing the scope and correcting errors becomes more expensive as the project progresses.
Once the project's goal has been defined, developing the project plan is a much easier task. A project plan essentially answers the following questions:
• What can go wrong and what can we do about it?
• How did we estimate the schedule and budget?
• Why did we make certain decisions?
• How will we know if we are successful?
In addition, the deliverables, tasks, resources, and time to complete each task must be defined for each phase of the project. This initial plan, called a baseline plan, defines the agreed upon scope, schedule, and budget and is used as a tool to gauge the project's performance throughout the life cycle.
After the project's goal and plan have been defined, it's time to put the plan into action. As work on the project progresses, scope, schedule, budget, and people must be actively managed to ensure that the project achieves its goal. The project's progress must be documented and compared to the project's baseline plan. In addition, project performance must be communicated to all of the project's stakeholders. At the end of this phase, the project team implements or delivers a completed product to the organization.
Execute Project Plan
As was mentioned, a project should have a definite beginning and end. The closing phase of a project ensures that all of the work is completed as planned and as agreed to by the project team and the sponsor. Therefore, there should be some kind of formal acknowledgement by the sponsor that they will accept (and pay for!) the product delivered. This closure is often capped with a final project report and presentation to the client that documents that all promised deliverables have been completed as specified.
Sometimes the value of an IT project is not readily known when the system is implemented. For example, the goal of a project to develop an electronic commerce site should be to make money—not to build or install hardware, software, and web pages on a particular server platform. The technology and its subsequent implementation are only a means to an end. Therefore, the goal of the electronic commerce site may be to produce $250,000 within six months. As a result, evaluating whether the project met its goal can be made only after the system has been implemented.
However, the project can be evaluated in other ways as well. The project team should document its experiences in terms of lessons learned—those things that it would do the same and those things it would do differently on the next project, based on its current project experiences. This post mortem should be documented, stored electronically, and shared throughout the organization. Subsequently, many of these experiences can be translated into best practices and integrated into future projects.
In addition, both the project team and the project itself should be evaluated at the end of the project. The project manager may evaluate each project team member's performance in order to provide feedback and as part of the organization's established merit and pay raise processes and procedures. Often, however, an outside third party, such as a senior manager or partner, may audit the project to determine whether the project was well-managed, provided the promised deliverables, followed established processes, and met specific quality standards. The project team and project manager may also be evaluated in terms of whether they acted in a professional and ethical manner.
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 (SDLC), 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 (McConnell 1996). Although there is no generally accepted version of the SDLC, the life cycle depicted in Figure 1.3 includes the generally accepted activities and phases associated with systems development. Keep in mind that these concepts are generally covered in great detail in system analysis and design books and courses. For some, this may be a quick review, while for others it will provide a general background for understanding how IT project management and information system development activities support one another.
Planning, analysis, design, implementation, and maintenance and support are the five basic phases in the systems development life cycle.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.