I work in the computer trade and frequently find that when I'm assigned a problem to solve, it invariably happens that other problems need solving before I can work on the real issue. Is there a word for these on-the-way problems?
I think I would simply call it a sub-problem.
(If the problem is mathematical, there is a specific term for it; lemma.)
A prerequisite perhaps?
For example, I have the problem of adding a new transport protocol to a device. A prerequisite of that is to make the segmentation threshold at the client end adjustable, and a prerequisite of that is to install the tools that will let me build the client.
One term I’ve heard used for this sort of thing is dependencies.
This comes from a common geekspeak etymological process: imagine you were a computer program; then, what technical programming term would apply to this situation? I’d imagine that most programmers would grok this pretty quickly, while most people without programming experience would need an explanation. So whether it is appropriate would depend a lot on whom you’re trying to communicate with.
I like "roadblock" or "stumbling block" for that sort of thing.
My preferred term is a "threshold issue." You can't go through until you cross the threshold (resolve the issue).
I consistently use “bottleneck issue” (or “bottleneck result”) to describe this: you have no way around it to reach your goal.
In particular, in technical reports and research planning, I commonly read references to “technological bottlenecks”, i.e. key technologies (or components thereof) that need to be worked out for a full solution to be implemented.
I use the term secondary problem. Secondary work is often used to describe tasks in the way you are mentioning problems. i.e. I want to wrap a package, but first I have to find the scissors. Whether you are describing the thing as a problem to be solved, or a task to do, I find secondary, tertiary, etc. useful to convey that Im working on something, but one level removed from my ultimate goal.
Another term I use is 'blocking' or 'masking'. In dealing with computer programming issues, you often find yourself revealing layers of issues. As you resolve issue, a second issue might arise because you a) got further into the program or b)there was some sort of ripple effect.
You could say issue1 was a blocking issue. Issue2 was not found until Issue1 was resolved.
Taken to an extreme you get "yac shaving", but that does not apply only one or two levels in, and may not be understood by non-hacker audiences without some explanation.
In more general managerial contexts you might use the phrase "critical-path issue", but it is a bit of a mouthful and sounds like it is wearing a suit. This also carries some implication about timing requirements: not only is it required, but it needs addressing before any other absolute requirements.
Speaking metaphorically, your “problemettes” might be:
- hurdles to be crossed
- hoops to be jumped through
- obstacles to be cleared
on your way to the finishing line.
There is a huge variety of "stuff that needs to be done in order to do other stuff". Some of those very specific things (which are not at all synonymous with each other):
- prep work
- capital acquisition
- parts acquisition
- building a jig, building a stencil, building a template, building a skeleton
- sowing the seed
- watering the seed
- "laying a foundation" (Whether we pour cement to make a house foundation, or drive piles to make a foundation for a bridge across a stream, we use this phrase -- I can't recall ever hearing "pouring a foundation" or "driving a foundation").
- dry run
- spike solution
- splitting (before burning a tree in a fireplace, it must be split into small pieces)
- "sharpening the saw"
While most of these words and phrases describe some specific literal task in the early stages of farming, roadwork, and building construction, many of them are also used as a metaphor for analogous tasks in other fields, or a synecdoche for all the preparatory work in general.
I call them dominoes, as in there is always some other domino / problem to knock over / solve before you get to the main one.
The term I hear most often is showstopper.
OK, after reading some responses and thinking of this question I'm going to coin a portmanteau. These problems are prequirements. ;-)
Not a single word, but this is at least related to a "Critical Event chain."
In [software] engineering, such a problem is called a
If I have to solve other problems before getting to the one I want to/have to focus on, I generally just call them steps: "step 1," "step 2," etc..
In French they sometimes talk about "le ticket d'entrée" - but that's more to do with the up-front cost of learning a new technology (before benefiting from any - hypothetical - productivity gains).
Down-payment? Pinched from another domain, but it might fly. Though it implies money more than work.
Meta-problem? (Meta as in 'before').
I think there is probably a difference to be made between 'drudge/donkey work' (setting up IDE, etc.) and a 'real' up-front problem (something that requires the same level of problem-solving as the actual problem to be solved). Maybe that though will inspire some more answers...
See sine qua non, defined by Cambridge dictionary as
a necessary condition without which something is not possible.