There is a saying: “if you change form, fit or function, you change the part number.” On the surface this seems like a good saying. People use this saying as rule of thumb to determine if a new part number is required.  Taking out new part numbers cost the company some administrative time and effort […]

There are a number of quality tools that can help to evoke the risks that may be associated with your project. One such tool usually associated with cause and effect is the Ishikawa diagram. We can use this tool to explore risks as well. We will explore what happens (cause) and how it will impact […]

We can use value analysis and value engineering techniques to improve our product cost structure and ultimately our value proposition.  The analysis phase of this activity is called value analysis. The design phase of this activity is called value engineering.  We are a bit constrained during these activities since as we have a product already […]

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

We would like to thank those that have sent us some ideas. To sweeten the pot, we make the offer below. We have decided to extend our story acquisition for the configuration management book.  Please send your stories and techniques to my email address at Jon.Quigley@valuetransform.com Elaborate all that you can (2-15 pages) without divulging […]

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

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

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

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