In the previous post I talked about Software Configuration Management. This post is about management of software requirements and the link to software configuration management.
Although I did not specifically discuss management of software requirements in the previous post, it is evident that managing the configuration includes the specification sources i.e. the requirements. In the first recommendation of the previous post I touched on the object Work Request and example supporting materials e.g. specifications that may be attached. Ideally requirements are decomposed to individual requirement line items, i.e. similar to a tree. Each such line item would then specify the desired function but also instructions essential to developers but also test scenarios and the required end results that must be met.
In the requirements set you also find the actual failure mode and effect analysis i.e. if this function fails; what would be the effect and what would would need to be implemented that this failure would not occur. Obviously this is not just the software itself but the complete integration with the hardware it may need to control. As pointed out earlier, this level of detail is critical to also manage the prototype test process and also the actual life test i.e. the software as it is installed onto the product. The myriad of interconnections considering this level of detail and also combined with Change management records makes data management a daunting task without the right PLM capabilities.

Read the rest of this entry »


In general companies do a good job recording problems and issues about their products. In specific industries elaborate problem records, trend analysis and resolutions are mandated by regulators. They may operate a Failure Record and Corrective Action – Preventative Action register. However what commonly fails is a formal register regarding Ideas for improvement i.e. not driven from failures. Ideation as a process is more than a box for personnel to deposit their thoughts about products. I once worked with producer/retailer company that claimed that out of the 1000 innovations per year 70% of their new product introductions flopped and failed to yield results they had planned for. Can you imagine the revenue potential this represents. If there was a way to half this flop rate, it would make a big difference to the bottom line. How much would this equate to.., take for example the lost aggregate potential revenue of specific products or categories that failed to reach the sales ramp-up phase in the last two years.

What would be the solution…. Today companies, with little effort and cost, can introduce a collaboration platform that would register ideas. Suppose you could populate this platform with (process-to-follow) templates i.e. how to move this idea further, see what earlier projects had similar patterns and above all can you imagine the potential that you could reports an internal ideation pipeline the same as you do with your sales forecasting.

Not to embark on Microsoft marketing, but SharePoint is an example of a capability of such collaboration technology. With again little effort companies can build a complete (hosted) ‘environment’ around the Ideation process. Personnel that generate these ideas can be those directly involved with marketing or product (sustainment) engineering or even those that are in the field, for example trend scouts, all would find a single source of information to record their observations but also share opinions regarding marketing potential. Operating such Ideation framework, you can would support the formal innovation process from internal surveying, reviewing and analyzing the potential and challenges and risks you may encounter and need to consider. Some level of Quality Function Deployment may be completed and recorded also. So basically you can easily address the information management needs and establish a foundation to drive a Structured Ideation process.
As companies hit a specific Ideation maturity stage/gate, more personnel and financial resources may be allocated and a formal ‘gated project’ may be decided. Here comes Schedule Management into the equation that I talked about in other posts. Companies may want to operate specific new product introduction work breakdown structures and schedules for specific product categories. And here is the crux, these ‘standardized’ gated schedules then become success teamplates and the base for continuous improvement. It would make new production introduction process structured and predictable which should ultimately have a positive influence on the right product for the right market and corresponding sales success.

Lastly, as an idea moves forward and reaches maturity, marketing and product development start to exchange product requirements causing ‘requirements engineering’ to kick in. As more requirement information is generated, the need for requirements management is imperative and as more aspects of the product are being defined (project brief) we then gradually transition into the formal Product Lifecycle Management defined processes.