When was your last responsible moment? Procrastinate to make better decisions

There are many obvious advantages to making a decision quickly and then acting on it. However, in complex projects where a wide variety of factors are at play, and many unknowns exist, such as software development, far better outcomes can be achieved by waiting until the last responsible moment before making a decision.

The Last Responsible Moment, or LRM, is the strategy of postponing a decision until it becomes more costly to wait than to act. It acknowledges that certain choices have lasting consequences and are hard to undo.

One simple example to illustrate: when planning a trip, you don’t know if it’ll be raining or not. Let’s say you don’t already own an umbrella or waterproof coat, and outside of this trip, you don’t really need them. You could simply buy them anyway, and then you have mitigated the risk of getting wet, but you’ve also incurred the expense of purchasing these items that’ll now sit languishing in the cupboard. By delaying your final purchasing decision until the last responsible moment (waiting for the most accurate weather forecast available while allowing for the expected delivery time of the items), you’ll only incur the expense if you really need them.

Strategic Delay

Sometimes, what appears to be procrastination to outsiders is actually strategic delay. If a decision isn’t urgent, leaving your options open gives you time to collect more information, leading to a better-informed choice and avoiding the potential difficulty and expense of reversing a hastily made decision.

The hard part is that there often isn’t one single moment, and you might only know just when it passes. Equally, the moment can last for days or even weeks.

Personally, I find the concept useful as a heuristic for evaluating whether a decision must be made now or can safely wait or be punted down the road a bit when we’ll all know more than we do now.

If there are specific unknowns that would help to be known, then you can also direct work towards finding that information before the decision must be made.

Here’s how the concept is applied to the more complex endeavour of software development; plus, it’s useful for non-technical stakeholders to understand why we do things this way.

One of the perennial issues for us as an agency is helping the client determine an appropriate budget for a new software development project. Ignoring for now how this initial budget is determined in the first place (that’s a topic for another time), the real question for each feature is, “How are we going to do this?” The problem is that when you have these conversations too far in advance of actually doing that work, there is an increasing chance that the conversation was wasteful.

• By the time the work happens, it might simply not be needed. Earlier decisions were made, which means the system took a different turn from what was originally imagined.
• Assumptions made at the time to size it initially may no longer hold true. Other factors could well have changed, so this conversation has to be held again to find and understand all the new assumptions.
• If the conversations happened a long time ago, key details may have been forgotten and have to be rediscovered. Similarly, the team itself may have changed, so the people involved in the original discussions are no longer working on the project.

Another way this can play out is in the ongoing software development journey. You can deliberately delay shipping a feature and see if your users actually miss it.

It’s all about risk management. By strategically delaying decisions that are costly and difficult to undo later, we give ourselves more options to gather additional information to make a better decision for a successful project.