Very Computer

> Has anyone implemented a CCB (Configuration Control Board) at an
> organizational level instead of at a project level? i.e. multiple
> unrelated projects working with one CCB.  I'm interested to know how
> effective it was.

> Thanks,

> Sent via Deja.com http://www.deja.com/
> Before you buy.

> A caveat to what follows is that it depends on the size and structure
of the
> organisation under discussion. What follows applies to large
organisations,
> many projects and many developers. If your organisation is small say
twenty
> developers with two or three projects and string, involved central
> management then a single CCB may work.

> Generally, in organisations with sufficient commitment to the CM
process, I
> instigate a CCB hierarchy rooted at the most senior level within the
> organisation. Each CCB then delegates to 'sub-CCB'. Each CCB can
create new
> 'sub-CCB' to delegate further, according to the needs of that CCB.

> Obviously a CCB can delegate only those responsibilities it already
has.
> Each CCB has a document detailing it responsibilities and the
constraints
> under which it operates. and usually produces a summary report of its
> activity to the parent CCB.

> Changes are handed first to the most local CCB (so on a small project
this
> would be the project CCB, on  a larger project each sub-system may
have a
> CCB).  If the change is beyond the remit of the CCB it is passed up
to the
> next most senior CCB and so on until it reaches one that can make a
> decision.

> This sounds rather long-winded but works very well in practice since
most
> changes that are beyond the scope of a local CCB require more
consideration
> because they involve larger budget or resource considerations the
addiitonal
> time needed to pass t up to an appropriate CCB is inconsequential.
> Furthermore, with careful consideration, changes can be expedited by
change
> managers very quickly.

> Organisations that have adopted this scheme have seen turnaround
times on
> change management increase because most change management is
localised but
> all changes are managed at the appropriate level and consequently
changes do
> not "get lost" which is common when this sort of CCB hierarchy is not
used.

> The problems with a large central CCB are manifold:
>     - Size
>         These CCB tend to get large because everyone wants to have
input.
>     - Vested interest
>         The politics of the CCB are such that these larger
centralised CCB
> tend to lose their way because they do not have a clear central
objective.
> Project CCB are very focused on progressing "their" project, a
central CCB
> has no such ownership concerns driving it.  Consequently smaller
project's
> changes can get lost among the larger organisational concerns.
>     - Overload
>         This one is just common sense and simple arithmetic.  If you
have an
> organisation with say 10 projects each one handles 10 changes a week,
this
> means that the central CCB will have to deal with 100 changes a
week.  Many
> software projects deal with considerably more changes than
illustrated here
> and the problem of overload on the CCB results in changes being
prioritised
> down a long list and perhaps never receiving the attention they need.

> Hope that helps.

> Regards,
>     Mark Bools
>     Inspect (UK) Ltd
>     http://www.inspect-uk.com

> > Has anyone implemented a CCB (Configuration Control Board) at an
> > organizational level instead of at a project level? i.e. multiple
> > unrelated projects working with one CCB.  I'm interested to know how
> > effective it was.

> > Thanks,

> > Sent via Deja.com http://www.deja.com/
> > Before you buy.