Success Line

Deniss Ojastu

Deniss Ojastu

Partner10 October 2018


Most development processes are just that – development processes – and gives other important aspects short shrift. I’m sure you’ve seen those diagrams where the description of the development process starts with the first iteration and ends with the last one (if it ends at all). But before the development starts, there’s a fair bit of prep work that needs to be done in a short timeframe. Later, there will be a need for maintenance and admin for what’s already been developed. Success Line puts the “pre” and the “post” on the chart, too. Full transparency is best, because it’s easier to optimize what you can see. It also visualizes the process of maintaining and developing the cooperation as a whole parallel task.

Read also: Building innovation with custom software development


The first, optional phase of Success Line – used when needed – is QuickStart. In essence, it resembles preliminary analysis and the objective is indeed similar – to gather all kinds of input about the client’s organization so that the initial solution can be proposed. QuickStart makes it possible to start even if the client doesn’t have a product manager to collate the information we ask for. A top gun analyst from Helmes does that part of the job. In an average of three intense days of work, the analyst will be responsible for getting 360-degree input from different specialists from different departments, mapping the existing systems, mining the relevant data and digging into any existing client research.

Solution design

In Solution design, the service designers and solution architects are joined by infrastructure engineers who help think through the hosting and availability issues, security and monitoring needs and system performance requirements. In other words, things that can’t easily be grafted onto a built system at a later date. The Helmes infrastructure engineers have experience with business-critical solutions hosting, handling the unexpected operational issues, and thus their input in pre-empting later incidents can save a huge amounts.


Other non-functional requirements get the same kind of very high-level scrutiny in the course of the Kick-off meeting. At Kick-off, we sign all participants in the project to a Working Agreement, in which all understandings on cooperation and the initial principles of cooperation are recorded. It is a living, evolving document we update based on how we learn and fit the puzzle together during the project.


One of the most important ways that development is different from the “other guys” is that we don’t hold retrospectives only at the end of the iteration or about that specific iteration. At Helmes, retros are held at a reasonable interval and also address teamwork and cooperation with the client. Optimization is geared to making cooperation as smooth as possible so that any hindrances to maximum productivity are quickly eliminated. In other words, sometimes we slow down a little to take a good look at what we are doing in order to speed up afterwards.

Support after live

Support after live is the period after major releases where development and infra engineers are on stand-by, ready to resolve any unanticipated situations, answer urgent questions from the customer and third parties, and provide whatever customer guidance and support it takes to keep the system running smoothly. Often obstacles crop up precisely on the third-party side, so it’s important to be in contact with them and ensure they, too, are in a state of basic readiness for rapid intervention when needed.


Usually, software development process diagrams end with iteration n, or in extreme cases with a triumphant deploy/launch. Yet there’s a real need to think about how the application will work later on in the live environment. Success Line puts Aftercare on the map as a separate process/field. If it didn’t, a long-term partnership might suddenly see a decline in its actual capability to develop new functionality due to maintenance and support operations taking up development resource. Aftercare should be given separate consideration and preferably set up as an agreement, because parameters other than the ones for developing new solutions often come into play in this work: reaction times, readiness, problem solution times, monitoring needs, etc.

Why is the chart even necessary? It keeps important aspects (besides developing the new functionality itself) from being overlooked. And it also makes the process of working with us transparent and understandable for those new to development. With Success Line, there won’t be any surprise items and expenses that might appear to delay the project and inflate the budget.

Similar posts

  • Investigating Clinical Decision Support with the help of Green ICT

    Investigating Clinical Decision Support with the help of Green ICT

    Our team at Helmes spent the second half of 2019 investigating how to integrate advanced Clinical Decision Support (CDS) into medical practitioners’ workflows. The project was co-financed by the Norway…

    Kristjan Männik

    Kristjan Männik

    19 December 2019

  • How Business Professionals Can Enter the IT Sector?

    How Business Professionals Can Enter the IT Sector?

    We often meet talented business professionals who aspire to work for the IT sector. Most of them have had exposure to software projects, and they’re amazed by the value technology…

    Evelin Aulik

    Evelin Aulik

    25 November 2019

  • 11 Books that Every Team Leader Should Read

    11 Books that Every Team Leader Should Read

    I recently stumbled upon someone’s quote that it was easier to learn about leadership than to actually lead. For the most part I agree – it’s only through practice that…

    Evelin Aulik

    Evelin Aulik

    25 November 2019