Trading, risk management

Risk management is one of the key points when you trade in any market

I have to mature the risk management mindset and measure how the actions I perform are working with respect a level of exposure that I want to take.

Definition of level of exposure

  • Perform operations between 0,5% and 2% of the value of your portfolio.
  • Understand that for higher volability, the time-spam for trading has to be short, as the risk exposure is higher.
  • When you define a move you have to define the amount or percentage that you expect to earn.
    • You will have to define a ratio of earnings/loss.
    • This ratio should be between 2 – 3. This means that if you expect to with 20 points, you should stop when you are losing 10 points; this corresponds to a “2” ratio.
    • A ratio close to “2” is more conservative. A ratio close to 3 is more risk.
  • If you lose 20% of your portfolio, stop trading, think about what is happening with the right perspective. If you not do it, you have high percentage of losing all.
  • A loss of 10% in a month is unacceptable, this is also an event that should trigger you to stop.
  • Backtest, backtest and backtest is an exercise that really improve the results and reduce the risks.
  • Review trading bias regulary.

Stop Loss

  • Define where to put the stop-loss.
  • Do not touch the stop loss.

Risk Management on programs

Tolerate uncertainty and live with it, understand complexity, ambiguity and live with it, manage all these tensions about what can happen is the main goal of risk management.

Projects managing risks in an isolated way is a big risk for the organizations. By this reason the use of a clear risk management framework at program or portfolio level is used.

Risk management strategy , should reflect the organization’s risk policies and processes. In this way the program will inherit same principles and risk appetite of the organization. It also facilitates the organization to define the limits of delegation of authority they want to delegate.

The definition of tolerance thresholds is key as it translate risk appetite into a guideline that steers program and project behavior. Thresholds define the exposure to risks on one level that, if exceeded, requires escalation and reaction from level above.

The uncertainty associated to a risk is expressed within the relationship of the likelihood and the impact it has (preferably expressed in $$). In a program the complexity increases as the combination of risks of different projects can generate a complicated net of exposure, which typically is represented on a risk matrix diagram. Sometimes what is negative for a project is an opportunity for other.

The use of healthy checks during the definition of the programs or the attendance of a bid is key to review the business case or the opportunity from risk management perspective. They oblige you to think about key questions you should think about. I find them useful, not as a controlling tool.

Project aggregation; sometimes a project under execution is added to a program. This requires to the program team to asses the impact of this addition at risk level, review the business case and review the budget.


When you want to review things you cannot understand

We are involved in a project with a weird set of requirements: customer insist on approving all technical documents involved in the project.

Ok, no problem, we have adapted the project plan to deliver them and allow them to check it. If you are able to check it, we have not problem to adopt this approach.

Functional analysis and technical analysis has not been a problem, they were able to review it, to understand it and to provide some feedback about the functionality. Everything approved and we go ahead with next phase: design.

Last week we delivered first 2 design documents, and they still are not approved. Why not? Let’s review some background,

The client teams are composed by a project manager that is not specialized in .NET activities and the end users core team are chemicals that in the past used to develop applications in Visual Basic (this is the reason to be involved in the core team).

I was waiting this point, the project manager was so surprised about this event, but I was waiting for it.

My point of view seeing the people who compose the project team from the customer side is that they have to use the technical and the functional requirements as the maps to go through the application development. It’s supposed they delegate this development to an external company because they don’t need to have this knowledge in their staff.

The good thing was that the RACI matrix was done in the planning phase, so now is easy to identify who should do this. Let’s see how the communications go,

(Astorga, León, Spain)