Configuration Management
Do you know all the data your project consists of? And where is this data?
What exactly did you even send your customer in last week’s demo?
Controlling your versions and baselining your work products will be a tremendous help if your customer inevitably changes their mind. You don’t need to be afraid of change: it’s to be expected that your customer’s ideas evolve as you build their product for them. But only if you know with certainty what was agreed and what was delivered, and when, you are well equipped to talk to them about the consequences of change. Be they related to scope, cost, time, or anything else.
The gospel
The CMMI handbook says
The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.
Lots of big words, but the idea is simple: make sure you record everything you use to create your products, in such a way that you can find it again. Even a year later.
What does that mean?
Configuration Identification: Making sure you store everything you use for your work
This can be source code, emails, media, contracts, specifications, tools, build environments and everything else (called “configuration items” in CMMI-ese). Thought experiment: grab a brand new PC. Do you know exactly what to do to get a working environment with all necessary files and all programs (in the correct version, with the right configuration) to recreate your current product?
Try not to miss anything, even text message conversations with your customer. Find a way to preserve it all.
One good approach would be to stick all your data in a version control system, such as Subversion or Git, but just collecting everything in a designated directory may be fine as well. Whatever works for you.
Version control: tracking change and giving it meaning
While this is an article in its own right (even an entire series in fact), it deserves mention here.
It is very valuable to record the history of a document’s creation. What was changed, and when, and perhaps by whom.
A possibly even more valuable thing to record, however, is the nature and reason of this change. Writing decent versioning comments (which is an art to be explored in depth in a different article) is a note to your future self. Why did you do this, and what exactly is “this”, anyway? If you work together with others, it’s even more useful as a tool to communicate your intents and decisions to your coworkers.
Configuration Management and Baselining: Making sure you know exactly what went into creating a specific product version
If you deliver a product to your customers, ask yourself this: are you able to recreate exactly the thing you shipped to the customer six months ago? If you create software, for instance, do you know which version of a particular library you used? Can you find it again? What customer specification was current at the time of this delivery? What did the draft logo look like back then?
Handling descriptions which explain exactly what something is made up of, is called configuration management.
And one such description, kind of a snapshot of all your configuration items, is called a baseline.
A baseline will usually be a list of documents (specifications, contracts, agreements) with their respective versions or dates as well as a way (perhaps a revision ID or tag, if you use version control) to identify the files and other items and their content exactly as they were the moment you decided to create this baseline.
Controlling change: No one gets it right the first time. And that’s OK.
Now you have all these building blocks in place, and it’s not even lunchtime yet. But now we can begin to really reap the benefits of the system you just created.