On Abstract Systems
We’ve all seen those abstract systems that are used for analysis like: Strategy = Ends + Ways + Means, Waterfall Model: Requirements, System Design, Implementation, Integration & Testing, Deployment, Maintenance, SWOT: Strengths, Weaknesses, Opportunities, Threats, ect.
Classes that teach these tend to be boring. Often you’ll get three different business models thrown at you with minimal motivation. You won’t be told about the environment this model evolved in, nor why the particular elements were included. Sometimes you’ll get a concrete example, sometimes not, but if so, it’s more likely to be a made up scenario rather than an example from someone’s real life experience. It is even rarer that you will receive multiple such examples.
This is largely a result of people’s bias towards explicit knowledge. But the explicit knowledge is in most cases simply one of many ways of carving up possibility space. Much more important is the implicit knowledge of how to apply the system and what situations it is helpful in. Strategy = Ends + Ways + Means becomes more applicable when you learn that it became dominate after the Vietnam War when it was felt that the loss was the result of attempting to achieve certain objectives without sufficient resources. So instead of just asking, “What are we trying to achieve?” and “How could we achieve it?”, you also wanted to ask, “What resources are needed to achieve it?”. Similarly, the Waterfall Model becomes more useful when you are told that many projects have not been as successful as desired because of a failure to consider requirements (ie. using a framework that requires Internet Explorer 10+ when some staff are stuck on Internet Explorer 9). Similarly, people often perform the cost analysis of projects for just the initial coding, without accounting for the maintenance cost. This is a system for making sure that you don’t forget the obvious.
It would be even better if I could illustrate these with examples from my own experience, but this should still be sufficient to illustrate my point. I do think that these systems can be useful. But only when communicated in the right way.
This post was written with the support of the EA Hotel
This has been motivating my thinking about these problems a lot lately. I am beginning to see the need for communicating in the right way to be a weakness for a given system, because this makes it very easy to misapply.
Just like executability is one of the criteria for goodness in a plan, I feel like gathering the context to apply the system properly should be an explicit part of the system.