P
paul
I'd like anyone's opinion on dealing with a change of scope on a
software project. For example, I have a schedule with several tasks
(Feature1, Feature2, etc.), with resource assignments, baselined, and
some actual work recorded against each. In the course of execution,
it becomes apparent that Feature 1 was poorly estimated (or unforeseen
problems came up, or assumptions were not valid, whatever), and a
decision is made to cut that feature. (Assume the work to "remove" it
is negligible.)
I don't think I want to set RemainingWork=0 (or %Complete=100) because
the feature is not done. I don't want to just delete the task because
some cost has actually been incurred. I've thought of renaming the
task to reflect it's cancellation (e.g., "Feature1 - Cancelled") with
%Complete=100, but then we lose information about how far along that
feature really is/was at the time it was decided to stop work on it.
I also don't want the earned value picture to be skewed - i.e., I
don't want the EV to equal the original total task PV, but I think I
can get around both of these problems by setting the EV Method for
this task to Physical%Complete and manually entering the appropriate
percentage. On the other hand, I don't know if I want to carry this
"penalty" around for the rest of the project. (There will always be a
variance by doing this.)
So that motivates the possibility of rebaselining, probably just that
one task, so that PV = EV = AC (to date, and NOT the original PV for
the entire task).
Does anyone have any best practices for handling this type of
situation? Am I asking for trouble with any (all?) of these
approaches?
And lastly, what are your thoughts if you are planning a version 2
product that will include the problem feature? (I'm guessing enter
the revised remaining work, arrange the predecessors to shift the task
into the ver. 2 timeframe, and rebaseline that task.) Is it common to
keep this in the same .mpp or do most people treat ver. 2 as a
"separate" project?
Paul
software project. For example, I have a schedule with several tasks
(Feature1, Feature2, etc.), with resource assignments, baselined, and
some actual work recorded against each. In the course of execution,
it becomes apparent that Feature 1 was poorly estimated (or unforeseen
problems came up, or assumptions were not valid, whatever), and a
decision is made to cut that feature. (Assume the work to "remove" it
is negligible.)
I don't think I want to set RemainingWork=0 (or %Complete=100) because
the feature is not done. I don't want to just delete the task because
some cost has actually been incurred. I've thought of renaming the
task to reflect it's cancellation (e.g., "Feature1 - Cancelled") with
%Complete=100, but then we lose information about how far along that
feature really is/was at the time it was decided to stop work on it.
I also don't want the earned value picture to be skewed - i.e., I
don't want the EV to equal the original total task PV, but I think I
can get around both of these problems by setting the EV Method for
this task to Physical%Complete and manually entering the appropriate
percentage. On the other hand, I don't know if I want to carry this
"penalty" around for the rest of the project. (There will always be a
variance by doing this.)
So that motivates the possibility of rebaselining, probably just that
one task, so that PV = EV = AC (to date, and NOT the original PV for
the entire task).
Does anyone have any best practices for handling this type of
situation? Am I asking for trouble with any (all?) of these
approaches?
And lastly, what are your thoughts if you are planning a version 2
product that will include the problem feature? (I'm guessing enter
the revised remaining work, arrange the predecessors to shift the task
into the ver. 2 timeframe, and rebaseline that task.) Is it common to
keep this in the same .mpp or do most people treat ver. 2 as a
"separate" project?
Paul