Who We AreInvestor RelationsNewsCareers

Adopting an Agile Approach to Commercial Operations in Life Sciences​

Executive Summary
Agile operations hold the promise to drastically reduce production timelines and introduce nimbleness to the life sciences content supply chain. Currently, campaigns can take upward of 80 days to move from ideation to execution, and by that time the messages and content lose their relevance to the customers.
By bringing "doers” closer together and eliminating inefficient handoffs, agile operations provide an opportunity for teams to test, learn, and iterate at speed. However, Agile (like any other transformative change) needs time, effort, resources, and commitment from all levels of the organization to deliver on its true potential. Leaders who aspire to implement Agile operations need to lay the right foundations first. They need to identify the right use cases, formulate the right staffing strategies, implement the right mechanisms for demand planning, and figure out the right resource mix to set up their Agile implementation initiative for success. Early indications from companies who are implementing Agile show that it is worth it. The objective of this white paper is to explore how agile operations can bring about a transformative change to content and commercial operations in life sciences.

Table of Content

Industry’s speed breakers

Why Agile, why now?

Why is speed-to-market so important?

Why life sciences' content has been slow out of the gate

What is Agile all about?

How an agile workflow saves time?

Which content development is suited for agile pilots?

What should be the role of MLR then?

What does Agile mean for Agencies?

How to get around the traditional brand planning cycles?

Why is resource planning so important?

Is Agile more expensive than traditional operations?

What should be the resource mix of agile pods?

How to staff the teams and who to staff them with?

What are the tools, technologies, and processes that one would need?

Can modular content turbocharge Agile?

The wrap up

One cannot devise exceedingly long-term strategies and unilaterally execute them without course corrections. The statement also holds true for life sciences’ commercial operations in general, and is best illustrated in content operations and campaign strategy. Content development in the life sciences industry has been mostly centered around periodic sales force planning cycles than the market needs. This approach of “set it and forget it” meant that the published content would not be iterated until the next sales cycle or occurrence of key events such as a label update when new data comes in.

Brands were also limited by high publishing and distribution costs. Frequent modifications and variations to the content would result in costintensive reproduction of print assets. Field teams had to be then retrained on the updated content to ensure that they effectively deliver the updated messages as well. As a result, commercial organizations often relied on their field personnel to personalize the messages on the fly based on customers’ preferences rather than frequently updating content and creating multiple variations to suit various customer personas.

As customer-facing personnel are increasingly losing access to their customers—a trend accelerated by the pandemic. This field-centric approach to content does not bode well for the industry now. Therefore, commercial functions cannot just rely on field teams for ad-hoc personalization at rep-led customer touchpoints; content has to lead personalization across all channels now. As customers’ needs, preferences, and personas are evolving at a dizzying pace, content, campaign, and measurement frameworks must shift accordingly to be more dynamic and be in an “always-on” state. Speed and relevancy of content and campaigns hold the key to personalization now, and new operational models are critical to enabling this shift.

Industry's speed breakers—the barriers that have shaped the traditional approach to content

Compliance and regulatory barriers have largely dictated the pace of content development and publishing. Moreover, most of the customer engagements were conducted face-to-face. Therefore, organizations could not systematically measure their customers’ content affinity and preferences. The data collection and measurement systems deployed in the digital channels focused on measuring channel engagement (click, opens, visits, etc.) and lacked the capability to measure content engagement at a granular level. Thus, brands had to heavily rely on field insights or lengthy market research engagements to understand their customers’ content preferences.

Advancements in data collection, measurement, and insights generated over the digital channels have now enabled brands to develop a deeper understanding of their customers’ content preferences. However, content development processes still lack the robustness needed to rapidly operationalize the insights by developing relevant content and tactics at speed. The traditional processes hinder the development of content in an iterative and test and learn approach. The cyclical approach to campaigns also creates a high latency between the measurement and the campaign deployment. Consequently, the teams are limited from developing and distributing content at a volume, velocity, and variety that can keep up with the rapidly evolving customer needs and preferences.

Why Agile, why now?

In this whitepaper, we will explore how agile methodologies can help life sciences organizations to structure their operations to respond to market dynamics in a better way and enable a test-learn-iterate approach to content development at speed. Although the Agile can be applied to a broad spectrum of commercial operations and beyond, the focus of this whitepaper is on agile content development operations (a key area of commercial capabilities). Most of the concepts discussed refer to iterative content development as opposed to developing net-new content. We have deliberately focused the discussion of this whitepaper on iterative content development as many organizations are in the early stages of their agile journey, and iterative content development is a better fit for those organizations. We will explain why that is so in the following sections.

Why is speed-to-market so important?

Speed-to-market of content is vital to stay relevant with the customers. Organizations spend millions of dollars on market research, data collection, and insights generation, and meticulously plan and tune their campaigns in cycles in an attempt to meet their customers’ needs and stay relevant. Despite all their efforts and spending, they are not able to consistently meet their customers’ needs. True personalization necessitates relevancy that is linked to individual needs and preferences. These needs and preferences evolve as the environment, mindset, or other individual situations evolve.

A DT consulting study conducted in 2019 measured the gap between the content preferences of US-based healthcare providers (HCPs) and the content they received from life sciences companies. The study highlights clear gaps concerning what was preferred vis-à-vis what was received.1

Why is speed-to-market so important?

The prolonged time to market of content contributes to this gap. The rate of change of customers’ preferences and demand for information outpaces the rate at which life sciences’ campaign cycles operate. As preferences evolve at a high pace, relevancy erodes from the content as it remains static for longer periods. In the current paradigm, content and campaigns have an increasingly shorter shelf life, and the low velocity content cannot keep up with the evolving content needs of the customer. To stay relevant, life sciences must drastically reduce the time to market of their content and messaging. Though organizations are turning their focus toward personalization at scale, they need to up the ante when it comes to speed as well.

Why life sciences’ content has been slow out of the gate?

Planning, coordination, and handoffs delay the workflow

The content supply chain in life sciences involves multiple stages in the creation and production of content that require work outputs to flow from one functional unit to another. Each of these functional units corresponds to a workstream that addresses a specific stage in the development. Thus, the development requires coordination and alignment between multiple functional units (both internal and external). Each of these functions conducts their own planning exercises and organizes their work differently from one another. Not only are the intra-functional planning exercises inefficient in themselves, but they also need integrated planning exercises to tie them all together. Considerable coordination efforts and time are required to align the priorities among various workstreams and synchronize the workflow between functions. Furthermore, elaborate and expensive integrated planning exercises are needed to plan capacity, budget allocations, resource allocations, and so on.

While the coordinators spend time aligning the plans and priorities, the actual development activities wait in the work queue of the functions. These inefficiencies accrue at each stage of content development eventually adding considerable delay to the process in content development. In many organizations, the majority of these content development functions are not dedicated to brands but are shared services. This adds another layer of complexity to the prioritization exercises and contributes to the delay.

It does not end there! The work output out of each of these functions needs to be handed off to the subsequent function in the content supply chain so that the next stage of development can begin. These handoffs take interfacing, project briefings, kickoffs, alignment meetings, and so on. These interfaces contribute to a gap in the development timeline, which widens at every stage of the development.

Some organizations have decoupled their content supply chain to address creation and production separately. Though decoupled content supply chain and large-scale centralized production operations deliver cost efficiencies, their structures and firewalls fragment the development workflow and slow down the development process.

Traditional content supply chain


Long drawn out initial phases of content development

In life sciences, content must go through a review and approval process by medical, legal, regulatory (MLR) functions before publishing. The cost of review tends to be expensive due to the specialized skillsets needed for MLR review and approval. Thus, the content creation functions come under pressure from the brand teams to create content that is right the first time to keep the cost of MLR review and approval as low as possible. The cost pressure forces the development teams to aim for getting “approval ready” content out of the gate from the get-go. This approach ends up consuming more time in the initial phases of development and stretches the timeline. This approach also enforces a submission bias and discourages adoption of a test-learn-iterate approach to content development.

What is Agile all about?

The technology industry has traditionally done a good job at understanding the need for speed. Case in point: most of the mobile applications are being updated and released at an average frequency of 9 days to stay relevant for their customers. They have been able to do so with the help of agile methodologies.2

Life sciences can borrow a page out of the technology industry's agile transformation playbook to transform their own operations and deliver at speed.

Agile is not just a way of working but it is a way of thinking too—it is a culture in itself. At its core, it shifts the bias from planning to outcome-based actions. One of its 4 core values is “deliverables with value over comprehensive documentation”

So, what does Agile do?

In essence, it eliminates the waiting time, allows process overlaps and concurrent activities to run. It also eliminates non-value added activities and enables the teams to prioritize what matters most for the customers. And it does this by handing greater autonomy to the team members. Also, agile teams have a single stakeholder (the product owner) to align priorities with as opposed to multiple stakeholders in the traditional development. This structure helps them to align priorities quickly and be laser-focused on set priorities. Priorities for the upcoming sprint (work organization cycles that usually last 2–3 weeks) are aligned right at the beginning and are rarely revised in the middle of a sprint. This approach enables the teams to move faster with their tasks without the worry of changing priorities.

Its core principles insist upon bringing together collaborative cross-functional doers only, thereby stripping away the need for extensive planning and coordination. This principle simplifies the operating model of organizations. The autonomy and purpose it hands to the employees drive better employee engagement too.

Finally, although cost savings are not the primary objective of Agile, it is a consequential outcome.


How an agile workflow saves time?

Content development workflow permeates through the stages of ideation, pre-approval, production, post-approval, and publishing. In the traditional development, multiple functions tackle each of the stages discretely. Agile takes the entire development and timeboxes it into 2–3-week sprints where a single agile pod tackles all of the stages as a whole in that sprint.

In the traditional waterfall process, the subsequent stage of development had to wait for the handover of completed output from the preceding stage. Whereas Agile allows activity overlaps and allows them to run concurrently – a large block of work can be broken into smaller chunks and passed on to the next stages of development on the completion of those smaller chunks. For example, in agile development of web content, the testing engineer need not wait until all of the coding is completed and handed over to begin testing. Instead, they can concurrently begin testing part of the code that is completed while the rest of the code is still being written.

As the team members are working elbow-to-elbow, any revisions or amends to output in the preceding stage can be easily communicated and passed on to the ensuing stages to be incorporated. This way of working also takes the pressure off the individuals to get it right the first time. It also allows for a rapid feedback loop within the team that is much faster than the traditional one since it does not have to pass through functional firewalls.

Which content development is suited for agile pilots?

What brands are suitable for Agile? It is most suitable for brands that have higher digital responsiveness and digital affinity. These brands tend to have a higher digital media presence, social media presence, higher web sophistication, and so on. The rich and diverse real-time insights from these sources provide continuous and consistent ammunition for the teams to iterate upon. Also, brands tend to generate the bulk of their insights in post-launch and growth stages—stages that follow the launch till the peak sales tend to generate more insights in all of the brand's life cycle. All the above criteria could be used as filters to select the right brand in the right stage of its life cycle for agile development pilots. In contrast, brands with lower digital affinity tend to have less sophisticated measurement system and insights mechanisms. In mature and late lifecycle brands, in addition to lower volume and frequency of new insights, the opportunity for content iteration tends to decline.

The degree of MLR review rigor applicable and risk profile of the content are also key criteria in the early stages of the agile journey that decide what content can be pulled into agile development.

Higher risk tier

Net-new content
Depiction of interpretation of evidence
Pull content requiring opt-in / active participation

Lower risk tier

Existing or adapted from approved content
Primarily restatement of approved label
Push content/ passive content
When content is categorized into tiers based on its risk profiles, net-new content and new claims get classified under higher risk tiers, whereas adaptations to existing content occupy lower risk tiers. Higher risk content draws more attention from MLR teams, takes a long time for review, and may not fit into agile sprint cycles. Thus, the development of net-new content and campaigns, new core claims, changes to campaign theme and core is not feasible at the early stages of the agile journey. They can throw a spanner in the works by causing review bottlenecks, delays, and derail agile pilots.
In addition to the MLR complexity, authoring core claims needs extensive brand knowledge and expertise that often reside within the brand teams, not with content operations. Unless MLR and brand personnel are fully embedded within agile pods (an agile team of people with varied competencies) to work alongside other pod members, one must not tackle new content development.
How does the complexity increase? Net-new campaigns and changes to campaign theme often carry large creative development aspects involving production elements such as photography and videography. Production of such elements takes time and does not fit well into the agile development frameworks. New campaigns are backed by extensive market research too. Market research includes the elaborate voice of customer (VOC) programs, surveys, and focus groups that are inherently dependent on customers and hence cannot be carried out in an agile way, as Agile works best for activities with very few or no external dependencies.
Hence, agile initiatives are more likely to find higher receptivity from MLR functions, when they are adopted for lower risk content at first. Agile is most suited to iterate upon existing fixed concepts (campaign theme, approved core claims) to develop a variety of assets for various microsegments or customer personas—such as variations and updates to email content, digital detail aids, web page content, banner ad content, social media content, and other forms of digital content.

What should be the role of MLR then?

The role of MLR really depends on the content one picks for agile development. If MLR resources do not have a minimum threshold volume of content to review, it results in the wastage of valuable resource. If they run out of consistent work, it results in a productivity loss. Therefore, dedicating an MLR resource solely to an agile pod may not be an efficient utilization of an expensive resource when there is not enough content to review.

Moreover, agile development teams leverage already approved core claims and core messages to build iterative content. Such content does not need to undergo extensive review, but only an audit and approval. This activity could be delegated to someone who is part of the agile core team and can approve the asset or tactic on behalf of MLR. However, aligning with MLR leadership is critical to ensure success of this approach.

Organizations can start their agile initiatives with iterative development, with peripheral involvement of MLR. Then their involvement must be incrementally scaled to embed MLR into the core agile teams as they mature in their journey and generate enough volumes of content for MLR review. Once MLR is fully embedded, agile can take on higher risk content development that needs rigorous review and approval.

What does Agile mean for Agencies?

Life sciences heavily rely on agencies (both internal and external) for their content development. Brand teams tend to engage with multiple agencies to develop their content. While agencies possess an intimate understanding of the brand and unique skills that makes them valuable, fragmentation is one of the major reasons for inefficiencies in content development. Engaging with multiple agencies requires extensive coordination efforts and resources.

The agile approach relieves most of the coordination efforts by bringing the development in-house within a single team. Does this mean agencies no longer have a role in development? No, they still do; it may be necessary to staff agency resources with specific skills in agile pods. However, the agency engagement model would be entirely different. In Agile, only doers get to be a part of the core team, not the coordinators in the form of account executives and project managers. Agencies are essentially seen as resource pools rather than outsourcing destinations. The objective of this new agency engagement model is to leverage the skills of agency resources without the coordination and bureaucracy components. This is a massive cultural shift for brand teams who are accustomed to interfacing with agency project managers for their work.

Most agencies are not familiar with this type of new engagement model. They have their own cultures, staffing and resourcing strategies, and key performance indicators (KPIs) that do not fit perfectly into the new agile frameworks and new agency engagement models. These differences have to be ironed out, and standardized agency engagement models and rules have to be devised. Organizations must also develop different evaluation and selection criteria for future agency partnerships for agile content development.

How to get around the traditional brand planning cycles?

This is one of the key questions on every leader’s mind who wish to initiate Agile in their organization. Life sciences customarily practices annual financial, strategic and tactical brand planning cycles. Although there are calls for completely reimagining the cyclical brand planning, the industry has not been able to move away from it. In these early stages, agile development has to embrace the cycles and integrate with them. Since Agile is deployed for iterative content development, it has inherent dependencies on brand plans and cannot operate independently.

On the contrary, annual brand plans and their derivatives such as engagement plans and personalization strategies feed Agile. They serve as a basis to estimate the content demand. The variations and volume of content required to achieve the personalization strategy must be estimated from the plans—they depend on a number of customer personas for the given brand, their content needs, customer journey paths, channel preferences, device preferences, preferred frequency of content, and so on. The content demand then dictates the number of agile pods to be set up, the roles that need to be staffed, and resources that need to be mobilized from within, hired, and/or contracted and/or staffed from agencies.

Why is resource planning so important?

In traditional operations, one can afford to have large spikes and dips in workload as the agencies and large-scale content production houses (external and internal) are structured to absorb them. They can also absorb unexpected surges in volume, whereas agile teams are not designed to do so. Agile teams have a fixed capacity and pre-allocated resources; they are structured in a way that each member of the pod is dedicated to a specific job. They are structured to handle a continuous, steady stream of work. It is not easy to increase development capacity at short notice. Agile teams are deliberately intended to be small (typically not more than 10 members) and highly focused. More personnel cannot be just added to existing pods, as large teams tend to dilute their focus and diminish their ability to collaborate. Thus, to increase the development capacity, one has to create new pods, which can take up to 90 days to become operational by some estimates.

On the other hand, when the content volume (in agile development) declines, the built-up capacity cannot be easily released too. As they are a team of mono taskers, they cannot be disbanded and assimilated into the traditional content operations and reassembled when volumes rise again. However, as Agile scales up in the organization and a network of content development agile pods starts operating concurrently, the mobility of the agile team members increases. Then the individuals can be moved among the various agile pods as the needs dictate.

However, in the current context, excess capacity of resources in agile pods directly impacts the cost. Over forecasting leaves fully staffed agile teams without a steady stream of work and eventually resulting in underutilization of resources. Whereas, under forecasting causes a logjam in the agile teams’ work queue and results in delivery delays. Therefore, inaccurate demand forecasting and planning could prove very costly. Agile teams come with a continuous carrying cost too. One needs to carefully build the right amount of capacity to have a high rate of utilization. So, how to plan for resources precisely then? One needs to adopt a capacity utilization approach to resource planning, the way manufacturing industry does it.

Is Agile more expensive than traditional operations?

This tends to be a main concern for most. Agile may seem so, but it is not! At a macro level, traditional operations leveraging centralized content production and shared services deliver cost benefits due to economies of scale. Also, traditional content development has annual peaks and troughs in volume work. Thus, while working with agencies in an FTE-based model, the resourcing cost can be largely contained to a particular timeframe that corresponds to the peaks. of capacity to have a high rate of utilization. So, how to plan for resources precisely then? One needs to adopt a capacity utilization approach to resource planning, the way manufacturing industry does it.


Whereas, Agile bears a comparatively high initial staffing cost followed by a continuous carrying cost. Agile locks in dedicated monotasking teams into a specific development. For instance, an agile pod focused on the development of email content for physicians cannot take up the email content development for patient awareness campaigns. This fixed, non-versatile nature of agile teams does give an impression that agile is more expensive than traditional development—but it is not. According to this study, 20% to 30% of cost savings were realized by organizations that implemented agile.3

Agile’s biggest cost advantage comes from its ability to operate without coordinators and project managers. Also, in the early stages, when only few experimental pods are in play, the agile resources are not fungible, making them a sunk cost if not well utilized. However, when a network of agile pods is in play, the cost savings become apparent. When Agile is scaled across the board for all content development across all addressable brands and regions, the underutilized individuals from one agile pod can be easily relocated to other agile pods catering to different brands, regions, and so on. As agile teams are staffed with individuals having pointed skillsets and not brand expertise, they are easily transferable to other brands’ development pods where their skillsets can be put to use. This flexibility and mobility ensure that their productivity is not lost.

Agile’s cost benefit also comes from a sizeable reduction in the development time and increase in efficiency of individuals that translates to a sizable increase in per capita productivity. Productivity gains essentially save on resourcing costs in the long term. However, these cost advantages are not evident in the early stages of the agile transformation journey. Instead, a substantial investment is needed for transition from traditional operations to agile operations.

What should be the resource mix of agile pods?


Agile teams are purpose-assembled to a great degree. The content demand, engagement plan, and development objective dictate the composition of agile teams. The core team must be staffed with mainly doers, and the necessary specialist support and liaison roles are placed in extended teams. Although there is significant debate around the size of agile teams, research suggests that a team size of 5 to 9 is the most efficient.4

For example, let us consider a typical agile pod focused on developing web content. It may have an author who develops the variations of content, an editor who reviews and approves the asset, a front-end web developer who programs the web pages, a tagging engineer who assists in metadata tagging of asset, and a testing engineer who tests the functionalities and code of developed pages. The team also needs a data analyst who ensures that there is a measurement plan, tracks engagement of the assets, enables testing of messages, and creates a feedback loop for iterations. Data analysts can be part of either the core team or extended team depending on the robustness of measurement and frequency of insight and feedback.

Lastly, the team needs a pod leader/scrum master, who organizes the doers. The scrum master facilitates the hands-on work, the related detailed scrum, and task planning. Although the product owner is responsible for prioritizing the items in the backlog, the pod leaders are involved in backlog grooming. Backlog grooming (also called refinement) is a process where backlog items are refined and organized into actionable tasks before the team can take up the development in the upcoming sprints. The other facet of the scrum master’s role is a facilitator leader who ensures the agile team functions as it is intended to. They act as a quasi-team leader as the individuals in a pod do not necessarily report to them. The pod leaders also act as agile coaches—they protect the team from interference, remove impediments, guide them on agile methodologies, and ensure that the agile practices are rigorously applied. Due to the dual nature of this role, it is recommended that these roles are staffed with individuals who have digital marketing and/or digital content production backgrounds and are trained in agile practices as well.

The product owner who represents the brand. Their primary responsibility is to prioritize the items for development from the product backlogs (a collection of objective-driven tasks). For instance, one of the items in the product backlog could be revamping a landing page to suit the web browsing and content preferences of particular personas of physicians that are being directed to the landing page. The product owner’s role is to prioritize such items in the backlog that must be pushed imminently to development over the items that can be activated and actioned in the next sprint.

How to staff the teams and who to staff them with?

Content demand and content plans necessarily inform on staffing strategies. Based on the requirement, leaders need to devise staffing strategies—How many to source from the internal resource pool? How many to source from agency resource pools? How many to hire? And how many to contract? Organizations who intend to broaden the scope of agile development, need sufficient runway to staff and build the teams, as it could take up to 90 days to set up a fully operational agile pod. The teams essentially will undergo their forming, storming, and norming stages before they start performing to their full potential.

The pod leader’s role is critical to the success of agile operations. They must have an end-to-end understanding and know the nuances of content operations. Since agile pods are composed of individuals with very specific skillsets, they need to be tied together by a pod leader who has a broader understanding. The deep disciplinary expertise of team members must be augmented by cross-functional expertise. Individuals who fit this bill are scarce. Due to the siloed nature of traditional operations, it is hard to find such individuals within the content organization who have end-to-end understanding. This gap must be bridged with rigorous upskilling and training.

Leaders must also pay special attention to the softer elements such as the attitudinal attributes of the individuals. A change driven mindset and a strong execution bias are necessary to work in agile teams. Individuals who thrive in uncertainty are a key for success in the pilot stages, as the processes are fluid and still being defined.

Here is a common pitfall to avoid while initiating pilots. Agile resources staffed from existing teams should not continue to have dual roles; it confuses them with competing priorities and different ways of working. Resources should be fully committed to Agile. While staffing for pilots from the internal resource pools, individuals should be taken out of their current non-agile roles and recruited into the agile pods.

What are the tools, technologies, and processes that one would need?

Agile, principally, is more about individuals and a collaborative way of working rather than about tools and technologies. However, that may be an overly simplistic statement. Advanced tools and technologies may not be needed to initiate Agile, but they are needed to scale it. To cater to multiple brands and markets, one needs to set up a network of agile pods. To manage that network efficiently, demand estimation and tracking tools are necessary. Capacity planning tools are vital to staff the teams in the network with optimum capacity. Greater visibility into the resource utilization of each pod is necessary to transfer the resources as required.

How to do it? Take help of resource management tools to track the utilization and free capacity in the pods. Right project intake processes must be set up to facilitate the intake of development projects from multiple brands and markets.

Automating the steps in testing, pushing the assets for review, publishing, and so on can supercharge the productivity of agile teams and allow them to focus on more value-added tasks.

Along with automation, one cannot overlook the usefulness of standardization in the way the content is built. This may not be appealing, but it is critical. Due to the history of working with multiple agencies, organizations have not been able to standardize tactical aspects such as file formats, the design tools used to build the creatives, the storage platforms, digital asset management systems, and so on. As agile teams iterate upon the existing base, standardizing these tactical elements makes it easier for the teams to work and helps speed up the development.

Can modular content turbocharge Agile?

Modular content is not necessary for Agile but can significantly accelerate the development cycles and help teams focus on value-added work. Teams can leverage content libraries, templates, and modules that they can leverage to rapidly develop content variations. It also helps speed up the review and approval of developed assets—as final assets built by leveraging pre‐approved modules do not need to undergo rigorous review. By dramatically speeding up the development, it enables agile to scale faster across the various types of assets. However, building modules is an effort-intensive task for the brands—they have to build modules of claims, messages, visuals, and so on that the content development teams can leverage to churn out the variations of assets at speed. Automating modular content can dramatically scale up modularization and turbocharge agile content operations on this basis. Modular content is difficult and requires different thinking—from creative, to review/ approval, to production. Trying to implement Agile and modular content at the same time might require change management to a greater extent and slow the organizations learning process.

The wrap up

Executive leadership, brand leadership, and functional leadership buy-in are vital to driving the agile transformation. Agile content development, when scaled across brands and regions, can potentially impact the cost structures, agency partnerships, resourcing and staffing strategies, content supply chain, MLR’s roles, brand teams’ roles, service organizations’ structures, and much more.

Agile is a massive change management exercise. It needs a mindset shift across the breadth and depth of the organization. The ripples effects of agile transformation are not only limited to content operations but are felt across the commercial functions. It also takes a sizable investment to transition from traditional development—investments for resourcing, enabling technologies, modular content, and so on. Most of the organizations will need a top-down approach to drive this amount of change. Leadership must be convinced of the value of Agile—they must be convinced that it is worth making this investment to accelerate operations, and that this way of working improves commercial effectiveness and ultimately impacts business outcomes. Early indications from companies who are implementing Agile show it is worth it.




Srinivasa Adithyan
Srinivasa Adithyan
Srinivasa Adithyan

Insights to build #FutureReadyHealthcare

Let’s partner for #FutureReadyHealthcare

© 2023 Indegene. All Rights Reserved.  

Privacy PolicyCSR PolicyIndegene Speak Up