Lifecycle management

Lifecycle Management - Selling a concept for agile maintenance

Maintenance, Sales

Last week, Teemu wrote about the need and concept that gave birth to Lifecycle Management here at Futurice. I'm going to continue on the topic and discuss the basic public relations challenges we face with the concept.

Let's start with a quick question. How do you feel about software maintenance? If you are a software developer, odds are that you don't think very highly of it. Indeed, the reputation is terrible. Unmotivated and/or unskilled coders, wasting away in a career dead-end position. Low-skill work, lots of tickets, instruction manuals and unhappy customers. Right?

If you are a software buyer, odds are that you don't think too highly of maintenance departments either. You've probably read and signed ambitious Service Level Agreements (SLAs) and decided upon detailed pricing models. You might have discovered that the mandated response time is fulfilled by an email auto-reply and not when the actual work on the ticket starts. Sometimes you even have to convince the vendor that the problem is in their domain, and the burden of proof lies with you. This gets especially bad in multi-vendor environments, where vendors like to point at each other instead of finding out the cause of the problem.

To make things worse, a typical pricing model for solving a problem ticket encourages the vendor to employ resources that don't solve the problem too quickly. It is bad business to solve a problem in 45 minutes, if it can be solved in 8 hours to get 8 times the money. I've lately started to suspect that defining a software maintenance contract that improves the service provided is as difficult as defining good personal bonus criterias. The challenge of defining a good contract is an interesting topic and I will write more about it later.

Bringing superior service to a technological field, where bad service by low-cost personnel is the de facto industry standard, sounds relatively simple on paper. Just do the job well and bring value to the customer, right? Not so, in our experience. First, you need to convince skilled and motivated people to provide the service. After that, you also need to sell the idea to the customer. This is where we need to shape the expectations brought by the heavy maintenance stigma.

Recruitment is difficult. Well, recruitment is always difficult, but recruiting talented people into a software maintenance and post-production development organisation is especially so. Try asking any developer if they would like to work in an organisation related to maintenance. They are likely to run away before you finish the sentence. Internal transfers from other teams to our team do not really happen, either. For anyone uninitiated with our concept, a transfer to our team would feel like a demotion. It is not going to happen voluntarily, and mandating such moves would be a very effective way to destroy motivation and make people quit.

Taking the time to explain our concept effectively to the candidate pays off when recruiting. After that, it becomes evident that the job is a challenging one and it offers opportunities for professional development. We want our people to be customer-oriented technology generalists, who are able to understand the customers business well and learn new technologies quickly.

While this sets the bar quite high, our promise for the recruits is equally bold:

  1. Nobody works alone on a service.
  2. You can get as much customer responsibility as you like.
  3. You get to participate in pre-production development projects if you want to.
  4. There are no internal fences here. If you don't like working in our team, you can join another one.

The promise has so far been largely kept. Currently, we have two people participating in long term pre-production development projects and some participating in shorter projects. People have worked alone in projects for some periods of time, but these have always been periods of very low activity in the project. Customer responsibility is always there for the taking. We haven't had to test the fourth promise yet. We see this as an encouraging sign and a success in building a team with an identity.

The perception of customers is another challenge. It is difficult enough to sell a "better model" for maintenance and post-production development. When the perception is that the maintenance department is mostly able to answer the phone and follow pre-made instructions, it is hard to convince the customer that we actually have competent, senior developers at their disposal. Sometimes it even seems difficult to sell the idea that our organisation would actually be able to do any post-production development. Not long ago, a customer described their need to be exactly what we offer: active small-scale post-production development that would, in itself, take care of the software maintenance needs. They just couldn't believe that it could be done by a 'maintenance' organisation. The traditional split between development and maintenance organisations is heavily ingrained indeed.

We are still searching for the right ways to sell our service to customers. Different purchasers from different organisations value different things. Some value detailed SLA:s, some value direct communication with a known person. Some value ease of buying. Some will think of any post-production activity as a mandatory evil which should be avoided if possible. Selling continuous post-production development will sound to many as an ambitious maintenance department that has forgotten its place - which, to be fair, is a view that in some cases holds a grain of truth in it. If the software in question is not an essential part of the customers business, it doesn't make much sense to make an ambitious maintenance and post-production development plan for it. When we recognise these situations, we strongly recommend bringing in a third party for the maintenance.

For us, continuous development is the whole point. We believe that there is no better way to retain and increase the knowledge of a system than working on it. There is no better way to do post-production development than doing it continuously, keeping the knowledge of the system fresh all the time. There is no other way to keep an experienced developer motivated to tend the system than continuously working on it and being able to produce quality. If we believe that the business case does not enable us to do this, then the case is not for us. But when first class post-production development is needed quickly and economically, our way is a proven way to do it.