"A custom solution allows the woodpecker to find new food sources, build better nests and mark their territory." - Why don't woodpeckers get headaches?
If you want to bring innovation to the market that will have a lasting effect, you cannot avoid a custom-made product here and there. The unique strategic characteristics of your business model often only become possible through custom development. You already have the right team. Now you have to find the right partner.
It is a fallacy to think that in an agile world there is no longer a need for requirements specifications. If you want to find the right systems and partners, you have to know what you want. The right partner will only be able to estimate costs and deadlines on the basis of a clean specification. This transparency not only simplifies the project management of the first release, but also of the downstream operation.
To be honest; the better we specified, the more appropriate the chosen partner and the more accurate the cost and schedule estimates. The concepts, built on stories and diagrams, are well and good on the strategic and conceptual level, but not detailed enough for a custom build.
The central element of a clean requirements specification are the use cases. These are the detailed and structured user stories. They describe in straightforward language the individual steps of a user with a system and what comes out afterward. From this, you derive the business rules, the data structures, and the user interface.
The system suppliers will present the solution based on your use cases and not on a pre-formatted sales presentation. In standard solutions, the gaps become clear, and with in-house developments, you can show the costs by use case. You can then derive the costs for the respective user stories and prioritize them accordingly.
You will not order everything at once. Do small iterations. However, the first release must be viable. Define the requirements specification as part of the contract and pay for the project in tranches.
Firstly, you never, ever foresaw everything while specifying (that would be inefficient anyway), and secondly, reality changes from day to day; new people with different ideas come in, systems don't react as expected or effort and time run out.
Divide the individual releases into many small iterations according to the agile approach. Track the progress of the project by means of completed, unimplemented, and newly added use cases. This way you have transparency about the costs incurred at the end of the project.
Work with design-free wireframes or mockups before writing code. Use them to play out the use cases described above. The goal is not to create beautiful layouts, but usable ones. You don't need to layout every screen, just enough so that the test audience understands the main flow.
The employees who will work with the system afterwards are part of the team. Their expertise is important in defining the user experience. They are the ones who train the end users. They become the representatives and developers of the system once it goes live.
