Over the years, we have heard executive level individuals cry out for cultural change in their organizations without understanding the ramifications of what they are saying. With cultural transformation as usually touted, we are talking about massive levels of upheaval. The upheaval approach can be counterproductive if it does little more than produce a culture […]

The real kaizen is all about the 10,000 things. Maasaki Imai’s description of relentless, creeping quality improvement is apt. It also fits with the comprehensive philosophy of total quality management (TQM). We say “real” kaizen because we have so-called kaizen events that have nothing to do with inexorable cultural change and a whole to do […]

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

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

Configuration control is generally, what first comes to mind when somebody brings up the topic of configuration management (CM). While it lies at the heart of the system, all the components of a CM system are critical. The purpose of this component is to: Maintain and control configuration baselines (known and defined states) Document and […]

MIL-STD-973 lists configuration identification as the first step in the configuration management (CM) process. We do not think this is some bureaucratic whim, but rather, one of the most important components of CM. Are speaking about systems, subsystems, components, parts, software revisions, and more? The simple answer is, yes! To avoid confusion when using bills […]

Once we are using a configuration management (CM) system, how do we ascertain the status of our engineering change? Configuration status accounting (CSA) is the method by which we accomplish this record tracking. We can get software support by using a dedicated tool or implementing a dedicated database that tracks what we want tracked: Approved/rejected […]