When discussing change from the management perspective, we need to cover two dimensions. First, we must look at the dimension of change within the actual project. An agile project is more likely to take a zigzag course through a network of pathways to reach its completion point. By contrast, a classic project may take a more direct route along a well-planned primary path. The second dimension to examine is the organizational change that must come about to support the agile project. This dimension includes redefining individual, leadership, and organizational roles to meet the dynamic needs of the project, and it is definitely more difficult to address. We should also draw a distinction between senior management and functional management. While in some cases these two types of management overlap and may actually be the same, for the purposes of this discussion, we’ll use the following broad definitions to reflect the matrix organization used by most companies:
Executive or upper managers are those people who create the long-term business strategy and direction for the overall organization.
Functional managers are those people who manage a specific part of an organization made up of people of similar skills sets (e.g., R&D, marketing, or manufacturing). These managers loan out their resources to projects, based on their particular needs.
Upper Management and Project Change
In the classic project environment, upper management has minimal involvement with course changes within a project. Their primary project roles include endorsing/sponsoring the project, committing resources, setting a project deadline, receiving status reports, managing escalations, and providing rewards to motivate the team. Perhaps upper management’s only direct involvement in managing project change might be in approving an unexpected course change before implementation, or encouraging the team to “try something new”. Generally, upper management does not get actively involved in steering the project.
In the very fluid world of the agile project, the role of upper management (see Figure 9-1) becomes more active, and not just on the back end by approving changes, but on the front end, influencing them. Upper management is largely concerned with fulfilling business strategy (at least partially) through the successful execution of tactical projects. In a predictable business and technical environment, management would define a set of projects that, in total, would lead to the fulfillment of key business objectives or strategy. These projects would be handed off to various functional areas and cross-functional project managers for planning and execution. Since the projects were well defined and bounded, management could let them run independently and would only need to check on their status periodically.
Figure 9-1: Upper management’s role in the agile versus classic project.
On the other hand, an uncertain, fast-changing business environment requires that the business strategy be tightly linked to the tactical projects during execution, as well as in definition, so that each exerts the appropriate influence on the other (see Figure 9-2). Upper management’s role shifts to one of understanding the linkages between the business planning process, business strategy, project portfolio, and tactical projects, then facilitating course change decisions based on their knowledge of the high-level business environment.
Figure 9-2: Strategy, business objectives, and tactical projects all exert appropriate influences on each other.
Each of these dimensions (business strategy, business objectives, programs, and projects) may be owned by a different person in the organization. Since there is some ripple effect that ties them all together, it is critical that the owners of each of these dimensions know where they fit in. Generally, a big, upstream change (i.e., a strategy change) will have a greater ripple affect on the downstream areas like the tactical projects, but not always. In the agile world, everything is a project, and whole business strategies may hinge on the outcomes of a few key projects. In a nutshell, there can be a two-way ripple effect. The more you understand how what you’re doing may affect someone else, as well as how what they’re doing will affect you, the better.
Agile Strategy Understand and manage the linkages between business strategy, high-level objectives, and the tactical project portfolio to better keep your organization on task to achieve its high-level strategies.
In the agile paradigm, senior management must be more actively involved in understanding project-level decisions, since the ripples caused by these decisions can potentially impact the high-level strategy. Likewise, their strategy-level decisions have potentially magnified downstream impacts; thus, they need to understand how changes in the business strategy may impact a specific project, or all portfolio projects in general, before enacting anything at the high level. In this way, they can avoid adverse downstream consequences that would delay rather than accelerate any desired strategy-level change. I wouldn’t think that upper management needs to be intimately up-to-date with all project interactions; however, it should expect to be pulled into the project-level decision-making process more often in the agile environment than the classic one.
In the agile project environment, there is a two-way ripple effect between the high-level business strategy and the tactical project portfolio when either of them change.
Functional Management and Project Change
The functional manager really has two project-related roles in the classic, matrix management model. First, she is responsible for hiring (and then developing) personnel within her area with the intent of building the necessary skills to advance overall functional capabilities. Second, she allocates personnel, as needed, to work on various projects. This setup, in a way, isolates the functional manager from direct involvement in the project. Any project information relayed to her, or any influence exerted by her on the project, is conveyed via the people that she has allocated to the project.
In the agile environment, the functional manager must become more directly involved with the project than she is in the classic project environment. In keeping with our concept of aligning the business and projects, the functional manager must keep her organization aligned with both. For projects, this means obtaining the people with those critical skills needed for project success in the agile environment. These skills include the ability to work across traditional functional boundaries, as well as the ability to perform detailed technical tasks. Because of the rapid pace of change in agile projects, the functional manager must know when to hire a permanent employee and when the use of a consultant, or temporary employee, would be better. Hiring in today’s business environment is a big commitment. It must be handled appropriately to support both the company and project objectives. The only way to do this effectively is to work directly with the project managers so that you know the project objectives, direction, and required skill sets. In essence, the functional manager is now being asked to obtain and develop project-specific skills rather than the more general, functional skills.
Agile Strategy Get more directly involved with projects so that you can provide the right personnel/skills to advance them, and thus advance the overall organization.
How people with these skills are acquired can have a profound positive or negative influence itself on the business. For instance, if you need someone to provide high-level technical direction, as well as to form the cross-boundary networks necessary to nourish new ideas, then it’s more desirable to add this person permanently to your core team. Even after this particular project is over, a person with these uncommon skills can surely contribute to the next one. In the agile project environment, the bigger change involves the greater use of consultants for specific technical roles. There are two reasons that agile businesses should not be spending their energy and money trying to develop permanent, specific, technical skill sets. First, the very nature of the agile environment means that the need for that specific skill could vanish overnight, if the project takes an unexpected turn. This creates risk for the business, in the form of an unwanted liability (i.e., person). And second, agile projects often need specific skills for short periods of time, or on an as-needed basis. In these cases, it doesn’t make sense to hire a full-time person, even if you want to. As an alternative, you could have one of your permanent employees take on a task that’s outside of her specific expertise. This approach is good for personnel development but bad for the agile project, since it will not get the high-level expertise that’s needed. Generally, it’s more efficient for the project (and the company in the long run) to outsource these roles to experts, even at a premium.
Agile Strategy Look to outsourcing as a means of acquiring specific technical talent, especially if this talent can’t be repurposed, in the event that the project in question no longer needs it.
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.