Effective software management is not just having a tool that records who made what change to the code or documentation. It is also the thoughtful creation of naming conventions, policies, and procedures to ensure that all relevant parties are involved in changes to the software. It means that:
- Everyone knows how to report a problem.
- Everyone knows how to request a new requirement.
- All stakeholders are informed of suggested changes and their opinions are solicited.
- Change requests are prioritized and scheduled.
- Versioning is figured out.
These things used to be recorded in a document called the software configuration management plan (SCMP). It would be written early in a project and get approved around the same time as the software requirements specification (SRS) is approved. These days it seems that no one makes these plans. Instead expecting their tools to tell them what to do when they start a project which results in some lopsided projects. For example, most teams I know report problems using JIRA internally. Some provide JIRA accounts to their users to report problems externally but few combine the two which results in a skewed view of product. A developer view vs a user view.
I could give more examples but that would be getting away from the point:
At the start of each software project, round up the stakeholders and have them agree to how each of the above bullet points will be handled. Make special effort to ensure that there are answers for internal vs external and a way to blend the two views.
Reference:
Bersoff, E., Henderson, V., and Siegel, S., Software Configuration Management, Englewood Cliffs, NJ: Prentice Hall, 1980.
