JDI and it’s slightly more risqué cousin ‘JFDI’ are management maxims that we have probably all come across from time to time. The acronym ‘JDI’ stands for ‘Just Do It’, and its implications are that we should stop thinking about anything except the immediate task at hand, and plough on—often without questioning the validity of the task or considering whether the results of the task will actually be desirable.
It has to be said that there are some contexts where JDI really is the best approach—where urgent action without deliberation or hesitation is necessary. If you are in a meeting and the fire alarm goes off, there is some very clear action that needs to be taken (evacuate via the nearest and safest escape route). This is likely to be fairly uncontroversial, and even if people had different views on how the situation could be handled, the urgency of getting out of the danger is sufficient enough that we need to quickly decide, commit to action, and then ‘Just Do It’. Of course, once you are out, there will be time to reflect and it is highly likely that someone will want to assess the root causes of the problem (in this case the fire).
Organisational Problems are Rarely Clear Cut
The types of problem we deal with in organisations tend to be tricky, messy and open to interpretation. So often there are different perspectives on what the business problem actually is, and if these aren’t discussed then we are going to end up at best delivering something that disappoints some groups of stakeholders, and at worst we’ll end up circling round dealing with conflict and eventually ‘pushing something over the line’ once everyone is exhausted and fed up having worked 15 hour days for the past six months. Combine this with the human tendency to fixate on solutions before fully understanding the richness of the situation and the problem, and that other managers have a tendency to issue the ‘JDI’ to get those ‘solutions’ implemented we enter dangerous territory. In some corporate cultures ‘JDI’ may be seen as bravado – it reinforces the idea that senior managers set the agenda, middle managers set the work, and everyone else just follows. Yet what if someone on the shop-floor knows something fundamental that drastically affects the range of possible solutions? Should we ignore it? Of course not!
In reality, there is a strong argument that solving problems is about learning. Rarely does any single stakeholder have the full broad and detailed picture. It is by facilitating collaboration that we start to understand the detailed nuances of the problem, and then we can start to discuss and propose interventions (‘solutions’) that might improve the situation.
This might sound abstract, so let’s take a hypothetical example. Imagine a piece of work is initiated to:
“Migrate from CRM Package A to CRM Package B”
We could ‘Just Do It’ – work on getting the data migrated between the two packages. But then what? Surely there will be processes that interact or rely on the new software? And people that will need to be trained? If we ‘Just Do It’ we’ll probably deliver a silo’d software change that is unlikely to have the full range of benefits that were anticipated. Delving deeper, one of the first questions that ought to be answered is why (or what outcomes/benefits are you looking for and what problems are you trying to solve)
Imagine the sponsor articulates the problem as:
“Nobody is using CRM Package A, so I want to buy CRM Package B – I used it in my previous organisation and everybody loved it”.
Now we are getting closer to the nub of the issue… the problem from the sponsor’s perspective is that people aren’t using the CRM system. This can lead us to ask why this is the case, and will lead to many other questions besides. Techniques like multiple cause diagrams, fishbone diagrams and problem statements can be useful exploratory tools here. We can engage with the wider stakeholder community, understand the needs and perspectives of a whole range of stakeholders, and come back with a number of options.
Perhaps we’ll even come back with something quicker, cheaper, and more effective than the initial idea. Perhaps a better acronym is ‘GOAL’ (Get On And Learn)—collaborating with teams to understand the situation and get closer to a shared objective. And surely that’s more valuable than the bravado of ‘JDI’? 🙂
What are your views? Please add a comment below, and let’s keep the conversation flowing!
If you’ve enjoyed this article don’t forget to subscribe.
About the author:
Adrian Reed is Principal Consultant at Blackmetric Business Solutions, an organisation that offers Business Analysis consulting and training solutions. Adrian is a keen advocate of the analysis profession, and is constantly looking for ways of promoting the value that good analysis can bring.
To find out more about the training and consulting services offered at Blackmetric, please visit www.blackmetric.com
I have found that once I know what to do, how to do it, and a first iteration of the procedure or task list has been created it is best to use JDI.
I have also found it is only worthwhile to do JDI just long enough to get the data, then have a retrospective on how to improve, and repeat the cycle.
The other thing I have found is if JDI comes from top down and I am not involved in the retrospective or improvements then I hate JDI. Although, if I am involved in the improvements then JDI becomes apart of the process to improve then I see the value, and have greater desire to JDI.
Thank you for sharing Adrian, hope you are well!
Thanks Adam, glad you liked it! Yes, I agree–the process you’ve described sounds very much like a “learning cycle” where the situation is assessed, probed and then reflected upon. That sounds like a great approach… And as you say, when the JDI is top down then it’s much trickier.
Thanks again, glad you enjoyed the article.