standardize while at the same time will give us the leverage to customize. And let's use tools that help to document the process and provide process guidance without us having to write detailed process documentation that will end up on a shelf somewhere.
The third key to unlocking the puzzle is to approach process and tools from a role perspective. It's fine to specify the state flows for the various objects in the repository, but if we can't view these from a role perspective then the learning curve skyrockets, and user rejection of process increases. Process definitions and tool interfaces must be role centric. Ideally, processes can be described fully and tagged appropriately so that role-based descriptions result from a central process definition repository. Similarly, although tool components, especially menus, to-do lists, dashboards and work stations can be defined in such a way as to provide a wealth of generic capabiliites, they must also be appropriately tagged so that the proper components and information appear for each role.
Use the Plan to Achieve Your Goal
A CM Plan can be a top level document that then fans out into a number of how-to guides, strategy documents and other such process guides. But ideally, we want a plan that can go right from the overview to the tool, with very little training in between. Achieving this goal means:
- Ensuring the process is natural and straight-forward,
- Working to establish generic frameworks for process that are well known in the industry,
- Identifying and using tools that are process-centric and that support adequate customization, and
- Integrating role-specific process guidance into the tools being used.
Moving into the next generation of CM/ALM tools, recognize that process support and easy-to-use customization capabilities are a must. Don't sell yourself short by buying into technology just because you have the expertise on hand to support a particular tool. If anything, the fact that you need such expertise should raise an alarm. The desired expertise is on process, not tools. If the tools can't support the process or provide too complex or costly a customization path, look elsewhere. There are CM/ALM tools out there today that meet these reqiurements. As data management and ALM functionality converge with process engines, there will be an increasingly rich set of choices.
So write your CM Plan. Review it with a view to simplifying your development organization by using newer methods and better processes. Are there huge areas of uncertainty on how to bridge the gap between the Plan and the development Team? Or between the Plan and the Tools? Work the plan, work the technology, and use Team input, until the uncertainty shrinks into clarity. Use CM Crossroads and tool vendors as your resources. Ask not how you can write a CM Plan, but how your CM Plan can be used to drive your Process and Tool goals.
To everyone who reads my column, thank you for your support throughout the year. We end 2008 in turmoil, but really, its our job to help to streamline our organizations, not just by providing better CM/ALM, but by presenting a model of operation and improvement that can be used by the rest of the organization. CM/ALM is a backbone technology, and the underlying next generation technology will reach well into all aspects of the organization. Have a Merry Christmas, a Happy Chanukah, and a prosperous year ahead!