Decisions Not Made
When you get right down to it, we spend a lot of time every day making decisions. From the clear decisions of how we are going to spend our time, whether we are going to do this or that, to decisions that are not as consciously performed, like how we’ll make that first coffee in the morning or choosing our route home in the evening.
On projects, the decisions we make on a daily basis determine the outcome of the project. Some more than others, of course, but like a butterfly flapping its wings in the Amazon, many of our decisions have far greater impact than we might think.
Even more than those small decisions we do make, though, it is the decisions we often neglect to make on our projects that can have the greatest impact at all. it’s unlikely that this impact will be positive.
Many of the decisions we don’t make fall under the category of assumptions.
Assumptions never cease to amaze me in training sessions. When I set a group loose on an exercise, I rarely get a question about my instructions (even after I raise this very point). Far more often, though, when it is time to debrief the exercise results, many of the questions I have to field are actually about details that weren’t even understood up front. The group has forged ahead with implicit assumptions.
We all go through life, everyday, supported by a large number of assumptions. We build routines, standard ways of doing things to reduce the number of decisions we need to make. While chances are that these decisions were appropriate as a basis for our routine assumptions when they were formed, there’s a good chance we are running on a bunch of decisions that are now, over time, seriously flawed. It wouldn’t make sense to always question everything we do, but at least once in a while, we should step back and consider if our assumptions are still valid.
One great way of validating our assumptions when we are interacting with someone is to paraphrase what we thought we heard. If they can confirm you got it right, you’ve made reasonable assumptions.
On projects, another type of decision we don’t make are the ones where we simply choose the first good looking option that comes to mind.
We take the first words out of our end-user’s mouth as gospel rather than analyzing whether this is indeed an appropriate requirement. Our system design is usually not the one chosen after comparing a range of potential options and selecting the best, but more likely the first one that pops into our head. I would guess that few of us have given much thought as to whether a bubble sort or a selection sort would be more appropriate in a given situation after we had to answer that question on an assignment back in school.
We look back on these decisions and lament “why hadn’t I thought of that?”. It is usually better to select from a range of possibilities that we have generated than to just go with the first thing that pops up.
Still another type of non-decision occurs when we delay making a decision until we have run out of options, and there is only one way left to deal with an issue. This is often forced on us during projects as we discover late in the project issues that were injected in the early stages, but have been lying hidden, typically because we haven’t hunted them down. If we find a requirements flaw early, we have a wide range of approaches to fixing the problem, but when we catch the same problem a week before we ship, it’s far too late to adjust the architecture to address the issue.
Frighteningly, I know people that routinely use this as their standard time management strategy.
Finally, there are those decisions that are made without the right people involved in the process. A set of requirements written by an analyst, without consulting the developers for feasibility, the testers for testability, or sometimes even the customer for…well, you get the idea here. Taking the opportunity to decide on something when the person who should be involved is on vacation. Making promises that something will be delivered in a given timeframe, despite what you know the people doing the work would say.
This seems to be, sadly, making the proverbial “executive decision”.
Outdated assumptions, taking the first thing that will work, running out of options, and not involving the right people in the decision-making process. Each approach can be devastating to your project, and we are all guilty of these on occasion. Which ones are going to come back to haunt you later in your project? – JB