How software configuration management help in improving project management?

Question

Which best practice involved in software configuration management to help in improving project management?

Answer 1

It mitigates a whole bunch of project risks, including:

• The risk of making a change which is found to be incorrect: SCM software allows you to see the change and roll back
• The risk that you could lose all your source code (much less likely since everyone has a copy on their machine)
• The risk that two people could make incompatible changes: good SCM will allow you to merge the two and get the best of both worlds.

Also, these days SCM is so easy and cheap to set up that embarking on a software project without it is madness.

Answer 2

Assuming you're really focused on best practices, I can outline a couple of possibilities.

Using the best (SCM) tools available. While this might depend on your specific goals and constraints, Mercurial and Git are hard to beat (distributed, excellent branch/merge capabilities, multiplatform, FOSS, really fast, flexible workflow etc.).

You can analyse the data in your source repository using a tool like PanBI (disclaimer: I wrote it). A short screencast shows off what you can learn from repository contents analysis. In brief:

• general work dynamics on the codebase
• breakdown per developer
• daily work dynamics
• type of changes to the codebase (add/remove/modify), part of the source tree

...and much more.

Connecting an SCM tool with an issue tracker can also add value. Developers place issue ID's in commit messages, e.g. "[#1455]: improved performance a bit" and the issue tracker relates the issue with the changes in the code repository. From a project management perspective, this allows you to loosely track the time spent on individual issues, project phases or complete projects. A simple commit hook refusing commits without an issue number can go a long way in ensuring data consistency. Such "measured" data can be compared to the baseline to understand what's working and what isn't.

Building official releases on a build server from a tagged source version pulled from the repository could also be considered beneficial from a project management perspective because it's a way to control quality. Building software this way detaches the build process from any dependencies or specifics of developer machine environments, provide reproducibility, allows robust automatic/semiautomatic publishing of the build etc., i.e. streamlines and shields parts of the deployment process.

These are just some of the possibilities, it doesn't stop here.