How to Properly Maintain a Single CM Team
You have your hardware and your software configuration management departments managing the same product. Their goals are really the same, but they often clash. Should you have a single CM team?
Yes, you should. But you’re not going to get there unless you do two things: Make sure each group fully understands the other and make sure you have tools that work for both hardware and software CM.
There’s a current LinkedIn thread dealing with this very topic—CM vs. SCM. A recurring question, and one that came up during my last presentation at the Canadian Space Agency, is “How well can a tool built for software CM (SCM)—a part of application lifecycle management (ALM)—also handle hardware CM (HCM)—a part of product lifecycle management (PLM)?” The response from Rick St. Germain, a respected CM consultant, was basically: CM is CM. ALM and product lifecycle management (PLM) have the same fundamentals.
And that’s the basis of the battle. There are lots of differences between ALM and PLM tools, but the CM fundamentals are the same. In his Forrester blog, Tom Grant wants to see ALM and PLM come together. The artifacts and management processes are virtually the same. Yes, there are some differences in hardware, like tracking part quantities in a design, and in software, like storing deliverables in the configuration management database.
The artifacts are things like requirements, test cases, test results, engineering change requests, updates, baselines, problem reports, documents, etc. The processes are similar, but also dissimilar, from one organization or project to another because of requirements dealing with cost, security, reliability, failure impact, deadlines, and product characteristics.
But there are more differences between organizations than there are between hardware and software within an organization. So a solution designed for ALM should be able to do PLM. However, most organizations are unable to so because their ALM solution is rigid or based on specific SCM components—version control, build automation, merge tools—glued together and then integrated with common CM management tools.
There are exceptions. For example, CM+® received CMII certification from the Institute of Configuration Management but only after demonstrating a combined hardware and software CMII capability. The key was to create a tool with the capability to expand functionality, so that both specific hardware and software CM requirements could be met, while sharing the common CM elements.
In this case, an ALM tool was expanded for PLM. It’s more difficult to go the other way, largely because ALM has to deal with storing the software and deliverables within the CM database. Physical hardware is not stored in PLM tools. Both have implications, but on the PLM side, it means more management functions; on the ALM side, there are specific merging, branching and revision history, and build automation functions that are not easily added to PLM tools.
Should hardware and software configuration management teams be combined? Tell me what you think in the comments below.
