went into which build, what were the issues, and how often was it released? Our tools hold massive amounts of metadata. But too few tools have the ability, without proprietary scripting at individual companies, to provide the bigger picture and demonstrate the real issues that affect our daily work and rework, and most importantly, the cost to the company's bottom line. How often do you see the data showing help desk call volume tied to release management, and further back to user training? We see the same mistakes project after project with the same or new user groups but there is little to show the costs of poor management. It's our worst repeatable process. Pushing those kinds of behaviors up to the level where something can and will be done about it is the kind of incremental improvement we need within the bubble to make it possible to cross the membrane and be heard.
Back inside the bubble we still have opportunities to make significant changes. Why can't I drag and drop a baseline label to a build icon and expect a complete object? Or drag two release labels to a merge tool and let it create a new branch or integrate to one or the other existing branches? Why don't I have a graphical presentation that shows me where all the defect reports point to in the code so I can visually see where the problems hit most? Maybe there's something the company can fix or even buy that will do what our problem code does, but cheaper and better. That's not to put ourselves out of business
but if you aren't providing the best value for the money or at least a competitive advantage, there are no ruby red heels to click together.
Our tools have so much to offer. Requirements management, version control, testing functionality and recording, build management, but we aren't correlating that with all the relevant information possible. It's like having a library of all the knowledge of a business yet it requires a ‘key' to open it. What's most important is that we can't imagine yet where all this could take us. Think about 25 years ago. Early 80's. What kind of person would you need if you wanted someone to create a web page, manage thousands of songs, control bank transactions electronically, and book a vacation? Today, you can literally take anyone off the street to do it. MySpace, Ipod, Orbitz, and virtually any bank's online account management make this viable. Does that mean we've dumbed our systems down? Not at all. We've simply put functionality ahead of logic, market need ahead of Orwellian regimentation. That's the kind of thinking we need to make the next leap. Linking all the functional areas, past production implementation for the true SDLC, across tools that are not traditionally CM concerns is the comprehensive approach that will keep us relevant and effective in the future.
Managing the finite detail is the core of what we do but we simply cannot allow it to be the only thing we do. Version control, branching and merging, and all the other aspects of the discipline of CM are part of the whole cycle of organizational life. We are effectively clinging to the coral while the pH balance of the sea changes around us and kills the reef. We have to provide our own ability to alter the pH balance of the sea in which we live. The only way we can do that is to get outside our bubble.
Randy Wagner is a Contributing Editor for CM Crossroads and a software configuration management consultant. His experience ranges from major financial institutions to multimedia multinationals to the Federal government. Working in small to large project efforts has given him a unique perspective on balancing the discipline of SCM and enterprise change management with the resources and willpower each