In software, the catalog is the center of the universe. Yet, during my nearly 40 years of experience, I’ve often wondered: Why do we approach building software differently than we approach building anything else?
In software development, clients can articulate the end product and business benefits instead of what their software is actually “made of.” It’s like creating a shopping list with only the word “omelet” on it with no knowledge of ingredient preferences for your family. Should you buy cheese? If so, what kind? The same goes for the conventional approach to software; we determine what we want but don’t describe it in enough detail to know what goes into it. Thinking ahead about what your software is made of ensures that you get what you want and that it addresses the problems that are specific to you, ultimately leading to better overall adoption of the product. Let’s look at it from a risk/advantage perspective:
What are the risks of not cataloging your software?
- Lack of alignment: The best approach is for all stakeholders to think through what goes into building software to ensure everyone is on the same page. If every decision maker isn’t involved, alignment ultimately suffers.
- Poor adoption: If software is built without clarity as to what everyone really wants, it leads to disappointment. Meeting and exceeding customer expectations starts with making sure their vision is completely understood; failing at this means their product and overall adoption will suffer.
What are the advantages of cataloging your software?
- You have better control over your software: You can refer to your catalog and gain a better understanding of all the ‘ingredients’ needed in your software product. When they embrace a catalogue, they receive an itemized example of how their vision of the product translates to the marketplace.
- You have a better understanding of costs: As your catalog grows, so does the price. It’s an easy way to demonstrate that you can remove things to reduce price or exchange similar items to keep the price stable. You’ll know that adding things increases the cost and scope of the project. Also, it provides transparency into how your software is built, how long it will take and how much it will cost.
Building software – and building an omelet – works best when the process is balanced. While you may be tempted to create an ultra-detailed software project plan, it can sometimes prove to be inefficient and unnecessary. Instead, focus on building a catalog that will meet the needs of everyone involved and solves problems specific to your business.