8

Project plans don't update themselves, sadly. So I'm trying to figure out what I need to do to keep them up to date. I can update work complete as tasks get done, but what should I be doing to ensure that we're on schedule according to the plan?

  • 2
    Can you tell us a bit more about your team please? I would probably suggest that developers might be equally responsible for closing the tasks. If you see that certain developer spent two or more days without closing any tasks or updating the progress, then concerns should be raised as it may affect the delivery date. – CodeWorks Apr 17 '12 at 15:08
3

If you have estimates for each of the tasks, you could use that information to estimate the progress (the measure of time of tasks completed) against the total estimated time (the estimation of all tasks).

Additionally, you could look at completed tasks and calculate the difference between estimates and actual time and then pad the remaining estimates with the average.

This could then tell you approximately how far off schedule or on schedule you might be.

As far as keeping the project plan up to date, this takes discipline, and you'll need to make sure that you set aside a specific amount of time everyday to update this information.

6

Schedule statusing and analysis should occur on an established frequency based on the length of your project, primarily. This type of control work is expensive so you want to do it as infrequently as possible. Not only this, but the more you dig in, the more you will compelled to chase variances, which is often nothing more than stochastic ebbs and flow, which you never chase. If your project schedule was two years long, even a year, weekly statusing is an overkill.

Use Earned Value, Earned Schedule, and Critical Path Management to monitor your performance against cost and schedule. There is a lot to each of these methods--too much to explain on this exchange. These methods are proven and well known so the results are credible.

When you use the word "updates", it implies you are actively altering the schedule. Unless a change goes through a formal process and is accepted, your schedule should be baselined and unchanged. If you constantly change it, you will never get a clean picture of your variances.

Also, there is a huge difference between estimate and target. Your estimate is probabilistic; your target--upon which your schedule is based--is deterministic. This means you will have variances. Some of these variances are unimportant, i.e., the package was not on the critical path and had zero effect on your schedule. Using the methods I indicated above will help analyze that and calculate your probabilistic estimates at completion.

  • i think the comment "Unless a change goes through a formal process and is accepted, your schedule should be baselined and unchanged." is a perhaps little too proscriptive. A project should have tolerances, and changes should be allowed within those tolerances. – rapscalli Jan 7 at 9:31
2

The best solution would be to have an easy-to-use time sheet/tracking system that was linked to your project tracking system. In my last company, we had to track billable hours and every time sheet entry was tied to a client already. They added a project management module that allowed you build a WBS, phases, tasks, and dependencies. As a first version, it really wasn't that bad, and it made tracking project status really simple.

It worked for us because everyone was already used to entering detailed time sheets. You will need a way to allow people to easily and quickly update their list of tasks in your tracking system. Since you tagged this question with MS-Project, I assume you are using that as project planning tool. I have not found a decent solution to this, yet, so I can't point you to a specific tool.

2

Everything depends on the team, their inputs, their responsibilities and collective effort. I generally track the project progress frequently during the initial days of the phases - for example how and when each milestone is being worked upon by the responsible. It creates a general feeling on how each facet of the project is progressing. In a web development project, I felt the designer could take +-5 days for each milestone, so I generally did not update the project plan everytime he gave me an update, only when a milestone meeting were held. But in the case of the developer,

1

One system we used for a while is EVS. (Earned Value System)

Essentially, a task can be in 1 of 4 states, defined as:

  1. 0% - not started,
  2. 20% - started,
  3. 80% - ready for testing and
  4. 100% - complete

You can adapt the states and percentages to your particular whims and needs. :-)

So, how does this help you? As I wrote in my blog many years ago:

The most important lesson I learned from using EVS was this: It's irrelevant whether the task is 41% complete or 78% complete. It's either 0% (not started), 20% (started), 80% (ready for testing) or 100% complete, having been blessed by QA.

This saves a lot of useless schedule updates, which are meaningless since nobody really knows how long the task will take, and often the last 20% of the task takes 80% of the time.

So, back to your dilemma:

So I'm trying to figure out what I need to do to keep them up to date. I can update work complete as tasks get done, but what should I be doing to ensure that we're on schedule according to the plan?

You can't know if you're really on schedule, because you're not building a 100-floor skyscraper that can be tracked as 100 x 1-floor x N-days to complete.

All you can do is track your 4 states and break it down into small enough pieces that you will have ample time to do Crisis Management if something falls behind.

P.S. For your sanity, you may want to do an occasional MBA (Management by Walking Around) to get a feel of how things are progressing by shmoozing to team members.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.