Requirements Engineering

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.

Controlling

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.