Cost of Quality & task lists

[Mr_DJ]

I'm a quality manager at an elearning development company and we've just
implemented EMPS - hurrah! However I've been getting a lot of grief around
the length of project task lists. The project task template is built around
our development cycle, which is great. The problem lies in that nearly every
task is broken out into Review, Revision and Change. This adds about 80%
more task lines. Let me explain why these tasks are broken out into Review
Revision & Change. As part of our Cost of Quality program, we (I) measure
how much time is spent on Review (inspection), Revision (this is time spent
on rework) and Change (stuff the client pays for i.e. out of scope). Is there
a way of capturing these custom tasks without having them recur throughout
the task list. Keep in mind that this is a linear approach with
dependencies. We work in a matrixed environment so there are no dedicated
teams.

Any of you who live in the Quality Assurance world should understand what is
trying to be achieve here.

Any input would be greatly appreciated.

 

[Steve House [MVP]]

Project plans are usually decomposed down into summary tasks for all of the
component deliverables and the individual work activities that go into
creating each one. It sounds like you're on the right track as far as I can
tell, though I'm not a QC/QA expert. If, for example, your project is, to
create coursware for the MS Office Suite, the module for MS Word is a
different deliverable from the one for MS Excel and each one would go
through separate Design, Review, Revision cycles. The only part I see a
possbile problem with is the "Change" attribute, since that is what triggers
a number of activities rather than being an activity, set of activities, or
a deliverable in its own right. The client asks for a change and that would
cause a revision cycle to start. If you have a number of changes, each one
will undergo the cycle repeatedly. If you make a revision, send it for
approval, then make additional changes, etc, each pass through the cycle
will occasion separate Review tasks and they can't be grouped together since
we'll review change 1 in February but not review change 2 until April
perhaps.

The rule of thumb in creating a WBS is to decompose into greater and greater
degrees of granularity until you get it down to the level of a one task to
one resource correspondence. That means that signifigant projects may have
hundreds or even thousands of individual tasks. So if you've been getting
grief about large task lists, depending on what you mean by "large," it may
be perfectly normal.