What You Will Learn
Introduction
In order make a good project schedule we’ll need to be clear on what is the objective the project aims to meet; that is, what is the scope of the project. Then we have to understand who are in charge of executing the project work and the environment in which the project is to be executed.
Knowing the scope and the team, we will assign responsibles for each work package. These team members must provide detailed tasks, dependencies and durations. With all these elements we can begin construction of the Project Schedule.
WBS
As noted by (Butchnik, 2009) the WBS is the best way to control project scope. The WBS helps to understand the details of the project work, which further facilitates the preparation of the schedule. It is used to describe the scope of a project in terms of its deliverables, divided into pieces that are small enough to plan and work easily. These pieces are called work packages.
The 100% concept
At the top level of the WBS is the expected final product of the project.
The next level is a list of all deliverables contained in Project Charter. To conform is suggested to consider only nouns, not verbs (such as “database” and not “Process data”). At this level the major deliverables that will exist after the project is completed should be included. These major deliverables should describe the 100% of the final product.
On the third level we will break down each one of the major deliverables, and their components should describe 100% of deliverable second level.
Each level of the WBS should, by itself, express 100% of what the project should deliver.
The team must understands what this 100% represents in each level. We must also understand that any feature that is not part of the Level 1 of the WBS, is not part of the project.
Ensure that each element of the WBS represents 100% of the project also helps identify and prevent problems, including business rules: When a business rule can not be expressed as part of a WBS element is likely to be due to a problem of understanding.
The sum of the work packages at the lowest level of the WBS should be 100% of the scope of the project.
The OBS
The Organizational Breakdown Structure, represents the breakdown of the organization, from the highest work unit (company, department) to the lowest (person). We need to know this structure to establish what people should support the development of the Project schedule. Usually the same people who will work on the project will help to build the schedule, because they know what tasks are required to develop a specific work package, as well as the duration and relationships between them.
The RAM
The Responsibility Assignment Matrix uses the WBS on an axis and the OBS on the other to identify the connecting points between the two structures. These intersections indicate who (within the organization) is responsible for developing each deliverable.
Each work package has a unique responsibility. This is the best person to assess the activities required to produce the work package and duration of these activities. If not, you should at least approve the estimate.
Network Diagram
The logical dependencies between tasks are defined using a diagram of network activity (activity network diagram) that allows identification of the critical path.
The rule of 80 hours
It is suggested to establish a policy on the maximum time a task can last. The recommendation is a task not last more than 80 hours, and the implication is that if we have a task with more than 80 hours, it should be divided into as many tasks as necessary, while respecting the maximum established.
The detail work package
Finally, we know in detail each work package. For each work package we can answer the questions: who will do it?, what are the dependencies with other work packages?, what additional resources are needed?, when will it be done?, what are the detailed sub-tasks to be executed?
Integration
We have to determine activities to be performed for each work package in order to complete it. At this time the sequence and dependences of activities is established, and we have to ensure that each action is aimed at generating a deliverable.
When we have clear idea of all project tasks, we can group them in phases if necessary.
Each line of the schedule must relate to a number in the WBS in a many to one relationship. That is, a WBS component corresponds with many lines (tasks) in our schedule. And for each WBS component must be at least a milestone in the schedule.
With all the above items we can create our project Gantt chart:
a) Create a summary task in the project
b) Enter all milestones
c) Enter all human resources
d) Enter the necessary tasks to prepare each milestone
e) For each task, define responsible
f) For each task, set logical dependencies with other tasks
g) For each task, define constraints
h) Group deliverables in the stages have been defined
Once our initial version of the Gantt chart is created, we will save the baseline.
Regardless of the tool you will use to create a Gantt chart, consider an initial configuration of the tool. The topics proposed are:
1. Default:
a. Set the Project Start Date
b. Define the standard calendar for the project
c. Assign Project Defaults
i. From where they initiate new tasks (from the beginning or end of the project)
ii. Unit task duration (months, weeks, days, hours)
iii. Currency unit
iv. Default task type (fixed units, fixed work, fixed duration, effort-driven.
d. Choose the columns to show; the ones suggested are:
i. Task Name
ii. % Completed
iii. Duration
iv. Work
v. Start date
vi. End date
vii. Resources
2. Enter the project resources (RBS)
a. People
b. materials
c. rates
3. Define the necessary personal calendars
References
Buchtik, L. (2010). Secrets to Mastering the WBS in Real-World Projects: The Most Practical Approach to Work Breakdown Structures (Wbs)!. Sylva: Project Management Institute.
