Project Cycle: Support & Maintenance

What happens after your software is built? How we further maintain your project and how does it all work? Read on.

Software support and maintenance is a standard part of any project that is more complex than a website on a WordPress template. This contract is called either support & maintenance or a service level agreement (SLA).

The client – you – enters into a written agreement with your software supplier – us – in which we agree to continue to take care of your software for a monthly fee. An SLA agreement ensures that even if we’re not currently working on your software but something stops working over time, we’ll prioritize it and fix it. Because we know that your entire business often depends on it.

And we still take your interests as if they were our own.

What the contract includes

In the SLA contract we agree on:

  • max. number of days to address the reported bug
  • what the bug ticket must contain (see below for instructions)
  • what we are responsible for and what is beyond our control (third-party applications)
  • the duration (usually 1 year with the expectation of renewal)
  • terms of cooperation

Financially speaking, the monthly expenses cover:

  • data management
  • regular updates
  • providing support to users
  • fixing software bugs (hence debugging or bug fixing)
  • allocation of development capacity
  • maintenance of know-how
  • account management
  • reporting
  • licenses for project tools

You then pay the fixed SLA fee for the past month as in the case of an invoice.

Remember that the contract does not include fees for hosting that we transferred to you during the launch phase. Depending on the number of users, these range from hundreds to thousands of crowns per year.

Communication

You will receive access to the bug and features reporting system. In Siesta we use Atlassian’s Jira Service Desk. Your project manager will train you on everything. However, even your less tech-savvy colleague can handle Jira Service Desk, so you have nothing to worry about.

At this point, you will meet our colleague from client care who will work with you to resolve any reported bugs and, in cooperation with your project manager, any new development requirements. The records you submit to the Jira Service Desk are called tickets.

  1. Select whether you’re reporting a bug or a feature (new functionality or UI change)

Clients tend to report everything as a bug. But of course, we evaluate all incoming tickets and if we find out that it is in fact not a bug but a new requirement, we will write to you back that we are including the new requirement in our development capacity planning. All new development and its planning is then handled by your project manager as before.

So, by incorrectly flagging your ticket, you are extending the time it takes us to get to the resolution. Therefore, we really recommend that you take a small moment to consider which flag you give to your ticket.
  1. Give your ticket a title

A headline that tells us at the first glance what is it all about. In case of a bug, we recommend to describe the bug with a verb (the functionality does or does not do something).

For example: the Filter button on the Customers page is not responding

  1. Describe your requirement in detail

If it is a bug, it is essential that you include the following in the ticket:

  • the date and time when the bug occurred
  • whether it occurred once or repeatedly (if possible, always try to reproduce the bug)
  • user details (username, password, email or phone number to which the account is registered)
  • exactly what you were doing in the app or system when the error occurred (ideally, record a short video or take screenshots with descriptions)
  • how the app or system responded (take a video or screenshot)

If it is a new request, it is essential that you include the following in the ticket:

  • Describe the functionality in user story form (as <role> I want <capability> to <benefit of action>
  • describe any changes associated with the new functionality
  • in case it is a UI change, attach a drawing that shows how the change should show up (wireframe, mockup,…)
The more details your ticket contains, the sooner we can start to resolve it. That way you won't waste time asking questions before we really understand what happened, to whom and why.

It’s worth ticking off the list of details to make sure you’ve really sent us all the information you have. You’ll find that after a few months of working together, you’ll be sending tickets like a professional.