Technology V Requirements the Chicken and Egg dilemma

A recent tweet from a business analyst said,

“We need to change the system so that it works for you, instead of you working for the system.”

As much as this is laudable in the true business analytical form of establishing requirements first and then build the system the practicality and real world scenario is somewhat different.

With the increasing use of cloud service platforms that spread the costs of development over large numbers of clients the reverse becomes reality. Changing systems to fit to your specific needs is expensive and time consuming, the alternative though is a loss of differentiation.

I feel a similar way about sector capability frameworks if an insurance company has the same capability map as another how does it make itself competitively different.

Over recent years we have seen, driven by technology platforms, a move to standardised working. The economic pressures of reduction in development costs and SAAS platforming has increased commoditisation.

This trend results in value being created through cost leadership - size and the spread of fixed costs being the order of the day.

On our course in developing operating models we address this issue and use a matrix grid to plot choices whether to build buy adapt or use stitch and glue addressing the balance between value chains delivery (differentiation) and cost. #businessarchitecturetraining #operatingmodels #business analysis.

Methods seem to be the answer to all business change issues, follow a methodology and all is well. As the years pass I see repackaged ideas with new fancy names, promoted by fancy graphics and delivered by accreditation and expensive training courses. Each one is the new silver bullet that becomes the mantra of the cult that follows - it nothing changes.

Methodologies actually restrict creative thought, create silo thinking and result in increased costs in change due to  focus on method rather than outcomes. What is needed is a more critical evaluation of methods using the right tool for the right tasks not just blindly following the latest craze.

These thoughts stem from thinking about Dave Snowden's work on Cynefin which I was introduce to earlier this year - see earlier posts. It illustrates that one dimension thinking results in trying to apply a method to inappropriate scenarios. Why do I say this? Well previously I was a business process    management acolyte I did lean and had played with 6 Sigma now and again. I was in "disorder" see Cynefin Model but didn't know it!

My business architecture paradigm was  - strategy, design, deliver in a holistic top down approach what I now realise that this is fine for the simple and obvious domains and perhaps for complicated - "the fine engineered watch"  - but not for the complex and chaotic where centrally controlled design blue prints, EA and  holistic business architectures just don't fit.

Whilst it is still valid in many cases a one stop method doesn't fit every organisation, especially those based on emergent strategies and evolutionary change.

So, time to think about dynamic operating models and techniques in these more challenging zones.