Tools for deciding, or confusing?
The last few days have been spent clarifying the problem and then trying to understand the tools best suited to solving it. We used a little bit of a methodological approach even in deciding which tools to try (!), and then each person volunteered to try to implement the ones that interested them. Upon meeting again, we attempted to present the results of our findings to each other, most of us thinking that our work had got us to the point where the group might be able to finalise decisions.
How wrong we were!!! Our internal biases had once again led us astray, and into thinking that our work could be without fault, and that each of the others would automatically understand what we had worked on, making the assumption that they had the same tacit knowledge that we did! It's becoming clear to me that managing all kinds of bias is certainly the biggest and most important challenge when making any judgement or decision.
What actually happened was that we found our work either littered with mistakes we hadn't previously seen, or in some cases, the rest of the group held wildly different views when presented with the work we had each done. This meant that much of what we had done turned out to be work in progress rather than the finished article, as so much rework was required! For example, I had largely focused on the decision trees, both for deciding what our options were and working through the possible results of around 8 different resultant scenarios. But, I'd failed to take into account that we might need another tree entirely for choosing the best location, or that sunk costs shouldn't have been included in the expected value calculations...
Once again, that means that after much confusing of our teammates, who might not have known the tools we worked with as well as we did, and realising that even we might not have used them correctly and entirely, or done requisite research, we find ourselves unable to make a decision still! Monday will be an important day for this.
Reflecting back, and thinking about future applications, I think that this will always be a problem. We will often have to present to colleagues entirely unfamiliar with our methods, so it will be crucial to learn how to translate our resuls in a transparent way, making sure to avoid the curse of knowledge. Of course there will be times when we fail to see errors in our work, so it is also very helpful to have colleagues who also know the methods and can check our work. This is quite a common approach in most engineering situations already, but perhaps as managers or leaders, we are not quite so used to this.