6

ORGANIZATIONAL CONSIDERATIONS FOR PROJECT AGILITY

Every project exists in an organizational context. Cultures, structures, and policies can influence both the direction and the outcome of any project. These dynamics can challenge project leaders.

While project leaders may not have the ability to change organizational dynamics as they see fit, they are expected to navigate those dynamics skillfully.

This section explores the way the organization and in some circumstances, the project context, influences projects. Leaders can explore options for change, to increase project success.

6.1 ORGANIZATIONAL CHANGE MANAGEMENT

Organizational change management covers the skills and techniques for influencing changes that support agility.

The PMI publication, Managing Change in Organizations: A Practice Guide [2], describes a comprehensive and holistic approach for successfully introducing meaningful change. The recommendations offered there include:

• Models for describing change dynamics,
• Framework for achieving change, and
• Application of change management practices at the project, program, and portfolio levels.

Sections 6.1.1 and 6.1.2 explore the considerations of change management specific to an agile context.

Figure 6-1 shows the relationship between these two topics.

6.1.1 DRIVERS FOR CHANGE MANAGEMENT

All projects are about change. However, there are two key factors that further motivate the use of change management practices in an agile context:

• Changes associated with accelerated delivery. Agile approaches emphasize delivering project outputs early and often. However, the receiving organization may not be fully prepared to incorporate those outputs at an increased pace. Accelerating delivery will test the organization's ability to accommodate that delivery. Successfully discovering and delivering a project's features is not enough. If the organization resists the project's output, then the targeted return on investment is delayed. Customer acceptance of and alignment with project outputs becomes even more prevalent in an agile environment.
• Changes associated with agile approaches. Organizations just beginning to use agile approaches also experience high degrees of change. Higher degrees of collaboration may require more frequent handoffs between teams, departments, or vendors. Decomposing work into iterative prototypes involves rework that could be viewed negatively. Leaders should consider change management techniques to address the hurdles of transitioning to the use of agile approaches.

6.1.2 READINESS FOR CHANGE

Organizations beginning to use agile approaches should understand the relative compatibility of those methods with their current approaches. Some organizations will have characteristics that more easily support agile principles of cross-department collaboration, continuous learning, and evolving internal processes. Examples of these change-friendly characteristics include:

• Executive management's willingness to change;
• Organization's willingness to shift the way it views, reviews, and assesses employees;
• Centralization or decentralization of project, program, and portfolio management functions;
• Focus on short-term budgeting and metrics versus long-term goals; and
• Talent management maturity and capabilities.

Conversely, there are other institutional characteristics that may be roadblocks to achieving the changes associated with organizational agility. Examples of these include:

• Work is decomposed into departmental silos, creating dependencies that prevent accelerated delivery instead of building cross-functional teams with guidance from centers of competencies.
• Procurement strategies are based on short-term pricing strategies, rather than long-term competencies.
• Leaders are rewarded for local efficiencies rather than end-to-end flow of project delivery or optimizing the whole (in regard to the organization).
• Employees are specialized contributors with limited tools or incentives to diversify their skills instead of building T-shaped specialists.
• Decentralized portfolios pull employees simultaneously onto too many projects at once instead of keeping them focused on one project at a time.

The degree to which an organization is willing to review and modify these practices will determine how quickly and effectively agile approaches can be adopted. However, in response to these organizational impediments to agility, project leaders can try various approaches to accelerate a cultural compatibility for:

• Visible and active executive sponsorship,
• Change management practices, including communication and coaching,
• Progressively pacing the adoption of agile practices on a project-by-project basis
• Incremental introduction of agile practices to the team; and
• Leading by example by using agile techniques and practices where possible.

6.2 ORGANIZATIONAL CULTURE

An organization's culture is its DNA—its core identity. Culture will always influence the use of agile approaches. Organizational culture runs along a continuum, from highly predictive plans to lean startup where everything is an experiment. Although agile approaches fit well with the lean startup culture, a highly predictive organization can encourage empirical measurements, small experiments, and learning so they can move toward agility.

6.2.1 CREATING AN ENVIRONMENT OF SAFETY

Organizational culture is difficult to change, but the most important cultural norm in an organization willing to try any new method or technique is enabling a safe work environment.

Only in a safe, honest, and transparent environment can team members and leaders truly reflect on their successes to ensure their projects continue to advance, or apply lessons learned on failed projects so they do not fall back into the same patterns.

6.2.2 ASSESSING CULTURE

Every project finds itself in tension with competing aspirations. How can the team go fast without compromising quality? How can the team preserve flexibility while also hitting a firm date? Most importantly, how does the team satisfy and meet the requirements of the customer?

Project leaders may feel their job is to meet every expectation of every stakeholder; but, when compelled to make a choice, there is often a priority depending on the culture and requirements of the organization's business environment. For example, a mobile telecom project has a greater bias for speed, where a government program may have a greater bias for generalization and stability.

To navigate these dynamics, project leaders should take the time to assess where emphasis is most often applied in the organization. Figure 6-2 illustrates what an assessment might look like. In this example, a project leader initiates a conversation about organizational priorities with stakeholders, team members, and senior management. Those priorities are then recorded as positions on a sliding scale between two extremes. The results are then used to find agile techniques that best fit with those priorities.

Several models exist for assessing such dynamics; however, the model or method used is not that important. It is more critical that project leaders invest the effort to understand the forces that shape their context. Understanding the organization and the industry requirements that an organization needs to satisfy allows for choosing the right conversations, the right tradeoffs, and, especially, the right techniques.

6.3 PROCUREMENT AND CONTRACTS

As mentioned earlier in this practice guide, the Agile Manifesto values “customer collaboration over contract negotiation.” Many project failures stem from breakdowns in the customer–supplier relationship. Projects incur more risk when those involved in the contract take the perspective of winners vs. losers. A collaborative approach is one that pursues a shared-risk-reward relationship, where all sides win. Some contracting techniques that can formalize this dynamic include the following:

• Multi-tiered structure. Rather than formalizing an entire contracting relationship in a single document, project parties can achieve more flexibility by describing different aspects in different documents. Mostly fixed items (e.g., warranties, arbitration) can be locked in a master agreement. Meanwhile, all parties list other items subject to change (e.g., services rates, product descriptions) in a schedule of services. The contract can reference them in the master services agreement. Finally, more dynamic items such as scope, schedule, and budget can be formalized in a lightweight statement of work. Isolating the more changing elements of a contract into a single document simplifies modifications and thus flexibility.
• Emphasize value delivered. Many vendor relationships are governed by fixed milestones or “phase gates” focused on intermediate artifacts, rather than a full deliverable of incremental business value. Often, these controls limit the use of feedback to improve the product. Instead, milestones and payment terms can be structured based on value-driven deliverables in order to enhance the project's agility.
• Fixed-price increments. Rather than lock an entire project scope and budget into a single agreement, a project can decompose the scope into fixed-price microdeliverables, such as user stories. For the customer, this gives more control over how the money is spent. For the supplier, it limits the financial risk of over-commitment to a single feature or deliverable.
• Not-to-exceed time and materials. Customers incur unwanted risk from a traditional time and materials approach. One alternative is to limit the overall budget to a fixed amount. This allows the customer to incorporate new ideas and innovations into the project not originally planned. When customers want to incorporate new ideas, they will have to manage to a given capacity, replacing original work with new work. Work should be closely monitored as hours allocated reach their limit. Also, additional contingency hours could be planned into the maximum budget if considered helpful.
• Graduated time and materials. Another alternative is a shared financial risk approach. In agile, the quality criteria are part of what done means. Therefore, the supplier can be rewarded with a higher hourly rate when delivery is earlier than the contracted deadline. Conversely, the supplier would suffer a rate reduction for late delivery.
• Early cancellation option. When an agile supplier delivers sufficient value with only half of the scope completed, the customer should not be bound to pay the remaining half if the customer no longer needs it. Instead, a contract can offer the customer to buy the remainder of the project for a cancellation fee. The customer limits budget exposure and the supplier earns positive revenue for services no longer required.
• Dynamic scope option. For those contracts with a fixed budget, a supplier may offer the customer the option to vary the project scope at specified points in the project. The customer can adjust features to fit the capacity. Then the customer can leverage innovation opportunities, while limiting the supplier's risk of over commitment.
• Team augmentation. Arguably the most collaborative contracting approach is to embed the supplier's services directly into the customer organization. Funding teams instead of a specific scope preserves the customer's strategic discretion on what work should actually be done.
• Favor full-service suppliers. In order to diversify risk, customers may seek a multisupplier strategy. However, the temptation will be to contract the work such that each supplier does only one thing, which creates a web of dependencies before any usable service or product emerges. Instead, place an emphasis on engagements that deliver full value (as in the idea of completed independent feature sets).

TIP

Culture versus Structure

Some people insist new organizational structures be installed before any cultural shift can begin. Others maintain the opposite—those new organizational structures are only superficial adjustments until the collective culture moves in a meaningful direction. In reality, one cannot progress without the other. Project leaders wanting to achieve agility should consider the current and future states of both of these aspects in their organization.

It is possible to create agile contracts. Agile is built on a synergy of collaboration and trust. The supplier can help by delivering value early and often. The customer can help by providing timely feedback.

6.4 BUSINESS PRACTICES

The willingness and ability to create new competences within an organization when the need arises is a mark of organizational agility. These do not have to be earth-shattering changes and could be less disruptive in an organization that is focused on agility and the results it provides. Transparency and open collaboration are absolutely key.

As cross-functional teams deliver value, the teams and individuals might encounter problems with various support functions in the organization.

As team delivers value on a regular basis, finance departments may have the opportunity to capitalize the product differently. If the team has contracts with other organizations, procurement departments may need to change those contracts to help the other organizations deliver value frequently and synchronize with the team.

Once teams start to work in a cohesive and cooperative manner, they will challenge internal management policies. Human resources may notice individual incentives make less sense, and managers may struggle with the performance appraisals of self-organizing employees. In each case, these are opportunities to review the degree to which existing practices support agile ways of working.

As organizations progress to greater agility, there will be obvious needs for additional business units to change the way they interact and perform their responsibilities. The changes that have benefited other areas of the organization should now be embraced so the effectiveness of the entire organization can be realized.

6.5 MULTITEAM COORDINATION AND DEPENDENCIES (SCALING)

Many projects incur dependencies, even when they are not managed within a given program. For this reason, it is necessary to have an understanding of how agile works within an existing program and portfolio management context.

6.5.1 FRAMEWORKS

The guidance of the most widespread agile methods such as Scrum and eXtreme Programming focus on the activities of a single, small, usually colocated, cross-functional team. While this is very useful for efforts that require a single team, it may provide insufficient guidance for initiatives that require the collaboration of multiple agile teams in a program or portfolio.

A range of frameworks (such as the Scaled Agile Framework, Large Scale Scrum, and Disciplined Agile) and approaches (e.g., Scrum of Scrums) have emerged to cater to just such circumstances. More details on these can be found in Annex A3.

6.5.2 CONSIDERATIONS

There is more than one way to scale work. The team might need to scale the work of several agile projects into a single agile program. Alternatively, the organization can design a structure that supports agile approaches across the entire portfolio.

For example, it is helpful to start small and learn as rapidly as possible what works well in the organizational context. Teams can achieve successful outcomes even when everything is not completely transformed into an agile approach.

Regardless of the approach, a critical success factor is the healthy agile team. If using an agile approach for a single team is not successful, do not try to scale up to using it more broadly; instead, address the organizational impediments that prevent teams from working in an agile way.

The goal of large-scale agile projects is to coordinate the efforts of different teams to bring value to customers. There is more than one way to do that. Teams may use a formal framework or apply agile thinking to adjust existing program management practices.

6.6 AGILE AND THE PROJECT MANAGEMENT OFFICE (PMO)

The PMO exists to shepherd business value throughout the organization. It might do this by helping projects achieve their goals. Sometimes, the PMO educates teams (or arranges for training) and supports projects. Sometimes, the PMO advises management about the relative business value for a given project or set of projects.

Because agile creates cultural change, over time, the organization might need to change, including the PMO. For example, managers make decisions about which projects to fund and when, and teams decide what they need for training or advice.

6.6.1 AN AGILE PMO IS VALUE-DRIVEN

Any project should deliver the right value, to the right audience, at the right time. The PMO's objective is to facilitate and enable this goal. An agile-based PMO approach is based on a customer-collaboration mindset and is present in all PMO programs. In many cases, this means the PMO operates as if it were a consulting business, tailoring its efforts to meet specific needs requested by a given project. Some projects may need tools and templates, while others may benefit from executive coaching. The PMO should strive to deliver what is needed and keep the pulse on its customers to ensure that it knows and is able to adapt to their needs. This intrapreneur approach focuses on the PMO activities that are perceived as the most valuable to the projects it supports.

6.6.2 AN AGILE PMO IS INVITATION-ORIENTED

In order to accelerate progress on a value-based charter, a PMO may be tempted to mandate certain solutions or approaches, for example, to make everyone do it the same way to get some quick wins. However, a more deliberate perspective incorporates the desire for employee engagement. This is achieved by inviting only those interested to engage with PMO services. Higher engagement with PMO practices makes it easier for those practices to be “sticky.” If the PMO is delivering value to its clients, it is more likely that clients will request its services and adopt its practices.

6.6.3 AN AGILE PMO IS MULTIDISCIPLINARY

In order to support project-specific needs, the PMO needs to be conversant in several competencies beyond project management itself, because different projects require distinct capabilities. For instance, one project may need organizational design to address staffing challenges while another may require organizational change management techniques for stakeholder engagement or unique business models to support customer goals.

Some organizations have been transforming their PMOs into agile centers of excellence that provide such services as:

• Developing and implementing standards. Provide templates for user stories, test cases, cumulative flow diagrams, etc. Provide agile tools and educate supporting groups on iterative development concepts.
• Developing personnel through training and mentoring. Coordinate agile training courses, coaches, and mentors to help people transition to an agile mindset and upgrade their skills. Encourage and support people to attend local agile events.
• Multiproject management. Coordinate between agile teams by communicating between projects. Consider sharing items such as progress, issues, and retrospective findings and improvement experiments. Help manage major customer releases at the program level and investment themes at the portfolio level using an appropriate framework.
• Facilitating organizational learning. Gather project velocity profiles and capture, store, and index retrospective findings.
• Managing stakeholders. Provide product owner training, guidance on acceptance testing, and how to evaluate and give feedback on systems. Champion the importance of subject matter experts (SMEs) to projects.
• Recruiting, selecting, and evaluating team leaders. Develop guidelines for interviewing agile practitioners.
• Executing specialized tasks for projects. Train and provide retrospective facilitators, create agreements with agile project troubleshooters, and provide mentors and coaches.

6.7 ORGANIZATIONAL STRUCTURE

The structure of an organization strongly influences its ability to pivot to new information or shifting market needs. Here is a listing of key characteristics:

• Geography. Geographically distributed and dispersed project organizations may find several challenges impeding their work on any project. Project leaders and regional managers may have alternative or even competing goals. Additionally, cultural differences, language barriers, and lower visibility can slow down productivity. Fortunately, the use of agile approaches can encourage more collaboration and confidence than would otherwise exist. Project leaders in these contexts should encourage dialog at the team and executive level to tailor techniques for the context and to manage expectations about the effort required to do so.
• Functionalized structures. Some organizations are structured on a spectrum ranging from highly projectized to matrixed to highly functionalized. Projects with highly functionalized structures may find general resistance to collaboration across its organization.
• Size of project deliverable. Reducing the size of a project deliverable will motivate more frequent handoffs across departments, and thus more frequent interactions and a faster flow of value across the organization.
• Allocation of people to projects. Another approach is to ask for a single person from each department to be temporarily, yet fully allocated, to the highest priority project.
• Procurement-heavy organizations. Some organizations choose to implement projects primarily through vendors. Although project goals may be clear, vendors have a responsibility to look after their own financial viability. Moreover, once vendors complete their obligations and leave the engagement, the associated project knowledge goes with them. This limits the internal competencies needed for sustained flexibility and speed. Agile techniques such as retrospectives and follow up on possible improvement areas when the vendor is still engaged can help mitigate loss of product knowledge.

6.8 EVOLVING THE ORGANIZATION

When addressing an individual challenge area or implementing a new hybrid or agile approach, it is recommended to undertake the work incrementally. A common practice is to treat the change process as an agile project with its own backlog of changes that could be introduced and prioritized by the team, based on perceived value or other considerations. Each of the changes can be treated as an experiment, which is tested for a short period of time to determine suitability as-is or the need for further refinement/consideration.

Use kanban boards to track progress, showing the new approaches already in use as “done,” those being tried as “in progress,” and those still waiting to be introduced as “to do.” See Figure 6-3 for the initial board with a ranked backlog. Figure 6-4 shows an example of what a board might have as work progresses.

Using these tools to organize and manage the change implementation provides visibility into progress and also models the approaches being implemented. Rolling out changes in a transparent and appealing way improves the likelihood of their success.