I work for an IT shop with a total of 100 people, but my small dev team consist of a total of 12 within IT. My struggle: The group is responsible for the development, deployment and last line of defense support for almost 700 end users. The team spends a large majority of their time doing ad-hoc support and very little on dev work. It typically has to be squeezed in b/c the actual support team has not gotten up to speed on all the products. Also, project request can go directly to my team members and not funneled through a standard process.. why? well, it's all about the squeaky wheel at this organization and who screams the loudest.
I'm interested in understanding are there other people who have had similar situations and how did you go about handling the problem. I've talked about putting a PM on all projects and having all request funnel through me including ad-hoc request but I've only been there for 2 months (don't want to make a drastic change, but my team is getting overwelmed and they need focus) hope this makes sense.

US41's picture

You're a manager so make a plan and present it. Make it brief - just three or four slides max. Define the problem visually (not using UML or anything - think marketing). Show how your organization will look with project managers on it and define the process. Name the process.

You are in the perfect position to not only make a proposal for organizational change but to also lead that change. You know what to do. Why are you hoping someone else will do it and rescue you? Get up and go rescue your people by assuming leadership over the entire process.

I'd have an organizational chart on one slide showing my PM's, my tier 1 support team, my tier 2 team, my designers, my developers, and my qa people. I would have another slide with a horizontal timeline showing the major milestones (no more than ten) in SDLC I was going to use. I would set up gates for projects to pass through those gates.

Then I would have a slide showing the headcount I need to perform these tasks and run this organization with cost projections. I would go out in advance and find out if any customer groups are able to help fund this team and help me stand it up.

Keep doing O3's. Start positive feedback per the rolling out the trinity podcast. But start your planning and proposals now. 1Q09 is a great time to make a change. You can do this and the timing couldn't be more perfect: new on the job, 1Q coming up, and a company that doesn't know how to do something you do.

BJ_Marshall's picture
Licensee BadgeTraining Badge

I agree with US41, and I'd like to add a couple things to make sure you know what you need to do. (And then, yes, get up and go rescue your people.)

You've only been there two months. You're still in the first 90 days stage of [url=]fi..., fit-in, fit-in[/url]. Have you [url= to all your stakeholders[/url] to find out what it is they want, need, and measure from your team?

Questions pop up in my mind like "what's up with the actual support team, that you need to pick up their slack?" and "What do your upper-ups want from your team, considering that maybe they DO want you to also do ad-hoc support and not just dev work?"


stephenbooth_uk's picture

To me, having worked in similar environments in the past, this sounds like 2 problems.

1) The dev team is also 3rd line support (nothing unusual about that, actually it's pretty much ubiquitous) but 1st and 2nd line support (*) are just passing calls straight through.

2) Lack of change control or formal process for submission of change requests.

I think US41 and wmarsha1 have handled #2. The thing I'd add is maybe take a look at ITIL or PRINCE2/PMBOK. Possibly use or adapt the change control methodologies from those. ITIL tends towards production/service environment where as PRINCE2 and PMBOK are more project oriented, go with whatever fits you better.

You might also want to look at getting some business analysts in or train up some of your existing staff in the discipline to make sure that requirements are gathered and analysed correctly before you develop the software.

Problem #1 is probably more difficult as it involves something outside of your control, the support team. Could you suggest putting in place an agreement that defines both resolve time targets and processes for the management and recording of issues. That won't solve the initial problem of calls that should really be handled by the support team (i.e. 1st and 2nd line support) being sent straight to 3rd line (i.e. your dev team) but it will provide a vehicle for tracking and reporting on the issues that are being directed to the dev team. If you can identify the calls that are really more 1st and 2nd line then you can analyse why they are getting passed through to dev and suggest remedial action. Such action might include developing a knowledgebase of known issues and workarounds, training for support staff, call analysis. These can also feed into software and documentation development, if a lot of calls are being generated from a particular module then perhaps that module could use some improvement or the documentation could be improved.

You might want to take a look at the call management system your support staff use. Many include a knowledgebase system and will also support management of change and requirements. Populated and kept up to date this can be very helpful in prioritising changes ("Change A will prevent 10 support calls a week, change B will prevent 1,000 support calls a week for the same amount of development effort . We'll do change B now and change A when we have time.") and linking changes to requirements to calls ("In the past 3 months we've had 3,000 very similar support calls in Module Q. On analysing the calls we discovered that the functionality doesn't do what the business actually needs so created requirements A59 and A60 which we then agreed with the business. Change G will implement these requirements."). Once you can do that justifying your team to senior management (who may not know about IT but probably know quite a bit about the business) becomes a lot easier as you can link your development effort to business delivery and therefore the bottom line ("X weeks of development effort at a cost of $Y lead to a 20% increase in through put allowing us to take on extra business so adding $YY to our profits."), it also looks good on the resume.

Again, take a look at ITIL and consider adopting or adapting some of the processes. A major caveat with ITIL (and PRINCE2, probably PMBOK as well) is that, like many standards and 'Best Practices', if you try to implement it as written then you'll have a failure on your hands. A really well documented failure but a failure never the less. Study it, identify the bits that are useful to you, adapt them and implement them, then throw the rest out.

You say that the support team haven't gotten up to speed with some products, if these tend to be in house developed products then perhaps you need to look at your handover procedures. An important but oft missed step in handover is making sure that the support team are able to support the product. One company I worked for, a 70 person software house with about 25 developers/testers and 15 support people, had a system where at all times one or two support people (depending on the volume and scope of work in the current release) would be assigned to dev, mostly to do testing and initial documentation QA (final QA of the documentation would be done by the Training section). When a release was made the support people who had been in dev went back to support and one or two of their colleagues joined dev. This rotation, plus the odd dev person doing a spell on support (typically the first couple of weeks after a release had gone live) and other support people who had been pulled into testing on an ad hoc basis, meant that there was at least one support person (usually two or more) who had in depth knowledge of the new release and could back up their colleagues when the calls came in.


* 1st line typically means a known issue with a known workaround that requires no analysis, or a standard software install. The stereotypical "Try turning it off and back on again" is a 1st line issue work around. A 2nd line issue typically requires some analysis to identify the problem and/or develop a workaround, e.g. identifying what patch to apply or setting to change. A 3rd line problem (note change of term from 'issue' to 'problem') will typically requires a change to the program code or configuration, hence 3rd line support often being within the development team or at least co-located with them. I'd expect that when a call arrives at 3rd line there's already a significant amount of information attached as to the workarounds that have been attempted and the analysis done at 2nd line.

DrMaltz's picture

Thanks everyone for your replies. We actually have implemented ITIL and a call tracking system. So, the infrastructure is already in place.
I guess from my perspective I do know what to do but not sure of the best way to go about it politically.. For example, our customers.. call my developers directly to help them resolve issues. Possible solution: Direct developers to push those calls through the helpdesk. A. This will help us track the issue and it's exposed to more than the developer.

jhack's picture

All calls should go through the help desk. You can't measure call volume, time to resolve, issue counts, and other metrics unless they are all following the same process.

Our firm has a specialist who handles escalations: if the standard help desk can't resolve, he reviews (and sometimes resolves himself), and decides which developer should work on it, or if it should go to field services. It's a great role (he was voted "Employee of the Year" a couple years ago).