[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