The Slow Death of Dinosaurs “e-commerce Projects”

E-commerce projects are dying. Why? Because the requirements in digital trade can be met less and less in the form of “projects”. We remember: Projects are characterized by a beginning and an end, there is a “project plan” in the form of a Gantt chart, and this plan must then be adhered to – or at least come close to it. The quality of the “project management” is ultimately measured by how well this succeeds.

CEO André Roitzsch & CTO Manuel Ludvigsen-Diekmann

CONSTANTLY INCREASING REQUIREMENTS

And it is precisely these projects that have become increasingly complex in e-commerce in recent years. Because the requirements have become more complex, e-commerce projects have grown like dinosaurs – project volumes of 1,000 PT and more are not uncommon (although perhaps “only” 400 PT were planned). And that’s not all: Because “projects” of such volumes also have a correspondingly long “project duration”, they overtake themselves – in other words: what was planned at the beginning is no longer up-to-date after a few months “project duration”, right or purposeful. In the best case, this is recognized, replanned and implemented as a “change request” differently than originally planned. Market requirements simply changed faster than the project progressed. Can happen. So the “project” doesn’t end, it goes on. It’s going to be rebuilt – before it even ends – and that’s why it’s no longer a project (projects come to an end, after all), but just a frustrating juggernaut. And “guilt” is somehow everyone involved and somehow no one.

Therefore, these dinosaur “projects” are not viable in their size.

And their extinction has long since begun: Contemporary software development is often driven forward in an “agile” manner these days. We then no longer speak of a “project”, but we develop a (software) “product” that is continuously further developed in releases. Open end. On the basis of a rather roughly outlined and also variable “product vision”. Accordingly, the old “Project Manager” becomes the “Product Owner”. At least we would have left the outdated framework of a “project” with a beginning and end.

AGILE PROJECTS “WITH THE CROWBAR”

On the commercial level between client and service provider, however, the agile model has so far not caught on: The client usually has to know before the start of a “project” what it should cost for his budget planning – and what he gets for his money. He doesn’t care what we call it. Which methods we work with, whether we sprint, create a specification or perhaps maintain a backlog – but what he gets for his money and what it costs, that’s what he wants to know. Period.

This way of thinking, commercially a “work contract”, of course fits wonderfully into the old world of “projects”, where there is an end and you can eventually draw a line under the whole thing, but it fits less well into the agile world of quasi endless product development. Where there is no end, there is no final price.

So an attempt is made to find a compromise with “milestones”. An attempt is made in advance to define the requirements for an MVP, a “minimum viable product”, i.e. the minimum version of what you want to have at the start. That’s then priced, and we have… a good old project. In the hope that it will be smaller, more manageable and easier to plan than the dinosaur projects described at the beginning. These MVPs are then further developed into releases, and each release can wonderfully be a small, manageable project. This is the compromise and often the current state of affairs in many customer-service provider relationships in the field of agile software development.

However, this model also often produces undesirable side effects from which clients and service providers alike suffer. On the one hand, these MVPs and the subsequent releases are not so small and manageable in the end that a more or less traditional project planning can realistically grasp the scope, on the other hand, we are currently experiencing the trend that market requirements and technological possibilities are now changing quickly change that in the end there should still be adjustments to the original project, which are supplemented in the form of change requests (CRs) and stretch the project duration and budget beyond the planning. And here, too, considerable additional effort is required, especially in project management, in order to separate and document CRs from requirements from the original scope. Same same but different!

CTO Manuel Ludvigsen-Diekmann

ADVANTAGES OF THE RETAINER MODEL

This approach creates various advantages:

CTO Manuel Ludvigsen-Diekmann

NO PIECE OF “ZEROS AND ONES”

Incidentally, the reason why many clients still have difficulties with the retainer model outlined here is unfortunately a very stubborn “phantom reason”: The budget is fixed – i.e. the costs from the client’s perspective. But what is developed for the budget is not yet developed. This fuels the concern that in the worst case you could get “a bunch of zeros and ones” for your budget, the function of which is not guaranteed and which may deviate far from what you originally had in mind.

This “risk” theoretically exists. But it is very unlikely, in practice it does not happen. Because every development cycle (= sprint) is followed by acceptance and approval by the client. Every month, it is checked and it is ensured that the output of the development is matched by an adequate business value for the client. And – quite apart from that – we can’t see that the good old “dinosaur projects” have a flawless record here. Or do you know of an IT “project” in which excellent project planning and a clearly defined scope would have ensured budget and quality in equal measure in advance?

Exactly! That’s why they die out, the dinosaurs.

ALSO INTERESTING