👉 If you haven’t read Part 1, do that first.
In the last post, I discussed the question of access to capital and why’s important to verify that we do in fact have a problem before we attempt to “solve” it.
Now, we’re going to talk about the method for measuring the extent of this problem — after all, you can’t improve what you can’t measure.
We mentioned 3 metrics we’d need to have in order to ascertain that we do in fact have a problem:
These metrics make sense in the context of determining the extend of the “access to capital” problem, assuming such a problem exists.
However, it’s also possible to expand or contract the scope of our problem to address larger or narrower issues, respectively. It is absolutely essential that we set the scope upfront. With the many stakeholders that would undoubtedly be pulled into this effort at a national level, we can’t risk having any ambiguity about the goal of this exercise — or the expected outcome.
In this specific case, we can easily expand the scope to address the question “Why don’t SMEs contribute a greater portion of Bahrain’s GDP?”. Taking this even further, we could ask “How can we grow Bahrain’s GDP?”.
It’s obvious how this would work — but a word of caution: Expanding scope would also make the project ALOT more complex. The appeal of having narrower, more focused problem statements is that they projects much more likely to close since they have shorter timelines and more definite steps. They can also be iterated upon fairly quickly.
In general, the smaller the commitment — the narrower the scope needs to be.
The goal you measure will influence everything you do later — make sure it’s the right one! Be careful what goal you set though. A valid solution to “end human suffering” is to kill all humans. (Luckily, this process is human driven so runaway machines are not a concern.)
The point is, make sure to set unambiguous targets.
A final note on goal-setting is to ensure that the data you collect is reliable. A good way to ensure that happens is to map out the process for data collection.
In our case, we know that banks and credit unions in Bahrain have access to the data we require. However, since we’re going to be aggregating data across at least 20 institutions, we’d better be explicit about the data we need from each institution — lest our instructions get misunderstood, and we end up with shoddy data.
You may think, oh we could just ask them to give us a dump of all their loan data.
But if Bank ABC (an actual name of a bank in Bahrain, mind you) sends you data on all loans, while Bank DEF gives you data on just loans made out to SMEs, you’re then left trying to figure out whether the data you received needs filtering or not. That’s one potential avenue for a mistake.
Another is when you repeat the process at the end. Left to chance, the probability of such a mistake happening is pretty high. Having a process (even if something as simple as a checklist) ensures this doesn’t.
Also, be very careful of people “remembering” data — always rely on cold, hard data points (so actual data exports from systems) and not fireside stories from executives.
Watch out for Part 3 next, where we start diving into the data we received from the banks and start preparing for addressing the sub-metrics that matter. See you then!
Comments? Hit me up on Twitter @yazinsai