Ready or not tasks

[Conrad Santiago]

In our projects, we often have tasks that are dependent on external actions, e.g. client needs to send us info before a task can start. We also have internal actions that can keep us from starting a task. Examples of this are managers unable to review work in time, computer renders are backed up in the rendering farm, inserts from other projects taking precedent

My question is has anyone come up with a way to plan this so that in the current day, there is no chance of a task not being ready

So far, we have implemented these two methods

1. Created a text column labeled "Status" with four values, Ready, Committed, Not Ready, On Hold. The manager would have to "status" each task daily

Ready = Task was ready to star
Committed = Client promised info; 90% chance of task being ready to star
Not Ready = Task was not ready to start; keep out 3 day
On Hold = Task was on hold; push out 2 week

We ended up with too many days where work was assigned for the current day but the task was not ready; either Ready tasks were not really ready, or Committed tasks didn't come in. It became too much work for me to keep the managers "honest" and for the managers to evaluate every task, every day

2. So, I came up the idea of having them set milestones for anything that would keep a task not ready. After all, we're using MSP, why not use the natural tools of the program instead of adding another dimension of complexity. We also set a rule to add a 1-day lag after each milestone. This way if a milestone is not met, the current day is not affected. Now, this is not working because it becomes cumbersome to add a milestone for every situation, lack of discipline among the managers, or lack of time to do it

Is there a true-tested method out there to handle the readiness of a task? Is there something in MSP that can manage that better

Any advice is appreciated

Conrad Santiago

 

[Steve House]

For the dependencies from outside the organization there's not a lot you can
do - I like your idea of a milestone as a predecessor with a SNE constraint
of the date they've promised plus a lag time to allow for variations. If
they don't make it on time, get a new estimate from them and revise the
constraint date accordingly. Barring unforseen events, for internal
predecessors the issue is more political and managerial than schedule
related per se. I know this may sound militaristic but your internal
resources and managers need to understand that the task start dates and
deadlines are not merely suggestions but rather are job requirements. Once
the project schedule is accepted and approved by senior managment it becomes
official company policy and compliance becomes part of the mandated job
performance standards that have originated with the Project Sponsor and
other members of senior management well above their paygrade. Obviously a
wise project manager consults with the functional managers and key resources
as the plan is being developed to get their input and buy-in, but once the
plan is in place and approved by senior managment, deciding on their own
whether or not to comply is simply not an option. Should circumstances
arise that requires changing the schedule, and such things certainly can
happen, they may not arbitrarily decide on their own to do so but instead
such changes must be done in consultation with the project manager and only
after the (preferrably written) approval by the project sponsor. If the
project requires that a senior engineer fly to Bismark on Tuesday, he damned
well better be on that airplane unless there is a very good reason, the
reason is documented, and the project sponsor has approved that deviation
from plan beforehand. Such problems as you describe are part of the reasons
that a change managment plan and approval/rejection strategy, with everyone
involved clearly understanding that any intentional deviation from the
schedule requires formal approval, should be a basic part of all project
plans.

--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

In our projects, we often have tasks that are dependent on external

actions, e.g. client needs to send us info before a task can start. We also
have internal actions that can keep us from starting a task. Examples of
this are managers unable to review work in time, computer renders are backed
up in the rendering farm, inserts from other projects taking precedent.

My question is has anyone come up with a way to plan this so that in the

current day, there is no chance of a task not being ready?

So far, we have implemented these two methods:

1. Created a text column labeled "Status" with four values, Ready,

Committed, Not Ready, On Hold. The manager would have to "status" each task
daily.

Ready = Task was ready to start
Committed = Client promised info; 90% chance of task being ready to start
Not Ready = Task was not ready to start; keep out 3 days
On Hold = Task was on hold; push out 2 weeks

We ended up with too many days where work was assigned for the current day

but the task was not ready; either Ready tasks were not really ready, or
Committed tasks didn't come in. It became too much work for me to keep the
managers "honest" and for the managers to evaluate every task, every day.

2. So, I came up the idea of having them set milestones for anything that

would keep a task not ready. After all, we're using MSP, why not use the
natural tools of the program instead of adding another dimension of
complexity. We also set a rule to add a 1-day lag after each milestone.
This way if a milestone is not met, the current day is not affected. Now,
this is not working because it becomes cumbersome to add a milestone for
every situation, lack of discipline among the managers, or lack of time to
do it.

Is there a true-tested method out there to handle the readiness of a task?

Is there something in MSP that can manage that better?