Skip to main content
Back to News
Lessons learned: Delivering software programs (part 1)

Lessons learned: Delivering software programs (part 1)

14 August 2024
  • Software Engineering

By Stephen McCarron, Head of Forecasting Engineering

Delivering large software programs is challenging. Having worked in software delivery for many years, across a wide range of programs of all sizes and scopes, I’ve seen many different approaches to delivery, with varying degrees of success.

Over time I have seen various practices that more often predict a program’s likelihood of success.

Some of the more notable ones are:

1. Alignment on outcomes

Ensuring everyone is shooting for the same thing

2. Addressing uncertainty

Removing complexities early

Read part two
3. Constant adaptation

Adjusting quickly when the state changes

Read part three
4. Compartmentalising

Breaking down problems into smaller, independent units

Read part four
5. Communicating

Ensuring everyone is up to date with the ever-changing state

Read part five

In this series of articles I will describe each in turn, detailing what they look like in practice, why they are important and how you might implement them.

1. Alignment on outcomes

A typical IT project involves many participants, from those doing the coding and development to customers, end-users, partners, stakeholders and sponsors. Each shares an investment in the project’s success.

For some, their understanding of the project needs to be very granular, for others that understanding should be high-level but what everyone needs is a shared understanding of – and alignment on – the intended outcomes. All too often this is not the case.

Achieving alignment and clarity on the goal of a project allows everyone to make better decisions, decisions that align best with the outcome. It enables the teams doing the work to focus on a clear target that they can optimize towards and ensures stakeholders are clear on what is being delivered, allowing them to have productive interactions with delivery teams along the way.

Lessons learned: Delivering software programs (part 2)

“Successful programs prioritise dealing with uncertainty.”

Read part 2 now

Defining the goal

How the goal is defined is important to the successful delivery of a project:

  • Goals should articulate the business outcome that is intended, not the manner of achieving it
  • Goals should be clear enough to work as a reference point for decision making

When defining goals it is easy to say something vague yet unarguably positive, for example, “Increase revenues on platform X”, “Diversify portfolio” or “move to cloud”. But this is unhelpful as it does not give enough information to inform decision making.

Articulating the why

Articulating the “why” is important to achieve your objectives; if this is unclear in your program then it is going to cause problems.

Often these generalisations occur to avoid difficult conversations at the start of a program when different stakeholders can have different concerns, which often results in more general “keep everyone happy” outcomes. Therefore it is better to iron out those differences early rather than after investing too much time, money and effort.

Once agreed, all the key stakeholders need to get behind those outcomes. If stakeholders, sponsors and participants are interpreting the goal differently it is like building a tunnel from either end but each end going in a slightly different direction, with obvious consequences.

Example: Moving to the cloud

Take as an example a paradigm often found in the industry; moving to the cloud. If the outcome is defined crudely as “move to the cloud” it will likely risk cost overruns and have teams doing more than is strictly necessary because there are so many different ways to move to the cloud.

This generic target doesn’t specify how the program will help the business achieve what it wants to because the goals aren’t clear. What needs to move? To what cloud? Why even do it at all? How does one expect to benefit from using the cloud?

There are a huge number of decisions that will need to be made before achieving the outcome of ‘moving to the cloud’. As it is, the goal gives no assistance in decision making when it should act as a guide to steer the choices made.

Better would be to articulate the benefits the business hopes to gain from the move, outlining the “why?” of the program.

In this cloud example, the why could be, for example, to “deliver cost savings through elasticity of usage”. This extra information explains the intended outcome and allows the team to optimise the way they do the job to achieve a successful result. In this case they can make localised decisions that optimise for cost savings, helping the business achieve its outcomes.

Getting that shared outcome clearly articulated is a key component of successful delivery. Try asking the question of “why?” independently of the participants in your program, if you get a large variation in responses then I recommend you do something to correct.

Latest News

Going 15 Percent Faster with Graph-Based Type-checking (part two)
  • 13 Jan 2025

Hear from Florian, Open-Source Software Engineer, in the second part of this two part series, on the challenges and breakthroughs of an internal G-Research initiative aimed at enhancing the .NET developer experience at scale.

Read article
G-Research December 2024 Grant Winners
  • 09 Jan 2025

Each month, we provide up to £2,000 in grant money to early career researchers in quantitative disciplines. Hear from our December grant winners.

Read article
James Maynard on Prime Numbers: Cryptography, Twin Primes and Groundbreaking Discoveries
  • 19 Dec 2024

We were thrilled to welcome James Maynard, Fields Medallist 2022 and Professor of Number Theory, at the Mathematical Institute in Oxford, on stage for the latest Distinguished Speaker Symposium last month. James’ talk on Patterns in prime numbers hones in on unanswered questions within mathematics and the recent developments that have brought the solutions to those problems closer to reality. Hear more in his exclusive interview with us.

Read article

Latest Events

  • Platform Engineering
  • Software Engineering

Hack the Burgh

01 Mar 2025 - 02 Mar 2025 The Nucleus Building, The University of Edinburgh, Thomas Bayes Road, Edinburgh, UK
  • Quantitative Engineering
  • Quantitative Research

Pub Quiz: Oxford

12 Feb 2025 Oxford - to be confirmed after registration
  • Quantitative Engineering
  • Quantitative Research

Pub Quiz: Cambridge

25 Feb 2025 Cambridge - to be confirmed after registration

Stay up to date with
G-Research