This blog entry discusses the internal process at JTeam to structure our support and maintenance work, and at the same time exceeding the client’s expectations.
As you might know, if you are a regular reader of this blog, JTeam is a software development company. We develop enterprise applications for our customers. See for example our blog post about the Paazl project for a description of one of our projects. After implementation, these applications often will be maintained and developed further by the customer's own development team or is being outsourced. There are however some projects which stay at JTeam. We keep on maintaining the project and implement new features.
These kind of projects require a different type of development and management process than the other projects. Especially the support work for these projects (i.e. bugfixing) is something that involves a whole different approach.
Here at JTeam we’re constantly looking for ways to improve our development and management processes. This is why we wanted to create a better way to handle these support issues.
This blog entry discusses this process. It will feature multiple parts, so you can follow our strategies and conclusions. Maybe it will help you to find the perfect process for your own business.
Problem description
As said, support and maintenance work is work for projects which are ‘done’ but are troubled by bugs or other problems. At JTeam most of the time the person who knew the most of the project was assigned to fix the problem. However, this solution is not without problems:
- Knowledge stays within a select group of people
These people are not always available (e.g. when working on other projects). When these people are on holiday, sick or leave JTeam, work cannot continue. So, the ability to solve problems, or adding new features, depends on the availability of those people. JTeam becomes dependent on them.
- People keep working on the same project over and over again which can become kind of tedious in the long run.
We thought of a possible solution for these challenges and came up with the following initial solution.
Solution I
(code name : you spin me round)
Our first official support initiative was a combination of support and maintenance work with rotating teams.
We assigned 3 people each week that had ‘support duty’. These 3 people were expected to pick up support and maintenance calls, for 16 hours a week, and handle them together to make knowledge transfer possible. Every week, one person left the group, to make room for a new person. This way, the two people who were already in the support team, and stayed in the support team, could transfer knowledge to the new person. Resulting in rotating teams with a lot of knowledge transferring. Additionally we made sure that every week there was a domain expert or a software architect assigned to participate in the support group, to teach the other members of the support group enough of that project.
With the big amount of knowledge transfer, a lot more people got acquainted with the running support projects at JTeam. The added value of this is that we, and in the end our customers, were no longer dependent on one or two people who knew how to fix the problem. More people knew enough of the project, so our availability factor increased drastically. Thus allowing JTeam to plan people more efficiently. They could be billable on a lot more projects then they were before. A Win-Win situation for both the customer and JTeam!
To make the support process more enjoyable for people, they were after all expected to be in the group for 3 weeks, we decided to invest in these people. At JTeam we believe in the personal development and improvement of our knowledge. We do this by training our colleagues and letting them investigate and work with new technologies. This is why we decided to let the people who work on support duty, investigate cool new innovative technologies when no support calls where due.
Business wise, we offered our customers an Service Level Agreement (SLA). We needed 3 people to be available every week that could handle support calls. That meant those people had to discuss with their teamlead that they will be less available for the coming week(s). This has influence on the project they currently were working on. Guaranteeing availability is an added service to the customer, which can be agreed upon in an SLA. Customers with this SLA will be part of this process and will benefit from the advantages of this system.
However....
this way of working was used for 3 months, but currently no longer used at JTeam due to several reasons. Next time I will describe these reasons along with our new support.
In the mean time, I’d really appreciate your feedback on the above structure and solution. What do you think is wrong with this, and how could we improve? How does your company handle these challenges?