Tasks that don't drive the Task Duration

[tshad]

How do you handle tasks that don't drive the Task Duration - have no effect
on it?

For example: I have tasks such as: "Ongoing testing"? There is no duration
and shouldn't affect the duration of the project.

Thanks,

Tom

 

[Dave]

First of all I think there is a problem with terminology. It is
impossible that the ongoing testing task has no duration. If you are
doing work on it in you project then that work will take place at
certain times so its duration must at least exceed that.

Similarly, how can the testing task not drive at least the end milestone?

It is not clear what it is that you are testing. My question would be
are you testing something that your project has produced or is it
something already existing.

I think you should ask yourself what this activity is meant to achieve.
The title 'ongoing testing' seems to imply that the work is not
precisely scoped. Is there no way that you can define the activity so
that the testing is trying to show something specific such that a
certain functional behaviour or specification has been met? If you
can't do this, how will you know when it is complete (the danger is that
you have an open ended task which consumes money because people book to
it indefinately)?

Again, is it truly the case that nothing depends on the outcome of this
testing? If that is the case, then why are you doing it?

Dave

 

[tshad]

First of all I think there is a problem with terminology.

That might be true.

It is impossible that the ongoing testing task has no duration. If you are
doing work on it in you project then that work will take place at certain
times so its duration must at least exceed that.

I am mainly putting it there for notation as well as for testing that we do
as we are developing our software project. We have people that do some
testing but at no particular time (such as customer support). It won't
change the duration of the project as nothing depends on it. We just know
there will be about 5 days of various testing that is going to involve
someone that should be accounted for.

For example, I may be in the middle of working on part of a task and I may
ask someone to look at it while I go do another task. I don't necessarily
plan for it and it could happen 10 or 15 times along the way at different
times during the project. It doesn't affect the projects timeline at all.
But I assume it will take about 10 hours of someones time which should be
accounted for. There is no way to know if the time is going to be accurate
but it is a cost should be added into the project. A sort of "line of
credit" that you can draw on.

Of course, we have other testing points as well. These would be planned and
would drive the projects duration.

Similarly, how can the testing task not drive at least the end milestone?

It is not clear what it is that you are testing.

That is the point. This would be a general testing bucket that anyone can
use in the project and is not planned.

My question would be are you testing something that your project has
produced or is it something already existing.

I think you should ask yourself what this activity is meant to achieve.
The title 'ongoing testing' seems to imply that the work is not precisely
scoped.

It is scoped. Just doesn't drive the duration. We just assume there will
be 5 days of miscellaneous testing that doesn't take anybody away from their
tasks - so the duration wouldn't be affected.

Is there no way that you can define the activity so that the testing is
trying to show something specific such that a certain functional behaviour
or specification has been met? If you can't do this, how will you know
when it is complete (the danger is that you have an open ended task which
consumes money because people book to it indefinately)?

All other tasks would be scoped. This is just a buffer that takes into
account that there will be some unplanned testing that will natually take
place and will take someones time and hence a cost.

Thanks,

Tom

 

[Dave]

OK, so what do you mean by 'how do you handle'?

A couple of options spring to mind.

One would be a task running the entire duration of the project but with
only 5 days effort assigned to it. That in my view would run counter to
best practice.

Probably I would have a summary task for the 'general testing' and then
have monthly activities in order to track the overall expenditure. The
sum total of the effort on these monthly activities would then add up to
the 5 days effort you quote below.

Hope this helps.

Dave

 

[tshad]

OK, so what do you mean by 'how do you handle'?

A couple of options spring to mind.

One would be a task running the entire duration of the project but with
only 5 days effort assigned to it. That in my view would run counter to
best practice.

That would work.

Actually, If I set up the task to depend on the first task and have nothing
depending on this task it wouldn't drive the duration at all.

You may be right on best practice - but I personally think having this task
is more realistic. A task for unforeseen work that is incidental but still
something that should be accounted for, kind of like Petty Cash.

Probably I would have a summary task for the 'general testing' and then
have monthly activities in order to track the overall expenditure. The
sum total of the effort on these monthly activities would then add up to
the 5 days effort you quote below.

Not quite sure how you would set that up but that defeats the purpose.
Perhaps: "Misc Task Jan" 1 day, "Misc Task Feb" 1 day, etc. The monthly
activities would have to have durations as well. The problem is that this
is not 1 day per month type of task. You may not use it at all the 1st 2
months but may the 3rd month. This is the problem with budgets. At the end
of the year you need to spend anything extra so as to use up the budget.

Thanks,

Tom

 

[Dave]

Not quite sure how you would set that up but that defeats the purpose.
Perhaps: "Misc Task Jan" 1 day, "Misc Task Feb" 1 day, etc. The monthly
activities would have to have durations as well. The problem is that this
is not 1 day per month type of task. You may not use it at all the 1st 2
months but may the 3rd month. This is the problem with budgets. At the end
of the year you need to spend anything extra so as to use up the budget.

Thanks,

Tom

I don't think it does defeat the purpose - although admittedly it is a
little (very small amount) of extra work. The point is that there is a
total of 5 days work totalled in the summary task. You may have to
move the work around from month to month a little, but this avoids
having large open ended tasaks which I don't like. So if no work was
carried out in February, you put that work in March. If March used up
too much effort then you borrow from April.

 

[Steve House]

But it simply must drive duration at some point. The duration of the
testing task is how ever long it takes to do the required amount. The
operative word there is 'required amount.' If the testing ISN"T required,
don't do it at all, it's just a waste of resources. It may be that you can
do it early enough in the project and in parallel with other tasks that it's
not going to be a critical task but that's another issue. If it gets
delayed to a certain point there will be nothing else in the project left to
do except the required testing and at that point it will drive the project
duration since the project isn't done until every bit of required qork is
done, including the testing.

 

[Steve House]

You apparently thinking of the project plan as some sort of allocated
work-hours budget spreadsheet instead of a work plan and schedule that
deatils who does what where, how and for how long. While it is partially
that, trying to focus on just that part of the process is going to give you
headaches.