Access Services Department
Knight Library

Project Planning and Management

Workshop Nov 7 - 9, 2007

Preliminary Project Schedule

  • Create a preliminary schedule (PS = LR+TDE)
    Preliminary schedule equals Logical Relationships plus Task Duration estimates.

    2.2.1: Logical relationships : It's logical that you have to make up the survey instrument before you can send it out to the faculty. Just put the tasks into little lines with a start point and then what has to happen and then what and then what. You probably will have several start points. For example, you can be getting permission to use human subjects at the same time you (or another person) can be creating the survey instrument. One task does not rely on the other but you cannot administer the survey until after it's been created and tested or before you have permission to administer it to humans.

    Estimate time duration for each task: Get the owner of the task to talk to the do-er of the task and ask how long it might take to do it. If the do-er says, "Uh, I dunno....." then break down the task further and ask how long it might take. Keep breaking it down until the do-er can say, "oh, yeah! Painting that wall would take one and a half hours."

    Make sure you and everybody knows the difference between effort estimates, duration estimates, and calendar estimates.

    If the person is unsure about how much time a task might take ask: "What percent chance that you'll finish early?" and then "What percent chance that you'll finish late?" and break down the task to a smaller size and ask those questions, and keep breaking it down until you get those numbers even.

    At the very worst just accept the gut reaction of the do-er. Gut reactions are usually better than trying to make up a scientific answer. Ernie gave each group a big bag of M&Ms and had us estimate the number of green ones per bag. Then he'd give us a piece of information like "in teenie bopper world green ones are seen as aphrodisiacs so the Mars company put FEWER of them in each bag so the teens would buy more bags to get those green candies. That led the groups to change their estimates, etc. Then he gave us another tid-bit like "there's an average of 360 M&Ms in each bag". Then we'd change our estimate again. Then he let us open it and start counting, and we'd change our estimate again. Sometimes up, sometimes down. In the end, our original gut reactions were closer than our step by step logic.

    There are lots of technical ways to estimate time: PERT (Performance Evaluation Review Technique), COCOMO (Constructive Cost Model), Delphi (a collaborative method) but if you want that kind of detail, look it up.

    Here's the silver bullet to good estimation, though:

    "Get the right person making the estimation, break the task down to a recognizable level, and have the estimate done in the context of the particular project".

    Also, don't pad or underestimate. Padding an estimate for a single task has an impact on the time when other tasks can start or finish. If you're unsure about the estimate, tell the project manager that, and that person can pull from a "managerial reserve" of time that will, with luck, be built into the project.

    Tell the sponsor and the customer that you have XX unknowns and you want to be upfront from the start and build into the project a "managerial reserve" amount of time. Then put the time where you need it as the project goes forward.

    2.2.3: Integrate schedules:

    I think this is where we got a big Gannt chart and we colored in little boxes for how long each task should take and whether it was a start point or where it fit in a line (something had to happen before it, something had to happen after it).

    That was lots of fun. Took a chunk of time, but lots of fun. Got all the tasks in a logical order that allowed us to see where each task fit. We drew brackets on the chart for which tasks had slippage (that is, they were in a logical progression, but didn't really HAVE to be started until task 3.2.1 was done. Could start earlier, but nothing relied on its being done until 3.2.1 was done. That's called the "late start" and it measured the amount of slippage you could have for that task. That's good to know since the do-er of that task might be doing something else and his functional supervisor won't release him until later in your project. Now you have a way of knowing whether his release-date works with your task-to-be-done-no-later-than date.

    Next on the bottom of the Gannt Chart we looked at each task and who did it and played Tetris. We dropped each task down during the same timeline it occupied above but to the bottommost row of the chart that it could go so we could see if the task owners had too many things piled up on them at the same time in the project. If they did, we used the slippage time to see if that could fix the problem, or we could fix it by having the owner delegate to more available do-ers. Or if nothing else worked, we could take that problem to our constraint matrix and see if our sponsor might allow slippage of the schedule or not. And of course, we'd go see our sponsor with the preliminary project schedule.







  • Return to How To index