It is difficult to make decisions owing to e.g. the size of the problem etc.
In this particular topic we cover the risk of being unable to grasp a problem, or being unable to see the whole problem. Where we are not sure how to approach the solution the topics LackOfConsensus, LackOfDirection or LackOfVision may be more appropriate.
The problem may be complex, or maybe there are various different aspects or viewpoints that need to be taken into account. Here we do not cover the standard Analysis approaches of dividing up a problem area, classifying and organizing the requirements, though we do touch on ObjectOrientedAnalysis for a quick overview.
In the case of a complex problem area, the standard approach is Analysis. We do not cover the topic here, but offer some pointers. When looking at the business or at the system requirements, it may be a good place to start to ModelTheDomain. Where the architecture of the system is expected to be complex, use an ArchitectureTeam. At all stages in development, not just in producing code, it is useful to tackle the problem in right-sized chunks as a series of ProgrammingEpisodes.
Once the methodologies support the ability to respond to change cheaply, there is less need to consider large chunks of the problem up front. The complexity of problems tends to show itself when trying to look at the whole problem at once, rather than looking at the highest priority bit first. In general, the agile approaches avoid the problem by, for example, right-sizing requirements in UserStories and ensuring none have excessive effort estimates. Architecture may be emergent rather than all planned in advance, and if so, the architecture never needs to be more complex than is needed to support the immediate requirements. The XP variant of DevelopingInPairs has the pair forming for a single ProgrammingEpisode.