The approach doesn't just ask, “Can you meet our requirements and how well?” It focuses on the project process and operational aspects of that process.  It says, “This is our process.” How well can you support it?  What changes would you make to give us an even better process?  What capabilities does your tool have that will enable our users to readily support our CM plan while increasing their productivity?

So perhaps this begs the question:  Should a CM plan be part of a vendor's solution?  Certainly each vendor's tools have their strengths and weaknesses.  Some even bundle the tool around a specific process.  However, if the process doesn't fit the organization or project, how can the CM Plan be a solution asset?

The Three Keys
There are a number of keys to unlocking this puzzle.  The first deals with process standardization.  It's true that one process does not fit all organizations.  A small number of process standards will, however, cover a majority of projects.  Across the ALM functions, there are common components that are, or should be, a part of every project's process:  gathering requirements, customer request tracking, problem reporting/ defect/issue/bug tracking, to name a few.  There are also cross-function components: state-transition flow, role definition, email triggers, etc.  Some functions are very specific detailed pieces, while others are more generic components.  Still, even if we could identify a small number of process standards and process components that widely apply, most projects have some very specific process requirements.

So the second key deals with customization.  Any process you start with is not going to be the same as the one you end with.  Any two projects are going to have differing process requirements - maybe not so much overall, but in the details or in the design management arena (i.e., traditional vs. agile development).  Process definitions and CM/ALM tools must be able to support both a generic process framework and specific process variants.  They must allow for customization not only between projects, but also during the lifetime of a project.  Ideally, the tool will also support different processes for different releases.  These would include the following steps:  release 1, initial process; release 2, new improved process; release 3 and forward: ultimate process.  Most would settle for an easy way to continually improve process.

Now having the ability to support a changing process does not mean that the environment comes with a compiler and/or scripting language that experts can, for an appropriate fee, use to morph one phase of the process into another.  It means that the project office itself can fine tune process as the need occurs and can plan for and make tool environment changes for larger process improvements without needing a customization department in the organization.  The language of the tool environment needs to conform to the language of the CM Plan and of the Process documentation.  We don't need another area where the real world is different from the technology - relational databases already give us that head ache where we need someone to map the real world problem onto relational data schema, and then we need someone to map the data back to the real world so that we can understand it.

Instead, the tools we use for process definition, as well as the tools we use for CM/ALM functions themselves, must be easily customized to speak our language.  Process definition has common components across projects.  So do CM/ALM functions.  Let's then create an environment and dictionary of common terminology and real-world actions that will help us to 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 capabilities, 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 that 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
• 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.

Write your CM Plan.  Review it with a view to simplifying your development organization by using newer methods and better processes.  Are there areas of uncertainty on how to bridge the gap between the plan and the development team?  What about 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, it is our job to help to streamline our organizations.  This is done not only by providing better CM/ALM, but also 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 Hannukah, and a prosperous year ahead!