Deliverable planning and control

For many people Configuration Management is little more than controlling the versioned storage of work products, sometimes extended with Change Control which is little more than controlling change requests and problem reports. But both boil down to something like an sophisticated database with a sophisticated tool, sometimes not even sophisticated.

But the real added value of Configuration Management is that it helps manage and control the project. Let’s have a look of a project in general first. In short every project is an enterprise, a journey, to establish a particular result of a particular quality, within the limits of particular resource constraints (typically money, time, people, technology, methodology, etcetera).

Every project starts with planning. Planning the result means expressing the results in items that will be delivered – if the project is executed according to the plan. Those items need to be identified (Configuration Identification), controlled (Configuration Control) and must be of a certain quality level expressed by a status (Configuration Status Accounting). So the first order planning of – the result of – a project already involves configuration management.
Secondly, these resulting items don’t fall out of the sky; they need to be developed. So every item will require at least one task in the planning that produces the item. Some tasks may even product multiple items, that’s OK. But every task needs input. So there we have a second order of configuration items.
Thirdly, these second order items need to be produced also, or they are inputs to the project from an external source. These can be requirement definitions, architectural definitions or even complete subsystem implementations from another project or a previous project.

Anyway, project planning strongly involves configuration planning, which is a responsibility of configuration management. In other words, configuration management is part of project management, at least during planning.

After the planning has been built up, which involves a lot of other things to be planned as well, the project is executed according to the plan. The tasks are being executed and the (planned) items are being produced as the result of the tasks. Some items may be produced iteratively, thus producing multiple versions of it. Anyway, these items (i.e. the versions) are stored in the CM system and status is assigned to indicate the progress of the item (how far is it “ready”? which is a quality attribute) and the maturity (how good is it? which also is a quality attribute). But controlling the versions and their status – and even the status of integrated items, which is a different thing than the status of the individual parts. This is all Configuration Management, which contributes to the Project Monitoring and Control of the project.

All I am saying is that the deliverable planning and tracking processes are both part of Configuration Management and of Project Management. That’s why we should not consider CM in terms of the tools, databases, licensing issues, disk or network performance issues, branching issues, access control, etc. Those issues are not configuration management, but they are IT systems management issues. Configuration management is a project management discipline that is concerned with managing the physical work products of the project.

About Frank Schophuizen (fschop)

Hi, my name is Frank Schophuizen and I am working as a consultant in CM, Agile and ALM for TOPIC Embedded Systems. I have over 30 years experience in software development in the technology industry, with the last 15 years mainly in process improvement, deployment and integration of methods and tools in the area of Agile (SAFe, Scrum), CM and ALM. I am strongly interested in the complexities of collaboration and integration in multi-project and multi-site organizations. I have worked with various technology companies such as Philips, ASML, NXP and Vanderlande, and with various tool vendors such as Atlassian (e.g. Jira, Confluence),IBM Rational (e.g. ClearCase, Synergy, Jazz products) as well as open source tools (e.g. SVN, Git, Jenkins, Trac, Eclipse). I am living in Eindhoven, the Netherlands, with my wife. We have 3 adult children. My main hobbies are classical music and photography.
This entry was posted in configuration management, planning, project management, tracking. Bookmark the permalink.

2 Responses to Deliverable planning and control

  1. Hi Frank! I agree to a large extent, tho not 100%. I do like to think in terms of multiple views/perspectives (as you know), and I think the logical or conceptual content “view” of CM is deinfitely conerned with the heart & soul of projects and project management: deliverables, the effort (tasks) that produce them, and the value they are supposed to realize (e.g., the functionality) when completed and delivered.That’s one reason why I think of CM as the “glue” (and “transport medium”) between the proposed concept and the delivered reality, that binds together features & requests to the tasks that implement them in the items that realize them in the versions that deliver them (and the underlying environment that facilitates it, or sometimes “debilitates” it).


  2. Frank says:

    Thank you, Brad! I am very honered that you comment on my blog, since I have great respect for your insights.I don’t get which part you don’t agree, since what you write makes perfect sense to me. Can you explain?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.