5 Ways To Stifle Organizational Agility

organizational agility - man in cast
Posted by Sandra Pinnavaia in Featured, Future of Work on Sep 20th, 2018 19:39 CST

Everyone is talking about the agile workforce these days. We’re all for it—and who wouldn’t be? In work as in life, it’s hard to argue against the concept of enhanced agility: nimble responsiveness to changing circumstances and opportunity.

What’s more, 2018 is shaping up to be the year of agile. Companies from ING to IBM have recognized a need for new tools, policies, processes to evolve—or even break—long-established habits in light of a quickly changing economy and an increasingly competitive world. Formal agility frameworks, like the Agile organization, have taken hold in many corporations, providing an important new lens for problem-solving and growth mobilization.

Unfortunately, even formal, big-A Agile is elusive enough, at the corporate level, to be easily corrupted or diluted. Change is not agility. Yet too often, the concepts are conflated, and “Agile” is used to justify a business transformation whose goals are too vague to be useful.

Change is not agility. Yet too often, the concepts are conflated, and “Agile” is used to justify a business transformation whose goals are too vague to be useful.

Further, very few big companies are positioned to set up and run agile teams. One challenge is giving people enough freedom from traditional operating responsibilities to make time for agile projects. Another is breaking embedded processes and policies—think incentive plans, budgeting cycles, reporting loads, and the like—that weigh down agile explorations.

Here are five ways we’ve seen that happen—and what you can do about it.

1. You spend more time talking than taking action

Trite but true? Funny but sad? You bet, and we’re seeing it!

We’ve watched companies talk for years about taking a more agile approach to consulting without setting up a single pilot. We’ve seen HR and procurement leaders at F50 companies create programs specifically to drive organizational agility, then take disproportionate amounts of time to approve projects within the program. (Should it take four weeks to approve external support for a two-week exploratory initiative?)

We’ve watched leading global brands assemble an agile team of internal and external experts to tackle an important project … then burden that team by adding “observers” from each Business Unit and each function. Yikes!

How to avoid this trap? As you think about enterprise-wide agile programs, construct smaller pilots along the way that resource problems and opportunities in non-traditional ways. Make sure those pilots are sponsored by key execs in your agility movement—and track success metrics like usage and satisfaction rates to boost momentum going forward.

2. You don’t know the difference between tasks and projects

An agile organization runs on teams that are organized around different projects or initiatives.

In classic project management, iniatives are divided into workstreams, which are then are broken into tasks and assignments that lead to discreet, pre-defined deliverables. In Agile projects, that workflow is overlaid with an additional, and distinctive, philosophy: a flexible and active construct that emphasizes ongoing problem-solving, cumulative scope refinement, and permission for creative destruction from start to finish.

In other words, Agile projects are still broken into tasks and assignments—but more creatively, and with more latitude about the exact outcomes that are ultimately delivered.

When companies confuse tasks with projects (a common mistake in both casual language and in procurement definitions) you get too specific too quickly to be Agile, because you don’t leave any room for the creative problem-solving. Projects involve more than the production of a deliverable—they also include problem structuring and, often, restructuring and refinement. Tasks, by contrast, are already well-defined. Accomplishing a task may require some creativity, but mostly it just needs to get done. Here are some examples we’ve recently seen of tasks disguised as projects:

  • Gather competitive intelligence on product X
  • Create growth forecasts for Franchise Z
  • Analyze customer experience data

Why is it so important to distinguish tasks from projects? Projects require participants to make decisions—they drive to a specific conclusion or recommendation. Tasks, on the other hand, result in information, insights, and progress against a to-do list. But they don’t drive to measurable business change or performance improvement.

What’s the best way to turn a task into an agile project? By reframing it as an open-ended problem and letting your team explore the best solution:

  • Develop competitive action and reaction strategies to gain market share for product X
  • Explore growth strategies for Franchise Z using design thinking and rapid prototyping
  • Find new ways to improve customer experience and boost customer retention

3. You conflate efficiency with agility

Classic outsourcing is not agile. It’s simply cost-effective. It’s a form of restructuring your workflow to achieve enhanced efficiency. There is nothing fundamentally creative or generative about the process.

A truly agile workforce—one in which your teams have access to the internal and external resources they need, and are empowered to make fast, intelligent decisions about where to go next—is often cost-efficient. That’s especially true of situations like M&A deals, where the workflow is uneven and the expertise you need to evaluate new opportunities can vary widely from deal to deal.

However, the real reason to “go agile” is growth. That’s why companies need to drive instead towards the kind of outsourcing that enables them to take advantage of new opportunities—to move more quickly and access skills that aren’t in-house. Agility is about having the right expertise at the right moment, whether you’re contemplating moving to a new market, piloting a new planning process, or capitalizing on a new technology. You can and should think about outsourcing certain tasks to external talent to create bandwidth for an overworked team. But you will kill the promise of an agile workforce if you view it solely through the lens of outsourcing.

4. You think that agile teams will come together on their own—and only pull from internal resources

In an agile organization, teams are independent, self-directed, and scalable. That doesn’t mean that they’ll come together on their own once everyone has been trained in Agile methodologies.
In the age of “people analytics,” data can certainly help improve the way you identify, attract, and develop the right talent for an initiative. But structuring each role—and understanding the trade-offs involved with using internal and external talent—requires some consideration. It also requires you to articulate a clear strategy and framework for making the decision. Questions you might ask include:

  • What’s the business goal of the initiative? If you’re conducting an experimental pilot, it might not be critical to include a lot of internal talent. If you’re building a critical new capability for the business, on the other hand, you’d think differently.
  • How clearly do you understand the type of talent that will help you succeed? In situations where technologies or techniques are new, it’s not always obvious what you should look for at the outset of a project. Using external talent in these circumstances can help you get up to speed more quickly and cost-efficiently (indeed, in some cutting-edge areas, it might be your only option).
  • How can you make sure your company retains the capability moving forward? Taking an organized approach to knowledge transfer is one of the best ways to protect yourself from ending up with half-finished products and strategic recommendations that gather dust on the proverbial shelf.

The bottom line: it takes a strong partnership between HR and procurement to distribute the work and outline the trade-offs between quality, fit/cost, and business objectives. It also requires a business partner who understands the marketplace of on-demand talent and goes beyond identifying the right talent to build a solution that works for your goals and your company.

5. You build a program, but don’t spread the word

As Peter Drucker famously said, “Hope is not a strategy.” We’ve seen companies build on-demand programs, formalize partnerships with key vendors, and announce them with great fanfare… then wait around for months while business leaders ignore all their work.

How can you prevent this from happening at your company? By formalizing an educational plan that translates broader program goals to specific value props and use cases inside the business. Have executives been tasked with reducing consulting spend? Help them understand how agile external talent can help them get better results for less. Are they focused on driving innovation? Help them understand how they can take advantage of the cutting-edge skills that aren’t available anywhere else but on the independent marketplace.

Your work as a program leader should be agile and iterative, too: cultivate internal advocates publicize their success stories, then use their insights and feedback to refine your program and processes.

Meet Your Agile Workforce

The rise of high-end independent talent is powering a new path to greater organizational agility. Learn how your company can capture the benefits.

LEARN MORE

Sandra Pinnavaia

Sandra Pinnavaia

Sandra Pinnavaia is BTG's EVP and Chief Innovation Officer. She brings over 25 years of experience as a business leader, management consultant, and trusted advisor, and she drives the development of the company’s enterprise relationships with top clients.

No Comments

Post A Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Send this to a friend