There is a well-accepted body of knowledge that the repair time for problems increases the further away you get from the source of the problem. This is due to several different interacting situations:

• the further you move from a problem's origin to its integration into a larger system, the more likely that people are observing symptoms, rather than clear indicators that directly trace to the problem itself.
• the longer that problems take to resolve, the more people & resources that usually become involved, whether they are actually contributing to solving the problem or not.
• people tend to chose to solve problems they understand first, before they take on problems they don't; therefore, poorly defined problems take longer to solve
• people also tend to jump to possible solutions based upon assumptions, rather than data, if they don't have data to act on

As a result, there is an enormous variation in how long it takes to solve problems, and that variation is largely driven by the effectiveness of communications and access to key resources that either have the answers to what's happening, or good clues that lead you to these answers. To demonstrate some of these principles, let's consider the following parable, which has multiple endings. One of the endings is real, and follows a path which I have personal knowledge of. The roles in this tale have been deliberately obfuscated, though, to protect the guilty:

Once upon a time there was a used Car, a car Owner who just had purchased it, and his teenage Son. One day, the Owner had a problem when he put his Key into the Car ignition, because Car didn't let Owner turn the key. Owner jiggled Key and Car was happy and allowed itself to be started up.

Several days later, Son parked Car on a hill, and left for an errand. Later that day, Son returned and tried to put Key in Car to start it, but Car wouldn't let Key turn. Son tries to call Owner for help.

At this point, there are several different versions of what happens next, with different outcomes:

1. Son couldn't reach Owner, and abandoned Car on the street. Car gets towed and Owner has to pay towing bill ($150), impound fine ($125), and arranges for taxi to pick up Son($35). When Owner goes to place where towed, Car accepts Key and allows it to be turned and so starts up. Owner suspects Car is flakey and is not happy. Son feels guilty and doesn't get to use Car for a while. Son is mad at Owner, Owner is mad at Car, and Car is working as designed.
2. Son is successful in reaching Owner by phone and tells Owner car won't start. Owner makes suggestions on things to try, like jiggling, but none of the things Son tries is successful. Owner is thinking that reason Car won't start is because of Car problem, not key. None of Owner's suggestions help Son or Car. Owner arranges for car to be towed to Dealer. Car arrives at Dealer, who tells Owner that car starts fine, but suspects that reason Car wouldn't start earlier is flakey starter control module. Dealer replaces starter control module at cost of $875 for parts and $475 for labor (Car is just out of warranty). Owner is not happy with Dealer, but believes problem is solved, and lets Son drive Car. Son parks Car on a hill, and Car does not start. Repeat steps from the beginning.
3. Son is successful in reaching Owner, who gets a ride to where Son and Car are. Owner learns problem is key will not turn. Owner jiggles transmission selector lever and wheel, and pumps brake. Key does still not turn. Owner calls Friend, who drives out. Now Owner, Friend, and Son begin to disassemble parts on Car, with no success, and much aggrevation. Son, Owner, and Friend are all now late to other engagements, and problem still exists. Owner calls tow company. Go back to step #2.
4. Son reaches Owner, who suggests Son look up Key turning procedure in Owner's manual. Son thinks this is stupid. Owner and Son fight and argue over whether such an approach could possibly diagnose problem. If you think they agreed, continue to the next step. If you think they didn't, go back to step 3.
5. Son reads Owner's manual. On page 84, after reading through chapters on Fuel and Engine Exhaust Precautions, Instrument Clusters and Indicators, reviewing Driving Tips, and after notes on the Spark Ignition System, Seat Belt Requirements, Warnings of Prolonged Engine Cranking, Not Leaving Seat without Setting Parking Brake, and Removing Key While Vehicle Moving (and other Lawyerly noise extraneous to issue),  and before discussions about Ignition Switch Positions, Owner's manual contains note which reads: "If turning the key is difficult, jiggle the steering wheel from side to side." Son attempts jiggling and is successful in jiggling Key and starting Car. Owner is happy, as is Son and Car.
6. Son cannot reach Owner, but is lucky enough to know Friend who has same type of Car. Son calls Friend and tells him about the problem he's having. Friend say 'You mean your Key is not turning? I've had that problem. It happens when you park on a hill, and you turn your wheel into the curb. The wheel has sideways pressure that feeds back into the ignition interlock. Jiggle the steering wheel back and forth, and it will free it up'. Son does this, and Car starts. Son calls Owner. Son is happy. Owner is happy. Friend is happy. Car is happy.

Of course, the above silly parable and it's various alternative scenarios and consequences are all relatively painless in the Grand Scheme of Things, and only might cost a several people money and aggrevation over a relatively short period of time. On projects, when such a problem can occur simultaneously in many different settings, and the root causes - which might be far more serious than in this scenario  - goes undetected, the situation and it's impact to an overall development schedule can be much more serious. Lots of people can be simultaneously involved in experiencing and reacting to such symptoms, and inefficiencies can lead to significant schedule slides, which can lead to lost business, and end up costing far more than you would think. Notice what made a difference in the above scenario - connecting people with the right knowledge to ensure that an appropriate decision was made!

It's worth thinking about the actors in this parable and the roles they play. The Son is the innocent discoverer of the problem. The Owner is the person who has to deal with the problem. The Car is the site in which the problem occurred, but is not necessarily the cause of the problem (because the symptom of a problem is not the problem itself, as this parable demonstrates). The manual represents a log that provides hints to fixing the problem, but does not reduce the problem to it's root cause. It only is a source of potential work-arounds.

As long as the originating situation (parking and turning the wheel into a curb) is not removed, new discoveries can still occur by new people, and only when the role of diagnoser, who recognizes the symptom and correctly ties it to the circumstance which created it, is it possible to really understand the problem and potentially eliminate it in future implementations.

While not every problem is like this, there are always those ones that everyone remembers and looks back on, wishing 'if only I'd known'. One wonders about the history that led to putting the note in the owners manual in the above example. This situation is even more complex when something (especially multiple, potentially suspect problem sources) are potentially causes. For example, when a car is still being designed, the ignition control module, steering interlock, sensors, key, and other items could all be equally likely sources of problems, and many experts might get called in, all in search of the 'real' problem. In fact, there may be many different Car units, parked on many different locations, all experiencing similar problems, but with different root causes, due to changes in configurations, lack of clarity about what is actually going on, etc.

Sorting out problems in such an environment is likely to be highly dependent upon the maturity of the components in use, the adequacy of information provided about the underlying environment in which problems occur, the use of baselining to track changes across Cars, and the skills, creativity, and information available to the people doing the troubleshooting. Such investments in preparing for efficient problem resolutions pay off for difficult problems, but are critically essential when a well-organized integration activity is to be performed. When you compare how much time it would have taken to originally find such a problem in a well-controlled environment, detecting and characterizing the problem situation in isolation, and identifying an effective diagnostic procedure before integrating with other components, in contrast to the challenges of 'finding' the answer to a problem in a more chaotic, less controlled environment, you realize that why component testing and maturation is so essential to efficient integration.

That's why preparation and thinking through a good plan for integration and problem solving is so essential, especially with a focus on information management and clarity of communications (see for example, Solving Problems, and Answers to all your questions), regardless of where you are in a product's life cycle.