No description of a problem should be considered complete without some explanation of the impact. Impact is simply stated as the result of not solving the problem. All statements of impact should have a cost, a timeline to realize the impact, and a likelihood or probabibility of realization. None of these are precise measurements, because…
The Symptom
Problem solving is done better when the symptom is articulated separately from the cause and the impact. The symptom should be articulated as the experience of the person reporting the problem, and his or her opinion about where the process/system failed to meet his or her expectations. There may be some steps leading up to…
The Problem
Problem solving is difficult. The good news is that problem solving is domain independent, so good problem solving skills can be applied to any problem. They can be applied to business process problems, to technical software problems, organizational problems, anything that presents itself as a system, for which a potential customer can ask you to…
Behavioral Taxonomy
When developing requirements for a business process in which there are valid process variants, one usually describes the process variants as a behavior. When modeling these variants, it is useful to consider each aspect of a process that has variants, and isolate unique behaviors based on some decision framework. Both the distinct list of behaviors…
Semantic Clarity
One of the most difficult aspects of gathering and documenting software requirements is to get all of your stakeholders and project team participants to agree on terminology, especially words commonly used in the business domain. Common usage is never very precise, and often business problems arise from ambiguities in common usage. In developing a conceptual…
Transposition of the Familiar
Have you ever had the experience of having someone explain something new to you, and somewhere along the way, your brain replaced something new with something familiar? So when you went to the next step, to work on the new thing, you immediately became confused and either did the wrong thing, or did something that…
Document Driven Design
Software design is a process. It is a process of taking one abstraction – a business oriented model, and constructing a different abstraction – a technology oriented model. Since there are many different technology paradigms, the technology oriented model differs based on the paradigms selected. The business oriented model differs by business, and the problem…
A Template That Inspires Innovation
After adopting a new design process philosophy, and implementing a trial project using it, a design anti-pattern has presented itself. Document Driven Design – this anti-pattern is the practice of allowing whatever document template is mandated, drive the actual process or practice of design. It is common in the enterprise space, especially post Sarbanes-Oxley where…
The Solution
The notion that there is a single solution to any problem is a fallacy. There may be a solution to an equation, but every problem has more than one possible solution. We learned in math that there is one right answer for every arithmetic "problem". But in fact even that is fallacious, because we can…
A Framework
The first step in problem solving is root cause analysis. Identifying the root cause requires a framework. A simple set of questions, the answers to which allow you to rule out probable causes, so that you can investigate only the probable causes you can't rule out. I have watched as team members exercise a brute…