We implement every project to achieve the results defined by the company. In practice, this means that the project should produce specific deliverables. We should know precisely what sub-products and end products we want to create before we start working on building a project schedule. This is the first and fundamental step in building a practical project schedule. The required deliverables should be named and their content briefly defined so those responsible for creating them later know precisely what they should deliver. Such a list of defined products is shown in the illustration below:
Analogous to defining the list of products, we should put a lot of precision and care into building the WBS. When developing the structure of project tasks, it is worth starting by defining collective tasks and linking them to the products we have previously defined. In practice, we can either hook a product to a specific collective task or, at the end of each collective task, define a project milestone that will result in the required product. Once we have the bulk tasks defined in the project schedule, we can go down a level and define detailed tasks. In this case, we can treat each collective task as a “mini-project.” It is worth defining the tasks defined in the WBS briefly so that later, each person involved in the project knows exactly what functions are assigned to him. The following illustration shows the structure of the WBS and, for a selected, highlighted task, the dialog box with the details of this task is shown on the right:
Once we are comfortable that the project WBS we have developed is complete, we should define the duration of individual tasks (their labor intensity) and clearly define responsibility for their implementation. Anyone involved in project management knows how to assign owners to tasks and how to determine when a task should start and how long it should take. However, I would like to pay special attention to building relationships and the logic of links between the various tasks defined in the project schedule. If we wisely link the tasks in the project at the stage of creating the plan, our work will be straightforward in the future. If, at a later time, the implementation of any of the tasks is delayed, all the related tasks will automatically move forward. Also, if we have already created links at the planning stage when one of the tasks is moved forward or backward in time, the other related tasks in the project will move accordingly. In the illustrations below, we can see the structure of project tasks and the Gantt schedule with the marked relations:
If you are sure you already have a good project schedule developed, save it in the system as a project baseline plan (Baseline) that you will refer to during project implementation. The illustration below shows a project in progress and its current reference to the approved schedule plan. The thin black dashes under each task show the approved plan, and the thicker bars above them show the current degree of completion of each task from the project schedule:
A well-designed project schedule plan will significantly affect the ultimate success of implementation. People participating in the project will know precisely what they are supposed to do and when. While implementing the guidelines, we can monitor deviations clearly and take corrective actions.