The Project Lifecycle Table

Micro Learning Unit

The project planning phase is usually divided into an initial planning phase – in which the project is planned in macro resolution, and a detailed planning phase – in which the planning is deepened and refined as required.

In the initial planning phase, where the uncertainty associated with the project is at the lowest level, the scope of the project should be planned to such an extent that it will ensure that the decision to approve the project will be the right one. To this end, it is better to describe the project – from its goals, through the constraints that apply to it to its life cycle and deliverables.

Every project has a well-defined lifecycle, which generally describes its stages, tasks and deliverables. A typical project lifecycle is composed of four main stages: project initiation, project planning, project execution and control, and project closure. This generic lifecycle must be adapted to the specifics of each project.

This adaptation is done by developing a lifecycle table that outlines the story of the project and presents an overview of its process. The lifecycle table includes the chronological order of the project’s stages; the central tasks undertaken at each stage; the main deliverables and milestones; and the main controls that must be put in place to ensure that these defined milestones and deliverables are achieved. The lifecycle table acts as the initial planning platform.

At a later stage, it will serve to develop the project’s detailed work plan.

There are two main advantages to using such a table:

  1. The table is simple and easy to complete, ensuring that the most important aspects of the project are taken into account from the very beginning.
  2. It presents the project using simple language, facilitating clear communication with all the stakeholders without the need for process diagrams or work plans.

This table focuses on the big picture, does not delve into unnecessary details and emphasizes the project’s milestones and deliverables – two key aspects that should be in the managerial focus of the project manager.

The table is build from these columns:

Project Stage

Chronological order of the stages of the project
A description of the stages of the project in a short name that indicates the essence of the stage, in chronological order. The list of project stages should be fairly final (probably between 4-8 stages)

Main Activities

Main activities that can be further decomposed
Main activities, formulated as a future action to be performed, are large enough to be further dismantled at least one more level at the detailed planning stage.

Main Deliverables

A tangible deliverable
A list of main deliverables that describe something tangible (physical / static) at each stage; There does not have to be a 1:1 relationship between the main activities and the main deliverables.

Main Milestones

Milestones in the project that describe a goal that has been achieved and are formulated in the past tense
The milestone list must describe the entire project from beginning to end, thus serving as a central communication tool with various stakeholders, as well as the basis of all control activity to be undertaken throughout the project.

Main Control Activities

Control and quality activities to be applied to the project deliverables and milestones
Control activities refers to actions to be performed to ensure that all milestones and deliverables are achieved at the appropriate stage of the project.

For example, a lifecycle table of writing a professional book might look like this:

it’s important to remember!
  • Although the table describes the project in chronological order, it does not address scheduling. There is no prevention to schedule tasks in parallel when composing the project work plan.
  • The table does not deal with resources and does not go down to details. It actually “flattens” the project and looks at it from a bird’s eye view. The details will come later.
  • Proper planning requires maximum coverage of the project scope and this cannot be achieved when running into its small details. Proper planning process requires restraint and discipline to avoid running into small activities and to execution. Skipping this step and running directly to scheduling the project tasks, would inevitably lead to a zigzag project management whenever any task that was forgotten appears while working on the project.
Known traps in filling the table:
The language trap
The table should "speak" the language of the content world of the project. Do not apply language from one content world to another. This is a sure recipe for poor communication.
The resolution trap
The table should describe the project as a whole in macro resolution. This is neither the time nor the place to go into the small details of the project. If you have difficulty identifying the big details in the project, try to group small details with a common denominator together, and call them by name. Next, pay close attention to the big issue and continue to break it down into small details. You may be surprised that it now consists not only of the small details that originally made it up, but other specifications that you would probably forget.
The trap of completion
The table should be complete and describe the entire project. Any part that is not taken into account now will lead to a deviation from the boundaries of the project later on. Be sure to develop the table with relevant parties from the relevant disciplines - one step at a time, in order to reduce the chance of deficiencies in the initial planning of the project (subject to the existing level of certainty in the project).
The trap of clarity
It is important that the table be filled out concisely but not telegraphically. Do not spare a word or two that will ensure that what is written in the table is understood. On the other hand, do not be dragged into long stories. This is not the place for that.

In conclusion,

The lifecycle table of a project is in fact a popular chronological WBS, which emphasizes deliverable and milestones in the project. A good table as stated above will ensure not only that all the important aspects of the project are taken into account at the very beginning, but also that everyone – especially the customer, understands the project. This is the basis for making good decisions in a project.

Back to: