[kplato] Scope and Change Control (was Planning and Analysis 101)
Chris Clarke
kplato@kde.org
Thu, 14 Jun 2001 16:25:19 -0700
On Thursday 14 June 2001 14:41, Chris Herrnberger wrote:
[Configuration Mangagement]
> sure that one could very well be to the level of granularity described but
> some form of rudimentary doc and change order control needs be included as
> that is where money is lost/made: on change orders ie: scope creep with no
> control mechanism, perhaps a standalone but integrated, personally I would
> like to see this app as modular as possible.
I'm with you on the modularity.
Can you give us an idea of what aspects of change control you would like to
see integrated into the project? Having come from a government/military
contracting background I completely agree that scope creep is an issue
(especially when it becomes a scope explosion), and as a contractor keeping
the scope under control is definitely an issue with me.
The way I see it there are three issues with change control:
First we have the process of requesting, approving, and implementing the
change. This is largely procedural (define a process, stick to it) and I see
as outside the scope of the core project.
The second part is keeping strict configuration managment on the documents --
ensuring there is a central source for each document, keeping track of
versions and revisions, and keeping track of the change requests/change
orders. Tools are required to manage this (anything from CVS to manage whole
documents through to traceability databases to manage individual sentences),
and for the most part I see these tools as being outside the scope of the
main project. This is what I was thinking of when I was talking about a
seperate project with hooks into KPlato. Last I looked there was no good
requirements management/traceability software on the market, and I wouldn't
mind seeing some of that as a project.
Finally there's the task of costing the impact. This could definitely be
inside the scope, since it has a direct effect on the planning. I'm not sure
about our first milestone, but it would be nice to be able to track the cost
of scope changes and who initiated it.
[Snip work breakdown structures]
> partially: wb structures (usually completed on a team basis) are simply a
> method to take any task and break it down into it's rudimentary elements,
> assignments, with assigned costs/budgets estimated or actual costs (if
> contracted)
This interests me, and is something I would like to see included in the
project. Can you point me to any background information on this?
Cheers,
Chris C.
--
Chris Clarke
security@cfourconsulting.com
http://cfourconsulting.com