Programming Project Schedule Changes

[Bill Busby]

Right now this is at the idea stage and I'd like input on where it falls on
the 'great idea' to 'you gotta be nuts' scale.

We constantly have Project Pro making adjustments to our schedule (using
fixed duration, non-effort driven) tasks as we record time updates from PWA
(PM's not allowed to make their own changes to work effort). Project Pro
tells us we can't complete the task in the time alloted and I'm gonna help
you out by changing the duration. Our PM's need to do a better job of
assessing effort but the reality is we aren't likely to close that gap
anytime soon.

Possible solution? Have each PM develop their WBS and baseline their
schedule. Based on some event like closing the project plan have a job that
compares the schedule to the baseline and resets the duration (and by default
the finish dates) to the values contained in the baseline. Thoughts?

 

[Gary L. Chefetz [MVP]]

Bill:

The behavior you describe indicates that people are recording actual work
outside of your "fixed-duration" indicating that these really aren't
fixed-duration tasks. So, your question is, ultimately, can I bend reality
back to my plan? I guess I'm falling on the side "you gotta be nuts" side.
Why not use a better schedule model and live with reality? The consequence
of resetting duration after you've recorded actual work, is that doing so
will almost certainly alter the actual work record as well.

--


Gary L. Chefetz, MVP
For Project Server Consulting: http://www.msprojectexperts.com
For Project Server FAQS: http://www.projectserverexperts.com
For Project Server Books: http://www.projectserverbooks.com
For Project Server Training: http://www.projectservertraining.com
For Project FAQS: http://www.mvps.org/project

 

[Bill Busby]

I would love to agree about the behavior because that would give me something
concrete to fix but what I've observed is I can create a project with tasks
that last all year (to represent infrastructure support, not a true project
per se) and give people a certain level expected effort. Once people start
recording time in a pattern that doesn't match the level contured task
Project Pro adjusts the schedule. Even though the task finish date is a year
away and people are clearly not charging time outside the finish date. If
someone could explain why Project Pro does this I might be able to put the
crack pipe down and stop coming up with these crazy ideas about bending
reality <g>.

 

[Gary L. Chefetz [MVP]]

Bill:

A wise project expert for whom I have a great deal of respect, once told me
that thinking about these things to hard will make your head hurt. Consider
yourself warned. Why, you ask? Because the project programming deities said
so. That mainly, and because of two other factors: 1) The project scheduling
engine has an underlying bias toward changing duration. You don't really get
away from this by making a task fixed duration. 2) Using the EPM to process
actual work automatically kicks in the "reschedule uncompleted work"
tracking feature that kicks any planned work before the status date, forward
to the status date for each assignment you process. You can't stop this
behavior. Essentially you're snow-plowing it forward.<g>

This is the reason why you don't accrue planned work when you assign
resources to an Administrative project and their reason for being. So, by
using a standard project you're saying here's work we're committing to get
done, meaning it needs to be constantly rescheduled, when it's more likely
that although we're reserving time for it in our planning, if it doesn't
occur, it might expire its committed work status if it doesn't happen as
planned. Don't forget that you can also use MAX Units to account for
unplanned commitments or to discount resource availability for other
reasons. Bottom line is if you choose to use the method you're using, you
must accept that you have to keep replanning these tasks periodically. Don't
expect Project to make sense of it.

--


Gary L. Chefetz, MVP
For Project Server Consulting: http://www.msprojectexperts.com
For Project Server FAQS: http://www.projectserverexperts.com
For Project Server Books: http://www.projectserverbooks.com
For Project Server Training: http://www.projectservertraining.com
For Project FAQS: http://www.mvps.org/project

 

[Gregg Richie]

Bill,

After starting in the world of Project Management before it was even called
that, I find that nowadays most key contributors, stakeholders and project
sponsors are less interested with the nuts and bolts of scheduling tools and
managing the details. I struggled with the same issue you are..."Why is my
computer doing what it is told, instead of what I want it to do?"

In my industry it has taken me 5 years to develop detailed, effort-driven,
down-to-the-hour tasks in a schedule that follows the reality - not the dream
- of what it takes to get all of the various types of residential land
developments designed, approved and built. This includes the myriad of
governmental and environmental agencies, the firestorm of local residents who
oppose expansion in what was once a rural area, and sometimes the difficulty
of the engineering itself - all of which are very fluid and ever-changing.

My point is that a project is a project no matter what the industry.
Scheduling, task assignments, actual start dates vs. planned start dates, and
resource leveling are all dependent on how well (and how detailed) the
information is that is given to the management tool (MSOP 2007 and PS2007).
While some say that a task should be >=2 days and <= 2 weeks, I find that
working in a company of 30+ people, using an EPM Solution that automatically
assigns tasks, I believe it is imperative to spend the time and effort up
front to develop schedules that meet the reality. Not only will you find
that the work flows are smoother, but you can extract some very detailed
information for future planning and estimating.

Finally, I was told "you gotta be nuts" when I suggested that we develop
schedules that are as detailed as we have them now. Since we have installed
PS 2007 and every employee from the Managing Engineer to the errand runner
gets a task to get the job done, we find that our profits has increased
because task management is better.

Good Luck.

Gregg D. Richie
Engineering Project Manager
LeRoy Surveyors & Engineers, Inc.