Balancing project work against support

Soldato
Joined
31 Dec 2003
Posts
4,647
Location
Stoke on Trent
I'm an IT manager, everywhere I've worked I've had a battle to maintain BAU support whilst project managers try to use my team of engineers to work on their projects, Create new systems, install new stuff etc.

The best state I've been in organisationally is keeping a track in a basic excel spreadsheet of which engineer is working on which project, including working on our own stuff (upgrading IT systems to keep up to date etc) and refusing engineers to project teams unless they can argue with senior management that their project is more important than another project.

I denote IT stuff which cannot move, e.g. working on replacing SSL certificates which are due to expire, then I refuse the project team that engineer for that period of time.

I can't be the only one who's had this struggle, I'm curious as to how you've tackled this problem, what works for you?
 
Soldato
Joined
18 Oct 2002
Posts
6,365
Location
Bedfordshire
BAU and SLAs come above all else. In relaity though it's not always as black and white as that.

I think it's quite a common problem and I've been at two places now where they have broken out into two seperate teams for build and run.
 
Soldato
OP
Joined
31 Dec 2003
Posts
4,647
Location
Stoke on Trent
BAU and SLAs come above all else. In relaity though it's not always as black and white as that.

I think it's quite a common problem and I've been at two places now where they have broken out into two seperate teams for build and run.
That's one thing I'm tempted to do. It's then a black or white matter for the project/build resource as to whether they're available or not.
 
Soldato
Joined
18 Oct 2002
Posts
4,515
Should have a service desk team and an engineering team, unless your company is tiny.

Engineering should only do BAU if there is no project work, or as last resort if service desk is struggling.

Reality is very different to this in most places though.
 
Soldato
OP
Joined
31 Dec 2003
Posts
4,647
Location
Stoke on Trent
Should have a service desk team and an engineering team, unless your company is tiny.

Engineering should only do BAU if there is no project work, or as last resort if service desk is struggling.

Reality is very different to this in most places though.

I do have a service desk too doing bau, but I'm mainly referring to 3rd line server guys who help projects by creating services, integrating services etc. They also have important bau to do like ensuring servers don't fill up, watching for unusual CPU usage, checking backups, testing DR etc
 
Caporegime
Joined
18 Oct 2002
Posts
26,052
It doesn't answer the question but why do you have 3rd line guys making sure servers don't fill up, checking CPU usage etc. - that should be handled by a monitoring platform that has sane alerts set.

Same with replacing SSL certs, it should all be scriptable and if it isn't then you need to work towards using CAs and services that can have things like SSL cert renewal automated so that the load on staff reduces over time.

Generally speaking, your service desk team (excluding maybe team lead/managers) should be aiming to get away from the service desk, and it's better for your company if they achieve that by getting promoted away into more of an engineering role, and if that engineering role involves getting dragged back onto support duties on a fairly regular basis then they will start to look elsewhere for that promotion.
 
Soldato
OP
Joined
31 Dec 2003
Posts
4,647
Location
Stoke on Trent
It doesn't answer the question but why do you have 3rd line guys making sure servers don't fill up, checking CPU usage etc. - that should be handled by a monitoring platform that has sane alerts set.

Same with replacing SSL certs, it should all be scriptable and if it isn't then you need to work towards using CAs and services that can have things like SSL cert renewal automated so that the load on staff reduces over time.

Generally speaking, your service desk team (excluding maybe team lead/managers) should be aiming to get away from the service desk, and it's better for your company if they achieve that by getting promoted away into more of an engineering role, and if that engineering role involves getting dragged back onto support duties on a fairly regular basis then they will start to look elsewhere for that promotion.
I agree with your service desk point but don't you agree with the need for BAU 3rd line? Like doing stuff 1st and 2nd couldn't do
 
Associate
Joined
2 Sep 2010
Posts
2,031
Location
Somerset
At our place (NHS IT Team covering many hundreds of GP sites), there is first line (service desk), second line (me, desktop support) and then technical architecture (servers, networks etc). Basically, BAU comes above all else for all teams. If people go off ill or an influx of calls come in, tools down and man the fire hoses. The team I am in covers all of Somerset, there are 4 of us and we have to do BAU and project work. We just split into teams to do projects and BAU consecutively unless **** hits the fan.
 
Soldato
Joined
25 Nov 2004
Posts
3,792
At our place it feels like UAT is king. The business is so focused on getting new (read as income generating) functionality in that BAU and project work often suffer. NHS too. I'm 3rd line Infrastructure and Cloud Architect and spend most of my time supporting systems our 2nd line should be doing but somethings gone horribly wrong along the way and they have hired people who need reminders to breath let alone know how to support systems. I really need to leave lol.
 
Associate
Joined
12 Sep 2006
Posts
758
There’s that whole ‘continual improvement’ piece that gets lost - ie the stuff the BAU guys (should) be doing when nothing is broken…
 

Ev0

Ev0

Soldato
Joined
18 Oct 2002
Posts
14,152
I agree with your service desk point but don't you agree with the need for BAU 3rd line? Like doing stuff 1st and 2nd couldn't do

I don’t think he’s saying there’s no place for third line BAU, more that the examples given seem a bit ‘low skill’ (can’t think of best wording here!) for third line work.

Checking disk space, cpu etc is really third line? (Ignoring the other point made that those sorts of things should be automated)
 
Caporegime
Joined
18 Oct 2002
Posts
26,052
Yeah basically. I know if I was looking at jobs and what was basically a deployment engineer (the closest guess I can make really for what you’re doing) was also getting tasked with making sure a servers hard drive wasn’t filling up I would start to wonder how much of a dead-end that role was likely to be career wise.

I’ve not worked anywhere that the internal IT team and the customer-facing engineers/consultants are the same pool of people, it’s a bit weird.
 
Soldato
Joined
21 Jul 2005
Posts
19,981
Location
Officially least sunny location -Ronskistats
Refreshing reading this. Glad others are out there thinking/experiencing similar.

The team I work in originally was tiny so it was just firefighting and frustrating. Still small compared to huge companies out there but proportionally unless you have a bloated abundance of IT resources, there will always be a struggle to cover BAU yet deliver projects. If you can strike a balance then you have done well.

Between covering for holiday/absence, and churn if people leave you can blink and time has flown.
 
Soldato
OP
Joined
31 Dec 2003
Posts
4,647
Location
Stoke on Trent
Yeah basically. I know if I was looking at jobs and what was basically a deployment engineer (the closest guess I can make really for what you’re doing) was also getting tasked with making sure a servers hard drive wasn’t filling up I would start to wonder how much of a dead-end that role was likely to be career wise.

I’ve not worked anywhere that the internal IT team and the customer-facing engineers/consultants are the same pool of people, it’s a bit weird.
I think the source of confusion is perhaps that you're talking about a managed service provider. I am describing my customers as internal staff at the company I work for. The public are my companies "real" customers.
 
Soldato
OP
Joined
31 Dec 2003
Posts
4,647
Location
Stoke on Trent
Refreshing reading this. Glad others are out there thinking/experiencing similar.

The team I work in originally was tiny so it was just firefighting and frustrating. Still small compared to huge companies out there but proportionally unless you have a bloated abundance of IT resources, there will always be a struggle to cover BAU yet deliver projects. If you can strike a balance then you have done well.

Between covering for holiday/absence, and churn if people leave you can blink and time has flown.
That's what I'm trying to figure out; I'm sure someone must have cracked it who can give some pointers.

At the moment I'm adding loads of contingency in the tasks the project managers set and keeping 1 (ideally 2) staff out of the project rota completely to focus on BAU And it's greatly improved. The problem I've had Previously comes when the BAU staff dont have time to do the stuff which keeps the lights on as they're busy with projects (which always take longer than the pm thinks) like full up disks, renew SSL certificates, upgrade from old operating systems etc
 
Soldato
Joined
21 Jul 2005
Posts
19,981
Location
Officially least sunny location -Ronskistats
That's what I'm trying to figure out; I'm sure someone must have cracked it who can give some pointers.

At the moment I'm adding loads of contingency in the tasks the project managers set and keeping 1 (ideally 2) staff out of the project rota completely to focus on BAU And it's greatly improved. The problem I've had Previously comes when the BAU staff dont have time to do the stuff which keeps the lights on as they're busy with projects (which always take longer than the pm thinks) like full up disks, renew SSL certificates, upgrade from old operating systems etc

Sounds so familiar. Until we recruited two extra technicians I was struggling to get away from helpdesk and BAU. With the two techs who man the level 1 rubbish I find I can blast into projects much more. You do however need time to cross train colleagues which is another area that can slip if people dont make time.

I think I have wrote guidance/notes/instructions for 80% of the stuff and find I can burn out (gets boring too). Once managers know your good at it you have to be careful its not pinned on you. Case of expressing that colleagues need to muck in and they will only get better if they contribute... then I can get round to automate more stuff!! :)
 
Man of Honour
Joined
4 Nov 2002
Posts
15,508
Location
West Berkshire
I'm a fairly senior dev but still do some BAU stuff, though most of that is keeping *our* lights on (e.g. CI and test environment maintenance) - except when I get seconded out to the team I used to work for nearly 10 years ago to fix their stuff! I actually don't mind - its nice to take a break and do something completely different occasionally.

Thankfully our helpdesk does a good (and often under-appreciated) job keeping customers happy. I've been on support calls with customers, and even done site visits, but they're very rare (last one for me was over 10 years ago, but others in the team have done them more recently).
 
Soldato
Joined
3 Dec 2002
Posts
3,996
Location
Groovin' @ the disco
It really depends on the size of the org.
Here's my explaination of current and past two roles in companies of different sizes.

Company 1; was an elite small team which specialised in different areas but "should' have enough skills to cover for members being off. This worked well; I had to cover everything from helpdesk to development of servers. The issue that I or we had was that the management changed and lost it's backbone, in fact I; personally felt insultanted enough to leave as my role was treated and said to be a helpdesk role then next meeting I was being moan to about a system not being developed in time.

This only really works in small orgs with less managers/VIPs and they need to understand where they are in the pecking order. The more staff that expect/get preferential treatment for incidents the more water-down the service becomes.

Company 2; there was no official dev and ops selections for my area of the IT department, we used a lot of third parties including people from different areas of the department for dev, so I guess I would be part of the ops teams who was a stake holder and had a major say in how things should work. Incidents/requests was dealt with by first and second line. My BAU was security, checking over dev implementation, writing KB/Doc/Known issues, declaring/resolving/documenting known promblems, coms with the dev members, supporting 2nd/1st line, training and CAB.

Company 3; I'm rather new, but it's split internally between dev and ops, I'm in the Ops team; we have individual roles even in the sub-sub teams but it's similar to what I do at company 2, but with other stuff like going live with new systems.

Personally; I hate the term BAU... Business as Usual for one company, IT department, Team, Person is different for another...

I would check the service catalogue; this should be the bible.. so that it's clear which person/grade deals with what request/incidents.

My believe is
1st line: Advice, hand holding, most requests (if not automated), issues that don't require admin rights or issues that are well known that do require admin rights.
2nd line: Troubleshooting/resolving, draft KBs, harder to deal with requests and some project work to help development of staff.
3rd line: Security, helping other IT staff, Documention/KBs (pref done by the service owner or the person who setup the system), Training, project work, problems, demands/new services and changes.

You may find that 3rd line has a lot less incidents/requests to deal with and more time for projects/demands.. rather than fixing the end users issue, write a kb or train the 2nd liner how to resolve the issue, so that issue should get to 3rd line again as it can be refered to the KB or person.

There needs to be a "experinced" person or people at each level for people to turn to for help; grade 1.5/2.5/leaders/manager; it's horrible for someone not to have somewhere to turn to when they need help. In large orgs; some systems (and hate to say it "local knowledge") will be available to 1st liners that 3rd liners don't have or the experince in using, so even 3rd liners will need to reach out to 1st line to check something. Those people should be identify and recognised/paid.

As for the actual OP question... how to manage 3rd line time.
It depends on your staff... I'm happy to take an hour towards the start and end of the day to resolve/refer incidents.
it may be that you have one 3rd liner per day/week/month dealing with nothing but BAU and helping staff.

Have Gnatt charts of whos working on what; to a low level.. this person is working on this part/issue of the project, and have BAU as part of the Gnatt chart.

Roadmaps to show what the team is planning to be doing in the future and the time scales that is required.

and I hate to say it... time sheets.. as long as your staff can show that they are busy and you can show your paymasters that they are busy with the time sheets and gnatt charts, if they want more doing; they need more IT staff.
 
Man of Honour
Joined
4 Nov 2002
Posts
15,508
Location
West Berkshire
Time sheets are one of my personal bugbears, but a necessary evil when the taxman comes calling (research write-offs). As for Gantt charts? That's all very waterfall model. Time to get with the kids and be agile! :)

Seriously though, it may be worth collecting some metrics for what's actually happening and/or looking at alternative tooling. Excel is acceptable as a high-level planning tool but there are better options that could give you visibility into how and where time is being spent. For example, we used XPlanner for a while (free, open source) before moving on to commercial tools. Theoretically, many of those sorts of tools are geared more towards agile but we're somewhat hybrid and they're still usable. The dreaded time sheets can help too. Best not to overdo it though - if you're spending more time planning than you are doing, you're definitely doing it wrong!
 
Back
Top Bottom