Upper Management and Organizational Change

Organizational change is a totally different animal from project change. People rationalize that project change is temporary and, therefore, "worth a try" to see if it really works. Organizational change, on the other hand, is perceived as a more permanent modification in the way we do our jobs, so people generally feel threatened by organizational change. This is even more the case when the change is driven by the project team (rather than by management). In this new and ever-changing economy, the natural tendency of people is still to resist organizational change.

Because projects are themselves instruments of change, they are on the forefront of the organizational evolution. By the very nature of the change they try to accomplish, project teams push the organizational envelope, constantly discovering new organizational issues to address. As these new organizational challenges are uncovered, one of two things may happen. First, the organization can adapt and reinvent itself to meet the needs of the project. Or, second, the organization will refuse to yield, and it will force the project team to work within the current organizational framework. Depending on the situation, either one of these actions may be appropriate.

In the case of the truly agile project, one breaking new ground that is fraught with uncertainty, the first option is the one of choice. As discussed in Chapter 3, the project becomes the business in the agile environment. There is little precedent to work from and, therefore, little reason to hold to strict organizational barriers. The organization, driven by the needs of the project, needs to morph itself into a support mechanism to facilitate project progress. All too often, functional organizations put their needs ahead of the project's needs for purely parochial reasons. This silo mentality is a killer of agile projects.

It is in these situations that management must create an environment that is supportive and encourages organizational reinvention. This includes both rebalancing the matrix to divide responsibilities differently, as well as looking at new ways of doing work. Inevitably, it means crossing over and blurring traditional functional boundaries, which is, in fact, a key dynamic in the agile project. The agile project is a mechanism that is trying to create something never created before. An agile organization that can reinvent itself to support the agile project is a critical enabler of project success.

Agile Strategy

Create an environment that enables the breakdown and reinvention of traditional functional boundaries, if so required by the project and the business.

In the case of an operational business, such as a customer support call center, it is necessary to have great efficiencies across both staff and processes. A project to set up a new family of products for customer support must mesh smoothly with the current processes. Usually, these types of systems have been honed to great efficiency over several years of incremental improvements. In these cases, it does not make sense to reinvent the organization around the project. Instead, you should be looking at how to make the project fit the processes. (Note that these are not necessarily agile projects.)

The two examples of organizational adaptability (cited above and summarized in Figure 9-3) represent opposite extremes, making the contrast easy to see. As a champion of change, project managers need to help other stakeholders see the different needs of various projects and organizations, then highlight the gaps. Most organizations that resist change do not understand the context or need for the change, so they are also not necessarily motivated to support an organizational change. It is the job of the project manager to make the argument for organizational change, and the job of senior management to put in place mechanisms that motivate functional management to support the necessary changes.

Figure 9-3: Organizational adaptability in an agile versus classic PM environment.