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
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:
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.
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.
Inspect (UK) Ltd
> 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.
> Sent via Deja.com http://www.deja.com/
> Before you buy.