This may or may not be a true story, but I promise it happens every year.  We start with the customer organization and a supplier that the customer refers to as a partner supplier. This “partner” supplier collaborates with the customer to develop custom components for a larger system the customer sells to their customers. […]

Requirements and Benchmarking One of the things we can do to understand and develop our own requirements is to explore other products that are similar to our proposed product or that solve the same or similar customer problem.  Where there are similar needs met, benchmarking is a way for us to understand how other suppliers have […]

There are a number of factors that can influence the approach we take to managing the requirements.  I provide a brief list below (this is not an exhaustive list): the technical sophistication of the product the risk associated with a mistake distribution of the team The more technically complicated the product the more diligent our […]

Scope, Requirements, and Work Breakdown Structure The scope of the work and the requirements provide us with information from which we can build the Work Breakdown Structure or WBS.  In fact, even before we are able to start doing the work to build the expected results of the project, our work breakdown structure should capture […]

The customer can seldom articulate the technical details of the product.  The customer may define the product or need in terms of function and performance, but building the product from these documents will be extremely difficult or perhaps impossible.  We will need some type of document to begin describing in technical terms the product that […]

  This question was posed by Tom Cagley on Twitter.  At first blush these may seem at odds or exclusionary, but perhaps not.  I know why it may seem difficult to be innovative while we are hyper-focused on continuous improvement activities.  A company that focuses on continuous improvement that tends to be incremental can occlude […]

This blog post originates from Capers Jones LinkedIn comments about toxic requirements.  He posted a comment to a requirements article and brought up bloated requirements and toxic requirements.  I have never heard of the name “toxic requirements” perhaps that is uniquely Capers Jones identifier – I like it.  However, I believe I have experienced toxic […]

Our project must balance the input from a myriad of people that are associated and contribute to the project, along with those funding the project to be successful.   To be able to do this, we will need to understand our stakeholders and their perspective.  Some of our the stakeholders will add requirements, support existing […]

Requirements Language As we collect requirements we are going to need to perform some sort of evaluation.  We know the attributes of good requirements, now we will compare those attributes against the documented requirements.  However, we will not stop our evaluation at the type of language. We will extend this evaluation to other areas that […]