It is seldom that a manager get acknowledgment for postponing a decision when a decision could be taken although a decision could be deferred and better and maybe crucial information and data would be available. Please read below about the lean principle "Defer Commitment" that could save you from taking a bad decision in the future.
Emergency responders are trained to deal with challenging, unpredictable, and often dangerous situations. They are taught to assess a challenging situation and decide how long they can wait before they must make critical decisions. Having set a timebox for such a decision, they learn to wait until the end of the timebox before they commit to action, because that is when they will have the most information.
We should apply the same logic to the irreversible decisions that need to be made during the course of software development: Schedule irreversible decisions for the last responsible moment, that is, the last chance to make the decision before it is too late. This is not to say that all decisions should be deferred. First and foremost, we should try to make most decisions reversible, so they can be made and then easily changed. One of the more useful goals of iterative development is to move from “analysis paralysis” to getting something concrete accomplished. But while we are developing the early features of a system, we should avoid making decisions that will lock in a critical design decision that will be difficult to change. A software system doesn’t need complete flexibility, but it does need to maintain options at the points where change is likely to occur. A team and/or leader with experience in the domain and the technology will have developed good instincts and will know where to maintain options.
The text is from the book “Implementing Lean Software Development: From Concept to Cash” a great book by Mary Poppendieck and Tom Poppendieck.
Here is a bit more about “Defer Commitment” from an interview with Mary Poppendieck by Gustaf Brandberg (read the full interview at citerus.se):
Gustaf Brandberg: Another principle is delaying commitment. Isn’t the project schedule in danger of slipping when no one dares make a decision?
Mary Poppendieck: A military officer who was about to retire once said: ‘The most important thing I did in my career was to teach young leaders that whenever they saw a threat, their first job was to determine the timebox for their response. Their second job was to hold off making a decision until the end of the timebox, so that they could make it based on the best possible data.´
Our natural tendency is to make decisions and get them over with. However, it is far better to determine the timebox for every decision, and then make the decision at the end of the timebox, because then we can make decisions based on the best possible data. In Lean Software Development, decisions are not avoided; they are scheduled and made at the last responsible moment. This assures that all decisions are made in a timely manner, yet they are made with as much information as possible to help make the best decision possible.