[kplato] Scope and Change Control (was Planning and Analysis 101)
Brad Hards
kplato@kde.org
Fri, 15 Jun 2001 21:45:20 +1000
Chris Clarke wrote:
>
> On Thursday 14 June 2001 14:41, Chris Herrnberger wrote:
<snip>
> 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.
Any usually defined differently in each contract, and in each company.
> 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.
Definately needs to be a seperate, but linked, tool. There are a few tools on
the market (I've used Requirements Database Tool, which is basically a front
end on Access; and I've been on the receiving end of DOORS
(http://www.telelogic.com/products/doors/), but none that are free, and
nothing that I'd say really provides any insight.
> 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.
I think that the easiest way to do this is to treat the "replanning" as a task
of its own. The typical process that I have seen is to have a WBS element that
is called something like "Contract Management", and then you just raise tasks
under that for each change to the overall scope.
So, in WBS terms
X.Y. Contract Management
X.Y.1 Contract Change Proposals
X.Y.1.1 Contract Change Proposal CCP-2001/01
X.Y.1.1.1 Engineering Assessment
X.Y.1.1.2 Logistics Assessment
X.Y.1.1.3 Replanning Activities
X.Y.1.1.3.1 Modifiy Plato
X.Y.1.1.3.2 Gaze at Navel area
X.Y.1.1.4 Contract Amendment drafts
X.Y.1.1.5 CCP review
X.Y.1.2 Contract Change Proposal CCP-2001/02
Since this is usually a defined action (on big government contracts, in any
case), you probably just want to pull up one of a couple of "pre-built" tasks,
say one for "contractor initiated changes", one for "Buyer initiated changes",
one for "no cost CCPs", or whatever. That is why in my first rant, I asked for
the functionality to insert "pre-defined" tasks or "preb-built" modules of
work, hopefully with some smarts that allows "automagical" customisation.
Brad