module or a workspace a directory will add to
confusion. You'll either have to put more money into training or put up with the data entry errors the foreign terminology leads to.
Your process is well understood by your team. Make sure you take the time to tailor the tool to match that process. And part of that includes hiding any functionality that is not specific to the user's role. Some tools have hundreds of buttons, menu items, etc. If all users have to see all of them, they'll never find what they need. So hopefully you can customize the tool so that only an hour or two of training is required for each role. If not, take the time to write a compact role guide which gives the specifics for how to use the tool for all of the actions in a given role. Include a single page quick reference sheet
that can serve as a reminder until the team members are more familiar with the tool. And a separate advanced guide/sheet might help those who are more ambitious.
9. Automate Administration to Remove Human Error
Administration can be a costly aspect of your CM solution. I've heard horror stories,
and I'll bet you have too. Excess administration is also a road block to process improvement, primarily because of the impact on all of the administration resources. But the worst part of admin-intensive solutions is that human errors will cause both decreased quality and lower productivity. If you can automate your administration, do so.
And keep going until there's no more to automate. There are solutions out there which claim to require a fraction of a person for CM administration. And I believe these claims in some cases. What are they doing right that your solution can't do?
8. Enforce Change Traceability to Features/Problem Reports
If your developers are creating changes without authorization, your product quality will eventually suffer. Every change needs an authorized directive, whether an approved/assigned problem report, an approved development activity/feature, or a work authorization. Only then can you direct what's going into your product releases.
But that's only half of the picture. If your team's changes are not linked back to the authorized record (i.e feature/activity or problem report), they may be marching to their orders, but you won't know what state the product is in. And if problems arise, you'll have a difficult time tracing them back to the source. The best way to force traceability between changes and features/problems, is to force the user to select the problem/feature in order to create the change package (or checkout a file). The user interface actions should trigger automatic traceability information between the selected problem/feature and the
change package (or file revision in the worst case).
If your tool can't enforce this traceability, your team will have to spend time defining the traceability, either by entering information into different areas of the solution at checkout time, or by audit (and linking action) at the time of code review. Your code review should be a time to do part of your configuration audit - that is ensuring that the code changes match the request. But if the request is not traced to the code changes, this will be difficult at best, and your process will not be bullet proof.
7. Main branch per release vs Main Trunk
Do you want to start a good debate in your organization? Bring up this topic. Is it better to have a single Main trunk to which all changes are eventually merged or to have one main branch per supported release?
Well to start with, all changes are never merged to a single Main trunk. With a Main trunk, the team has to decide which release the trunk reflects. Changes not made to that release have to be made somewhere else. If they're for future releases, they'll eventually get merged to