While CM’s lot as a “poor relation” to PM is not a universal view, it is a pervading attitude that is especially evident in software development organizations.  Even where CM is seen as an integral management discipline, as in the military domain where it was first formalized, CM can have an administrative and retrospective quality.

The fact is that CM is always necessary but less often desired. The common view is that CM is a passive discipline that does nothing to help (and can sometime hinder) projects deliver on time and to budget.

The increasing complexity of development projects and the reliance on pre-existing components or (legacy) systems have forced PM to consider the change management issues that are at the foundation of CM. Few projects today do not rely on or impact existing systems and components, making project managers more attuned to the requirements of CM.

For its part, CM has evolved to address more directly the activity-based issues that give rise to a changed configuration. Recent approaches to software CM have made some important terminology and conceptual shifts that have brought the CM world closer to the mainstream PM thinking.

Certainly the need for improved and convergent paradigms are never more evident as the crossover between CM and PM is also at the epicenter of the stresses and dissatisfaction that represent development in today’s environment.

This paper attempts to highlight the converging concepts and introduces a release-centric approach to CM that is aligned with PM terminology, offering a shared language and a richer, more unified management perspective for software development.

The CM – PM Nexus

While PM identifies and manages the activities necessary to achieve a project’s objectives, in software projects these activities commonly produce, modify or indirectly impact the systems that support business operations.

The discipline of PM provides the familiar techniques for planning, organizing, resourcing, scheduling and statusing the project, using tools like the PERT, Work Break-down Structure, Critical Path Method and Gantt charts. But the PM discipline confines itself to activities, traditionally leaving the management of the systems impact to CM.

This division of responsibilities between CM and PM has become increasingly blurred as projects have moved from single, independent efforts to the highly complex, distributed and interdependent activities conducted across a number of sub-systems we have today.

So while the current management paradigms that support each discipline are being tested and are evolving in response, the inescapable fact is that projects impact systems – it is the nexus between the disciplines of CM and PM.

As a maturing discipline, CM has proven to be more fluid and is increasingly extending it scope to the development activities that relate to configuration changes. CM tools have evolved from static repositories that managed the source configuration, to providing integrated work areas for developers’ code and unit test activities, and more recently to providing process support that assists the promotion of a configuration through a defined lifecycle.

This evolution of CM has changed the once back room, administrative and passive nature of the discipline and made them more pertinent to the activity oriented, nature of projects. Modern CM repositories increasingly hold more than simple configuration information; they provide metadata that includes tasks, roles, releases and lifecycle states – attributes that relate directly to the execution of a project.

CM information is not confined to the rich, historical records that provide traceability of past activities. Rather, CM environments now offer current status of development tasks and releases that, with suitable abstractions, can be used as a predictive tool to gauge project trends and delivery confidence.

Evolving Paradigms

The evolving paradigms that strengthen the management link between CM and PM can be tracked through the increasing maturity of the tools that support software CM or Change Management as it is sometimes described by vendors - conveniently they share the same acronym and will be treated interchangeably in this paper.

The Object-Based Paradigm

Early software CM tools focused on the configuration and its constituent objects or artifacts. The connection between any configuration changes and the activity that initiated the change were often manually entered comments or associations between the objects changed and the Change Requests that documented the original need.

Further, these early tools only provided a repository that stored versions of the source files. These versions were snap-shots of the files that were checked-in when and as developers thought fit – they did not support, or integrate with the development activities themselves.

So early CM tools were designed to be administrative support for developers. Providing a historical trail, they offered only a weak association with the project context, and its activities, plans and schedules. At best, they afforded some traceability through the connection with Change Requests.

With the introduction of the work areas concept however, development activities became increasingly conducted within the CM environment, or at least under its control. CM was becoming more intertwined with the act of development (coding at least) and not simply an administrative after-thought.

The bond between a projects planned activities and its implementation under the control of a CM system had begun to strengthen.

The Task-Based Paradigm

The task-based paradigm was introduced to reduce developers’ administrative burden when managing changes that spanned multiple configuration objects.

Related to the similar change-set paradigm, the task-based approach conveniently used terminology that was derived from the activity-based world of PM.

By raising the level of abstraction to the task rather than the configuration objects, the task-based paradigm provided a natural and compelling means of identifying the context of a change and its impact across a number of objects. In doing so, it also removed some of the manual, administrative overheads that developers faced, and sometime failed to adequately perform – further encouraging the active involvement of CM in the performance of a project’s activities.

What is less well appreciated however, is that one of the most valuable abstractions provided by the task-based paradigm was its process-support. This changed the underlying basis for the promotion of a configuration through lifecycle stages - from being based on the maturity of the object, to being defined by the status of a task.

This has significant consequences in the relationship between CM and PM – the basis of defining a required configuration had switched from the objects that are traditionally the domain of CM, to tasks, that are the fundamental, activity-based, building blocks of PM.

This cross-over of concepts can be accomplished as an increasing number of CM tools support the assignment of tasks to a release. Here, a release-tag is used as a grouping mechanism for tasks that can define the required configuration, that can in turn go through the stages of the software lifecycle based on the promotion of the release tasks.

The Release-Centric Approach

While the task-based paradigm is extremely valuable at the development level, the granularity of a task often makes it difficult to communicate the capabilities provided to management or business users.

Tasks are too often couched in developer-language and often do not translate easily into user-understandable terms - unless the task is delivered in isolation, such as a patch. Even where tasks were understandable, since Releases comprise a number of bundled tasks, the status of each task less relevant than the status of the release, since that is the delivery vehicle with testing and quality assurance activities being conducted on the release as a whole.

With this motivation, the Release itself it is proposed as a more powerful level of abstraction for managers, end-users and executives dependent upon the delivery of software functionality.

What is perhaps most compelling about the release-centric approach is that it offers further union between the CM and PM disciplines, as a release commonly represents the culmination of a project and the delivery of the promised capabilities.

The Release-Centric ApproachThe Release as a Common Goal

The term Release serves as a shared focus for the developers, managers and end-users of software products or systems. It is the common goal that is well understood by all participants in a development project.

A Release is the delivery vehicle that managers and end-users wait for in anticipation, promising new, more powerful product capabilities. For software developers a Release represents the context of their development tasks and then, the project’s climax when “the rubber hits the road” and their work is delivered to the waiting world.

The fact is that a Release is a major milestone in the calendar for each of the product stakeholders – more accurately, it is a series of milestones. A Release often is a critical business issue for Marketers and Product Managers long before development personnel hear about the requirements placed on them. Alternatively, a Release may be a concern discussed by maintenance and support personnel long after it was first “released” by development.

To accommodate the reality that a Release is more than the verb representing the act of releasing – that used as a noun a Release actually IS the product in different states and at different points in time – we must break with the traditional CM view that a Release relates to the repeatable packaging of the software configuration.

In the broader perspective proposed, a Release has a lifecycle and represents the project deliverable in all the different states that it must take from concept to obsolescence.

Characteristics of a Release-Centric Approach

The release-centric approach to CM effectively builds on the already established Task-Based paradigm. While tasks continue to be assigned to releases as in the task-based approach, releases are now the primary focus of CM activity.

In summary, the release-centric approach can be characterized by the following:

• A release can be defined in different states representing past, present and future activities. Release states could include archival, supported, in-production, in-development, future-committed, future-planned
• A release must define the expectation, schedule and capabilities to be delivered as per the project plan
• A system and its releases can provide a means of navigating the CM repository and determining context.
• Releases for each system can be scheduled and represent a time-line that corresponds to project plans
• CM users may drill-down into in-development releases and view the different work areas being used to deliver the release’s requirements
• In-development releases can be statused directly from the constituent tasks and the lifecycle model adopted
• Release may be implemented using an appropriate lifecycle model, dependent upon the size and purpose of the release

Arguments for the Release-Centric Approach Management Visibility The underlying pain that drives the need for a higher, (project) management level abstraction like the release-centric approach is that of managerial visibility and empowerment.

The fact is that software development is currently a very “hands-on” activity, and that those that may have critical reliance on the delivery of software capabilities often do not obtain the key information they need to manage their business and their customers expectations.

Software projects too often have to be managed like black boxes – with little visibility and less understanding of the development process. Along the way, managers are reliant upon the interpretations and sometimes, opinions of the developers as to what can be delivered and when. It is not a desirable or acceptable manner in which to develop business critical software.

Converging CM and PM Paradigms

Utilizing a release as the link between the two disciplines of CM and PM, the release-centric approach to CM offers a potential evolutionary path for the discipline and the tools that support it.

While it is more evolutionary than revolutionary, the release-centric approach does provide a terminology and management perspective that is closer to PM. The present discussion has been necessarily simplistic avoiding the complexity of multiple and hierarchical systems, however taking the level of abstraction up to the level of a Release can offer management a simpler and less cluttered representation of the development activities, in a language that is familiar to them.

As well as the traditional traceability and historical perspective of CM, release-centric approach offers the prospect of improved insight into the current state of development projects by improving our ability to track and determine the true (as opposed to reported) status of the project. Further, identification of future releases and the planning of their capabilities gives CM a system release-planning role that complements the activity planning that goes with PM.

When the separate project plans and system release plans are synchronized and agreed we can expect to be close to achieving the benefits of the convergence of CM and PM.