How can I organize an on demand Support Team for a customer-facing project?

Question

I want to manage a team which developers themselves now support the software produced. Developers are the only people who know how to fix the problems.

The problem is that when something goes wrong the customer calls me as PM and want me to solve the problem asap. Sometimes I try to fix it myself and sometimes I should find other senior developer to solve it. And this is bothering especially when I (or the developer) am at home or on holiday! In most cases the problem cannot be postponed to the next working day and should be fixed immediate. Some can be solved temporarily (for example by resetting the service) and some need more knowledge. Now I think a support team is needed but I don't know how to define the roles. What they should do ? What they should know about the software ? Should they have the knowledge like developers?

Answer 1

If you can justify a support team, this will help your development effort by reducing the impact on them, as well as (hopefully) providing a better experience for your customers.

The support team should have:

• Access to as much documentation as possible, including outline and detailed designs, screen layouts, etc. These artefacts must be up-to-date and correct, otherwise they are useless - possibly even misleading and harmful. After the initial handover from developers, it is up to the support team to ensure that these remain up to date;
• Access to source code, an awareness of the coding standards used, and knowledge of using whatever language(s) the system is written in;
• Agreements with the developers over roles and responsibilities. Do the support team make software changes to fix bugs, or not? (I would prefer not, as the developers should be the only ones making changes, to ensure integrity, version controls, etc).
• Given my previous comment, the support team may require access to development resources, perhaps on a rota basis rather than always calling out the PM;
• The support team also needs to have a relationship with the customer. After all, they will be the point of contact at weekends, overnight, or during holiday periods, and they should know what the customer does, what his hot-spots are, and enough about his environment to be able to make suggestions for resolving problems without always making code changes at 3 o'clock in the morning.

Answer 2

welcome to PMSE!

It isn't clear how you 'inherited' this maintenance project... The takeover from the development phase to the maintenance phase is a vital part of the process - in ITIL it's the Service Transition phase; Really worth to take a look! - some definitions are important to be highlighted:

• Define a Grace Period: There's a Grace Period after the Go-Live where the Dev team support the project. If the project just went live, you can reach an agreement with the development team to define this period. Based on your project load, you can have specific agreements. Ex.: Your project has a higher demand in a specific period of the month. You can have an agreement between parts to have a Grace Period enclosing 1 full month plus 6 month-ends (if the month end has the higher load).

• Define a Knowledge Transfer agenda: Once the project is live, the knowledge needs to be shared across the maintenance team. A proper knowledge transfer plan (including all the documentation) is a must.

• Define SLAs with key users: In order to know if your maintenance if on track or not, you need to know how much time you can spend in your investigations. To clarify this, you can have a Service Level Agreement between you and your client. The client will always push for support as fast as possible, that`s normal. The bottomline here is to clearly define boundaries to ensure that if a support is required during weekends / holidays, both sides agree on the service (and of course, on the costs).

• Define support roles: You need to know what's the level of knowledge is expected from your team. Eventually the dev team will also support the application, the important point is to define which issues are expected to you guys take care of, and which ones must be forwarded to the dev team. To make things easier, both you and the dev leads can sit and draft the a top service request catalogue. Based on this catalogue, you look for an agreement of what belongs to your support, what belongs to dev. Notice that the dev team must provide the details to solve issues, I believe isn't logic to throw bunch of people into a new project and have them digging the code for something that a developer could answer in 2 minutes.

In case you're interested in more details about how to proceed, I'd strongly suggest you to take a serious look at ITIL... it will worth every minute you put on it.

Success!

Answer 3

The Support Team should have all the knowledge and access required to solve the problem.

While this sounds vague - in my opinion and based on my experience it's quite easy to implement (and there is a lot of possibilities). The methods I have experience with are:

• Throwing support member into the problem and control him until he/she learns to do the job
• Preparation of support knowledge base after solving problem using current resources

The first method is more expensive (You need to spend full wage even before the support member is capable to answer the calls), but is much faster to implement. From my own experience support request can be categorized using Pareto Principle, and those 80% of the problems can be taught pretty quick.

The second method is cheaper, but on the other hand takes much longer to implement. Preparation of support knowledge base takes time and need to be verified before it can be handed in form of manual to new support member.