How do you work around a production team that is distracted by support tickets and micro projects?

Question

I need some guidance on this project management situation.

I have a software team with 4 developers, 1 QA analyst, and 2 part time student interns.

I have several projects where the owner has over-promised on delivery milestones that cannot be moved. I have 5 large projects currently ongoing, with one project requiring 3 staff. I am juggling this while also being hit with micro-projects like 4 hour copy updates.

It's a challenge but with the sharepoint project web app and TFS I am getting though it, but I just can't figure out how to deal with support tickets that well.

We currently have 2 large projects that we have shipped and we are getting 3-4 hour support tickets every couple days. I can plan for a developer to complete a 16 hours of work over 2 days, but then suddenly they are taken away for a critical bug for 4-8 hours. This happens quite often and is causing just about everything to be late.

I was wondering what process you would recommend to plan for these interrupting and unplanned support tasks while still trying to hit planned milestones.

Answer 1

This is a classic management problem; trying to use a single body of resource to handle both time-based planning-driven work and ad-hoc unpredictable event-driven service requests. Unenlightened management love to get the fixed-plan project teams to "just do a little bit of support" as if time can be summoned magically out of nowhere.

I have personally had to manage this kind of problem twice in my career and in the end I deduced that there is only one possible way of doing it:

You have to ring-fence resource to handle support requests, leaving you light on project resources and then re-plan accordingly. In other words extend the project delivery timescales to take a reduced resource pool into effect.

That still doesn't quite solve the problem because, by their very nature, support requests are ad hoc, therefore you could still swamp the ring-fenced resource. When this happens you have no choice but to cover the support, to the detriment of the project. But the risk of this happening should be estimated and entered into the project risk log. Then when it happens make the project risk into an issue that affects the project schedule. This way you are calmly handling the situation instead of painting yourselves into a fire-fighting corner every time a new unforeseen support-style request comes in.

The battle is always getting management to agree to taking resource from project teams and ring-fencing it against support issues, however if you begin tracking time spent on development vs. time spent on support across the team you will have numbers to point to.

Answer 2

I don't have an answer beyond the very simple - you must either

• De-scope the projects
• Limit the support
• Extend project timelines
• Increase resource

Note that I said the answer is simple, getting management buy-in or understanding is considerably more difficult.

Since you have indicated that none of them are available I would suggest you only have one option left; protect yourself and your team with data.

I would record every aspect and make sure it is presented as a data-driven proposal. Management find it very difficult to argue with raw data when presented correctly. You must protect the reputation of yourself and your team; it is one of the only currencies a successful PM has to trade.

Ensure your risk log is updated daily and signed-off or validated at the highest level. If you have one escalate to the Programme or Portfolio Board. Ensure that all minutes of meetings have recorded your objections, constraints and advice.

Propose the changes you need to ensure successful delivery then present the management team with a range of limited options. Explain that the status-quo will result in project delivery coming under severe risk.

Do not accept a poisoned chalice of a project simply because it was foisted upon you.

Lastly, good luck.

Answer 3

Similar to above you could try a couple of things -

First , set a set % available for the resource time. For example if you have access to timesheets then you should try and come up with historical data and use that as basis for resource allocation for new projects.

So, if you find out the resources spend 30% on average on other tasks then the resource availability of all the resources should be 70%.

Second, make it clear in the project initiation or business case or any document you use to initiate a project that the resources are not FULL TIME.

Hope it helps.

Answer 4

"I was wondering what process you would recommend to plan for these interrupting and unplanned support tasks while still trying to hit planned milestones."

As above posters have pointed out, there is no process that will give you extra time. But if you are looking for a lean process that is well tuned to your particular work environment, Kanban may be a good fit.

Kanban will not help you hit your planned milestones more or less than any other process, but it has the following benefits:

1. Minimal documentation
2. Work chunks are usually small; broken down into 4 hour to 1 day increments.
3. Allows just in time changes (ready work can be re prioritized at any time)
4. Forces rapid/formalized team communication on changing work priorities through Kanban board
5. Contains a mechanism (WIP rules) to manage context switching and the efficiency loss associated with it.
6. Limits multi-tasking

That said, adopting Kanban requires a lot of team discipline as well as commitment to transparent communication. Kanban fails quickly if team members do not communicate the status of their work or feel they have ownership over certain types of work or domain knowledge.

Answer 5

It seems inherently silly to have a fixed number of resources, fixed deadlines, unpredictable or fluctuating demand on ad hoc support, and fixed project scope with an expectation of high quality. We all know it does not really work this way. We can fix a couple of the variables, but the rest will move as result...and management knows this.

They also know that when they give on one of those variables, such as slipping the deadline out in order to provide relief on development, then that increase in time will be all used up with imminent complaints that the team needs even more time. They can add more resources, increasing costs, but the complaints of needing even more will start soon enough. Parkinson's Law.

I like both Marv's and Venture's ideas. But I also think you need to reframe this problem as a management challenge in that what they are looking for is a can do attitude, best efforts, creative out-of-the box thinking, and let your results hit where they come in, e.g., you will be late on some projects, you will miss a few SLAs from time to time, you may miss a quality spec every now and again. But as a good PM you will escalate these risks and issues early and often, keeping everyone aware of normally occurring obstacles we face everyday.