Many high tech products these days cannot work without software that controls specific (user) functions of the product. Take your car; engine functions that were traditionally mechanically controlled have now been replaced by devices and capabilities that are managed by software. Also when you travel to your vacation destination by air the very plane you are flying in is loaded with software to control for example the avionics or the (glass) cockpit instrument panel. Recently I was asked to consult for a client that had configuration management issues regarding software installed in their product. They had challenges to manage the appropriate version of the software in relation to the hardware configuration and also assuring that certification results were correctly captured. A further challenge was the collaboration with partners that actually does the software development and the maintenance. Our recommendation consisted of the following set of improvement initiatives and functions.

Read the rest of this entry »

Advertisements

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 »

As discussed in ‘Schedule Management your smart Project Engine’ and considering new product development, WBS templates will be synchronous with a product breakdown structure. The military Def.Std 0060 and Mil.Std. 13882b define functional and physical product breakdown structures. The focus of the first is the requirements definition whereas the second is the resulting physical product as it will be certified for operational usage according to the ‘V’ model. Both approaches support top-down engineering principles where you start with the product schematics that gets detailed and populated with assemblies, sub-assemblies and parts. This approach is an ideal mechanism for front-loading.

Obviously it is not necessary to front-load a complete product, the ability to just complete this for certain product areas is by itself a major advantage. The prove that this works can be found in the automotive industry. Today’s turn around time for vehicle development is the result of being able to front load specific disciplines with placeholder product breakdown structure (PBS) and to drive the engineering process with the linked work ‘Requests’. As the industry works with product platforms and initiating such a PBS, specific assemblies and sub-assemblies and component items are carried across/over. It must be realized that those items Carried-over and -across are in fact technically and commercially certified and the certification management may extend to certification across multiple model years or multiple vehicle lines. The downstream benefits of such approaches are enormous.

So basically the schedule is the structure of events that need to take place.. you could call it a work breakdown structure (WBS). So for different product categories there are different ‘project’ schedules and WBS’s. In principle you would have schedules for new product development and its introduction, change schedules initiated by ‘change introduction boards’ as well as ‘product sustainment’ schedules.

What they all have in common are these ‘organic’ processes, for argument sake let’s call these verification and release processes and surprise….; these are the processes that are usually regulated per industry or defined as best practices for example your internal procedures as defined by regulators or derived from ISO standards or better CMII.

In highly regulated environments you may see these implemented even as ‘V-models’. The WBS, going down on the V,  determines the full design process by the different disciplines i.e. the product system breakdown from low to high fidelity. Going up the V the verification and the release processes.

As stated earlier there will be different WBS’s for different purposes. Probably defining the first set of WBS’s are a challenge but the reward will be huge. As it becomes a standard approach for doing specific things, it would then form the basis to gradually apply Kaizen and the 5S’s campaign you would apply to Gemba i.e. the (work) place where it all happens. As companies get smarter defining and optimizing these processes the cost and schedule outcome would also be better predicable and it would provide an opportunity to ‘front load’ such WBS structures with all product related system engineering templates and required documents. Lastly these WBS’s would also form the basis of your project management with or without your management approaches such as earned value management.