I have been in the business of implementing business solution for over 25 years. During this time, I have been amazed at two things: 1). the incredible speed of innovation in this sector, and 2). the incredible inertia of silly requirements that keep us from utilising these innovations. No - this is not an advocacy to just blindly implement whatever shiny new thing that is concocted - I am merely implying that a number of the requirements put up are designed to maintain the status quo - intentionally or unintentionally. Typically, the technical restrictions of the current solution become the most restrictive requirements of the new. Read on for tips how to recognise this.
Where do I put the horse?
Imagine, late 19th century, at the onset of the invention of the Automobile. What if the requirement to be able to harness a horse was maintained? We now know that this would be completely unnecessary, but if the concept of the Automobile is completely new and alien to you, it is a reasonable assumption.
Do you have any "harness" requirements?
Culprit no. 1 - Finance
For the uninitiated, finance is the area where magic happens. Somehow, the finance department makes sense of all the operations of the business, and quantifies that neatly in a profit and loss statement and balance sheet. For sure, you don't mess with that! However, not all requirements are affecting the production of the statements and reports required to run a business - some are just... there to keep things running as they were for years.
Example - booking time in 10 units per hour
Those that are booking time, in the "old days" did so in 6 minute units. This is driven by the invoice not dealing in time, but units (base 10 instead of base 60). With the introduction of actual time sheets, that are able to capture actual time (either as duration, or as a from - to record), it is now possible to capture actual times, and these are converted to base 10 units in the invoice (yes - in most systems, you can set 6 minute intervals in the conversion). And what was a requirement at an organisation I did some work for a while back? You guessed it: we do not accept writing time sheets in actual time, please modify this to reflect our 6 minute units...
Example - operational reporting from the general ledger
Before the 1990's (yes, integrated systems have been around that long), the financial system was used for reporting, and the operational systems (as far as they were not paper-based in the organisation) were used to drive the process. Both financial and operational reporting had to come form that one system that had all the data consolidated into one reportable database. Before a decade ago (or so), creating reports was quite complex and expensive. Since the turn of the millennium the complexity and costs have gone down considerably, and now it is almost "end-user" work to create meaningful reports out of multiple data sources. Yet, in quite a few organisations, there is a very complex ledger structure, split out with a ledger account almost on product and customer level (I have seen an organisation with a general ledger containing 21000 ledger accounts, split by customer(!)). The cost and complexity to map all ledger accounts to operational activities is significant - it is also highly error-prone requiring regular reconciliation verification activities. In modern (anything from the last 20 years, really) systems, collating financial and operational data into a meaningful report is considered a given - yet the requirement for such detail in ledger setup remains at some companies.
Example - after-the-fact purchase approvals
Every company needs to control the purchases and bills. Especially when the systems are not integrated between finance and operations (see above - operations used to be mostly manual), a purchase invoice needed to be verified prior to payment. With the onset of integrated systems and approval workflows (mid-2000's), any invoice that comes into the business is either an expected non-purchase invoice (i.e. utilities), or the purchase order is somewhere in the system. These orders are pre-approved as a purchase, and in case of a physical good, matched to the receipt of the product (so-called three way matching - where the invoice, the receipt, and the original purchase order are matched for consistency). It makes little sense for these purchase invoices to go through a separate workflow yet again prior to payment, increasing activity (cost), complexity, and a delay in paying suppliers (supplier relations). Instead of separating the unexpected non-purchase order related invoices from the pre-approved invoices, many times I see companies adding the double workflow on the purchase invoice for approval for these expected invoices. The outcome? 100% approved, or if there is a rejection, it is due to a discrepancy found in the three way matching.
A new system is not "magic"
New software systems enable a more streamlined and efficient process. That implies that it facilitates doing things differently. What no new system can do is make a convoluted, outdated, and inefficient process work smoothly. It actually costs you more money in implementation, and modification of the system, to make it adapt to poor processes. It is a fallacy to expect a new system to bring in the process utopia, when you do not change your process.
How to establish the true nature of requirements
In most cases, the list of requirements for a new system is composed by people that know the current system (because they use it). It is therefore not a surprise that the requirements read like a summation of activities performed with the current system, plus a wishlist of things that would make it better. Often you hear the phrase "at the very least we want all features we have now, plus some more". Given the old system has been in place for 5 to 7 years (or sometimes even over a decade), and the rapid innovation in the business application space, it is no surprise that requirements tend to hold you back in the status quo.
Here are some steps to establish the true nature of your business requirements:
- instead of compiling the list what people do, establish what outcome they need to achieve
- for each outcome, ask what benefit this outcome brings (or what "disaster" is averted) - try to quantify this
- establish if the new solution can achieve the outcome - identify if it does so in the same, or a different manner
- assign a classification to each requirement (MoSCoW - or Must have, Should have, Could have, Won't have (now)) - is a great tool to manage expectations
- use stepping stones, not a big leap forward analogy - make every release slightly better than the last, instead of aiming for perfection and never delivering anything to production