3) The Exact Solution

See also

This (third) chapter of the SIA presents an alternative solution that fulfils all requirements again. It takes different factors and perspectives on their importance and priorities into consideration.
Where “2) The Authentic Solution” is creative, this one is more classical. The next one, “4) Plastic Fantastic”, will be completely different again.


We can develop a brand-new “chrome bumper” with the required old style. It gives the looks and robust image you are looking for, and we can make it fit exactly. It’s not just the size or width of the car that matters, but also all the bolts and nuts that are needed.
That might even help to assemble the car quickly and easily.

Pros & Cons

  • It will always fit, but it requires a lot of manual labour, which makes it expensive.

  • Working with chrome is complex; it needs time to “Stabilise” (compare it with paint that has to dry). That rest period costs nothing but affects the (overall) planning.

  • Roughly, we need 13 steps, with (on average) a week between
    Note: this is not applicable for \({\alpha}\)- and \({\beta}\)-versions; they are faster.

    • This option is scalable: more bumpers for many cars are possible.


This demo is small, we skip a lot of (relevant) details.

For example, we mention the “assembly” topic and address the location of the bolts, nuts, and holes, but only very slightly.

An SIA (even an agile one) frequently has sub-chapters on those (functional) slices, to be introduced in Chapter 1, or ’in’ one of the solutions. That mostly depends on how generic the “slice’ is for the solutions.


In the workshop, we go into more detail.

In this “bumper example” we might handle ‘slices’ like: ‘Mounting/Assembling’, ‘Reliability’, and ‘Validation of the complete car’; depending on the audience.
We can also use more software-relevant topics, directly. Like ‘does a solution fit in the existing (CI/CD) pipeline’, ‘is training needed’, etc.

To say something cleaver, including the effect on cost, duration, risks, etc a (prematurely) design may be needed – I didn’t (nor can’t) do it as I’m not a mechanic.
But remember: a SIA is not a design document! Design (whiteboard style) just enough to underpin your statements. Don’t present it to your stakeholders, you only will annoy them. Unburden them!


comments powered by Disqus