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.
Functional Management and Organizational Change
The functional management level is where organizational change efforts are solidified or circumvented. While senior managers are charged with creating an atmosphere conducive to organizational change, it is the functional managers who must make it happen. Whereas senior management generally represents high-level goals for the organization, functional management usually has more specific goals that don’t always completely align with those of the project. Additionally, most organizations have competitive undercurrents between departments and functional areas. A certain amount of organizational competition or tension is actually healthy for the business. It forces people to continually push themselves toward improvement. However, all too often the tension becomes personal when people become protective of their turf and not only fend off others who might encroach on them, but actively try to expand their area of influence. This line of thinking is the basis of the so-called silo mentality, where strengthening of the silo becomes more important than the overall organizational goals to the functional manager. This attitude naturally is filtered down to the individuals who work on the project teams, and this is where the problem is generally first identified.
As the agile project progresses, it is not only breaking new ground within the project itself, but it is also breaking new organizational ground. The project manager and other change champions will be looking for ways to bridge these new organizational obstacles. Both the project team and the functional management team must work together to address these never-before-addressed organizational challenges (see Figure 9-4). Usually, it will be the project team that pushes for change, since its members have identified it as a potential issue preventing the project from moving forward. On the other hand, functional management may be somewhat resistant to change, since it’s looking for more predictability and less risk within its domain. Functional managers generally don’t see the whole picture from the project’s perspective, and, very often, the project team doesn’t spend the time to educate them. Many functional managers have been brought up in the old school, where project teams operated within already-defined organizational boundaries, not the other way around. The change champions of the project team need to spend time making their case to functional managers also. They must lay out the big picture and explain why the rapid pace of change in today’s business environment requires increased organizational agility. They must show how participating in the creation of this organizational agility will actually strengthen, not weaken, each manager’s respective functional organization.
Project Change
Organizational Change
* * *
Upper Management
Manages the linkages between the business strategy and the tactical project portfolio
Creates an environment supportive of organizational change
* * *
Functional Management
Obtains and aligns the skills necessary to advance projects
Works with project teams to design and implement organizational changes
Figure 9-4: A summary of management roles unique to the agile project environment.
Agile Strategy Make the case to management regarding organizational change by laying out the big picture and its implications to the project, the functional areas, and the overall business.
The leadership organizations of the future will be those with the capacity and agility to adapt to the situation at hand and effectively execute strategy through projects. Whether at the business level or the department level, organizations that cannot, or will not, adapt will be left behind and may eventually be dismantled in favor of more flexible structures.
Summary
Senior management must understand the linkages between business planning, portfolio management, and tactical project execution.
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 changes.
Functional managers should consider outsourcing as a means to staff agile projects, more so than for classic ones.
Agile project teams constantly push the organizational envelope and uncover new organizational obstacles to overcome.
The capability of an organization to reinvent itself is an enabler of agile PM, as well as overall organizational agility.
The silo mentality is a killer of organizational reinvention.
Laying out the big picture of the agile project will help all levels of management understand the need for organizational reinvention.
Chapter 10: The Operational Project Management Infrastructure
This chapter touches on the unglamorous parts of successful project management. It provides some practical organization to topics that you are largely familiar with, but perhaps never thought were important enough to develop further or standardize in your company. Hopefully, you will see that there is some low-hanging fruit and that picking it is not only easy, but will have a dramatic affect on your project management agility.
Developing a project management infrastructure is one of those important but not necessarily urgent internal activities that organizations must undertake to support their project managers. It is important because with a well-honed and integrated set of tools and processes at his disposal, the project manager is freed up from administrative PM duties and can focus on some of the more critical duties discussed in Chapter 5. Unfortunately, for many organizations, PM infrastructure development is just not urgent enough to make it to the top of their list. Ironically, this is because most project managers are able to “get by” using their own homemade systems, which are usually based on multiple different general-purpose software programs. So, while the inherent organizational capabilities of project managers enable them to move forward despite a lack of specialized PM tools, they are forced to work on lower-value administrative areas of PM. Consequently, the organization itself never reaps the full return from its investment in project management.
What Exactly Is an Operational Project Management Infrastructure, and Why Do I Need One?
A project management infrastructure is an organized set of tools and processes that can facilitate the project management process from start to finish. While these tools and processes are usually clumped together, I find that it makes more sense to categorize them into two broad groups (see Figure 10-1). The first grouping applies to the “initiation and planning” processes. The second is those tools and processes that apply to “execution and control”. This chapter is primarily focused on the second group, which is where agile projects can gain the most benefits; however, as you will see, there is some overlap.