Program trigger events were discussed in our last blog. We can set up a program data base that has inbuilt triggers or we can pick up on the issue if we build these triggers into frequent product development reviews. We feel the project/program manager is the primary party to monitor for trigger events. Secondarily, the […]
A contingency in project management is a reaction plan to an untoward event; in short, we plan ahead for the failure of a given task. In order for a trigger to “fire,” we must set a threshold value that activates the trigger; otherwise, the trigger should never fire. Thresholds can be set based on financial, […]
Risks need to be assessed in regard to their business impacts, so that business decisions can be made promptly. Strategies should be built and decided based on the quantitative value of the risk. Managers must decide on whether to spend $500,000 to avoid a delay in a project. How long that delay is impacts the […]
Many organizations have a series of activities or processes (design reviews, analyses, verifications, validations, etc.) that they go through to produce the end product or service. The work will start with some kind of development process, which may be a matter of days, months or years, depending on the complexity of the product or service. […]
The trigger is a new concept to those acquainted with the FMEA approach to problem elimination. The trigger event (or threshold) is how we know we need to invoke our risk reduction activities and is direct responsibility of the person monitoring. Risk Response and Contingency Budgets Each risk dollar amount at stake is multiplied by […]
The SEV, PROB, and CTRL fields quantify the amount of risk to which the project is exposed. The higher the number, the more risk to the project. This information is used to prioritize and generate action to reduce or eliminate (transfer) the risk. Also, we wish to identify the detection—how do you know the risk […]
We recommend a modified version of the FMEA approach to assessing the risk. The approach is tailored to the needs of project and program managers. We will model the time line as a control plan with minimal controls other than the typical tollgate reviews and, perhaps, team meetings. We know from personal experience that treating […]
Experience suggests risk management happens after we have already encountered numerous and severe risks. We can see engineers bringing “risks” to the project manager when we are already witnessing the symptoms and the impact to the project is inevitable. To be relevant, risk management has to occur when there is time to plan actions that […]
A qualitative analysis will generally involve a subjective level of assessment. The classic Kastle-Meyer test uses phenolphthalein to check for blood—it is quick and cheap and eliminating expensive and specious DNA testing save times and money. Quantitative analysis, as the name implies, uses measurements to assess the topic of concern. Both have their place in […]
Risk management is often considered a project management function, but that is not necessarily so. For any sort of endeavor we will be well served if we have some consideration of risk and the management. For example, our previous blog posts discussed configuration management. We saw how a wayward configuration management (or lack of configuration […]