Keep the Technical Design Specification short to stay creative
Our first-time enterprise clients keep reminding us through their projects that we should read their technical design specifications (TDS). Whenever a detail comes up through the project, they become furious and tell us that this issue was on page x of our 100-page TDS. When that happens, we remind them that we only use their TDS as a reference, but we follow the one we’ve written ourselves, which is only 3-5 pages long. We work out the details as the project moves along. We only focus on the few design problems that need to be dealt with immediately per development cycle rather than many hypothetical ones that are brainstormed in advance.
That is the purpose of our initial meetings with our clients. To understand the problem they are trying to solve and propose a simple solution which often takes up only a few pages of descriptions, bullet lists, and diagrams. This document defines the project’s general direction and the objectives for the first 3 or 4 development cycles. After each development cycle, the results are again reviewed, and if any changes need to be made, they are decided and agreed upon. This is the very essence of lean and agile development.
We believe that lengthy TDS documents take away flexibility and creativity. They are counterproductive and bureaucratic.
The first-time enterprise client remains skeptical until we deliver their project successfully. That’s when they become our good references and recommend us to others.
Why is a TDS so “tedious”
So why is an enterprise TDS so tedious to read and write? There are multiple reasons:
Analysis Paralysis
First is the analysis paralysis. It is human nature to minimize risks by over-planning a new project. All kinds of compliance and liabilities need to be addressed in an enterprise. To prevent those, a product development team tries to minimize the possibility of things going wrong. However, product design and development aren’t the same as production. A company may have all kinds of protocols and guidelines for mass production, but creating something out of nothing requires focus and creativity. Focus on solving a specific problem in the most elegant and minimalist fashion. That can only be achieved through many development cycles where each product release focuses on solving a small, well-defined set of problems. Compliance and liabilities can be addressed throughout the development cycles, and adjustments can be made to the design. In some cases, obsolete rules and regulations can even be challenged or tested again to see whether they still serve a purpose while using the new and modern product.
Keeping the System Analysts Relevant
Second, dedicated staff and system analysts often write the TDS documents. It would be tough to justify their role if the end document was only 3 to 5 pages long. However, a 100-page document would make them appear valuable company members and possibly impress their bosses. This scenario especially happens when developing an Enterprise Aspiration App. System analysts are key actors in the Water Fall model, and Agile Development made their role redundant. It may sound a little harsh, but some software architects even believe that system analysis is dead; Agile Development killed it.