"I mean, it’s all about value to the client. A client comes to us for a support contract because they don’t have the technical capability or they don’t have the capability in house to do it but the websites are important to the running of their business so they need the confidence that, should things go wrong that we can handle it in an appropriate time." – Janusz Stabik
Barry O’Kane: This is Episode Two of Season One. Welcome back. Season One is all about the long haul. We dig deep into building long term client relationships, recurring revenue, repeat business, referrals and more. Everything that’s vital to building an agency that not only survives but grows.
In this episode, we dig deep into the practicalities of providing support and maintenance services and learn the powerful lessons from the success of Bristol based agency, Mayfly. I hope you enjoy the interview.
I’m absolutely delighted to have Janusz Stabik here with me from Mayfly Support. Hi there.
Janusz Stabik: Good morning, Barry.
Barry: So, just to start us off, why don’t you introduce yourself and tell us a little bit about yourself and Mayfly?
Janusz: I’m the MD of a company called Mayfly Media based in Bristol. We’re a digital agency. We’re quite technically focused. So, we specialise in the provision of websites built predominantly with two content management systems. That’s Umbraco and Sitecore.
There’re kind of two arms to our business, really. We’ve split the business in two. One side focuses on project work, so, building a new website from scratch including the user experience and the creative work and then the technical development integration. And then the other side of the business, Mayfly Support, specialises in supporting those websites with different types of models and contracts and billing methods.
I guess we realised quite early on that managing a client who needs support, the process, the SLAs, the contracts – I guess the whole management of contracts is very different to the way you would manage a project. Hence our, kind of, dual offering and why we have the Mayfly support brand.
Barry: I think that’s brilliant. I really like the split between – the way you’ve differentiated between the project work and the different service offerings you have there. Before we dig into that in a little bit more detail, can you tell us a little bit more about Mayfly? How big you are and how long you’ve been around for and the kind of clients and work you do?
Janusz: Sure. So, we’re 15 strong. We’re based in Bristol. We do a lot of our work within the third sector actually. So, we’ve got a lot of charity based clients or membership organisations, public sector. Those type of clients, who are great to work with. They’re all incredibly nice people and quite visionary, as well, in the kind of things that they want to do.
We’ve been around for about five years. When we first started we were very much a tech house. Myself and my old business partner, we used to be developers so, we set up an agency to effectively provide outsourced development services to other digital agencies and then as we’ve grown we’ve gained more direct clients and turned much more into, I guess, a full service offering.
So, a full service digital agency at the very least. We can provide the strategy work, user experience, creative and development integration and then moving on into support after that point. Or taking on other people’s support contracts. A client might have had a website built by another agency and we can facilitate the support for that too.
Barry: That’s another reason that I wanted to connect with you. I saw you do a lot of third sector work which is something that is very close to my heart as well. Is that a conscious decision or did it just kind of happen?
Janusz: It kind of happened, actually. So initially our offering was very technical. It was ‘we are the Umbraco and Sitecore guys.’ And I think through the nature of the referrals that we had for the initial work that we did, the initial agencies that we were working with, a lot of the referrals seemed to be in the third sector. So, it was something that we gravitated towards yet a sector that we love working within.
Barry: Yeah, much respect for that. I think it’s an awesome place to be working in. This series of episodes of Happy Porch Radio is all about long term relationships and building support and success, long term success, of sites. So, I’m really interested in your Mayfly Support service and how you consciously separated that out from the projects work. Can you first of all talk about how that separation happened and why it’s that way now?
Janusz: I guess in the early days, two or three years back, our first support contracts came in and we had a single development team. The way that we resourced the support request was through the team, basically. So, we would – if a ticket came in from the client, we would pass it on to the team. It caused a lot of disruption, initially. So, we might have a development team working on a project but all the devs were effectively scheduled on half a day’s worth of support per two days or something like that. When a support ticket came in it might take them off their project work so there was a bit of context switching there for the developer. If they weren’t able to complete a task that was assigned to them within their half a day it would then be passed on to another developer who was booked on to support for the second half of the day. So, there was more context switching and knowledge transfer that needed to happen.
It was just really disruptive and the very nature of support contracts is that they’re reactive in their nature. I mean, I talk a little bit about the different kinds of support contracts that we offer but predominantly they’re quite reactive. There might be a bug or an issue or a new feature that’s required for a site, typically with quite quick turnarounds required. We’re very much, kind of, reacting to our clients’ needs. They need a quick turnaround. So, it disrupted the projects that were going on and we were finding that, effectively, the turnover was taking longer than it should because of the content switching that had to go on within the teams too great.
So, we split it. We, effectively, set up a dedicated support function where we have dedicated account managers, dedicated resources, developers and creatives, effectively, in that department, dedicated tooling. So, the ticketing system that we use that the clients use to raise tickets with us is purely used for the support function. From day one we saw the benefit and that was a benefit to us and a benefit to the client. We were able to get things out the door, get things finished, within the SLAs we had defined in the contracts, we were way more productive. We found that we were able to handle, sort of, 30% more tickets purely because the team was dedicated to that function as well.
Barry: Wow, there’s so much in that that’s really powerful. Let’s start right from the beginning. So, that problem you described is something you see so often in agencies and people building websites. The conflict between juggling reactive support and things where you can’t necessarily control, you know, there’s no schedule, and actually having to schedule in the meatier projects or larger tasks. Did you struggle through that for awhile and tried other different solutions? Or did you immediately go, ‘okay, we need to split this out’?
Janusz: No, we did. We did struggle with it, for awhile actually. We tried different methods of resourcing. So, again, for argument’s sake, let’s say we had five or six developers in the development team, we would allocate, say, half a day of support per developer and then that would switch throughout the day. Or, we’d then put a developer on support for, say, two days a week to give them more time to be able to complete tasks.
So, effectively, we tried different methods of resourcing, probably for a good 18 months, I’d have thought. It was quite a bold leap, actually, to move to a dedicated function because we needed to add additional resource into the team and tooling. So we invested quite a bit in setting up the function but, yeah, it paid dividends straight away.
Barry: Did you feel that that was a risk as well? I mean, because, obviously, you’re investing time and money and resources into that. How confident were you that you would see that immediate benefit?
Janusz: Absolutely. At the time, it felt like a risk. We’re five years old, we went from two of us to four of us within 18 months and then from four to eight and then eight to 15 and as a small company grows, there’s growing pains along the way and you need to recruit managers and put processes in place and automation tools and this kind of stuff.
So, there was a lot of change going on within the business at the same time and this was another change. So, it absolutely felt like a risk. But it felt like the right risk. It was measured. It made sense. Quite clearly, it made sense before we did it but, yes, I think any decision we make feels a little bit risky but this was probably one of the, I’d say, the least risky ones we took at that time.
Barry: And you’re right, sort of, dealing with a change like that while you’re also at the same time growing the agency and juggling all the other balls as well.
Janusz: Absolutely. Yeah. Yeah, there was a lot going on. Yeah, we don’t regret it. It was a good move to make.
Barry: So, how did the transition actually happen? Did you spend a little bit of time, sort of, positioning everything, speaking to existing clients or did you just have a sudden cut off? How did that transition actually transpire?
Janusz: I think the first challenge to solve, actually, was an internal one. So, support work is very different from project work and it suits very different types of people, actually. Some developers get a great sense of achievement from working on a project for three months and seeing that project go live and other developers get a great sense of achievement from working on many smaller tasks across many clients.
So, the first challenge was to find the right team to be able to do it and to find the team that was satisfied in the kind of work that came through the support department. Fortunately, we had developers in the team who kind of thrived on that kind of work. So, yeah, that seemed like a big problem to solve at the time but actually when we opened up to the team we found the answer to that quick quickly.
One of the second changes was tooling. So, we were on a project management system at the time called Podio that we used for all of our, kind of, client based communication, ticketing, documentation, all this kind of stuff. We felt at the time that that wasn’t really working for us. So, we wanted, effectively, the developers and the creative just working from one system which was Jira were it wasn’t client facing, so it was only the account managers that were speaking to the clients and the devs could just crack on with their work. So we moved to the Atlasian suite tool, so Jira and Confluence and that kind of thing. Then put Zendesk ticketing system in front of that, that the account managers and the clients use to simplify their work flow.
So, yeah. The first thing we did was put the team in place. The second thing we did was to implement the tooling. That was really the only thing that the client saw. That they moved to a more simple communication tool which was Zendesk. I mean, they saw the benefit of it. They saw that we were getting things out the door quicker and on time but the only real change that they probably saw was the change in the ticketing system.
Barry: So, you didn’t actually have to juggle much, you know, repositioning, or pushback or challenges from any of the existing clients?
Janusz: Not really. I think one of the changes that we made at the time was probably to redefine our SLAs and our contracts as well. So, typically – we have like a three level SLA. So, priority one, priority two, priority three and different turnaround times. So, associated to those different priorities, which we were able to build into the ticketing system quite well.
So, we put a lot of work into actually defining what those priorities meant. So, if a client was to raise a priority one ticket, a priority one ticket meant that the website was down or there was a yellow screen of death in the .NET world or there was a broken piece of functionality on a business critical piece of function on the website. So, if it was a charity, perhaps the donations were down or the event registration feature wasn’t working, and we did the same amount of work with the level twos and level threes.
And again, that streamlined us again. I think historically we used to rush to fix all issues with equal priority. And we’d be prioritising on the fly but actually in redefining our SLAs and how the priorities within those SLAs worked that again allowed us to work more productively and the client saw the benefit too. They were happy waiting three days for a level two because they knew that if they had a level one that came in, that it would be jumped on within two hours. So, yeah, redefining those SLAs was another big change.
Barry: Yeah, and that process must have been quite involved as well. For example, very often when you ask the client ‘what’s the priority on all this stuff?’ they’ll say ‘everything’s top priority one.’ Do you provide guidance or how does that work?
Janusz: Absolutely. So, historically everything was a priority one and, like I say, we used to prioritise on the fly and it wasn’t feasible. So, what we did was rewrote our contracts, defined very explicitly what a level one, level two, level three was and worked with them to define what could go into a level one.
So, a level one was absolutely a critical issue but nothing more than that. So, it was a website was down or, you know, a key, business critical piece of functionality was broken. Level twos are generally, something might be broken, so there is a function broken on the website but it’s not business critical. So, a newsletter sign up form might not be working or Google Maps isn’t showing or something like that. And then level three is typically styling issues or content or perhaps a new feature that they require, actually, something that’s come into the backlog, some additional development will go into a level three.
Barry: It’s interesting that that definition is very clearly on – it’s not technical, it’s not the difficulty to solve or like, whether it’s in hosting or front end or something. It’s very clearly on the impact on the client and so that they can clearly understand how to prioritise.
Janusz: Absolutely. That’s key. I mean it’s all about value to the client. A client comes to us for a support contract because they don’t have the technical capability or they don’t have the capability in house to do it but the website is so important to the running of their business so they need the confidence that should things go wrong that we can handle it in an appropriate time. So, it needs to be geared towards their requirements, absolutely.
Barry: Just to set quickly back to something else you talked about, and the different types of personalities or people that enjoy or are able to really add value to a support environment, did you actually consciously recruit more support engineers and creative people?
Janusz: No, we split the existing resource within the team, actually. We already had the resource internally. So, we defined the offering and then went to the existing team and said, okay, this is how we’re splitting the business, effectively, who’s interested? We had a few people put their hand up, which was great.
You know, the guys in that team absolutely thrive on that work. You get exposed to a lot of other stuff. More so perhaps, I think, than when you’re working on a project. So, you can learn a lot. You might be looking at other people’s work more frequently if we take on a contract through a previous agency, so you’re learning things from other people. You’re problem solving, you’re always problem solving I think. There’s an immense amount of satisfaction in a client raising an issue, you have absolutely no understanding about where that issue has come from so it’s down to, you know, the team to investigate and get to the bottom of why it’s not working then propose a solution that’s acceptable within the client’s budget and timeframes.
So, there’s not always, you know, one answer to fixing these problems. It’s down to the team to figure out which the most appropriate solution is and then to implement it and for it to go through a QA process, again, within an acceptable amount of time that’s right for the client.
Barry: Yeah, and again, you’re right – that feedback loop to seeing the impact of work or fixes you do is much shorter when you’re dealing with, as you say, the reactive stuff that’s happening. It’s sort of turning around quite quickly. So, that makes a lot of sense and there is a real sense of achievement there if that’s the thing that works with you.
Janusz: I think that’s the point. I think the guys that are more suited to support work, that excites them. It’s that immediate sense of achievement. It’s the problem solving. Because they might be problem solving five or six things a day so they’re getting quite quick feedback and kicks out of the work that they’re doing.
Barry: I’m guessing that a lot of your clients that you provide the support service to you also do projects for. For the those clients, do you have, like a process to handover between support and project? How do the two groups talk?
Janusz: We have quite a defined process map, actually. It’s quite large. It kind of covers all this stuff down to – all of the processes are deliverable. So, basically the – when a project’s finished it will launch and go into a warranty period. Typically and a warranty period is between five days and 30 days. During that period, any bugs can be raised that are in reference to the specification that we’ve built. So, the client has five to 30 days to raise any issues against the spec. When a project goes into warranty, it effectively gets handed over to the support team. Facilitating a warranty period is the same as facilitating a support contract from a business operating model.
So, at that point, upon launch, there is a handover. And again, we are quite wedded to the Atlasian suites. So, the senior developer who has been responsible for the project, the senior account manager as well who has been responsible for the project and the senior creative will sit down with the support team and run through any documentation that we’ve produced. So, specifications, wireframes, prototypes, that kind of thing. Any bugs that had been raised, say, through UAT and where there might be any risk in the project. Also there’ll be an end of project retrospective that happens and the support team would be in on that retrospective as well so that we can hear, you know, what went well, what didn’t go so well, what might we do better next time. Straight from the horse’s mouth, so to speak, so that they’re fully briefed on taking on that job.
Barry: So, even though each team has a very clear responsibility, there’s also a really close knitting and communication.
Janusz: Yeah, and they sit round next to each other as well, so there’s 15 of us and we’ve got, I think it’s 120m2 open plan office. So, they’re separate teams but they’re sat on the next table. It’s not like they’re sat on another floor and not party to the conversation and that kind of thing. So, yeah, it’s a very close team.
Barry: That leads me back to the value for the client that we touched on earlier, because, one of the issues I think that happens quite often is you get a site built or a project done and it’s kind of done in isolation without taking into consideration the longer term success from your client’s point of view of the site. But if you have these teams working together and there’s a commitment to providing an ongoing service, even above and beyond the warranty period, presumably that affects the whole project process as well as the support.
Janusz: Yes. So, it depends on the project and we are in different types of support contracts as well with very different models and totally different between different clients. So, we typically offer three different types of support contract.
So, the first type of support contract is maintenance. It’s like servicing your car. We will do a load of stuff on a regular basis to keep the website in good health and that might be server maintenance or applying patches and updates from Microsoft. It could be CMS maintenance. There’s a few tasks that you should do regularly within an Umbraco or a Sitecore platform just to keep them efficient, deleting temporary files, deleting logs, clearing out recycle bins, rebuilding databases, all this kind of stuff. They don’t necessarily progress the website any further but they keep it in good shape and we reduce the likelihood that the website might go down.
For that type of contract, we define the services in the contract schedule, and we just go and do them but the client doesn’t’ necessarily get any additional time to do anything else with. It’s purely regular maintenance and they don’t see us doing it, they don’t get any feedback from it. It just happens.
The second type of our support contract is more aligned to the conversation that we’ve had so far in this interview which is more for a retained relationship. So, typically a client will buy some time from us. We have support contracts ranging from between one to 10 days of time a month. The client buys the time and using the ticketing system they book in work for us on a monthly basis. That work might be bugs or issues or new features that they require. The client uses up their time and then the next month they get a new time allocation.
Then the third type of support contract is more strategic. So, a client would, again, buy some time from us but we’d own a certain piece of intellectual property on the website. So, we might be responsible for increasing conversions or engagement or improving the user experience in certain areas. So, we would use that time without the client requesting things from us to try and improve certain KPIs on the website. So, it’s more of a proactive, strategic support contract.
So, the type of contract that we offer, the type of contract that the client requires typically falls into one of those three categories, or a combination of them. So, if somebody’s got a time based retained relationship, they’ll probably have a maintenance agreement in place too. Other clients might have a technical team so once we’ve launched the website, they want to host it and manage it internally because they have a developer in house but they’re then looking for the ongoing strategic support to help move their website forward. So it varies very much. It’s pretty much dependent on the capabilities of the clients.
Barry: That’s brilliant and I love that you’re using the same terminology that I’ve always categorised those into – the maintenance and reactive and proactive and strategic. I’m really interested in – so, reactive, we’ve talked a lot about already but one thing we haven’t touched on yet is how do you manage client expectations in terms of, you know, we’ve used all your time this month, you know, do you have that communication process?
Janusz: Absolutely, so if it’s a time based kind of reactive relationship, then we have to maintain incredibly accurate time sheets internally. So, we will feedback time sheets, typically on a weekly basis. So, we’ll do a weekly status call with the client, we’ll have a chat about any tickets that are currently open, the status of tickets, when they’re likely to be deployed or ready for client feedback, that kind of thing.
At that point we’ll be sending over time sheets of any work that had been completed previously. Towards the end of the month one of the account managers will be saying, okay, so you’ve still got two days left to use before the end of the month. Just a reminder so that you can try and schedule some work in and get the most value out of your contract.
Barry: Do you have rollovers and queries around what can I do with the time that’s left?
Janusz: We do but only as a percentage of the previous month. It was probably a mistake, I think, that we made in the early days where we said, ‘Yeah, yeah of course, you bought the time, you can roll the time over.’ We found that – I think we had one support contract and they, the client, had, for argument’s sake, say, a day a month and eight months in they hadn’t used any time and in month eight they said ‘We’ve got eight days to spend, can you start tomorrow because we need this really big thing done.’
You can imagine again, I’m talking about the impact on the resourcing in the development team. We weren’t able to plan for that, we weren’t able to keep this eight days’ worth of resource within the team to be used at the drop of a hat and then you multiply that by the number of support clients that you’re able to support and you’re just not – we weren’t able to deliver on that.
So, when we do offer rollovers it might be a percentage of the current month and you can roll it over for one month. So, if you have 10 days you might be able to roll over two days into the next month so the next month you would have 12 days. It allows us to deliver on the resourcing side of it, basically. So, we can plan and resource knowing the capacity that we have to fulfil within the following month. Rolling over too much we’d need a development team of 40, on the off chance that everybody used up all their time in the next month if we didn’t do that.
Barry: Yeah, and that’s just about realistically managing what you can deliver, which is important from the clients’ point of view as well so that you’re still there.
Janusz: Absolutely, yeah.
Barry: The next level or category of stuff you talked about, the proactive, the strategic level stuff, is that an internal differentiation or do you describe it like that to clients as well?
Janusz: Yep, we describe it like that to clients. And it, again, it can be a combination of – a client might have the reactive time as well but then they’ve said, ‘Yeah, okay, a day a month can you do some user experience work for us,’ perhaps do a review of each section of the website, each month and come up some recommendations that might improve conversions within that section. So, we took down and put together a plan, recommend it to the client and they might use some of their reactive time to implement some of the suggestions that we’re making.
Barry: The other thing you mentioned was owning part of the site or the IP. What do you mean by owning? Do you mean actually owning or just taking responsibility for guiding?
Janusz: Probably a bit of both. So, we might be tasked to, say, increase donations for a client. So, we would say, okay, let’s have this amount of time, and in this amount of time we’re going to do a user experience review, we might implement a little bit of AB testing or personalisation tool and plan a strategy around that. It’s incredibly powerful. It requires a lot of measurement up front before you do the strategy work and planning and implantation and iterations. So, if you invent some AB testing or personalisation and it doesn’t work you need to be able to fail fast and loop that round and try something else.
Barry: I can see how incredibly powerful that is both as a business service offering for yourself but also that’s where the real value comes from the client’s point of view because you’re using expertise to help increase their conversion or grow their business in some way.
Janusz: Yeah, absolutely. And typically, these kinds of arrangements, they’re baked in from the start of a project, basically. So, if you want to increase conversions, you need to know how many conversions the client was getting before you did any work. You need to benchmark it. You need to measure it against something. So, even before we would start the project we’d be identifying the goals that the client needed to improve and then getting measurement data from the client. Day one, over different time periods, monthly, quarterly, annually, campaign based. Making sure that we’re measuring them and progressing with a design process, so that’s user experience and the creative design process, that was optimised towards increasing those conversions.
But then even after launch, even when you launch, you need to benchmark. You might have released a new website and the very act of releasing that website will impact the conversions that you were measuring. So, you need to be able to measure that. So, you have a second benchmark to measure against when you start to do the ongoing strategic work. Then you need to put something into place, and then you need to measure that.
Then you need to see the impact that that had and then iterate. So, the process starts very, very early on and typically at the start of a new website development project when they’re understanding that we’re interested in certain conversions. We’ll be planning from day one to be doing that strategic work, perhaps six, seven, eight months down the line as well.
Barry: In order to benchmark it and see and measure the changes and impact of changes over time.
Janusz: Absolutely, yeah.
Barry: So, all of this naturally leads you to long term relationships with your clients. So, do you start the conversation, like a sales or an enquiry conversation, do you start with the concept that you want to build a long term relationship in order to be able to deliver that because you can’t do that kind of service and even the reactive and maintenance services, you know, running them for a month or two isn’t really the point. It’s the requirements for the long term.
Janusz: Absolutely. We’re all about ongoing relationships than projects. We all enjoy what we do very much and we’re all incredibly nice people and a great and friendly team and we like working with good clients. From a business development perspective you can put a lot of effort and work into winning a new client. You might win one in five so it’s incredibly costly. From a business perspective it makes sense. You keep your current clients happy. You’re there for them and you support and you respond to them as they need to. You already won that client so you don’t have to go through the effort of winning them again so from a business perspective it makes sense.
You build up good strong relationships with your support clients. I’m very good friends with a lot of our clients ‘cause we’ve been working with them for so long. We have one support client we’ve been working with for five years, since day one pretty much. So, we’re always, always, always interested in the long term relationship. That’s I guess where, like you say, the support model fits in really nicely.
Barry: As you say, that’s really powerful both in terms of getting business success but also the enjoyment and avoiding the stress of less peace and family and that kind of thing. Also, it must be, to come back again to talking about value, focusing on what the client needs are and the value for the client, it must be really important to focus on that because otherwise you can’t build that level of trust and the long term relationships.
Janusz: Yes. We see it quite often when we, say, take on support contracts for websites, I guess, that have been built elsewhere. Typically, with the CMSs that we support there are a couple of right ways and a lot of wrong ways to build these sites. To understand how to do it the right way, you need to be trained or certified in these CMSs and typically be a partner. You can tell. If we get a support contract through the door and it’s been built by a partner, we do an initial risk assessment on it, we do a health check of the site and we go, ‘Yep, we can take this on, absolutely.’ It’s very easy for us to estimate how long it’s going to take.
Those that have been built the wrong way, built on a framework of sand, and held together by a piece of string, they can be incredibly risky, actually, for us to support because we just don’t know, actually, if we can deliver on the client’s requirements within the SLA because it’s just – it would take us a month to actually understand the code, to do the risk assessment and the client just doesn’t have the time for us to pace through that.
So, from their perspective, they’ve been, a lot of the time, burnt, before. So, they might be coming into a support relationship with us feeling quite nervous because they’ve had a site that’s not been built very well and it’s always falling down and they don’t know where to turn next.
So, for us it’s very much about, yeah, we need to understand the risk bits involved, and be honest with them about, ‘Okay, for us to be able to support this, this is actually a big job. You might need three or four days a month, actually, just to keep this thing ticking over.‘ To be honest with them at that point of time and say, ‘Yes, we can take the support contract but you might be better, almost, rebuilding certain elements of the site.’ That open and frank conversation, I think, clients appreciate because, again, they might be coming from a situation where they might have, typically with these kinds of sites, where they’re laden with issues where they might have had a failed relationship that’s been going with a previous agency for 18 months and they didn’t know where to turn. So, our job, in that instance, is to put their mind at ease and be honest with them.
Barry: That’s the only way to build that long term trust. Okay, so, there are two other things I’d like to touch on quickly before we wind down. One of them is that, you mentioned that, I think you said 30% more tickets or 30% quicker turnaround, when you split out the support. Obviously, you’re measuring that but what other things do you measure to try and make sure that that support service is delivering and consistently being valuable?
Janusz: That’s probably one of the key measures. The other is that we’re getting jobs out on time, to time. So, when a ticket comes in we do an initial assessment and an estimate that we send back to the client. So, this job will take five hours of development, two hours of UAT, 45 minutes of client services, an hour’s worth of deployment, etc. The client then signs that off and says, ‘Yep, happy for you to do that work.’
So, one of the key measurements is that we’re getting those jobs out the door in the time that we estimate, effectively. That just illustrates to us that we’ve still got a finger on the pulse in terms of how long it takes to estimate these jobs.
It allows us to plan things accordingly, because if you got the estimate, right, and all the jobs take longer than we originally anticipate, that impacts the next job that’s booked in for that do. So, if we estimate something at an hour and it takes us two, we’ve got an hour less to spend on the next job that we’re meant to do that day. So, measuring on time and to time a) keeps us productive but b) allows us to keep our clients happy because we can do the number of jobs that have been allocated for that day without overrunning.
Barry: Just one last question. What would be the one piece of advice you would give to any web professional who’s struggling with that original challenge you had where they’re fighting the scheduling and the resourcing issues of jumping between, context switching between the support challenges and also needing to keep larger projects running to time and budget?
Janusz: Two things – two very clear things and I’ve been asked this question a lot, actually. The two biggest changes that we made in our business that had the biggest impact was 1) separating the support from the project work. It’s different work. Support work is reactive. If you’re trying to facilitate it within the same team you’re impacting all different kinds of things. There’s context switching left right and centre, there’s knowledge transfers more frequently to happen. If you separate them out straight away you’ll see the benefit from day one.
And the second thing is – the digital industry seems to have moved towards a model of using what are called producers which are effectively a mix of account managers and project managers. We tried it and we see in other agencies and just don’t believe it works. Separating out your account management, your client services function from your project management function, we saw immediate benefit from it. You need your client services function to be speaking to the client, to be the client’s liaison within the company, to be understanding their issues, to be writing the briefs, to be helping with invoicing, to be chatting with them on a regular basis. They haven’t got the time to be making sure the thing’s delivered.
The project manager should be internally working with the development team to get the jobs out the door on time, helping with some solutions, perhaps helping with some additional resourcing that might be required. If you mix those two roles into one and into the role of producer, you become a jack of all trades. You’re spending half your time speaking to the client and half your time speak to the internal team and not really delivering on either. I think separating client services from project management is absolutely key.
Barry: And, finally, anybody listening who wants to reach out to yourself or to find out more about Mayfly, where to do they go?
Janusz: Two websites – our project function is www.mayflymedia.co.uk. You’ll see again our specialism in third sector and Umbraco and Sitecore. If you’re interested in our support function it’s just mayfly.support – type mayfly.support into a browser and you should hit our support function and our Twitter handle is just @mayflymedia.
Barry: Outstanding. I’ll put all of those links and the Twitter handle into the show notes for this episode at Happyporch.com/podcast. Thanks again so much for joining me. I think that’s amazing value from your time there, I really appreciate it.
Janusz: Fantastic. It’s been great speaking to you, thanks, Barry.