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 input can vary by:

• Organization
  • domain
  • structure
  • development philosophy
• scope of the work of the dependent group
• regulatory or legal implications

All of these go into determining the nature and details required input of each group or subgroup.  It is important that both parties (the sender and the receiver) understand these exchanges. It is not the time to find out that the material delivered to the receiving group is not relevant, or missing key information at the time of delivery. This is where a good many quality problems first appear. For example, our input comes from the previous group, but they do not know what we need to do our job, nor the quality metrics associated with that delivery.  Given this unknown, it is possible from them to delivery anything – but that may not be something that the depending organization can use.  Getting this input correct are key for an efficient and successful project and product delivery.