Thursday April 28th, 2011
The project plan should be a useful tool for you to manage your workload and future activity, it should help you to foresee potential roadblocks and risks in advance and it should also help you to communicate effectively. In this edition of the Planning Update, we gain a better understanding of the waterfall method of project planning and why it is dependencies rather than dates that drive a project to completion.
The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.
The first known presentation describing use of similar phases in software engineering was held by Herbert D. Benington at Symposium on advanced programming methods for digital computers on 29 June 1956. This presentation was about the development of software for SAGE.
Microsoft Project is a software tool that assists in the planning process that follows the waterfall approach. Our project uses Microsoft Project as its planning tool and therefore the waterfall concept impacts us. The purpose of this communication is to help you understand how your tasks cascade down the waterfall.
Although the waterfall contains high level activities, the detailed tasks are dependent on each other. Sometimes there are many independent paths to completion.
As you can see from the diagram, this is the typical progression of an IT project.
The project is conceived in line with the organization’s vision and it moves through the phases until realizing the benefits and return on investment that are expected.
As each phase of the project takes some time to complete, they can be seen as steps in the waterfall.
Not all phases can be expected to completely finish before the next phase begins and therefore each individual task inside these phases will be linked to individual tasks in previous and subsequent phases. Conceptually it appears to be a waterfall however in reality it is a collection of dependent drivers coming together at certain dates or “milestones”.
To understand how long it will take to complete a project we need to sum up the durations of all individual activities that we must undertake on the project. Some activities on the project may be undertaken concurrently, and some streams of activity start at the same point and end at the same point however are conducted completely independently. On our project for example the building of the interfaces all start at different times however they must all be ready for UAT at the same time.
It is important to understand how tasks relate to each other. For example in the diagram above task “C” is dependent on the successful completion of task “A”. Task “C” cannot begin until task “A” has successfully completed.
In this way we can say that task ”A” is a predecessor of task “C” and task “C” is a successor of task “A”.
Therefore should task “A” be delayed it will not be possible to start task “C”. On any project there will be delays experienced and by changing the duration of task ”A”, increasing the work involved of task “A” or changing the estimated completion date of task “A” will mean that the start date of task “C” will be affected.
In this way is not possible to keep the start date of task “C” fixed in stone.
As you can see based on the factors that will influence task “A”, the resources working on task “C” will be affected by delays or an early finish. To be able to plan effectively you need to understand the key drivers to task, this will help you to understand the importance of on-time delivery, how to mitigate delays and how to communicate down a waterfall so that the impact of your changes is minimized to those tasks and project team members who are dependent on your deliverables.
There are five key drivers to every task;
Task Work Effort
The Start Date
The End Date
The duration is the period of time in which we believe the task and be completed. The work effort is the amount of actual work to be conducted during the duration. The predecessors of those tasks which must start or finish before subsequent tasks can begin or finish.
If we have successfully entered the duration, work effort and predecessors the start and end date will be calculated for us. If there is a period of delay between one task and its successor we can optionally manually enter a start date.
PERT is a method to analyze the involved tasks in completing a given project, especially the time needed to complete each task, and identifying the minimum time needed to complete the total project. The tasks on the absolute minimum path to completion are called “Critical Path” tasks as a delay on any of these tasks causes the final delivery date to extend.
PERT was developed primarily to simplify the planning and scheduling of large and complex projects. It was developed for the U.S. Navy Special Projects Office in 1957 to support the U.S. Navy’s Polaris nuclear submarine project.
Andrew Ogura | Tokyo, Japan
Tuesday May 3rd, 2011 – 00:29 JST