search

furiousOyster / software-defined-org

Infrastructure is better as software. Organizations too.
0 stars 0 forks source link

Our market situational awareness totally sucks #2

Open furiousOyster opened 6 years ago

furiousOyster commented 6 years ago

We need to undertake research in a collection of areas listed on the Situational Awareness Page

This information should be regularly refreshed.

A pipeline should be maintained of proposed entries in to the list for prioritization.

ScottMaxwellBTL commented 6 years ago

The list of data to collect is good. As there'll be a mix of data sources we use here we also need to start recording some meta-data around each point. Propose we use this for now:

  1. Statement
  2. Source
  3. Confidence in Source

E.g.

Statement: "During its Q2 earnings call last night, IBM announced that they have seeded the market with over 60 active blockchain networks. This quarter they launched we.trade with 9 large banks, including Deutsche Bank, HSBC, KBC, and Natixis. This is the first live blockchain-based bank-to-bank trading platform." Source: John Thomson, via email. Date: Thu, Jul 19, 2018, 15:50 Confidence: (Red/Amber/Green). Green. Validated here: https://www.ibm.com/investor/att/pdf/IBM-2Q18-Earnings-Prepared-Remarks.pdf

ScottMaxwellBTL commented 6 years ago

Also, to turn this data into useful knowledge we need to be clear about what questions we need answers to. Here's a proposed format:

Question: Why has the number of IBM Active blockchain projects dropped from 400 to 250 to 60 over the last two years? Hypothesis 1: IBM has consciously reduced the number of projects to focus on those that are closer to accomplishing a production implementation; Hypothesis 2: The demand for POCs has slowed as organisations review the outcomes/lessons before continuing with subsequent phases; Hypothesis 3. Completed POCs did not demonstrate sufficient business value or showed lacking technical performance to justify subsequent phases.

Each question can then be assigned to be answered, using the data in our Situational Awareness repository. The answer would include:

  1. Answer
  2. Confidence (Green/Amber/Red)
  3. Sources used
  4. Implication for us
ScottMaxwellBTL commented 6 years ago

@furiousOyster

Final one until we can go through this and start it up.

You asked for a military format for analysis/decision support. Have been thinking about that and the best one I've used is the one currently in place in the Defence Intelligence Service, CIA and MI6. I've used this extensively and it works. It's called High Efficiency Analytic Decision Making (HEAD). (No, really, did actually have to give HEAD to the Prime Minister... ;-)

Here's the very high level structure.

  1. Start with the Question. Always, always. The question needs to have a point - not just curiosity. It should support a future decision or act as a trip wire to check previous decisions.

  2. Break that question down into "buckets" of facts that we should take into account. Ie given our question, what areas do we need to consider and what can we ignore? E.g. on the IBM question above the drivers would be something like: IBM's Revenue; POC Successes & Failures; Companies Engaged; Maturity of Tech. There are others, but we need to limit it to 10. If there's an eleventh, we're not being sharp enough and something needs to go.

  3. Data Collection. See above. This should have the source and our confidence that it's not bollocks.

  4. Answer. Given the above, we should be able to answer a well-formed question relatively easily. However, again, no wooliness or weasel-words. Each statement should be backed up by the data. If we don't have the data for it, we get it and list it under Step 4. We also note the Green/Amber/Red status of each, and give our answer a similar confidence level.

  5. Check for counter-positions. This is where we need the most robust level of thinking. If we have a position, it should be capable of withstanding a full-on airstrike. We should be hypothetically ready to publish it for the world to kick the arse out of. To do this, we need to know what other answers there could be, and clearly state (referenced the data) why they're not true.

  6. Decide on Metrics. These are predictions that support the answer and serve as the trip wire to reassess. They HAVE TO BE NUMBERS - no weak-ass wooliness. It's not that we're going to use those numbers to beat anyone up - they're trip wires for our thinking. If the real world proves us wrong we need to revisit. E.g. if the next quarterly IBM update shows that they now have 120 active blockchain projects, that's important. They had 400, then 250, then 60. So that means we need to think again.

  7. Act on the trip-wires. If new data comes in that fits into the buckets we've defined we need to spend a couple of minutes on each answer to reassess. Does this change the confidence level of our answer? Because we know what the question was for, do we care? Does it change what we're doing?

As mentioned above, it's unlikely that we have anyone that can produce highly efficient results from this as it's a hard-ass way to check your thinking. If you get this, then we should give it a go with just you and I running it, see if it works for us.

Final thought - this takes work and supreme fucking clarity of thought. It generates very high quality answers to important questions. It also has overhead in operating. My assumption is that we have time and the impact of this sort of decision support is gold. If I'm wrong we need to look for something less hard-ass.