Bottleneck Analysis

I've been thinking about risk analysis/assessment lately (for both my agile and final year project). Exactly what it means, when to look for it (risks/bottlenecks) and how to circumvent them. When is it needed?
Prudent thinking would suggest early on before problems/risks and bottlenecks begin to manifest them self. I don't know if the "..better late than never" approach applies here. Risks are a risk for a reason. If left too late, they may have severe consequences. What are the tell-tail signs?
Performing some form of bottleneck analysis may help identify this. Agile advocates early risk analysis/assessment and requisite tool/technology gap analysis through the use of spikes; an approach that aims to spike out the aforementioned and unkown or unfamiliar areas. Bottlenecks often occur as a result of a lack of forethought and appropriate planning. Early analysis is good as it brings out fuzzy descriptions. These fuzzy descriptions often highlight an underlying bottleneck (a lack of desired throughput and/or performance or possibly exceeded constraints). Obviously, the key here is fuzzy identifiers so descriptions which include 'slowly', 'insufficient', 'cannot handle', 'takes too long' etc. are prime candidates.

• This application performs too slowly
• This response time is poor
• This queue takes too long
• There exists insufficient resources
The lift cannot handle a load higher than 1500kg

These are all tell-tail signs of bottlenecks. If there is nothing that can be done to reduce this bottleneck than not only have you identified a potential bottlneck in or of the system, you have just identified a risk. How many risks identified, the severity of the risk and whether or not it can be reasonably mitigated will determine whether or not the project is still feasible. Not all risks are show stoppers. It simply pays to be aware of them in order to reduce their impact. How can we mitigate it?
An early spike session or bottleneck analysis goes a long way. Bottleneck analysis is just an alternate approach. Not all risks may be apparent (some may). But there may be certain bottlenecks or constraints in the system that are. Hence, these can help identify the associated risks. This article has focused heavily towards bottlenecks. With this in mind:

• Isolate: Isolate the bottleneck to a particular component
• Fix: Replace or remove the component in question

Is there another component or sub-system that can perform the same job? Albeit with an increased capacity to satisfy what the bottleneck does not. Can the component be removed entirely? Can we forgo its functionality entirely? All pertinent questions worth asking. A bottleneck is not a risk. But it may lead to one. Where all risks may not be initially apparent, bottlenecks or constraints might be. Identifying them early may highlight potential risks later on. Depending on the system you may not always be able to eliminate them completely. However, the sheer act of identifying and classifying the resultant risk (type of risk) along with the impact and appropriate measures at least means you are going to lessen the impact and are aware it exists. Being aware of a risk and its associated impact is the first step towards circumventing or mitigating its respective impact