Posts Tagged

We like this saying and see much merit and believe it to be an axiom.  We have touched upon this a bit in our blog on sponges.  We see areas where one part of the company or development process makes due or improvises with the malodorous input received.  The receiving entity may complain and attempt […]

Recently I have had email and physical discussions on the merit (or lack of from some perspectives) of Agile Project Management in developing embedded products.  I think the discussion is more about what is the correct tool for the job at hand.  I have been part of agile managed projects that have delivered wonderfully.  In […]

To go on further with the output discussion, we need to make sure we have an understanding of indicators.  Indicators inform us what is going on. My stomach growling is a pretty good indicator that I am hungry, and sweating while mowing the lawn is a good indicator I will need a refreshing beverage upon […]

How do we know when our output is successful?  Well, when the customer takes acquisition can be the first tangible evidence for many organizations the output is “good”.  So we know what we mean by good, I provide a brief list: capabilities of the output can be deployed suitable quality (Key Product Characteristics are met) […]

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

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

In some recent discussions with product development neophytes, we have heard a merging of the concepts of verification and validation.  Let us set the record straight.  Verification and Validation are not synonymous.  The World English Dictionary defines verification as “establishment of the correctness of a theory, fact, etc…”   and validation as “to confirm or corroborate”.  […]