How to plan software as a configuration item

Yesterday I got a question from a colleague about configuration items. In our projects we use a deliverable list to identify which items are being delivered by the project and which are being received from outside the project. To help projects plan their configuration items we have defined a deliverable list template.

The deliverable list template lists documents like various types of requirement specs, design specs, test specs, manuals, training materials, etcetera. It also contains an single entry for Software. Now the question was:

What software deliverables (and receivables) should a project plan for?

Obviously, the deliverable list template does not give much clues. But we know that the software consist of components, some of which are received from other projects or third party suppliers - and possibly modified by the project - and some of which are created by the project. Then, how do you know which software deliverables the project is going to deliver?

The answer is that it depends on the agreement with the customer of the project. The requirements agreed with the customer state what he will get, in terms of functionality, performance, quality and deliverables. And these deliverables should be listed in the deliverable list. If the requirements don't state the (software) deliverables, then apparently the customer does not care as a long as the functional and non-functional requirements are satisfied.
In that case, the architecture or high level design determines the software deliverables. Even more, the architecture determine which of the software components are reused from other projects or third party suppliers and which are created anew.

Okay, now that requirements and architecture/design define which software deliverables and receivables are applicable,

how do we plan in which release they are delivered?

For projects with a single (final) release, it is simple: everything is released and delivered at the end. For projects with multiple releases, like incremental development or iterative development, it is more complicated but still quite simple.

The total work of a project is divided in "work packages", chunks of work that deliver a number of (possibly internal) deliverables. These work packages are assigned to a release and this way it is determined that the deliverables of those work packages are delivered at that release. More precisely, the deliverables are packed together as a baseline and the baseline is released.

Now in many software development organizations, the work packages are handled just like problem reports and change requests. They are registered in the change control tool/database, and assigned to people and releases (or iterations). We could call them "work items"; the list of work items planned for a release or iteration (in a release plan or iteration plan) determines which software deliverables are released. You could list those deliverables in the deliverable list, but it is more practical and more accurate to generate a report from the change control database listing the work packages, problem reports and change requests assigned to a particular release or iteration.

Getting Things Done (GTD) made simple

For many years I have been looking for Getting Things Done (GTD) in a simple way. And now I have found one:

Monkey GTD at http://monkeygtd.tiddlyspot.com

It's a TiddlyWiki file with a very simple, very sparse user interface, yet extremely powerful and versatile. No wasted screen space, just plain and simple look-and-feel. Since it is a TiddlyWiki, it comes as a single (html) file, requires no installation except a browser supporting javascript. It works perfectly with Firefox.

You can create actions, ticklers and references. Actions are set next, waiting or future, ticklers are connected to a date at which they will appear on the dashboard, and references are just entries with no timing constraint. Each can be connected to a contactperson, a project, an area (e.g. a department), a context (i.e. a category) or a realm (e.g work, personal), and it shows and updates cross-relationships on-the fly. For example, if an action is connected to a person and a project, you will see the action from the person and from the project, but also from the area that the project is associated with.
Each of the entries are just tiddlers, with some additional features. A tiddler is a wiki-page in TiddlyWiki. This means that you can add (formatted) text, or change the title or other settings. And of course you can make ordinary tiddlers.

I also use it to first define an action (e.g. "Schedule meeting with Joe about CruiseControl"), then add my meeting notes (preparation notes and discussion notes) to it and finally change the action into a reference (e.g. "CruiseControl") or into a contactperson (e.g. "Joe Plummer"). This way I build up my own wikipedia, while also supporting GTD.

If you don't know TiddlyWiki, you definitely need to take a look since it is the simplest wiki in the world, yet extremely powerful and extended by macros and plugins.

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.