When evaluauting a software product, one of the most important things to understand is the core metaphors around which the software is built. Why do I use the term metaphor, rather than entity or concept? Because a metaphor is a substitute, a proxy, and in software, the core concepts are proxies for real concepts in…
Uncategorized
Practice, Rehearsal or Exercise
As leaders, we need to better distinguish between these three activities. In three domains that are "performance" domains, these words have somewhat different connotations. Professionals: Doctors and Lawyers practice – that is they perform their profession. They do not rehearse, nor do they exercise, at least they do not differentiate between the performance of their…
Business Capability Requirements
Many times when software requirements are collected, organized and documented, the focus is on the software capabilities needed. But software capabilities are not sufficient to get business value. One must also document the expected pattern of integrating the software capabilities into the business process to understand how the value will be realized. Stating requirements in…
Vendor Evaluation Framework
When your organization is a consumer of software capabilities and a producer of software capabilities, every project may be subject to a buy versus build decision. Many organizations struggle to have a rational repeatable process to make these decisions. Turf battles between IT and functional business units, personalities, experiences and emotions often become involved in…
The Cause
Causes of problems are sometimes elusive. Symptoms are misleading, reporters expectations are misguided, layers of business process and automation, and years of workarounds and patch jobs render the situation very confusing. The cause of a problem has a category related to it's proximity to the symptom revealing component: Local cause – when analysis reveals that…
Design vs. Specifications
Discussion about what constitute design vs. specifications has been a part of many projects and systems product teams that I have been on. In some groups we built detailed specifications for every component, and other groups just focused on the assembly of the parts in the design, and let each developer build the parts her…
The Impact
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…