Get in touch
I’ve “met” him regularly in the past 15 years. The boy who can implement an E-Commerce project in half the time of an agency – oh, what am I thinking, in a quarter of the time. Most of the time he’s the godchild or son of a good colleague of a decision-maker. And we service providers must then listen to statements such as, “That can’t be so difficult,” or “My godchild can do that on his free afternoon.”
Often enough in the past I became annoyed in such situations. But no longer. Now, I understand it as a signal for an immediate withdrawal from negotiations with the customer.
Why? Because with such claims the client either shows complete ignorance concerning the subject matter or is deliberately trying to unsettle the service provider. Whereas the former was par for the course and tolerable ten years ago, those times are now over.
The second point, that is the unnerving of the service providers, has always been unacceptable. But, at the dawn of the industry, when many of us had to convince every customer about the importance of the Internet and there were economical dry spells on occasion, we had to bite the bullet. Today, we don’t have to put up with this anymore.
I think that the fewest decision-makers are deliberately trying to mislead or unsettle us. On the contrary, I repeatedly make the observation that many small anecdotes contribute to the fact that these people really think that it’s easy. Stories such as the one about a student who developed an app that achieved 500,000 downloads in two weeks or stories about relaunching corporate websites within three weeks. That this usually pertains to a corporation that is actually a small business with 20 people – and not a corporation with 2,000 employees (of which 200 are dedicated to the relaunch), is ignored in all the euphoria.
This used to happen almost all of the time. The contact person at the customer didn’t understand why the change “xyz” took ten days, when all that had to be done was to “move the field down a little and change the sequence.” However, that accomplishing this required rewriting a large part of the module, didn’t really penetrate the thought processes, despite repeated explanations.
Another thing I have always enjoyed (and continue to enjoy) immensely was and remains to this day the discussions concerning the search function. Now, I’m not really the least-informed about the subject of online searching. We deal with the issue of complex, high-performance search functions on a regular basis. But, even today, it occurs occasionally that a customer writes “Just like Google” in the requirements for the project. Sometimes, and those are the most wayward examples, you can read “At least the way it’s done by Google.” And yes, you can read such things even in those large RFPs with lots of consultants involved.
To take care of this customer hoax is relatively simple, though: With great pleasure I calculate how many people at Google work on search functionality and loosely relate that number to the current project budget – something like, “If we were to implement the search in such a manner, we will need 480 times the budget you have provided, not including the actual E-Commerce platform.” This usually elicits a few laughs – and one can then, finally, begin with a serious discussion of search functionality.
At the beginning of my career in the Internet industry, where I mostly worked together with smaller clients, I had the impression, that his phenomenon was restricted to small businesses led by patriarchs. Over the years I’ve learned that this is not the case. Especially senior-level decision-makers regularly underestimate the scope of web projects. Something that is reflected in the budget specifications. It’s common for retailers to invest 3+ million in offline stores; E-Commerce platforms, however, have a hard time securing a budget of 500,000 Euros.
There is no evil intent here, just simple ignorance. Large, complex projects cost money. The larger and complex the customer himself, the more expensive it gets. And, as a rule, not in form of a few additional percent, but by a factor of “X”. This is because many things have to be considered that go beyond the actual code and functional design. Things such as load tests, external security and code reviews, hundreds of audits, communications, internal restrictions, many stakeholders, etc. Most decision-makers forget this, usually because they just don’t know. Experience, as so often, is key here as well.
People in the industry itself also have different notions about what is expensive and what is cost-efficient. Two years ago, when Namics was commissioned with implementing a CMS project for the Swiss government to the tune of 13 million Swiss Francs, passions ran extremely high (grammar). I can recall countless conversations, particularly with representatives of smaller agencies; most of them found the sum to be simply warped.
Many couldn’t imagine spending so much money on a web project. And the fewest agreed that it was a good idea to actually do so. I basically thought both were fine. Because, if you look at the job requirements, then you realize that as a provider you have to meet so many costly requirements that you simply end up with such project budgets in the end. The real criticism is targeted at the Swiss government that, from my point of view, defined an overly excessive framework of requirements. But this isn’t the fault of the service provider.
Then, my dear agency friends, please slap him. And I say this as a staunch pacifist and someone who abhors violence. But, it seems there is no way to silence him.
Or, better yet, force him to deliver on his promise. On a school-free afternoon.
Composable business is an interplay of IT architecture, technological solutions and the corresponding mindset. Steven Bailey explains in an article at ComputerWeekly why exactly this enables telco companies to make a push toward digitization.
Knowledge of products that are frequently bought together enables companies to offer their product range in a targeted and customer-oriented manner. In etailment, Steven Bailey & Steffen Kopmeier explain how.