Welcome to the land of risk and high reward.
Building a digital platform, like any large and complex tech project, can be a perilous journey. From the client to the agency developing it and business consultants somewhere in the middle – everyone has something to lose.
Seemingly out of nowhere, implementing certain features becomes more complex than originally thought. Existing system landscapes reveal unforeseen hurdles to integration. Agency partners can turn out to be in over their heads, having sold a promise they cannot keep. These things have happened, all to the detriment of a project's planned scope and budget. Building a project on shaky foundations will lead to a faulty outcome – if anything comes out at all.
Still, there is hope. Even if many digital projects are doomed to fail, it does not have to end this way. Projects fail along three dimensions: time, budget and expectations. Development may take longer than planned, costs may get out of hand and the final outcome may not be as expected. In general, what it means for a platform project to succeed is simple: the outcome generates real business value for the client, thereby proving the client’s market concept is viable, while staying within a predefined budget.
Often, it is not technological complexity that leads a project to fail – though, to be clear, technology plays an immense role. The main risk factors lie in miscommunication, insufficient preparation, and inadequate controlling. Let's dive into the main problem areas and explain how to avoid them, in order to build platforms that succeed.
The devil is in the details.
Any given platform project begins with defining what actually needs to get done: engineering requirements. What features should the platform exhibit in order to fulfill its purpose and have the intended business impact? This question shapes everything from which technologies need to be implemented, what expertise is required of developers, development times as well as costs. It is critical – and really hard to answer definitively.
Most client companies find their answer in breaking down a granular list of features and describing their functionality in high detail. This, in itself, is not exactly a bad thing; it's good to know what you want. What makes this practice dangerous is what it suggests, namely that a project is only successful when the outcome is exactly the way it was originally described in a detailed, finely tuned concept. This is a problem. A resulting platform has to fit the business model and match the market approach, not encapsulate every feature idea. Doing the latter precludes the ability to verify that all the things one originally dreamt up actually add real value. In practice, though, only while implementing them does one see whether certain features are valuable – or just too expensive for the value they are meant to add.
»What we have found is that the deciding factor isn't how good or fast developers are – they should be, no question. Still, it's actually more important to focus and set the right priorities«, says Matthias Gronwald, Technical Director.
In fact, the requirements phase is all about focus. When wishful thinking meets reality, what is doable and what is sensible? In the beginning, often everything has the highest priority. The job of an agency is to first communicate what is realistic within a given time frame and budget. Then, it is critical to assign what needs to get done first and what can wait.
»This is where experience is really important. Translating requirements into technological implementation is the easy part. The hard part is convincing clients that features they really want are unrealistic or less critical than they think«, says Matthias Gronwald.
If feature lists are so terrible, why are they so hard to get rid of? The answer lies in one word: security – or rather, the perception of security. Having everyone agree on a list of features to be implemented suggests that this is indeed what they will end up with, and it minimizes the perceived risk of not getting what was agreed upon.
»Frequently, detailed feature specs become part of the contract between client and agency, as a means of securing one's position in case things don't go as planned. But this security is completely fictional. It doesn't just automatically make changing conditions or new information over the course of the project go away«, says Christopher Möhle, CEO.
»The idea is to define the minimum variant the client can already live with. Then, you define several steps or iterations up to the maximum variant possible – always keeping in mind that you have to meet the deadline. That's what we all want«, Gronwald adds.
Instead of focusing too much on features, companies should be very clear in their overall vision and goals, and have an adaptable plan for all the rest. Software projects are agile projects. The way to go in platform development is to define thirty to forty core requirements and flesh them out, but in a high-level, rough way, not by breaking them down into six hundred sub-features. A good project is not just built on sound strategy – it’s also about deploying the right tactical maneuvers. Having high-level requirements opens the path towards tactical decision making, because they can be continuously reinterpreted in light of new facts, figures and developments.
Using standard software is smart. Unless custom software is smarter.
If the most important question is what purpose a platform is supposed to serve, then a very close second is with which toolset to actually implement it. Which technologies are suited to build and run your platform? Of course, this question cannot be answered generally; it's just too specific to each and every case. Still, selecting the right technology stacks is risky because of the high costs of enterprise software licenses – and then you haven't even started implementing them yet. You want to be sure you're using the right tools for the job.
More than anything, choosing technologies requires a close reality check. Often, companies pick standard software products – Hybris or Spryker for Commerce, Salesforce as CRM, S/4Hana as ERP. The promise of using established, tried and trusted products is obvious: everyone is using them, hence the standard, they have solid ecosystems, and there is lots of experience available. This means once a technology has been decided upon, you have narrowed down your options of service providers capable of implementing it. Companies map requirements with the feature catalogues of software products, make a decision and then look for an agency.
»Often, when we get involved in projects, we find the technology question already answered. Best case, there was some level of experience involved throughout the decision process. There are cases, though, where we are not at all convinced the software chosen is right for the project. Or it could have been solved by going another route. But licenses have already been paid, so going back is not much of an option«, says Sarah Hoidn, Senior Consultant at Turbine Kreuzberg.
Generally, it is good practice to at least get a second opinion. To avoid spending money on one tool when another may be better suited, involving the implementing agency early in the decision process can be key.
Standard software products do have their downsides. The most important lies in the extensive customization necessary to adapt them for each individual use case. Most times, this means getting rid of some modules and adapting others, which takes time and costs money – this, on top of license fees.
»If it fits the use case, especially larger companies could do well to be somewhat more brave and develop things from the ground up instead. I would rather invest in a developer team or put a small agency team on it and do it myself over two years, mapping my requirements as I go along«, says Matthias Gronwald.
If done well and according to established standards of development, it can lower follow-up costs. In addition, it enables building up your own tech expertise. After all, a platform is more than a new sales channel. Companies that build and run platforms must understand technology at their core.
Controlling ensures more than a clean project. It keeps you flexible.
No project can ever be successful without a high-quality controlling setup. Software projects are risky; risks need to be managed.
Put simply, most controlling looks like this: knowing how much total budget is available, keeping track of expenditures, and figuring out the difference, in order to allocate correctly for remaining efforts. Controlling is done periodically, such as monthly, bi-weekly, or around project milestones. Account managers share and discuss the results with project stakeholders to negotiate the way forward. Sounds easy enough.
In truth, this does not meet the mark: when it comes to controlling, the agile approach is over. While in the planning stage you should remain flexible and focus on high-level requirements, you should be much more detailed when controlling the actual development process. It is critical to know how much time has been spent not just on each task, but also each subtask and sub-subtask. How far along are they in development and how much more time is required to complete them? Time, after all, is money, and money is finite.
In addition, controlling is a continuous exercise conducted throughout the project, not just periodically. Agencies should be able to give a highly detailed, granular status update every day – if not for every ticket, then at least at the epic level. Continuous micro-controlling should never be neglected for risk of losing oversight and failure.This keeps a project adaptable and allows for shifting resources.
»One should see red lights as soon as they start blinking, not just at the end of the month, or in the worst possible case, when a project is almost completed. Put simply, you have to know at every point how many days of development are left for each task and reallocate accordingly. Things that were in no way obvious before and aren't part of any contract will suddenly become unavoidable. And they still have to get done«, explains Christopher Möhle.
This means getting developer input to make residual estimates. Time and time again, developers have to reassess how much future effort will be required. This variable changes constantly, because the longer developers work on a project, the more they learn, the better they become at anticipating how long something will take, and the faster they get.
Communication with stakeholders is an important part of this, keeping them informed as transparently as possible. This requires effort and resources, the right people doing it, as well as a system everyone can agree upon.
»When problems arise in a project depends on two things: experience and quality of controlling. Experience lets you know from the start when something is too complex and costly for the budget and to estimate what would actually be required«, Möhle says.
»Good controlling allows you to ›positively disappoint‹ as early as possible, meaning pointing out problems before they manifest and escalating them immediately. If these things unexpectedly turn up later, you haven't done your job.«
In short, a project that shows cracks early on is often more successful than a seemingly smooth, quiet project. Problems turning up during the implementation phase can be a sign of inexperience. If they reveal themselves at the end, controlling has fallen short.
Thomas Weber, Brand Ambassador
Samuel Krist, Consultant
With input from
Christopher Möhle, CEO
Sarah Hoidn, Senior Consultant
Matthias Gronwald, Technical Director