We perform risk audits on projects to ascertain whether we are deviating from the desired budget, schedule, and quality levels we specified at the start of the project. At the 50,000 foot level, risk auditing looks like the following: Define the problem Choose an audit team leader Choose an audit team or let the leader […]

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 […]

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 […]

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 […]

We received some questions about how configuration management and change management work together. Configuration management is a component of the change management process. The business requirements or demands drive the scope, which is a project management function (requirements elicitation and control of scope). On completion of the elicitation, we have the scope baseline for the […]

Another piece of the configuration management pie is the ability to move backward and forward from revision to revision. To demonstrate the importance of this concept I will relate a story. There once was a developer who was writing in assembly language for a new product.  He was incrementally developing the features for the product […]

Configuration auditing occurs so we can verify that what we said we were going to do actually happened. MIL-STD-973 specifies two flavors of auditing: functional and physical. Functional configuration auditing occurs when we verify that the change functions as the engineering change proposal specified it would. A change can be to hardware, software, or both […]