Map the Schedule to a Real Calendar

< Free Open Study >

Map the Schedule to a Real Calendar One of the things that seems to baffle most new project managers is how to construct a workable schedule. Often, since they know they want a Gantt chart when they are done (because they saw one in a management review once), they start with that view of their WBS in a scheduling software tool like Microsoft Project. Sometimes they don't even have a work breakdown structure yet and just start from scratch with a blank Gantt view and a table to the left side. Then they add dated activity entries on the WBS, or directly with the Gantt bars, and manipulate them until the dates look like they "feel right." Then they add some precedence relationships and adjust it all a little bit. Lastly, they add resources to the picture and get very disturbed when the leveling algorithms rearrange their carefully laid out Gantt chart, changing the start and end dates for many activities, and splitting others. So they "undo" it and just show a summary of the major components' start and finish dates. This is a "feel" schedule, not a "real" one. There are at least two things wrong when a schedule is created this way: The project team was not involved in the preparation of the plan, which means that it will be the project manager's plan, not the project team's plan. They don't understand how to map the information they do have together to create a "real" schedule (as opposed to a "feel" schedule). The Gantt view, or any other view for that matter, only reflects the underlying information from the WBS, activity precedence, resource assignments, and the (fixed sized, usually average time) work estimates for each activity. When mapped together properly and overlaid on a "real" calendar of available work time, a "real" schedule results. To adjust this realistic schedule, the underlying elements must be changed (with good reasons), not the start and end dates. To understand how to map everything together and get a "real" schedule, we will explore the relationship of the four major components of a scheduled activity: Work�staff time of estimated effort; Units�the number of resources available to complete the activity; Duration�work time needed to complete the activity; Dates�calendar time needed to complete the activity. The triple constraint's elements of scope, schedule, and cost have a relationship to these components. The work is the total staff time of effort estimated from the estimation processes described in Chapters 10 and 11. Its output would be something like: Work: "Design the GUI: 48 staff-days" The units would be the number of resources available to do the work. Perhaps for this example, it would be something like: Units: "Able, Baker, Charlie, and Dawn will do it" The duration would be the actual number of workdays needed for the resources to do the work, which may be calculated from the work to do and units available: Duration: "48 Staff-days / 4 People = 12 Workdays on task" The calendar dates for this would come from applying an actual calendar to the 12 days needed, assuming that everyone was working full time in a normal Monday through Friday 40-hour workweek: Dates: "We need 2 weeks and 2 workdays to design the GUI" The first three parts would remain fairly constant no matter when the work was to be done, assuming that the same people were involved. This last part is very calendar dependent, obviously, and is sensitive to the exact days that the work falls on. If any of the resource units were unavailable during the work period, the expected end date of the work would move accordingly. It is a fixed-sized pie. This relationship is a lot like the distance-time-speed relationship in Box 15�1. Box 15�1 Distance-Time-Speed Relationship If I want to go from New York to Los Angeles in my car, and average 60 miles per hour when driving, then it will take 50 hours of driving to reach L.A. But, I won't be able to drive 24 hours a day, so if I choose to drive for only 8 hours each day, then it will take me 6.25 days to make the trip. The only way to do it quicker is to either drive faster or longer per day. The same is true for the triple constraint parameters. If I want to "Build the GUI," and it takes 48 staff-hours and I have four people to do it, then it will take 12 days to build it. If I want it faster, then I have to reduce the scope (limited-function GUI perhaps), change my four people's work hours (add overtime), or add more people. Be careful with adding people to an activity, though, as the more people that get involved, the less efficient the communications, exchanges, and division of work (this is the famous "Mythical Man Month" that Fred Brooks warned us about).

< Free Open Study >