It sounds nice – and maybe also a bit utopian. However, in a time where everybody is talking about agile development methods (promoting progress by being flexible in scope and prioritization) – it strikes me as odd, why we continue to distinguish so strictly between the development and maintenance of a Business Application? In my mind, the only two major differences should be the inclusion of end-user input in the task prioritization and the extra precaution in release management, ensuring a stable production.

Longer life

By having a strong post-go-live organization, you can continuously ensure complete alignment between your Business Application and your daily operations. If your application is a customized standard product, like MS Dynamics CRM or AX – you will also have the ability to update regularly – benefitting from (mostly) enhancements, security updates and general bug fixes from the supplier. This will all help you to avoid that arduous upgrade project down the line – when the pain of a deprecated platform gets too big to handle.

Less Risk

Applying the Pareto Principle to application scope might seem a bit stretched, but it is nevertheless a common understanding, that most applications are flooded with features, which are never used – or where the value of usage does not match the cost of implementation. This is most commonly because the analysis and design phase got out of hand trying to cover every possible scenario. Why not go with the bare minimum and let the end-user co-decide on evolving the Application into that full-fleshed service portal you intended? It will keep your initial investment low, the delay before you can harvest the benefits shorter, and it will give you a much greater flexibility to re-prioritize your efforts.

Less Cost

All points above will affect your total project cost. The risk of failure is not only a matter of (partly) losing your investment, but also the effect of the delay – or absence – of the entire business case. So if you, for example, assessed that a new CRM system would improve your sales with 30% – what is the financial effect of that happening 6 months later – or not at all?  The same thing goes for continual alignment between the daily operations and the application. What is the actual financial impact of your staff slowly becoming more and more inefficient due to a static system in an evolving world?

Unfortunately, the approach of spreading out your spending over many years tend to collide with the financial structure in many companies. Application owners often argue that it is easier to get approval for a one-time investment rather than increasing the ongoing operational cost. To me that sounds like a misunderstanding. The whole idea with this approach is that the ongoing cost is a combined investment and operational cost.