People from time to time ask me, especially when working on smaller projects, why I spend the extra time writing detailed solution specifications and documentation in the beginning of a new project. I guess I sometimes get a bit carried away and maybe spend more time then actually needed to make sure I’m able to complete the project sucessfully. But this is my way of being in control of the project from an early stage.
I like to compare it with putting together a lego set
When you are building something out of lego you naturally open the booklet thats included in the box and you follow that step by step. This (if it’s done correctly) guarantees that you get the result you wanted when you started the build.
Many similarities
The process of building a lego set has many similarities with conventional project planning and documentation, it contains the steps (userstories) you have to take and in what order, it details what pieces you need to complete each page before you can move to the next. Each step is visually displayed to make it easy to see how the new pieces fits in with the build (mockups). They group the pieces into bags (sprints) so that you know what pieces are needed to complete each stage of the build (releases). If you discover an error or missing piece you correct it within that stage (QA testing and bugfixing). Since the different pieces are listed with their amounts with pictures its easy to detect if you are missing a piece, or you have the wrong one available (Acceptance criteria).
The people you are building the set for can easily get an overview of how far you have come by referencing the page number of the booklet. If there are any requests to change pieces while building this can be done by looking at that specific page of the booklet where this piece comes into play.
Makes you able to work on multiple projects at once
Having a booklet to follow when building makes it easy to build multiple sets at once, its also alot easier if someone else wants to complete the build on your behalf, they can easily figure out whats done and whats left.
If you look at it differently, not having a booklet when building a lego set, you will only have the picture on the box to rely on (in some cases you only have the description of the picture aswell), and if the set isnt a very simple one its very difficult to guess the structure of the build, the complexity of the internal parts, and different people would interprit the image or description differently. Having different understanding of the specification, when multiple builders are involved at different stages of the build, will result in having to redo work and having to spend time discussing who has the correct understanding.
Ensures the end result
The end result might look like the picture on the box, or fit the description, but how you got there might differ and you dont really know what pieces was used to get that result. Any errors or missing pieces might not get detected until after the build is complete and you notice that pieces havent been used (project requirements)
I also find that having a booklet (specification) from the start it’s alot less likely that someone wants to do changes or remove pieces from the build once you get started.
To answer the question why I spend the extra time. When I build a lego set for someone else and they pay me to do it I prefer to build it using the booklet. This way I know that the client will get exactly whats specified, and I know it will be delivered on time with minimal changes and interruptions along the way.