| We all know that in the real world we, as PMs, are | | | | 2) As soon as possible (flexible; default) - For |
| given the finish date of the project before we even | | | | projects scheduled from the start date. Schedules |
| have a chance to plan for it. This is a good enough | | | | the earliest possible start and finish dates for the |
| reason why we need to get better at scheduling our | | | | task |
| projects and leveling our finite resources. | | | | 3) Finish no earlier than (moderate; avoid) - For |
| Sure, there are tools that allow us to automate the | | | | projects scheduled from the start date. Indicates the |
| process but a tool is as good as the knowledge of | | | | earliest possible date that the task can be completed, |
| those who use it. All in all, all PMs have a tool and a | | | | and the task cannot finish any time before the |
| method by which we create our project schedules. | | | | specified date |
| But... we all suffer from common mistakes such as | | | | 4) Finish no later than (moderate; avoid) - For |
| having the wrong dependencies, excessive | | | | projects scheduled from the finish date. Indicates the |
| constraints, inadequate level of detail in the WBS, | | | | latest possible date that the task can be completed, |
| estimates too granular or inexistent, over allocated | | | | and the task can be finished on or before the |
| resources, etc. Ring a bell? | | | | specified date |
| The tool that is most widely used is MS Project® | | | | 5) Start no earlier than (moderate; avoid) - For |
| (MSP). And I am not going to take the time of this | | | | projects scheduled from the start date. Indicates the |
| article to talk about MSP since this is not the topic. I | | | | earliest possible date that the task can begin, and the |
| will, however, mention it as it applies to project | | | | task cannot start any time before the specified date |
| scheduling and resource leveling. | | | | 6) Start no later than (moderate; avoid) - For |
| The method is what changes from PM to PM. I will | | | | projects scheduled from the finish date. Indicates the |
| explain the "must do" steps and in the correct order.o | | | | latest possible date that the task can begin, and the |
| Develop WBS | | | | task can start on or before the specified date |
| Most organizations have a hierarchical structure to | | | | 7) Must finish on (inflexible; avoid) - Indicates the |
| break down the work. Typically, it looks like this: | | | | exact date on which the task must finish. Other |
| Stage, Phase, Task/Deliverable/Milestone. | | | | scheduling parameters such as task dependencies, |
| This is a way to organize and define the total scope | | | | lead or lag time, and resource leveling become |
| of the project by decomposing the work to be | | | | secondary to this requirement |
| executed into tasks that the project team can | | | | 8) Must start on (inflexible; avoid) - Indicates the |
| execute and create the required deliverables. The | | | | exact date on which the task must begin. Other |
| tasks, deliverables or milestones are components that | | | | scheduling parameters such as task dependencies, |
| can be scheduled, cost estimated, monitored and | | | | lead or lag time, and resource leveling become |
| controlledo Establish dependencies | | | | secondary to this requiremento Assign resources |
| Dependencies are defined so that the work is | | | | Resources (typically human) are assigned to tasks, |
| executed in the proper order. Understand the | | | | deliverables and milestones that need to be |
| following task dependency types before you use | | | | executed. At the beginning of the project, when |
| them; incorrect dependencies will impact the finish | | | | named resources are not known yet, roles are |
| date of your schedule and create unnecessary | | | | assigned that can later be replaced with names (i.e.: |
| constraints: | | | | the role of Analyst is assigned to a task during |
| 1) Mandatory (hard logic) - Inherent in the nature of | | | | project scheduling and is later replaced with John Doe |
| the work being done. They often involve physical | | | | when he is the analyst assigned to the task)o Level |
| limitations (i.e.: a test case must be defined before | | | | resources |
| testing) | | | | Helps in utilizing resources consistently throughout the |
| 2) Discretionary (soft/preferred/preferential logic) - | | | | project. Ensures resources are not over allocated. |
| Based on experience, desire or preferences (i.e.: the | | | | Helps the PM avoid delays caused by bad allocations. |
| team decides that they will create the user manual | | | | Helps the PM identify and take advantage of unused |
| after the first round of testing, although it is not | | | | times by analyzing task dependencies. MSP can |
| necessary) | | | | automatically level resources based on resource |
| 3) External - Based on needs or desires of a party | | | | calendar, task types, dependencies, and constraints, |
| outside the project (i.e.: the server must be | | | | however, I have yet to find a PM that has felt |
| purchased before configuring) | | | | comfortable with the way MSP does it. I level |
| A network diagram is used to show dependencies in | | | | resources manually via the Resource Usage view, but |
| a graphical form. MSP generates a network diagram | | | | if you insist in using the automatic feature of MSP, |
| automaticallyo Estimate work | | | | save a copy first. |
| Work is the number of labor units (usually expressed | | | | If you find resource conflicts (over or under |
| in hours, days or weeks) required to complete a | | | | allocations) you could: |
| scheduled task. Estimation is equivalent to success. | | | | 1) Delay certain tasks |
| Duration is the total number of work periods (usually | | | | 2) Assign a different resource |
| expressed as days or weeks) required to complete a | | | | 3) Change task dependencies |
| scheduled task. | | | | 4) Remove tasks |
| When estimating, keep in mind the different task | | | | 5) Add tasks (instead of using the MSP's split task |
| types: | | | | functionality which is not supported by some project |
| 1) Fixed units (MSP default) - Allows the schedule to | | | | management systems (i.e.: Clarity)o Determine critical |
| calculate the finish date ASAP based on resource | | | | path |
| availability | | | | Helps the PM identify tasks that must be carefully |
| 2) Fixed duration - Used when the priority is to | | | | monitored. The critical path is the longest duration |
| preserve duration. To complete work, assign | | | | path through a network diagram and it is the |
| resources as needed to satisfy the finish date | | | | shortest path to complete the project. Knowing the |
| (remember my comment about "knowing" the finish | | | | project's critical path should be the goal of the |
| date before we even plan?) | | | | scheduling process. MSP calculates the critical path |
| 3) Fixed work - Some project management systems | | | | automatically and through the Gantt chart it shows |
| (i.e.: Clarity, formerly Niku) that sit on top of MSP | | | | what tasks are in it. One thing to keep in mind is that |
| don't support this type because of the effort driven | | | | as tasks are completed ahead or behind schedule the |
| nature of it and the unpredictable results it may | | | | critical path changes. Another is that there can be |
| create. So, I have chosen to get used to not to use | | | | more than one critical path but this increases risk. |
| it at all | | | | If the critical path takes your project's finish date |
| This is how task types work: | | | | way too far there are a couple of techniques that |
| ...if you revise Duration ...if you revise Work ...if you | | | | PMs can use to compress the schedule: |
| revise Units | | | | 1) Fast tracking - Perform critical path tasks in parallel |
| In a Fixed Units task... Work is recalculated, and units | | | | that were originally planned sequentially. It usually |
| are fixed Duration is recalculated, and units are fixed | | | | increases risk and often results in rework |
| Duration is recalculated, and work is fixed | | | | 2) Crashing - Assign additional resources to critical |
| In a Fixed Duration task... Work is recalculated, and | | | | path tasks while maintaining scope. Almost always |
| duration is fixed Units is recalculated, and duration is | | | | results in increased costs |
| fixed Work is recalculated, and units are fixed | | | | As PMs, we forget a very important intangible: |
| Task constraint is the next item we need to look at | | | | resource calendars affect project scheduling. Public |
| when estimating. You must avoid using moderate and | | | | holidays or time off in a resource's calendar makes |
| inflexible types. Wrong constraints increase the | | | | those days as non-workdays and therefore, MSP |
| project risk and extend the finish date: | | | | skips them altogether. |
| 1) As late as possible (flexible; default) - For projects | | | | If you follow the basic steps explained in this article |
| scheduled from the finish date. Schedules the latest | | | | you should not have major problems with scheduling |
| possible start and finish dates for the task | | | | and resource leveling. Don't you think so...? Well, I do. |