Our organization’s structure can confound what constitutes and output.  Consider the company that is structured as a “functional” organization, the output from one group will typically go to another group in the system.  This organization structure is sometimes referred to as “silo” since each part of the company, group or department is segregated by expertise.  This has […]

Each process produces some sort of, at least intermediate output. The ultimate output will be the resultant of the series of inputs, processes and outputs, and will be directed toward the ultimate end customer. Therefore the ultimate output capability is the collection of all of the inputs and processes of the systems of the organization. […]

The process refers to the actions or activities we will take to achieve our objectives.  This link to specific objectives is essentially the rationale for the process. In our previous example, the Systems Engineering group may have requirements elicitation activities as well as concept generation and critique actions culminating in system requirements specifications.  These various […]

When we write about input, we are discussing the nature of the exchange to the depending group. The Systems Engineers, in our previous example, need some input from the Marketing staff to be able to design something to achieve the marketing personnel objective and subsequently meet the customer’s need.  What is that input? For example, […]

The next few blogs will be further elaborating on the systems concept of SIPOC.  Upon completion of the characters or phases in the systems thinking and chain of events (SIPOC itself), we will illustrate how we can use these to improve our organization’s capability. This post will treat “suppliers”. We are not referring to drug […]

We see well-meaning people adopt an attitude “if it needs done, then I will do it” even if their job or position in the company does not define them as the person to solve the problem. I call this absorption and it is part of the much ballyhooed “can-do attitude” upon which many companies thrive.  […]

            We strongly recommend automated testing whenever this approach is feasible. The test team can use a language designed for this kind of testing; for example, the National Instruments product Labview. The software should be able to read in the documented test cases, execute the test cases against the product, and finish by producing a […]

            We know that a very simple product or system can generate a vast number of potential test cases. With more complex systems, this number becomes astronomical. This is the result of a factorial calculation! One technique we use to get around this problem originates with designed experiments. Many designed experiments are based on orthogonal […]

We do not need to suffer the pains of the risk due to spot checking.  We have a number of alternatives. For example: Modeling and simulation Iterative testing throughout the development Launch AND continue test and verification Launch and continue test and verification reduce volume of customers Relying upon modeling and other forms of simulation […]

We have briefly discussed why verification is important to the product quality. Verification does not just address the product quality. Our project work requires verification as well. When we take on a project, we should have the scope articulated in a way that we can confirm that the project did indeed fulfill the objective.  As […]