CM: THE NEXT GENERATION of the CM Plan

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 there strengths and weaknesses.  And 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, one process does not fit all organizations.  However, a small number of process standards will cover a majority of projects.  As well, 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 report/defect/issue/bug tracking (we can't even agree on the terminology to use!), to name a few.  There are also cross-function components: state-transition flow, role definition, email triggers, etc.  Some are very specific detailed pieces, some are more generic components.  Still, even if we could identify a small number of process standards and process components that apply widely, 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 (e.g. traditional vs. agile development).  Your process definitions and your CM/ALM tools must be able to support both a generic process framework, and specific process variants, and must allow for customization, not only between projects, but during the lifetime of a project.  Ideally, the tool will coincidentally support different processes for different releases (e.g. Release 1 - Initial Process, Release 2 - New Improved Process, Release 3 and Forward - Ultimate Process).  But 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