In the previous part (part 1) of this series, I’ve discussed our first setup for a support structure in our company. As I said, this setup is not used anymore due to several reasons. In this blog post, I’ll clarify these reasons and take you in on our second setup of the support structure.

Keep in mind the original problems we had to tackle to improve our support initiative:

1. 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.
2. People keep working on the same project over and over again which can become kind of tedious in the long run.

Problem description

Since the launch of version 1, we experienced some difficulty in realizing this plan. This was mostly due to the fact that people are outsourced, being unavailable at the office, or inability to get people away from the customer to take on the job of support member at JTeam. Depending on the customer, it is rather difficult to tell/ask a customer that our ‘empowering’ colleagues working on their project should return to the JTeam office to handle support issues.

Secondly, it is a big risk for JTeam to have three people working on support, situated at JTeam HQ, with the risk of not having any support call to handle. They can fill up their time with researching innovative technologies or writing blogs, all also *very* valuable for JTeam, but they don’t do any billable work. Eventually this will simply cost too much money.

Third, mainly because of the first point, a lot of the same people were assigned support duty, which made the knowledge transferring requirement obsolete.

Solution II

(code name : only the lonely)
To solve the availability problem, we changed the process in a way that availability is not an issue anymore. In this version, one person, each week, a whole week, will function as the first contact for support calls. This person will gather all support calls and might directly know how to solve the problem or checks if a solution is already documented on our company Wiki (Confluence). If so, this person can help the customer immediately. If not, the call will be forwarded to the team of people knowing the most of this project. It is the responsibility of the support person to check up on/manage the person handling the bug. The Project Manager of this project can do this as well, but it remains an important task of the support person.

In practice this means that the first contact will listen to our support email address and picks up issues from there. If this person fixed it, and thinks the solution to this problem is handy for reference, he has to document it on Confluence, so the next person scheduled to be first contact can benefit from that information in the future.

But…how do we let the customer contact support?

Project managers will still receive emails and calls from customers, since they are used to calling a specific person. And they should. The development team can change, but the customer needs one contact person which knows about their functionality and can help them with requirements and decisions. In this case, the project manager takes note of the call/email, maybe already answering, and forwards the support call to the support member for further handling.

Since, as a support person, you only have to listen to the support email address, people who work at the location of a customer, can also function as the first contact. To the customer will be communicated that it can happen that you have to answer some emails, or put other people to work. For the customer, this is more acceptable, then having a member of their development team, leave the team to be at JTeam for three days to handle support. As was the purpose in version 1 of our support process.

Next to the above process, we also have some technical infastructure to facilitate our support process. Problems that are issued by email, are directly and automatically logged into our issue tracking system Jira, so the customer and the development team have a reference of the problem at hand (see a future blog post about the Jira setup).

This way of work allows us to make a planning upfront for the person who is going to be the 1st line helpdesk person for what week. Depending on the internal vacation schedule we planned a week for everyone. The schedule is publicly available, and rescheduling is always possible if it is mentioned upfront!

Transferring knowledge

So, if a lot of support calls are still assigned to the person with already the most knowledge of the project, how do we address the knowledge sharing and transfer issue? Not one person should have all the knowledge of the project! You’re right.
Well, to solve this, when new features are to be created for these support projects, someone who is available will be pointed out to pair program / learn from the master himself. This way knowledge is transferred and more and more people will understand the code of the project, so every time even more people can pick up issues for this project.

Knowledge transfer is important. If, in the team planning meeting, we know that some work on new functionality is planned for a support project, we will check to see if someone with less knowledge of that project is available to learn from the person who is implementing the new features. This can for example mean, that people that work at the customer 4 days a week, will work on some new features of a support project, the day of the week they are at JTeam. This way everyone will be familiar in a way with the projects at JTeam.

So…

this is the plan for now and is currently used at JTeam. As a true agile and pragmatic company, we’ll evaluate in a couple of weeks and review how this worked out in practice. If our structure is being modified I’ll let you know of course !

Any remarks and suggestions about our current support process, or other ways of implementing a decent support structure, are more then welcome.

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:

1. 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.

2. 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?

Before we move on, let’s get the terminology right. Erik van Oosten rightfully commented we might have to start using the terms fixed-feature and fixed-term on top of fixed-price. To take it to a bit more general level, in a project there are three basic variables: a collection of features (or scope), the deadline (or schedule) and the budget (or resources). I’m specifically naming them scope, schedule and resources as these are the exact same terms Scott Ambler came up with in his article titled The Broken Iron Triangle Software Development Anti-Pattern. In his paper, Scott argues that ‘refusing the recognize the implications of the iron triangle’ is ‘one of management’s more popular approaches to hamstringing an IT project’. He goes on to say ‘we really need to question the ethics of “fixed-price” IT projects‘, which confirms what we’ve already settled upon.

The next thing he says (and this is completely obvious, if you’ve ever encountered an agile project done right) is you should be prepared to vary one (or even two) of the factors involved. Vary the scope, schedule or the resources that is, based on what you encounter during a project.

That’s nicely said and all, especially if you’ve won the client’s trust already, but what are you going to tell a customer that has a budget of say €100k for which you’ll quite likely implement something nice that suits his needs. The client puts out an RFP and invites three suppliers to answer to the RFP. You now it’s best for the client to end up in a situation where in cooperation with the client you can vary either scope, schedule or resources, but you have to win the client’s trust first.

I think the answer lies in the response to the RFP plus a certain amount of risk you’re willing to take as supplier to win this deal and this is where the list of contracts comes in that I got from Martijn Dashorst of Wicket fame. The list, by Alistair Cockburn provides various options for drafting a cooperation between the client and the supplier, varying from fixed-everything to fixed-nothing.

I’ll be digging through this list in the coming weeks to see if there’s anything usable. In the meantime, one thought I had was to be upfront with a potential client and offer him the various options for drafting an agreement (or at least, the ones we feel comfortable with). I’m not sure this will work in all scenarios. There are plenty of RFPs for example that require you to come with a response without being able to discuss possible directions with a client (how weird that may sound).

This is why I’ve been reading up on what others have to say about this subject. What I found was pretty interesting and I’d like to share my findings with you and also reflect a bit on these findings.

Are fixed-price contracts evil?

Generally speaking deals where for a fixed amount of money a project will be executed result in the client having no or little incentive to accept the project as being done or complete. After all, broadening or changing the scope of the project can be done at no cost, since the price has been fixed at the start of the project. The risk is entirely at the supplier side.

Naturally the supplier wants to minimize this risk, so usually demands or forces the customer to be very precise about the scope before the start of the project. In addition he asks for changes to be done using change requests, which subsequently are charged at a certain rate.

In his turn, the customer then puts as many feature in scope as possible, thinking that if he does so, the chances will increase that the features he really needs are among those in scope, hence not needing any change requests.

The end result:

• Way too many features initially in scope, many of which will be left unused in the end product
• Too much time and money spent on these features
• A situation where the customer is encouraged not change his mind too much
• A situation where the supplier is not encourage to think along with the client during the process as this again results in change

In other words: fixed price deals result in fix bid projects where both budget and scope are tightly controlled and change is kept to a minimum.

We’ve all concluded in the past that agility and flexibility during a project’s execution is something that’s desirable. Given this and the above, fixed price deals are not the way to go if you want agility and flexibility.

So, what is the answer then?!

So if we know that fixed price contracts are not the solution if projects that accommodate change are a desirable thing, what contractual agreement should be used? Well, this is a question not easily answered.

Seth Schubert states things very elegantly in his blog entry on {codesqueeze}:

It is very difficult to arrange a contractual agreement that accommodates change. At the end of the day, your client’s accounting department is going to want to know how much the project will cost, and when they can expect to receive working software.

A bit further on Seth states that

a client will tend to perceive a fixed bid contract as less risky. By controlling the scope and budget in a project, the client’s stake in the project are seemingly protected. The risk of project failure by defining scope to early is not altogether intuitive or obvious.

He talks about the exact risk that we identified above. The risk of implementing too many or useless features, the risk of the supplier not thinking along with the client to prevent him from running into pitfalls, et cetera.

Next, Seth states that:

Even when presented with this information, a new client may still may be unwilling to enter into an open ended contract.

This is what it comes down to: having no prior relationship with the supplier, customers often simply cannot relinquish control over either budget or scope right at the start of a new project. To some extent, I find this completely understandable; after all, how can a customer trust the supplier in his doing the right thing? It’s the first time he’s met the supplier.

Based on this, the question still remains: what contractual agreement makes it possible for the customer to let go of budget or scope in the long term?

There’s in fact plenty of research out there and examples of contractual agreements that facilitate this, some of which I might highlight later on. For now, we’ll first discuss some of the alternative at JTeam and see which ones are suitable for our practice. I’ll report some more of my findings later on.

In the meantime, if you have experiences in this area, you’re obviously more than welcome to share them here .