Crystal Ball

Today's assumptions, when become tomorrow's factor. That kicks in efforts to refactor - the app supporting the process. BTW changing the data model would help. The worst case is when assumptions are so very deep rooted that we don't even acknowledge them as assumptions. They are just ... way things work. These can be worse than the normal assumptions. Refactoring this change just got bit more expensive. Sorry about it.

Watch for the grain

Examples of mundane daily chores like "driving a car" to explain a complex thought is simple yet powerful. We use our inherent understanding of the daily chore to understand a different abstract idea, like strategy of a company being " direction, talent and basic controls". we find it easy to understand the concept and need for each of the components as we make association to known accepted knowledge of driving the car - steering wheel for direction , gas pedal for the power bit, and basic controls for keeping us in the speed limit. Our unquestioned understanding and acceptance of the chore of driving a car helps us get over questioning the abstractness of the idea we are trying to present/explain/analyze.

The problem lies in incomplete or inaccurate choice of example. If example's components are not completely in sync with the prongs of the main idea, the risk of the idea being questioned is high, not the example's validity. Realignment of thoughts are necessary in that scope of time to come up with a new example. For example - if the last corellation of driving a car - for. eg. the car's dashboard was not recognized to be a valid candidate for being an example of basic controls of organization, we question the example or even worse, the idea is not complete.

Shadows on the Ground

Dragging thru requirements of what we would like in data store can be challenging. What appeares to make things more fun are overlapping effects of multiple processes going together. Having to deal with cummulative effects of different processes is one issue, but identification of these layers of functionality is another. These might have different owners and drivers and needs to satisfy but impact the ground ( data model ) all together.

Assumptions and Conclusions - One Way Street

We start with basic assumptions of a problem space. Thats our going in position. We analyze the problem space and exit with some conclusions. These conclusions might materialize in form of policies, process definitions and other components to quantify the problem space. Here is the dilemma - how do we abstain from making the assumptions dependent on the conclusion? Its tough one to maintain, when we are sure of our target, our solution or conclusion.

Procrastination - Dollar Side

Early idea definition has an explicit advantage - functionality definition on steroids. Decisions follow fast behind this definition. We like it. But ... for a moment if we consider procrastinating that, and be ready to work with an elusive entity, not yet a Biz entity, and explore the functionality, risk of redundant biz entities diminishes. We evolve that idea to form as few biz entities we can work with and evolve new biz entities only the existing entity shows sign of inability to conform to the activities expected to be performed.