Joe Dager’s Business901 podcast with Jon M. Quigley
Evolution of the Product Through Configuration Management
Product Management and Project Management Intersect at Configuration Management
Testing and Repeat-ability
Repeat-ability of testing results is important to establishing cause and corrective actions. If it is not possible to repeat the sequence of events leading to a failure, it is not possible to replicate and therefore difficult solve the cause of the fault or failure. The steps that evoked the problem are necessary to replicating the problem – only sometimes that seemingly does not work.
Testing and Configuration Management
Things like a specific system configuration may be implicated in the failure, testing to find a failure on one configuration after having found the problem on another configuration, does not mean the failure does not exist. This is another link between testing and configuration management.
Repeating the test with some fidelity requires documenting the test steps with some diligence as well as trace-ability of the test specimen, all parts are not created equal. When it comes to software or embedded products the latter is very true as it is … Continue reading
Just finished reading Configuration Management: Theory, Practice and Application, and I must say this is the most comprehensive document I have ever read on the subject. It addresses theory, practice, and application, with many real-world examples of what happens when the principles of product/configuration management are not followed! —Bill Dawson, SVP Product Management, Volvo Group
… the definitive guide to configuration management. No configuration manager should be caught without a copy of this book. … explores not only the technical aspects of the field, but the practical applications of configuration management in a wide variety of industries not just the technology field. —Joe Townsend, Configuration Manager, Indiana Public Retirement System
… captures the essence and significance of configuration management. It provides the framework, tools, and practices that will enable any enterprise to successfully create and manage a framework for CM in a mass customization world. … A much-needed book and discussion at a critical time in … Continue reading
It was the United States Civil war, the battle was Gettysburg. There was no doubt, General Meade had the intention to defeat Robert E. Lee. In the end General Meade was victorious and his congratulatory order to the troops was also sent by telegraph to the War Department (and would be read by Abraham Lincoln). The crux of the message was the invaders had been driven from our soil.
Later, President Lincoln would meet with General Mead:
Do you know, General, what your attitude towards Lee after the battle of Gettysburg reminded me of?” Meade replied: “No, Mr. President – what is it?” Lincoln said: “I’ll be hanged if I could think of anything else but an old woman trying to shoo her geese across a creek.
In the President’s mind, Meade had left the job unfinished. He had not pursued the rebels after the battle. General Mead had … Continue reading
Concurrent engineering problem take many forms
From our last blog, we have learned that of an organization that has concurrent engineering difficulty, specifically coordinating the design work. We will further explore this situation. One of the subsystem groups decides to improve the coordination effort internal to that specific department. For example, System 1 chooses to focus on their handling of the design coordination internal to that department. This is not a bad idea, as there are some inefficiencies and losses due to ineffectual coordination of the various subsystem designs.
There is another problem area, and that is the coordination of the systems that comprise the entirety of the product. Below is a graphic that illustrates this other area lacking coordination.
Where to start?
The trick is to understand the best area upon which to focus the finite resources. A short sample period, a portion of one large project, provides and example of the costs due to errant … Continue reading
Once upon a time
There once was a company, with a systemic problem with concurrent engineering and change management. This was a complex organization, with many functional areas. Each functional area, had sub-function divisions. This type of organizational structure is often referred to as a functional organization with the associated hierarchy. These various functional areas design and produce sundry parts that will be assembled together to produce a complex electro-mechanical and embedded software system. A partial drawing of the structure is provided below:
Concurrent Engineering Requires Coordination
Within the systems level, there are sub-system levels. These subsystem levels are departments within the systems department. Each sub-system focuses on a unique aspect of the entire system. There work has some commonality, for example system 1 could be the electrical / electronics engineering discipline. Work within this department is coordinated to meet that of the entire system. Generally speaking, these departments are often co-located, under those circumstances internal department communication can … Continue reading
Have you seen these risks in your projects? The project that selects a scope that does not match the constraints (cost, quality and delivery). The project strategy that dooms the organization to cost over runs, surprises the organization with late delivery that would have been easily predicted. The ineffectual risk register (or non-existing). The team that sees the incoming disasters possible but does not let you know until a risk becomes a certainty (then reports to you there is a risk).
All of these occurrences are common place, and should not be. Companies loose money, customers and overly stress employees by placing ridiculous demands to turn the tide of the project when the problem could very easily been avoided or at the least remediated. The first to leave are those that often your best talent.