Determine How a Vendor's Tool Will Support Your Project CM Plan


In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

I've seen countless sets of requirements and RFIs come my way for acquiring new CM/ALM tools. However, it is a very rare occasion when I see a company actually publish (and send out) the project CM Plan to potential tool vendors. In my most recent encounter of this approach, the pitch was: How would you change this plan based on your CM/ALM solution for us? This project has it right—not just a set of requirements, but an actual CM Plan, and not so much, "What does your tool do?" as, "What will our CM Plan look like with your solution?"

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.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.