Time waiting for vendor review

[jetfan]

Two questions.
How do you show a time period in project where you finish a set of tasks and
then have to wait for a vendor to review and respond before you can move
forward with additional tasks?
How would resources be assigned to this time period?

 

[Steve House [MVP]]

I prefer an alternate approach to what Jack suggested. Since waiting for
something to happen outside the actual project work is not an actual project
activity, I don't like to see it as a project task at all. Tasks are
activity, but waiting for something to happen is by definition
non-activity - you're doing nothing in the project while you wait. So to
refelct this fact, insert two milestones in the project, "Submitted For
Approval" and "Approval Received." They are linked as predecessor/successor
with a normal FS link and a 2-week lag time is inserted into the link to
represent the fact that whenever you send it off to the vendor, you expect
to hear back from him in 2 weeks. The first activity that you do when the
project resumes after getting approval is then a successor to the "Approval
Received" milestone. I think that's cleaner than psuedo-tasks to represent
wait times.

 

[Jack Dahlgren MVP]

Steve,

Interesting point, but in my opinion lags are a bad idea. They are not
really clearer. You can not baseline a lag. You can not report variance off
a lag. You can not make an assignment or specify a responsible person for a
lag.

It is work on the project, it is just not being performed by you. Having an
schedule which integrates all the activities is a good practice. Lags are
just not rich enough in properties to make them useful.

Or so I believe.

-Jack Dahlgren

I prefer an alternate approach to what Jack suggested. Since waiting for
something to happen outside the actual project work is not an actual
project activity, I don't like to see it as a project task at all. Tasks
are activity, but waiting for something to happen is by definition
non-activity - you're doing nothing in the project while you wait. So to
refelct this fact, insert two milestones in the project, "Submitted For
Approval" and "Approval Received." They are linked as
predecessor/successor with a normal FS link and a 2-week lag time is
inserted into the link to represent the fact that whenever you send it off
to the vendor, you expect to hear back from him in 2 weeks. The first
activity that you do when the project resumes after getting approval is
then a successor to the "Approval Received" milestone. I think that's
cleaner than psuedo-tasks to represent wait times.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs

Two questions.
How do you show a time period in project where you finish a set of tasks
and
then have to wait for a vendor to review and respond before you can move
forward with additional tasks?
How would resources be assigned to this time period?

 

[vanita]

Hi

I would also like to go ahead with Jack's solution, because for the projects
that are multi enterprise in nature, it is required that we indicate
interrelated works of different agencies in the same schedule and this
schedule should be circulated to all the agencies.

This way everyone knows that what other works are dependent on their works
and every agencie's accountability is also created.

I hoe it helps.
Vanita
--
Project Management consultant and trainer
(e-mail address removed)

Steve,

Interesting point, but in my opinion lags are a bad idea. They are not
really clearer. You can not baseline a lag. You can not report variance off
a lag. You can not make an assignment or specify a responsible person for a
lag.

It is work on the project, it is just not being performed by you. Having an
schedule which integrates all the activities is a good practice. Lags are
just not rich enough in properties to make them useful.

Or so I believe.

-Jack Dahlgren

I prefer an alternate approach to what Jack suggested. Since waiting for
something to happen outside the actual project work is not an actual
project activity, I don't like to see it as a project task at all. Tasks
are activity, but waiting for something to happen is by definition
non-activity - you're doing nothing in the project while you wait. So to
refelct this fact, insert two milestones in the project, "Submitted For
Approval" and "Approval Received." They are linked as
predecessor/successor with a normal FS link and a 2-week lag time is
inserted into the link to represent the fact that whenever you send it off
to the vendor, you expect to hear back from him in 2 weeks. The first
activity that you do when the project resumes after getting approval is
then a successor to the "Approval Received" milestone. I think that's
cleaner than psuedo-tasks to represent wait times.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs

Two questions.
How do you show a time period in project where you finish a set of tasks
and
then have to wait for a vendor to review and respond before you can move
forward with additional tasks?
How would resources be assigned to this time period?

 

[Steve House [MVP]]

I disagree that waiting times are project work done by someone other than
you. Consider conducting a customer satisfaction survey. We have a series
of tasks culminating in mailing our survey to customers. When we get back
some percentage of the surveys mailed we can start our data analysis. But
we have to allow for postal delivery to the customer and return, plus some
period for them to get around to filling out the form. Once we mail the
forms. our project goes on hold until we get enough responses start
analyzing the data. As far as the direct project related work, the tasks
involved in preparing to send the survey and the tasks required to analyze
the data once we get them back, nothing is happening during the time we're
waiting. The forms have vanished into a black hole until they reappear
sometime later.

Your objections are exactly why I prefer lags for this particular situation.
Why would you assign a resource to a waiting time? That implies the
resource is doing something, performing some activity that is part of the
required project work that is to be scheduled by the PM. But waiting is a
period where nothing that is part of the project's specific tasks is taking
place, no project-controlled resources are involved, nor is whatever is
going on being scheduled or managed by the PM. As far as the project is
concerned, everything just stops until some unseen and undefined force out
there in the universe allows it to resume. Once things are handed off to
the external entity, nothing under the PM's control is happening and the
project is on-hold until the external entity hands control back.

The baseline of a waiting period is the difference between the baseline
dates of the entry events. Just as non-working time is backed out of
elapsed time to determine duration, a waiting time is non-working time and
so doesn't have a duration, thus can't be said to have a duration variance
either. The apparent variance is really the variance in the actual dates of
the entry and exit events versus their baselines. No one should be assigned
to a waiting period because no project-managed work is taking place and so
no project-controlled resources are being consumed by it. The responsible
person is just a footnote as to who to contact for information, they're not
under the PM control and are not a project resource, and this can be handled
by a note attached to either the milestone events of alongside the lag.
Using a psuedo-task to represent the wait makes it look like it's project
work being paid for in the project budget when in fact it isn't.


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

Steve,

Interesting point, but in my opinion lags are a bad idea. They are not
really clearer. You can not baseline a lag. You can not report variance
off a lag. You can not make an assignment or specify a responsible person
for a lag.

It is work on the project, it is just not being performed by you. Having
an schedule which integrates all the activities is a good practice. Lags
are just not rich enough in properties to make them useful.

Or so I believe.

-Jack Dahlgren

I prefer an alternate approach to what Jack suggested. Since waiting for
something to happen outside the actual project work is not an actual
project activity, I don't like to see it as a project task at all. Tasks
are activity, but waiting for something to happen is by definition
non-activity - you're doing nothing in the project while you wait. So to
refelct this fact, insert two milestones in the project, "Submitted For
Approval" and "Approval Received." They are linked as
predecessor/successor with a normal FS link and a 2-week lag time is
inserted into the link to represent the fact that whenever you send it off
to the vendor, you expect to hear back from him in 2 weeks. The first
activity that you do when the project resumes after getting approval is
then a successor to the "Approval Received" milestone. I think that's
cleaner than psuedo-tasks to represent wait times.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs

Two questions.
How do you show a time period in project where you finish a set of tasks
and
then have to wait for a vendor to review and respond before you can move
forward with additional tasks?
How would resources be assigned to this time period?

 

[Steve House [MVP]]

The way you describe your situation, I would agree that they are tasks that
need to be scheduled, not really waiting times at all. Effectively you're
handing a summary task showing in your master plan as a normal task over to
the external agency and letting them schedule the detailed subtasks
themselves. But it's still part of the project, not a waiting period.

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

Hi

I would also like to go ahead with Jack's solution, because for the
projects
that are multi enterprise in nature, it is required that we indicate
interrelated works of different agencies in the same schedule and this
schedule should be circulated to all the agencies.

This way everyone knows that what other works are dependent on their works
and every agencie's accountability is also created.

I hoe it helps.
Vanita
--
Project Management consultant and trainer
(e-mail address removed)

Steve,

Interesting point, but in my opinion lags are a bad idea. They are not
really clearer. You can not baseline a lag. You can not report variance
off
a lag. You can not make an assignment or specify a responsible person for
a
lag.

It is work on the project, it is just not being performed by you. Having
an
schedule which integrates all the activities is a good practice. Lags are
just not rich enough in properties to make them useful.

Or so I believe.

-Jack Dahlgren

I prefer an alternate approach to what Jack suggested. Since waiting
for
something to happen outside the actual project work is not an actual
project activity, I don't like to see it as a project task at all.
Tasks
are activity, but waiting for something to happen is by definition
non-activity - you're doing nothing in the project while you wait. So
to
refelct this fact, insert two milestones in the project, "Submitted For
Approval" and "Approval Received." They are linked as
predecessor/successor with a normal FS link and a 2-week lag time is
inserted into the link to represent the fact that whenever you send it
off
to the vendor, you expect to hear back from him in 2 weeks. The first
activity that you do when the project resumes after getting approval is
then a successor to the "Approval Received" milestone. I think that's
cleaner than psuedo-tasks to represent wait times.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs


Two questions.
How do you show a time period in project where you finish a set of
tasks
and
then have to wait for a vendor to review and respond before you can
move
forward with additional tasks?
How would resources be assigned to this time period?

 

[Jack Dahlgren MVP]

Steve,

Vendors are certainly part of the project. There can be and often are
deadlines set for review periods and the like.
I'd really worry if a PM was just sitting there doing nothing waiting for
"some unseen and undefined force".
In fact, I think I'd give them plenty of time to do that - just not on the
payroll.

The point is that review periods are under the control of the PM and a
project plan should model how they effect the project schedule. If you are
not managing them, then you are not a project manager - no matter who does
the work.

"That implies the resource is doing something, performing some activity
that is part of the required project work that is to be scheduled by the
PM. "

If it is a review of work done and is necessary for the work to continue,
then SOMEONE is doing SOMETHING and it is required for the project to be
completed. If it has humans involved (rather than waiting for the sun to
rise) then it can and should be managed even if that means just calling and
politely asking how the review is going.

-Jack

I disagree that waiting times are project work done by someone other than
you. Consider conducting a customer satisfaction survey. We have a series
of tasks culminating in mailing our survey to customers. When we get back
some percentage of the surveys mailed we can start our data analysis. But
we have to allow for postal delivery to the customer and return, plus some
period for them to get around to filling out the form. Once we mail the
forms. our project goes on hold until we get enough responses start
analyzing the data. As far as the direct project related work, the tasks
involved in preparing to send the survey and the tasks required to analyze
the data once we get them back, nothing is happening during the time we're
waiting. The forms have vanished into a black hole until they reappear
sometime later.

Your objections are exactly why I prefer lags for this particular
situation. Why would you assign a resource to a waiting time? That
implies the resource is doing something, performing some activity that is
part of the required project work that is to be scheduled by the PM. But
waiting is a period where nothing that is part of the project's specific
tasks is taking place, no project-controlled resources are involved, nor
is whatever is going on being scheduled or managed by the PM. As far as
the project is concerned, everything just stops until some unseen and
undefined force out there in the universe allows it to resume. Once
things are handed off to the external entity, nothing under the PM's
control is happening and the project is on-hold until the external entity
hands control back.

The baseline of a waiting period is the difference between the baseline
dates of the entry events. Just as non-working time is backed out of
elapsed time to determine duration, a waiting time is non-working time and
so doesn't have a duration, thus can't be said to have a duration variance
either. The apparent variance is really the variance in the actual dates
of the entry and exit events versus their baselines. No one should be
assigned to a waiting period because no project-managed work is taking
place and so no project-controlled resources are being consumed by it.
The responsible person is just a footnote as to who to contact for
information, they're not under the PM control and are not a project
resource, and this can be handled by a note attached to either the
milestone events of alongside the lag. Using a psuedo-task to represent
the wait makes it look like it's project work being paid for in the
project budget when in fact it isn't.


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

Steve,

Interesting point, but in my opinion lags are a bad idea. They are not
really clearer. You can not baseline a lag. You can not report variance
off a lag. You can not make an assignment or specify a responsible person
for a lag.

It is work on the project, it is just not being performed by you. Having
an schedule which integrates all the activities is a good practice. Lags
are just not rich enough in properties to make them useful.

Or so I believe.

-Jack Dahlgren

I prefer an alternate approach to what Jack suggested. Since waiting for
something to happen outside the actual project work is not an actual
project activity, I don't like to see it as a project task at all. Tasks
are activity, but waiting for something to happen is by definition
non-activity - you're doing nothing in the project while you wait. So to
refelct this fact, insert two milestones in the project, "Submitted For
Approval" and "Approval Received." They are linked as
predecessor/successor with a normal FS link and a 2-week lag time is
inserted into the link to represent the fact that whenever you send it
off to the vendor, you expect to hear back from him in 2 weeks. The
first activity that you do when the project resumes after getting
approval is then a successor to the "Approval Received" milestone. I
think that's cleaner than psuedo-tasks to represent wait times.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs


Two questions.
How do you show a time period in project where you finish a set of
tasks and
then have to wait for a vendor to review and respond before you can
move
forward with additional tasks?
How would resources be assigned to this time period?