One of the common myths I keep hearing is about the cost of change. It is an interesting topic because there is no doubt about that there is a cost of change. The more important question however is just how much cost are we talking about? Does it justify the attempts to mitigate this cost by spending on more detailed up-front analysis and design? Is it even possible to mitigate this cost?
Let’s look into these questions one by one. Keep in mind that the obvious answer to all these question could be “It depends”! I am however sick of that - I want answers (even if they are only rule-of-thumb answers):
Just how much cost are we talking about?
The costs are most likely to be directly proportional to the level of skills involved. So if an organization is looking for the cheapest development partner there is a good change that the cost of change will be high. However if an organization chooses to engage a professional development partner the costs will be reasonably low. A professional partner will use best practices like Refactoring, Unit Testing and Continuous Integration from the get-go to ensure the quality and maintainability of the code. They will use standard architecture blocks (Software Factories, IoC/AOP containers, UI abstraction patterns like MVC/MVP, Logging frameworks etc) designed for flexibility and maintainability (unless your #1 priority is performance in which case they might choose not to use blocks). A professional partner will have an efficient change control process in place to minimize bureaucracy and documentation.If they don’t then you are overpaying them (regardless of brand recognition) - full stop!
Does it justify the additional investment in analysis/design?
To answer this question we must understand the cause and likelihood of change:
Legislation: Government agencies and regulated businesses are the most likely ones impacted by legislation changes. However it typically only happens a few times per year and is discussed in advance. This type of change is usually mandatory.
Market: Movement in the market place can force change - for example a competitor can introduce a new product/feature/service. Quite often Time to Market and First to Market are strong drivers on a project so even rumors about competitors working on similar products/features/services can cause change.
User Experience: Once your consumers (also called “users”) are able to use the development output there is a good chance for the well-known change requests. The reason for that is so obvious that it’s hard to understand why we sometimes think there won’t be change in a project: The fundamental justification for any project is that it changes the status-quo. So even if it is about the re-development of existing functionality it will include new or modfied workflows/UIs/features. Only with the end product the abstract analysis deliverables (use cases, wireframes, stories etc) come to life and can be validated. On any project of reasonable size changes are inevitable.
Is it possible to mitigate this cost?
So where does that leave us? In my opinion additional efforts in analysis can mostly mitigate legislative changes in a short project (< 3-4 months) and reduce user experience changes somewhat. I can’t see how you can ever mitigate market inflicted change. And I would strongly suggest that early and frequent exposure of your product to its consumers is less expensive and more effective in managing user-experience-invoked change.
Conclusion
There is a cost to change - no doubt about that. The most sensible thing to do however seems to be to accept that fact and plan for it - rather than trying to over-analyze in a desperate attempt to avoid the inevitable. Choose your investment wisely and spend just enough time and money to have a fair understanding of what you want to achieve (and why)! Keep requirements at a business level (i.e relevance of a particular requirement to a particular business benefit) rather than implementation details (“user clicks button xyz and that opens window abc”) to avoid high document maintenance costs!
