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.

Advertisements

Many companies implementing PLM consider workflow to be the panacea to many process related challenges. In the past when PLM was a relative new phenomena we tried to model  company process in a series of workflows. The abstraction that was needed was a far cry from the real processes and engineers were by-passing the implemented workflow functions. Also we found, specific processes for specific categories of products were needed and further that specific ‘organic’ processes were common regardless of these different product categories.

We ‘flowed’ deliverables through these workflows rather then the triggers that define the items that are expected from the process. The abstracted trigger objects are in fact different types of ‘Requests’ for example; work request, change request etc.. Requests regarding a task may have supporting items… you may call these requirements or specifications, in fact to which the deliverables need to comply with. Now.., how do you structure the right flow of events to trigger the execution: A schedule…, not a workflow. Yes; you would use the workflow to route the schedule trigger items but the schedule in itself is a Work Breakdown Structure.

The schedule assures that the right disciplines at the right time receive the Request (and authorization) to commence with the work (task). You may call it the engineering variant of the kind of functions that are common in manufacturing i.e. the Manufacturing Execution System (MES) and in this engineering case the Engineering Execution System (EES). It is my experience that the maturity of EES’s that companies operate is low. Usually it is a combination of enterprise and desktop applications. Consistent usage across projects/programs, process integration and technological interoperability are major challenges.

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.