COGNIZANT CONSULTING
Helping organizations engage people and uncover insight from data to shape the products, services and experiences they offer
Learn More

Contact Us

THANKS FOR YOUR INTEREST IN COGNIZANT.

We'll be in touch soon!

x CLOSE

Refer back to this favorites tab during today's session for access to your selections.
Refer back to this favorites tab during today's session for access to your selections.x CLOSE

Perspectives

Top 10 Reasons Software Development Lifecyle Automation Can Fail

2018-04-05


Automation is seen as a panacea for digital success. But it’s also filled with potential pitfalls and traps. Here’s what you can do to avoid them.

In today’s digital era, software automation is the key to cutting response times and unlocking even faster and better service delivery. While automation’s benefits are well established, many companies still find themselves on creaky IT foundations and/or have unrealistic expectations of how much can truly be optimized. 

We’ve identified the most common reasons that automation can fail across the software development lifecycle (SDLC). What follows is our advice on how companies can ensure that their investments turn sunk cost into an operational advantage and avoid liabilities. 

Figure 1

Not accounting for maintenance costs.

While new automation initiatives are often well planned and budgeted for, accounting for maintenance costs tends to fall through the cracks. It is essential to have clarity on where the budget for ongoing maintenance comes from — as part of projects or from a centralized fund — to properly estimate costs during IT expense planning. The cost of a maintenance miss is especially steep in the world of Agile and DevOps, where cycle time comes at a premium.

Aiming for headcount replacement rather than skill augmentation.

Viewing automation as job replacement is self-defeating, since the very people who create the algorithms are also the ones who will eventually be replaced. As such, this gives teams very little incentive to explore every avenue for automation. Moreover, in today’s knowledge economy, replacing a team with years of enterprise experience is typically counterproductive over the long run. It’s better to view automation as yet another tool to complement and free up the team for more innovative and value-added activities.

Viewing automation solely as a cost reduction lever, not as a source of innovation.

The business value of automation is often restricted to the bottom line and ignores more nuanced outcomes such as speed and quality. This sort of a narrow definition makes it difficult to determine return on investment (ROI). Automation ultimately needs to solve a business challenge and that obstacle typically transcends cost reduction. Excessive cost is only a symptom of the underlying problem. Sometimes, an automated solution might not reduce cost at all but still meet broader business goals such as faster service across more channels.

Treating automation as a checkbox rather than a catalyst for cultural change.

When organizations view automation as just another initiative, it tends to create a division between automation and non-automation resources. This makes automation the responsibility of only one group, who then miss the expertise of the other, which can lead to issues down the line. To avoid this, organizations should approach automation from a change management perspective for the entire organization.

Enacting ill-timed development cycles.

Automation initiatives are often put on the back burner while competing projects take center stage. As the calendar comes to a close, and managers have available budget, the focus typically shifts to automation as pre-paid investment in the coming year’s plan. In this process, what often happens is that traditional due diligence is disregarded in favor of “making the most” of the funds available and organizations end up automating processes that deliver subpar ROI.

Suffering from a lack of focus.

Automation provides a quantum leap in efficiency and typically provides the greatest “bang for the buck.” Automating indiscriminately, however, often leads to bad habits. For example, some organizations may find themselves stuck with large automated test suites that are unnecessarily run and re-run without ever catching a defect, just because it takes no additional effort. Thus, it is always better and especially important to be highly selective with automation projects.

Positioning each team as an automation island.

Since teams typically span silos, many organizations view automation very locally. In reality, automated assets created by one team are valuable to other teams as well, such as build automation that both development and testing teams can use. However, when the build automation process is isolated, other teams might end up re-creating automated assets, applying their own standards along the way. This reduces asset reuse and leads to a lack of consistency across the enterprise. While one team might be responsible for the creation and maintenance of automated assets, there should be collaboration across the lifecycle to ensure maximum reuse and ROI.

Eroding the company knowledge base.

One of the unintended consequences of automation is that it undervalues subject matter expertise, which prevents the passing of learned knowledge from one generation of workers to the next. This could gradually lead to an undermining of systems knowledge within teams and the entire organization, which could spell disaster if and when automation fails to achieve preset expectations, since no one person would be able to manually correct the shortcomings. Therefore, automation should always be complemented by strong documentation and knowledge management systems to ensure that reliance on automation doesn’t become a crutch in times of need.

Being impatient when it comes to financial returns.

As with other capital investments, automation requires a high initial outlay with the promise of future returns. To accelerate its realization, it is common to take a big-bang approach where more automation becomes a goal unto itself. This usually ends up defeating its purpose as ambitious savings targets remain unmet and project sponsors become hesitant to fund a failing cause. Thus, it is always better to take a phased approach, initially picking the low-hanging fruit that is simple to automate and will generate a quick return, before moving to more complex tasks. 

Choosing the right application to automate.

To further confound decision makers, there are a variety of specialized tools for various niches of SDLC automation. While a specialized solution might be apt for a few projects, it might not make business sense at an enterprise level. Before committing a substantial amount to one tool or another, organizations must conduct a detailed study, benefits and timeline analysis of all available tools to determine the best fit. In short, IT practitioners must automate for the right reasons, the right process, in the right way and with the right team. 

To learn more, please read ‘Missing the Mark: Ten Reasons Why Automation Fails,” visit our Quality Engineering & Assurance Practice, or contact us.

Related Thinking

Save this article to your folders


Save

PERSPECTIVES

Quality at Speed: The Key to Digital...

New Forrester research reveals the importance of software quality and...

Save View

Save this article to your folders


Save

PERSPECTIVES

The Ascent of Virtual Private Assistants...

Virtual assistants will soon remake enterprise collaboration. For those...

Save View

Save this article to your folders


Save

PERSPECTIVES

Agile Software Development: Budgeting...

As your organization makes the shift to digital, here’s how it can scale...

Save View
Top 10 Reasons Software Development Lifecyle Automation Can Fail