Skip to main content
We're enhancing our site and your experience, so please keep checking back as we evolve.
Back to News
Lessons learned: Delivering software programs (part 3)

Lessons learned: Delivering software programs (part 3)

14 August 2024
  • Software Engineering

By Stephen McCarron, Head of Forecasting Engineering

This is the third blog in a five-part series from our Head of Forecasting Engineering on the complexities of software program delivery – and the practices that more often predict a program’s likelihood of success.

Constant Adaptation

Every single day in the lifetime of a program brings new insights; more problems have been found, more problems have been solved and new information revealed.

The impact of this is that the plans in place the prior day might not be the best plans for the next. Well run programs acknowledge this and make adaptations quickly to better deal with those new realities.

In order to successfully adapt you need to ensure timely and appropriate communication with the program leadership. But before you get there, you need good information to make proper assessments and revisions.

Once you have mechanisms in place and confidence that you are as aware of the situation as possible, then there are various levers that are typically pulled to keep things running most optimally:

  • Allocation of people and resources
  • Removal or escalation of bottlenecks and blockers
  • Adjustments in priorities
  • Adjustments in outcomes or costs
Lessons learned: Delivering software programs (part 1)

“Achieving alignment and clarity on the goal of a project allows everyone to make better decisions, decisions that align best with the outcome.”

Catch up on part one

Allocation of people and resources

As far as possible, you want to leave teams stable through the project’s lifetime. This ensures continuity of understanding, of communication and of outcomes. The goal is always to have those teams moving as efficiently as possible to the outcome. However there are various reasons why you may need to change this. And if you do, the faster you change things the better.

Once you are aware of an issue, make the necessary change and monitor whether it is having the expected outcome. Like any adaptive process, fast feedback is critical.

The changes might be of various forms:

  • Bringing in more people: A workstream might have become more critical or revealed as a key dependency. Often the best approach here is to swarm that project.
  • Taking people out: Conversely to the above, if this stream is of lower and lower impact, then move people out to higher priorities. This has a bigger impact than adding more people, so be careful not to move so many people out that the entire work is then difficult to reboot.
  • Swap people: Sometimes the skills or dynamic balance isn’t working quite right and the team isn’t moving as efficiently as they could. Perhaps a domain technical expert needs to be brought in. Or someone who has a stronger relationship with a critical dependency, or perhaps just someone who is more able to communicate the outcomes to the team.

Whatever the reason, it’s important to identify when a team isn’t working as effectively as it could, and doing what you can to help that.  Often this can be the most difficult thing to get timely information on, and awareness of a team that needs help can remain un-surfaced until very late so do try to find ways to monitor this.

Removal or escalation of bottlenecks and blockers

Well run programs will not let bottlenecks persist for too long without some intervention. An example anti-pattern here I see is when these issues are held in a queue for some irregular review meeting, a “design committee” for example. If you see this then alarm bells should start sounding.

Any bottlenecks should have a quick escalation path. If the team can’t overcome them quickly then it should keep escalating until it gets to the program leadership. And they need to act promptly.

This isn’t always a case of simply getting the bottleneck removed. Sometimes the bottleneck will be too difficult or costly to remove, therefore the decision might be to sidestep the bottleneck, or give freedom to aim for different targets whilst it’s dealt with.

The key point is the program leadership should be imaginative in doing whatever needs to be done to allow the team to continue their flow toward the outcome.

Adjustments in priorities

Prioritisation is always clearer at the program level than at the team level. The criticality of one workstream isn’t always as clear as it might be within the stream. Inevitably difficult decisions will need to be made both within a workstream and across them. The critical thing is to make any reprioritisation decision as quickly as possible.

The goal of the program team is always to allow the workstreams to have a clear outcome and to have minimal disruption to their flow. If their priorities need to be changed, do it fast and decisively. And communicate it very clearly.

Adjustments in outcomes or costs

Often after progressing down one avenue something is discovered that threatens the intended outcome, for example, something is more costly or difficult than anticipated.

This is normal. The adjustment to be made here is to either accept the changing cost and continue down that avenue (or a new path that leads to the same outcome), or to adjust the outcome to the new understanding. This wouldn’t typically be a complete rewrite of the outcome, but more likely it would be an adjustment of one of the sub outcomes at the workstream level.

For example it may have anticipated getting to a key result of 95%, you might accept that moving to 85%, or they may have anticipated offering 10 features, now you anticipate nine. The scale to which you are prepared to move that outcome will often require collaborating with key sponsors and stakeholders. Do that promptly.

Through all this, be sure to find ways to keep informed and ways to inform others. And act quickly to ensure the entire program is not held up.

Catch up on the rest of the series!

1. Alignment on outcomes

Ensuring everyone is shooting for the same thing

Read part one
2. Addressing uncertainty

Removing complexities early

Read part two
3. Constant adaptation

Adjusting quickly when the state changes

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

Latest News

G Research
G-Research September 2024 Grant Winners
  • 08 Oct 2024

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

Read article
Lessons learned: Delivering software programs (part 5)
  • 04 Oct 2024

Hear more from our Head of Forecasting Engineering and learn how to keep your projects on track by embracing constant change and acting quickly.

Read article

Latest Events

  • Quantitative Engineering
  • Quantitative Research

Oxford Coding Challenge

23 Oct 2024 University of Oxford, Computer Science Lecture Theatre A, 7 Parks Rd, Oxford, OX1 3QG
  • Quantitative Engineering
  • Quantitative Research

Cambridge Coding Challenge

28 Oct 2024 East Hub 1, University of Cambridge, JJ Thomson Avenue, Cambridge, CB3 0US
  • Quantitative Engineering
  • Quantitative Research

Cambridge Quant Challenge

06 Nov 2024 University of Cambridge, Centre for Mathematical Sciences,  Wilberforce Road,  Cambridge CB3 0WA

Stay up to date with
G-Research