Home 
CM Journal Articles CM: THE NEXT GENERATION of the CM Plan
CM Journal Articles CM: THE NEXT GENERATION of the CM Plan
|
 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 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 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:
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! Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com
Set as favorite
Bookmark
Email this
Hits: 4675 Trackback(0)Comments (0)
|
| Last Updated on Thursday, 23 July 2009 10:47 |
TrackBack URI for this entry
Subscribe to this comment's feed