Managing Risk in e-Commerce Projects

I was listening to Eric Reis in Dublin last week as he espoused the benefits of the Lean Startup approach to software projects. This approach encourages startups to release early and iterate often in order to mitigate the risks of getting things disastrously wrong. This is not the methodology employed in most large enterprises and consequently in most e-commerce projects.

The ‘waterfall’ approach is more typical of enterprise e-commerce projects. This approach usually has two or three major sequential phases – Requirements, Build and Release. They’ll be called different things in different organisations. The problem with the waterfall approach is that the later in the project you figure out that you’ve got the requirements wrong, the more cash you will have burned and the greater the subsequent costs of fixing the error.

As you move along the project lifecycle the costs increase; based on elapsed time and levels and expertise of resources deployed at each subsequent stage. So too do the risks increase. A six or nine month project based on false assumptions about customers, for example, could result in a very expensive project that does not deliver on expected benefits.


Risk and Cost in Enterprise e-Commerce Projects
Risk and Cost in Enterprise e-Commerce Projects


The Lean approach involves creating proofs of concept, alpha and beta versions of a platform; releasing these in cycles with users to understand their behaviours on the platform. In many large organisations this approach simply isn’t feasible. Would you use an online banking system for example with the letters BETA stamped on it?

Where possible enterprises will release individual components of an overall platform in stages, incorporating learnings from early releases into requirements for later releases. However the costs required to re-work those early releases may be substantial. Proofs of concept are sometimes developed early in a project but these are rarely used for validation with real customers.

The waterfall approach, developed initially for internal software projects, requires adaptation if it is to be used successfully for e-commerce projects. Project owners need to find ways to engage real end users early and often with the project in order to externally validate assumptions.

2 thoughts on “Managing Risk in e-Commerce Projects

  1. I think that the lean/agile approach is more feasible in large organisations than most people think. Would I use an online banking service that was in Beta? Probably not, but I’m sure there are some people who would, and that’s the general spirit of the process – that a small subset of the population will be early adopters and that you should get a basic product into their hands asap, then monitor their usage and build on it.

    Maybe online banking with a beta tag is the wrong way too look at it, but instead concentrating on the minimum viable product. If you were a bank launching your first ebanking site, you’d really only need a secure login and a “view balance” functionality to attract the first few users. You could launch all future products with a lean process in subsequent iterations.

    Lots of big companies use a “labs” type system to get around this, launching basic versions of products to users that have opted to be guinea pigs. This, in theory, could allow a large company to launch products quickly to real end users, then iterate several times based on their usage patters, before “launching” it to the whole customer base.


  2. Hi Peter. Yes, you’ve absolutely identified a viable approach to take in larger enterprises. Start by identifying smaller core pieces of functionality, deliver them to the market and learn from customer interactions.


Comments are closed.