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!
ERROR IN THE SYSTEM
The (thinking) error in the system is the idea of providing a project, trade, “piece of software”, a scope of services – i.e. something clearly defined beforehand with an effort and a price. In truth, it’s really just a matter of clients securing know-how and working hours suitable for their project – i.e. resources.
Companies with growing and changing IT needs are best positioned in this environment if they secure resources from their service provider over a defined period of time, completely independently of a specific project or project goal, which enable them to respond flexibly to market and customer requirements react and thus become capable of acting in matters of IT.
At the beginning of such a period (e.g. 12 months), only a rough framework needs to be set and/or (based on this) an investment budget defined. The resources are then stored by the service provider with personnel to match the reported need and called up and billed as retainers in equal monthly installments (e.g. 20 PD/month).
CTO Manuel Ludvigsen-Diekmann
ADVANTAGES OF THE RETAINER MODEL
This approach creates various advantages:
- =There is a clear budget and therefore absolute cost certainty on the part of the client.
- =Nevertheless, it creates maximum flexibility: Month after month, the customer can decide how and with which priority the firmly committed resources should be used - what should be developed in which order in the next month.
- =The effort for project coordination decreases radically when there are no more projects.
- =There is no project planning that goes beyond the period of a development cycle (sprint) - i.e. a maximum of four weeks.
- =And - even more important - the nerve-racking for everyone involved in documenting deviations from the plan and discussing what is a new requirement and what is "planned from the start" - for functions that were designed months in advance and under different assumptions. That simply doesn't apply.
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.
According to André Roitzsch, digital pioneer and CEO of SHOPMACHER, it no longer works to carry out a website relaunch and then sit back and relax for three years. ITD: Mr. Roitzsch, the Corona crisis and the associated temporary business closures have given...
For more than 20 years, the office partners from Gescher in Münsterland have developed into an internationally renowned player in the field of office technology. With around 130 employees, the office partners provide their customers with office technology: printers,...