The development of customer orders is normally managed with a waterfall diagram or Gantt chart within which mechanical, electrical and/or electronic, and software design activities are planned to be functional for the construction and/or procurement of materials and components. All to enable compliance with the subsequent assembly and testing activities required to complete product construction.
In the case of products configured according to the options provided-as in the case of products defined with commercial configurators, often given to the end customer-the design activities are absent, and the waterfall logic is perfectly suited to manage the order.
In a large number of cases, orders are submitted with light customizations of a “standard” product, which may require minor work to adapt the product to the customer’s specific needs. These are minor adjustments that still require a pass through the technical department.
If such adjustments are executable in a matter of hours-and the time spent traversing the design area is negligible compared to the much more relevant activities of construction, procurement, assembly and testing-the waterfall planning logic remains perfectly suited to manage the order.
Software design, if present, is unrelated to the construction and procurement of materials, but is linked to the assembly and testing activities that allow the software itself to be fine-tuned by the presence of the physical product.
On the other hand, in the case where the following are to be developed orders with strong customizations of the product, the effort required by engineering department activities increases by one or two orders of magnitude, in other words from a few hours for the configuration of a standard machine to several hundred hours for the development of a customized machine.
The design effort, in this case, may be comparable to or greater than the construction and/or assembly time. As a result, it is unthinkable that all design should be completed before construction and/or procurement can begin.
Especially in the case of customized machines, the assembly activity very often takes place in one step. Unique in the sense that the assembly of the whole is not broken down into the separate assembly of all machine subsystems or machine assemblies, followed by a final assembly of the same (only structured companies with production pre-launches and assembly of entire subsystems according to sales forecasts implement these “sub-phases,” which in any case remain related to standard subsystems or assemblies).
With a single assembly step, all machine subsystems or machine assemblies are produced as a simple list of their components.
In such a case, the construction/purchasing BOM becomes a flat BOM, and the groups are “transparent” and, for that reason, are also called “ghost groups“.
Construction/purchasing planning is thus “pulled” by the “Lead Time” of each BOM item, also called “Lead Time.”
Design will then release the BOM elements incrementally, depending on the Lead Time. Items with long Lead Time should be released before those with medium Lead Time, and so on down to those with the shortest Lead Time.
Such different gradations of Lead Time do not normally lead to as many release dates, or too much negotiation of dates would result.
Normally, 3 or more release dates for BOM items are agreed upon between production and engineering, with as many types of procurement starting.
For simplification of exposition, I have referred generically to “design,” meaning all designs related to physical objects or hardware such as mechanical, electrical, and electronic.
In the exemplification shown in the Gantt chart, 3 Milestone dates for design are indicated:
- Design End Date Long Lead Time Elements.
- Design End Date Medium Lead Time Elements.
- Design End Date Short Lead Time Elements.
The Lead Time of new items is estimated by analogy with similar items.
SW design can move more freely, conditioned by the assembly and testing stages as previously described.
The diagram below is illustrative of the case of a design and build/purchase with 3 appointments or Milestones (Long, Medium and Short Lead Time).
It can be seen that the activity of the engineering department starts some time in advance, because there is always a systemic design without which it would not be possible to identify the special elements to be designed and the standard elements to be launched into production instead without modification.
It can be seen that design activities continue beyond the release of the technical documents needed to build/acquire the last component, as there are other technical activities to complete the work that do not impact the Lead Time of the components.
This is what production requires, but within the engineering department the breakdown of the work to be done follows a different rule, very similar to the one used to budget the work.
In the technical area, in fact, the product is broken down into all the elements to be developed, grouped by subsystems or groups, creating a simplified BOM or high-level base list.
Typically you get to structure a list of subsystems or machine assemblies to be designed.
And for each of them the Hours of Development are estimated.
| Elementi hardware da sviluppare | Stima Ore di Sviluppo (H) |
|---|---|
| Prodotto nel suo insieme • Studio geometrie CAD 3D • Studio modalità funzionamento • … | H previste = 82 • H = 28 • H = 23 • H = ... |
| Sottosistema A • Studio • Simulazioni numeriche • Disegni escutivi • Schede di collaudo • … | H previste = 148 • H = 85 • H = 35 • H= 30 • H= 25 • H = ... |
| … | … |
| Sottosistema B • Schema elettrico o circuitale • Distinta componenti • … | H previste = 170 • H = 120 • H = 23 • H = … |
| Sottosistema N • Studio • Disegni esecutivi • … | H previste = 90 • H = 52 • H = 18 • H = ... |
| … | … |
List of items to be developed and estimate of effort needed in Development Hours.
Almost all machine subsystems will have elements with different Lead Times within them; therefore, assuming construction planning based on a single release of a complete subsystem does not solve the problem of differentiated management of components having different Lead Times.
How to combine these two legitimate needs of design and construction and procurement?
Thinking of building for each subsystem a Gantt mini-diagram would lead to really too much planning complication, effectively making it unmanageable in the face of any slightest request to change the plan.
Plan variation is actually very common and can occur for a variety of reasons, including, for example:
- Design difficulties encountered.
- Difficulties and/or contingencies in construction and procurement.
- Variation of specifications by the customer.
- Varying development priorities of different jobs according to departmental load or customer demands.
- Difficulty or unforeseen at assembly and testing.
- Mistakes all along the way.
And this is where the agile backlog management approach comes to our aid!
If the top-level elements are the subsystems or machine groups, then it is immediate to give visual representation to the previous list, breaking it down to the desired detail. This constitutes the Backlog of physical or hardware development.
It is then relatively easy to add to it any software development backlog.
The iterative and incremental development process-represented by Story Mapping-involves distributing the second-level elements of the Backlog over the different iterations, transforming the breakdown of the Backlog from static to dynamic.
Job order development is always characterized by tight timelines, so it makes sense to maintain iterations of one-week duration. The weekly interval is sufficient to meet both design and production needs.
By rotating the Story Mapping 90° counterclockwise, the previous list of items to be developed could have this representation:
With weekly iterations, a Milestone macro-argument can be created that contains references to the Milestones shown in the Gantt chart.
The visual representation below enables management consistent with the self-organization needs of the technical area and compliance with Milestones:
In this mode, all work related to the long Lead Times identified by the color of the corresponding Milestone must be developed no later than the week of Milestone placement.
Similarly, work related to the other types of Milestones is operated in a similar manner.
The scoreboard allows immediate visualization of the tags for second-level elements, which are placed beyond the corresponding Milestone identified by the same color.
If within each card-representative of the second-level elements-the hours of development required for its performance are indicated, it is possible to calculate (by iteration) the total weekly workload, which can then be compared with the hours available or weekly capacity.
This approach can, of course, be extended to assembly and testing activities as well, in the absence of production planning systems or where these activities are highly interconnected as design activities are.
This simplified agile mode with weekly iterations-which is the basis for the Flash Meetings described in the book within Chapter 12 on the Agile Factory proper-is also described in Chapter 13 on the 3 cases of Product Development: Simple, Complicated and Complex.
In the book I called this simplified mode of iterative and incremental backlog management “Easy Agile“.
A suitable software tool can perform these calculations automatically making the approach much more sustainable, especially in a multi-project perspective.
I will return with another article on the multi-project management mode of job orders with strong customizations.
