From Our Readers…

Recently, someone sent me an email that expressed frustration with the process of implementing CM tools at their place of work

"I have supported configuration management at my company for two years now. I develop procedures, but developers often pressure me to cut corners. If I don’t agree then they complain that I am not a “team player”. If I don’t follow the CM procedures then I get blamed if there is a mistake. We change development managers so often that I never know who I will be working with next. This makes it very hard to get any improvements implemented and accepted by the developers. I don’t understand how any CM professional can bring about process improvements with these “real world” issues in place."

Signed – Weary CM pro…

In reading this note it is obvious that there two separate issues:

1. Developers don’t want to follow the procedures and the CM practitioner is pressured into adopting shortcuts which do not comply with the established release process. The can result in the CM practitioner being held responsible for any resulting mistakes.

2. Frequent personnel turnovers make process improvement difficult, because each new development manager has their own idea of what should be done and does not honor commitments from made by previous development managers.

Let’s discuss how we can understand this environment and select effective interventions accordingly.

Open Systems Analysis and Planning

Ecologists and other scientists concerned with our natural resources are often faced with understanding “natural” environmental systems as well as recommending important interventions to safeguard our nation’s natural resources. In this field it is common to need to analyze environments (e.g. ecosystems) which are constantly changing. Outside forces (obviously beyond the scientists control) may impact the overall environment and make it impossible to achieve important goals (e.g. resource conservation or reduction in pollution). While Scientists may take the challenges of an “Open System” in stride, CM practitioners may find that this lack of control results in frustration and makes their goals impossible to achieve. It just doesn’t seem fair that we are asked to safeguard the code without the full cooperation of our colleagues and management. Industrial Psychologists call this “Corporate Justice”. Research shows that a lack of Corporate Justice (or perceived fairness) can significantly impact our own productivity and motivation (Tyler and Blader, 2000).

How Can we Learn to Deal With These Issues?

The field of Organizational Development has suggested that Open Systems Analysis can also be applied to organizations as well. In this approach we view the business environment as an “Open System” that is impacted by both internal (e.g. organizational structure, corporate politics) as well as external (e.g. economic, legal, regulatory) forces. “Resource dependency” refers to the degree to which an organization relies upon other organizations for resources (Cummings and Worley, 1997). Adoption of some tools may create a significant resource dependency (vendor commitment to support essential software development tools), such that the organization might consider which vendors are willing to creating strategic partnerships (at a reasonable price) with their customers. At the very least, we must understand how implementation of specific tools will impact the organization and it’s environment overall.

Integration as Part of Understanding the Whole Environment

The CM practitioner can also discover how CM technologies can integrate with other systems by looking at the entire environment (as an Open System) as well. Most of us (CM techies) narrowly focus on the technical aspects of tools exclusively. We are often consumed by our efforts to understand a technology such as a complicated requirements or defect tracking system. Many of us really enjoy the (technical) challenge of customizing the CM tools. Many CM professionals also do a great job of defining a repeatable process. Unfortunately, we may not always be good scientists when it comes to looking at the business environment as an “open system.” We miss the “big picture.” We obviously need to understand the business environment in a complete and holistic manner in order to effectively implement CM systems as well as other development tools (e.g. requirements, defect tracking and IDEs). One step in this effort is setting priorities so that we know which technologies can (and should) be implemented.

Setting Priorities

For example, trying to implement both a defect tracking system and new automated testing tool may be impossible in a busy work environment. A more balanced view may be to ascertain which of the tools should be implemented first. Perhaps automated testing has a great deal of promise and is very tempting to a seasoned Software Process Improvement professional. However, if we look at the organization as an “open system” we may realize that there just isn’t enough support for effective use of automated test tools at this time. Perhaps the organization is downsizing and we just don’t have the resources to do a good job of implementing automated test tools. However, a defect tracking system will preserve important knowledge that may be lost due to turnover or downsizing. If we look at the big picture, we will set the priority with implementing the defect tracking system first.

Refocus on Success

In this example, instead of feeling frustrated with the environment that will not allow us to successfully implement two important tools, we consider this important information that helps us plan for success. Instead of feeling frustrated, we must learn that all of information we collect can be diagnostic and helpful in achieving our goals. We need to have a framework for understanding our environment in order to effectively deal with all of the “people” issues that are part of any change management effort. We all come to these situations with our own beliefs and assumptions. It may be hard to sort out the information that we see and hear.

Understanding Assumptions

CM Practitioners must be aware of a number of important assumptions when understanding Organization-Environment Relations. The first is that a developer’s perception of the environment (and their resulting actions) is essential in implementing effective CM practices. This means that it is not enough to have a solid CM process. CM practitioners need to “sell” their ideas to their colleagues and provide excellent “customer” support in order to ensure that developers perceive the CM function as being helpful to the software development effort. Employees must also have consistent and accurate understanding of their environment in order to plan effective responses and interventions in order to establish an effective CM effort. Successful environments don’t just “happen,” they are, in fact, created proactively. CM practitioners must learn to create effective interventions to achieve their desired results.

The implementation process includes understanding both the overall environment as well as the organization’s history of responding to external and internal challenges. Planned change must be based upon realistic assumptions and goals that are in alignment with the core goals of the organization. The difference between the status today and the ideal situation can be essential in understanding what needs to be changed.

Implementing Open Systems Planning

Implementing a new defect tracking system, automated testing tools or changing the way that applications are deployed can involve significant time and resources. Documenting the steps (and publishing them via intranet) is essential for effective implementation. Setting priorities (with input from senior management) is essential as well as setting realistic expectations and goals. Understanding “discrepancy” is the most important input for Action Planning. Too often we feel frustrated when our environment poses challenges to effective implementation. Instead we should refocus our efforts to view discrepancies are being essential information that can lead to effective action planning (discussed in our May issue). It has been this practitioner’s experience that discrepancy (or dissonance) between the perceptions of senior management and those of the software developers may provide the most valuable information for implementing Open Systems Planning.

Let’s discuss how we might address the concerns (of our reader) that were mentioned previously using open systems analysis and planning. First, developers being resistant to procedures may indicate that we need to do a better job of including the developers in defining the CM process up front (thereby improving perceptions of fairness). A common complaint is that CM processes slow down the release process. Perhaps the current process really is too burdensome in terms of paperwork or procedures. It is often good to have an “express track” that can be used for development and (non-production) integration builds. It is usually sufficient that rigid procedures be followed for “Production Builds”. What is even more important is effectively communicating that the CM practitioner is in the business of sharing best practices. It is usually a good idea to represent CM processes as being the synthesis of many developers best suggestions, including those outside the organization (e.g. industry best practices). This approach can help to avoid the CM practitioner being perceived as being in conflict with the developers. Instead we are just sharing the ideas of the developer’s peers and colleagues.

Sometimes it is necessary to cut corners! “If we are not up and running by 8am we will loose a lot of business.” However, bypassing procedures should require approval from senior management. Senior management will usually appreciate the visibility into why the normal procedures are being bypassed. The CM practitioner must be viewed as being fair but disciplined and reliable. It is always a good idea to define the process and the escalation procedures to bypass the process. Publish the procedures on your intranet as a first step in communicating the process.

Forces of Entropy

Organizational turnover can demonstrate the need for processes being documented and published via an intranet site. Processes that require a minimum of paperwork and defined steps (e.g. light processes) will stand up better to changes in the organization. Turnover can also be used in the CM practitioner’s favor. These changes mean that the organization in a state of constant change. The CM practitioner who understands the overall environment is in an excellent position to plan effective changes in a dynamic environment. Selecting which tools can (and should) be implemented and supported is an essential task that can be best accomplished when looking at the organization in holistic way.

When we implement developer tools including requirements management, defect tracking, and IDEs, we must look at the organization in a holistic manner. Open Systems Analysis and Planning is an important tool in understanding Organizational Behavior. Remember knowledge is power and learning to be a good Scientist will help you be a more effective CM practitioner.

What Challenges are you Facing?

If you’ve got a tough “people” related challenge, at work, send us an email and we’ll discuss how to create an effective action plan to bring about effective change in your organization.

References

Cooperation in Groups, Procedural Justice, Social Identity and Behavioral Engagement by Tom R. Tyler and Steven L. Blader, Psychology Press 2000.

Organizational Development and Change, 6th edition by Thomas G. Cummings and Christopher G. Worley, West Publishing Company 1997

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment