Confessions of a Non-Believer
by Larry Malopy
Armed with my newfound insight into CM, I started asking my customers some questions that produced some interesting replies.
"Why are you doing this?"
"Because I want to" or "because I was told to."
"Are any of these requirements written down?"
"No, too busy" - the most common answer.
The software people do not want to be encumbered by documentation. They need the freedom to be creative as they produce code. Checking code in and out of a central repository is too restrictive. It smacks of big-brotherism.
More important, programmers operate like the guilds of yore. Only people within the craft can have knowledge of how the program was put together. But even then, only the original programmer has real knowledge of its construction. Like the guilds, this protects jobs.
The network and hardware people also had their reasons why designs could not be documented and kept updated. Network people needed to be able to reconfigure their system as loads changed.
For similar reasons, hardware people needed to move or replace hard disks, printers, modems, etc. on systems which had been bought and identified for one purpose, but which were now being used for something altogether different.
The bottom line is that people do not want to look bad each time some software code needs to be corrected. If under change control, and if the change activity is high, it would be obvious that the design activity is not right. To document what we did could be very embarrassing and career limiting. This is why change management/configuration control are so difficult to implement.You're Full Of It!
So there I was, at my first CMII Awareness presentation and this guy tells me that the product of engineering is documentation! Come on! I've been an engineer, a noble profession, for 30 years We take theory and produce useful things. We make things happen. Am I to believe that I have been producing paper all this time..
I am also a computer scientist. Obviously, these CMII people have never experienced the rush of having written a particularly elegant module of code. Do you mean that the wonderful software program that I wrote was generating documentation?
As the months passed, I thought about documentation and its importance. As I played the design process through in my head, I realized that I, indeed, tried to capture an idea or concept in graphic form first and it eventually found its way to hard copy or digitized form on my computer.
If the idea had merit, I would want to protect it. I would review the latest patent and copyright laws. I would want to know if these laws had changed as I was developing my idea. Say, this sounds like Level 0 documentation that was addressed in CMII.
Now I've got to find financing that will make my idea a reality. This means presenting the concept in a manner which others will understand. It means tailoring the presentation to the audience which could result in several versions of the same concept. I will need to know who received each version and I will need to record their reaction. All of this requires documentation.
The key to implementing CMII or any CM process is understanding the organization's prevailing attitude toward change management. If the "corporate culture" is a closed one, then be prepared for resistance to the implementation of CMII.
We learned in Course I that CM could also be defined as "communications management." If your enterprise is comprised of islands of information, the first challenge is to foster the idea that information is shared but change is managed.
When faced with a closed corporate culture, how do you go about changing it so that CM has a chance of being accepted? Replacing the CEO with someone who fosters open communications is one way - - but that is not an option that is available to most CM practitioners.
What seems to work well is to identify key people in each of the major functional areas of the enterprise who realize that a problem exists and who are interested in working toward a solution.
Formation of a CM work group is relatively easy if initial demands are light and if management is approached on the basis that you want to explore possible ways of improving the change process for the company. (Now is not the time to break any sacred cows - - only form a core group of CMII believers).
Our objective is to create a trend, not a fad. Even managers most entrenched in their ways are savvy enough to listen to the troops. If the CMII approach is embraced long enough and by a number of different voices, managers will soon embrace it as their own idea - - mission accomplished! The Future For Change Management
A survey of 200 IS Managers in Computerworld Client/Server Journal's June issue, shows change management to be among the "hot spots" of skills most difficult to find. IS professionals with these skills can expect a 15% premium on salaries paid.
For those of us who entered the profession through the defense and aerospace industries, we knew that CM was required by contract and that its value was often questioned. As the birthplace of CM, these industries so institutionalized the procedures that they became almost impossible to implement.
Perhaps CMII does not answer all of my questions, but it does provide me with an excellent template to base my approach. It is a systems approach which can be applied to the life cycle of a product. It is also based upon continuous improvement, which is indispensable in the competitive marketplace.
I believe that organizations will place more and more emphasis on documenting their designs and processes. Their vision must be communicated. The information must be shared, protected and improved. CMII meets these requirements and gives us a common methodology which is vital for our future growth as a discipline.
Institute of Configuration Management Scottsdale, AZ 85261-5656 Tel: (480) 998-8600 Fax: (480) 998-8923 Email: info@icmhq.com