In every software implementation methodology I have seen, the first step is always a variation of ‘Define your problem statement.’ This is vital to ensuring efficient development and an effective solution. However, the reality is that the bigger picture is often lost when trying to rush through urgently needed functionality.

After the urgent need is addressed, the remaining functionality is then implemented over the top of what now exists, but adding to what end-users are now accustomed to requires a drastically different perspective, and compromises, compared to designing an entirely new solution. It is much more difficult to work within a structure that wasn’t designed with new functionality in mind than it is to build a new structure.

In one of my experiences in particular, assumptions proved dangerous when designing the first part of a much larger modification in isolation. The functionality of the initial implementation depended on specific scenarios and restricted the type of documents processed to only customer facing ones. In the larger picture, the modification required set up options and needed to handle internal documents as well, which required significant restructuring.

The reason that the modification, which was not fully defined, advanced into the design and implementation stages was that there was, as there often is, a time constraint on one particular area of functionality. While this is understandable and perhaps unavoidable, it invariably leads to more issues down the road.

Including previously unconsidered functionality in a pre-existing modification takes significant time and cost, both in developing the new solution and decreased efficiency from end-users when it doesn’t work how they expect or need. It also leads to an appearance that it was ‘designed by committee’, even if there is a single person making decisions.

Fully defining a problem takes discipline and time (which is sometimes in short supply) but the final product of doing so is of orders of magnitude higher quality than when the problem is defined piecemeal. Investing in this area will save both time and money in the future so it is certainly worth the effort.

mm
Written By Andrew Lang

Andrew moved from Brisbane to Melbourne to join Fenwick Software in January 2014. After studying Games and Interactive Entertainment at the Queensland University of Technology, Andrew gained broad experience in various programming languages and environments. Andrew is now involved in NAV implementations, enhancements, and developing web applications. Andrew holds a Bachelor Degree with Honours in Information Technology.

Leave a Reply

Your email address will not be published. Required fields are marked *

We're here to help!

Call us

03 9695 3333

Or, leave us a message