Start my assessment

IT cost control

IT cost reduction: beyond time and lines of code

Reducing IT costs is first and foremost about rethinking how IT is designed, governed and experienced.

By Souha Kassab · · 11 min read

Cover image for the article on IT cost reduction
What to remember, in 5 key points
  • For BleuLemon, agility is not only a method: it is a governance tool that connects strategy, business functions, IT and finance, so that decisions are better and costs stay under control.
  • Traditional estimation models, built on time and lines of code, no longer reflect real costs: maintenance, security, cloud, energy, carbon footprint.
  • Uncertainty is no longer an obstacle: agility makes it possible to reassess continuously, to make finer trade-offs and to reduce overruns.
  • Total cost of ownership becomes central: performance, sustainability, resource consumption and environmental impact now enter the equation.
  • Reducing IT costs starts with understanding what a solution consumes: every technical choice leaves a footprint and shapes future budgets.

Coffee break, high up in a tower at La Défense.
Around the coffee machine, one question comes back again and again: “How much time and money will it take to build this solution? And would we not be better off with an off-the-shelf one?”

Behind that question sits a far wider issue: how do you measure the real cost of an IT solution? And where does the reduction of IT costs fit in a world where no-code tools, artificial intelligence and CSR requirements are rewriting the rules?

Beyond a simple count of hours or lines of code, the task now is to rethink the real value of a solution: its performance, its ability to adapt to business needs, and increasingly its environmental impact and its contribution to a coherent CSR strategy.
Finance departments demand measurable results and IT departments have to justify every euro invested, so cost reduction becomes a strategic imperative. But how do you reliably estimate the overall cost of a digital solution without losing sight of what it actually consumes?

Are traditional estimation methods enough?
Do we have the right tools to take in the human, material and ecological dimensions?
And above all, how do you stay competitive while honouring the company's CSR commitments?

This article, the first of a trilogy, offers a reflection on the limits of traditional estimation models, the biases that come with them, and the routes towards a more responsible and holistic approach. Above all, it is a reminder of the reasons behind them.

I. Estimating software development costs: an inheritance in flux

Software development has already passed its sixtieth birthday (thank you Margaret Hamilton!), and yet the question of its real costs remains open.

For a long time, the debate boiled down to a slightly simplistic opposition: “time spent coding” versus “everything else”. That framing recalls the software development cost estimation models of the 1980s, such as COCOMO, which take the quantity of lines of code (LOC) as the measure of the effort supplied. Those approaches, useful in their day, did not yet account for ideas that have since become central, such as IT costs or the resources that digital solutions consume.

As recently as 2019, commentators still lamented that developers could spend no more than “4 to 5 hours a day” coding, and described as “lost productivity” the “continual interruptions, as well as the hours spent solving problems and reporting”. Some even went so far as to ask “how to make developers more efficient“ so as to increase the time they could spend coding.

But the landscape has changed a great deal since.

COVID imposed new ways of working, and AI has upended practices and reshaped the tools (see the latest report from JetBrains):

Illustration for the section “I. Estimating software development costs: an inheritance in flux”

Developers' use of AI tools

On top of that, an unexpected player has weighed in: the law!

In France, the National Assembly and the Senate passed law no. 2021-1485 on 15 November 2021, known as the REEN law, which aims to reduce the environmental footprint of digital technology across its whole value chain. Article L. 229-25 of the Environmental Code now obliges companies to account for their carbon impact.

In a world where every part of our lives is going digital, the question is no longer only “how much does it cost to develop a piece of software”, but also “what is its environmental price?”, and how to fold that dimension into an overall strategy for reducing costs and resource consumption. Reducing the environmental footprint of software solutions is no longer a choice: it is a necessity, and increasingly an obligation.

In such a context, it is no wonder that IT departments feel they are walking a ridge line: on one side, deliver solutions that are fast, robust and high performing; on the other, take on CSR objectives, reduce environmental impact and account for costs that fit no standard grid.

The result: reconciling the irreconcilable.

So how do you measure the real cost of an IT solution in the age of no-code, of AI and of CSR requirements? How do you control costs calculated purely in time-spent-coding? And to what end?

In that equation, software development is not an isolated objective: it is weighed against performance optimisation and the reduction of the environmental footprint.

II. Estimating IT project costs: the blind spots of traditional models

..or how do you reduce what you have not properly measured?

Estimating the real costs of an IT project is a demanding task. Traditional models built on the Waterfall approach (or V-model), effective at structuring a project, carry significant limits of their own. In particular, they focus on the means (how many lines typed, how much time spent) rather than on the results (solving the right problem, sustainability).

Those limits are sharper today than ever.

Illustration for the section “..or how do you reduce what you have not properly measured”

A count of LOC (Lines of Code) struggles to reflect the hidden costs of the development cycle (such as cloud and server use, the cost of security, of maintenance, and so on), all of them rarely taken into account in traditional approaches to estimating software development costs. Uncertainty tied to integration environments that keep evolving is poorly accounted for, and human biases even less so (things forgotten, undervalued, indirect costs no one knows about, unforeseen events).

The icing on the cake, the paradigm of the cone of uncertainty: a genuine estimate of a project's cost is hardest to produce at its very outset!

Yet pressure from stakeholders for early figures leads sometimes to overestimation (waste), sometimes to underestimation (frustration, risk).

In both cases, the initial promises of cost reduction quickly become untenable.

Illustration for the section “..or how do you reduce what you have not properly measured”

The cone of uncertainty in project management.

These elements are nonetheless rarely built into mathematical estimation models, even though the COCOMO models have evolved a good deal in that direction (COCOMO-II). They tend instead to paint a fixed, easily quantifiable picture of uncertainty.

Illusions of precision: a false sense of cost control.

The point is not (only) that the tools need changing. Traditional approaches remain relevant in certain cases:

  • a tightly bounded scope,

  • a locked budget,

  • a regulatory deadline.

But beyond the calculation models, freezing estimates too early amounts to producing figures that reassure right up to their first contact with reality. Illusions of precision generate frustration, overruns and rising tension between business units, the IT department and finance, not to mention the moral exhaustion of the teams.

Those frozen figures obscure the real levers of IT cost reduction: flexibility and adaptation.

Let us grant at this stage that you probably cannot optimise what you have not properly quantified .. but to what end?

Beyond the human and financial resources mobilised, the cost of an IT solution today has to reflect other factors whose impact or availability is critical, such as:

  • Material resources: servers, tools, cloud infrastructure, PCs.

  • Natural resources: water (to cool servers and data centres), rare earths, metals used in equipment, electricity, batteries.

  • CO₂ emissions: from hosting, from data processing and from use of the solutions.

In a hyper-connected world, where every line of code can have an environmental impact, ignoring these costs distorts the whole analysis.

So how do you take in costs that no traditional model counts?

III. Agile cost estimation: when uncertainty becomes a strength

The cost of a solution is not an isolated variable: it sits inside a triangulation between the project perimeter (scope), the budget and the time allowed.

Illustration for the section “III. Agile cost estimation: when uncertainty becomes a strength”

The IT project management triangle.

If that dynamic is ignored, software development cost estimation goes astray, and cost control becomes illusory.

If your estimation method ignores the key variables of the context (uncertainty over deadlines, interdependencies between features, operating costs), you are not predicting the future: you are betting on a fixed model inside a moving environment. In a market where margins compress and resources tighten, that bet compromises the cost reduction expected and drains the teams.

Agility: turning uncertainty into a lever for cost optimisation

Agile frameworks bring a pragmatic answer, because agility takes uncertainty in rather than eliminating it. In doing so, it fits better that wonderful faculty of Homo Sapiens: adaptability.
And it does so intrinsically, since it rests on the same pillars of the Agile Manifesto that brought it into being.

Illustration for the section “Agility: turning uncertainty into a lever for cost optimisation”

Agility rests on an integrated approach where estimation, collaboration, risk management and sustainability reinforce one another to optimise value and cost control. Cross-cutting visibility brings design, testing and deployment into a single dynamic. Estimating by iterations and reassessing risks continuously support a sustainable pace and better cost control.

As a result, Agile development teams are able to have estimates reassessed as their understanding of the solution and its complexity progresses!

A feature can be deprioritised, for instance, so that the team concentrates on the essentials.

Fewer last-minute discoveries = less waste = less overestimation.

The ecological equation: when estimating also means measuring your impact

Agility widens the perimeter of the estimate: design, testing, deployment, operation, and also maintenance and decommissioning. This approach gives a fuller view of the total cost of development. It thereby prepares the ground for new dimensions of assessment, with a view to putting in place practices that serve people and their environment.

Because estimating is not just putting a number on hours: it is measuring the overall impact of a choice!

For BleuLemon, agility is not only a method: it is a governance tool that links strategy and operations, putting business functions, IT and finance in dialogue, to decide better and spend less.

Doing that will even mean going beyond Agile frameworks.

IV. Total cost of ownership (TCO): a wider view of IT cost reduction

In France, the ecological transition agency (ADEME) has set the horizon for carbon neutrality at 2050 and identified four possible trajectories: frugality, repair, regional cooperation and green technologies. Transposed to information systems, now bound up with almost every area of our urbanised lives, that means every decision, whether of hardware, of architecture or of software, either contributes to that goal or does not.

From that perspective, it becomes essential to tie performance KPIs to the real added value of a solution. In other words, budget decisions, and operational ones, should no longer serve a logic of immediate return alone (how much do I make?); they should be weighed against the long-term effects of the solution built, on the customer, the community and the environment.

Illustration for the section “IV. Total cost of ownership (TCO): a wider view of IT cost reduction”

The new Agile triangle

A complex approach, certainly, but one that has become unavoidable in contemporary debates on the responsible management of resources.

Here again, tools already exist: open-source solutions for estimating the carbon footprint of an application (Green Algorithms), the use of more energy-frugal GPUs, and the adoption of new analysis frameworks (openLCA) are redefining the way we assess IT solutions.

These tools currently allow a more global approach, taking in both the direct costs of infrastructure and software and the externalities of energy consumption, greenhouse gas emissions and hardware obsolescence, which are often left out of information system governance.

In other words, they enrich the dashboard that guides trade-offs, just as budget or schedule do.

But how do these principles take concrete shape, as close as possible to the tools IT departments use every day? In a forthcoming article, Stéphane Génin, President of BleuLemon, offers a direct demonstration on Jira Software, showing the real impact of a single feature on resource consumption, and therefore on costs. Sign up so that you do not miss it.

V. IT costs, performance and environmental impact

This article has set out the value of a holistic approach when it comes to estimating the real cost of an IT development. Beyond the traditional frameworks, there is an urgent need to think about today's solutions in sustainable terms.

Estimating the cost of a solution has never been so complex… nor so necessary.
Behind the figures lies the question of real value: what the solution brings, what it consumes, and the impact it leaves on the surrounding world.

Agility helps us move forward differently: accept uncertainty, reassess regularly, bring performance, sustainability and cost control closer together.
IT cost reduction is not an end in itself: it is one compass among others, in dialogue with business priorities and the environmental footprint. To estimate today is not only to count hours; it is to take a position in a world that is changing.

In that context, Agility brings the tools but the approach has to remain holistic.

Illustration for the section “V. IT costs, performance and environmental impact”

Far from separating “hardware costs” on one side and “good practice for green IT” on the other, BleuLemon has chosen an overall strategy that reduces both your costs and the carbon footprint of your solutions.

See you in the second article of this series, where we dive into the still little-known world of the “tools and initiatives” that feed this ecosystem.

Illustration for the section “V. IT costs, performance and environmental impact”