Requirements Management and Distributed Teams

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 handling of the requirements.  To manage complexity will require coordination of the incoming product information stream.  You can perhaps think of this as the carpenter’s adage; measure twice, cut once.  This leads us to the second item in the list, the risk associated with a mistake. For example, if little management of the requirements places the customer and the organization at risk.  Consider for example, when our product is low cost (no tooling and non-recurring engineering or NRE) and has low consequences when failing (think sillybands).  The risks associated are so low and therefore low impact and so it is possible to approach the requirements with a lower degree of formalism – NOT lackadaisically.

Product development work can be distributed across the globe.  I have personally worked at a company where the development and manufacturing of the product happen in one location, and I have worked at a place where manufacturing is one place, with many portions of the product development distributed around the globe.  My experience suggests managing requirements is more important the more the team is distributed and requires a greater level of diligence and a more rigid approach in managing the updates and changes to those requirements.  A collocated team, and that includes those that are generating the requirements and customers, can work in a more informal way with requirements and the management.  That does not mean, not manage the requirements, it means the degree of formalism associated with managing those requirements can be decreased.  This is one of the premises of agile project management approaches.

Taking a prescriptive approach many things and that includes requirements management.  Taking a prescriptive approach can be suboptimal.  It is better to understand the situation you encounter; understanding the area from a systems perspective, thinking through the important aspects of the subject area from the final perspective and considering those things that can go wrong along the way.

Requirements are the foundation for our product development and project management.  No matter the situation, we will have to find a way to effectively managing the requirements within the confines of the project and the organization.

Post by admin