The Importance of eCommerce Requirements to your Business – Pt. 2

Before beginning the secondary chapter of this article, I would highly recommend you read the first installation to give you a better idea of what you are getting into.

But hey, I’m not going to stop you if you only want to read the second bit! If you feel confident to delve right into it, go ahead.

Measure Thrice, Cut Once

In ecommerce, it pays dividends to be right the first time.

This graph (kindly borrowed from Agile Modelling) displays the direct relationship between the cost of a requirements error and a project’s timeline.

From my experience with ecommerce, this graph represents a perfectly logical representation of what it means to ‘get it wrong’ in an ecommerce project. There is, undoubtedly, a compounding correlation between cost of change (fixing an error) and how far into the project your developers are.

Allow me explain.

The increasing nature of costs reflects the compounding complexity of the interrelated applications as your ecommerce platform is developed. As you build and integrate one application with the next, ultimately forming your ecommerce platform, you increase the various interdependencies between each of the applications. And don’t get me wrong; this complexity can work well if, and only if, you choose to include all of your necessary functionalities in your requirements stage.

Look at the X-axis on the chart, if your developers take into account your requirement for a certain application within the requirements phase, they can accurately plan and execute the rest of the platform with that requirement in mind, it comes at no (added) cost because it is already a factor that is considered in choosing and executing the later stages (Analysis/Design, Coding, Testing, Production).

But what if, in this stage, you miss a requirement that is business critical?

Much like a skyscraper that relies on the levels below it, the later stages of ecommerce platform development require a sturdy foundation (that is formed by its requirements). It’s because of this that adding a requirement later in the project will increase the cost and time of development by significantly more than it would have had it been recognised earlier.

Although not necessarily true for all components of an ecommerce solution, the business critical applications usually carry cost curves similar to the diagram above. Take a PIM for example:

If you need a PIM during your requirements phase – it is no cost to add in, simply list it or write it down as a requirement for your business. As the project progresses through design, coding, testing and production, this requirement will be factored into the project’s scope and will be catered for when calculating both cost and integration.

But

If you wait until the production stage to realise you need a PIM in your solution – it will come at a much greater cost in both time and money. As indicated by the graph, changing (or in this case adding) such a large component to your platform at such a late stage in the project would incur much greater costs because of the significant ‘re-working’ of foundation levels that is required.

None of the previous stages of the project have been developed with a PIM in mind, meaning there is a necessary re-work of the designing, coding, testing and production to integrate the new application.

Part 3 out next week…