Selling Drupal: How to win projects, and not alienate delivery teams

Good morning everyone and welcome to our session today. I am Hannah McDerma, operations director at Zucha. We are a specialist technology and experience design agency focused on creating people first solutions powered by Drupal. My experience at Zucha has largely focused on implementing and optimizing delivery workflows and more recently my remit has expanded to also include new business from an operational perspective. And hi everybody. I am Hannah Oli. So no, you are not seeing double and it is not a typo. We do both have the same name, but at least it makes it easy for you to remember. Um I am the lead business development manager here at Zucha and I'm aware the definition of that role can look quite different across different uh agencies. So for a little bit of context at Zucha, what that means is I look after the sales life cycle from opportunity qualification all the way through to hopefully handing over to the client services and delivery team. It's a role I'm extremely passionate about and have also been fortunate enough to speak at a previous Drupalcon in Drupal Europe Barcelona on how we manage this function towards success at ZA. So in terms of our session today, the title itself drew inspiration from a number of sources. The first was the naughties comedy with Simon Peg, How to Lose Friends and Alienate People. And the other was the hit Netflix show Southern Sunset. Now for those of you who aren't familiar with that show, the premise of it is that it follows the lives of glossy LA realtors as they sell homes to the rich and famous. You might be wondering what on earth does that have to do with selling Drupal? Well, actually quite a lot. Apart from their snappy sense of style, uh the needs of realtors is that they have to balance the needs of both the sellers and the buyers in that sales process. If they don't, they may leave the buyers feeling conned or missold and they may leave the sellers to deal with the consequences. That's the tension that we'll be exploring today. So yeah, that is what we are here to talk about today. It is that overlap between sales and delivery and a friction that has almost become a running joke across a variety of agencies and industries. So I've been with Zucha for coming up on about six years now and in that time we've continued to grow and scale significantly and what we've noticed is that as agencies scale and grow these frictions or misalignment becomes a measurable source of operational shortcomings rather than simply a you know complaint between departments that can be brushed off. revenue, client satisfaction, and team psychological safety are all taking a hit due to our perceived notion that this friction misalignment is um acceptable and nearon expected within an agency environment. We believe that this friction is structural and not at all personal and therefore within that there are actual opportunities to begin to reframe how you potentially look at these two arms of your agency business. So as we began to implement the structural and organizational changes that we're going to discuss throughout this session today, one thing that actually became immediately I guess obvious um to us was that Drupal as an open source open source software is actually being hit the hardest uh by these impactors. And if we want Drupal, and I'm sure everyone would not be in this room today if they didn't, to be able to succeed against uh large scale proprietary ecosystems, then that commercial maturity really matters. So to round off our introduction, we want to introduce three key themes that will be woven throughout today's session. The first is that revenue is a shared product. It's not solely owned by sales nor by delivery. The second is that operating models drive behavior. The systems and the structures that we put into place really matter. And the third is that alignment between sales and delivery protects both your profit margins, but also your reputation. Increasing revenue and increasing quality do not need to be mutually exclusive. As we've claimed with the title of this session, it is very much possible to sell Drupal and not alienate your delivery teams. So let's first start by asking the question, what is the cost of this misalignment to our businesses? The first area to consider is the commercial consequences. One of the common victims of this misalignment is your revenue forecast. Where sales and delivery are not working in lot, you'll often see your forecast being spiky or subject to last minute positive or negative adjustments. This means it's not something that you can rely on to make sound commercial decisions and therefore you're introducing risk into the business. Similarly, you'll also see unstable recovery rates where sales and delivery are not working together. What we mean by recovery rates here is the comparison between your original estimates and then the actual time spent. I'm sure we've all been handed a project where the estimate is 10 days and the actual time to complete it is 100. That is an example of a very poor recovery rate. And lastly, we can't forget the cost of renegotiating scope post contract. On the occasions where we are able to do so, the time to reestimate the potential financial penalties of doing so are all things that we must consider as a consequence of this misalignment. The second thing to consider is the cultural consequences of these two teams not acting together. This might be harder to measure and less tangible, but just as important for your business. What we'll see where the TU teams are not set up to work together is potentially defensive rather than collaborative behavior and therefore the opportunity for risk but also missing out on opportunities. As a result of that, we may see a negative impact on the team's psychological safety. No one feels uh safe to raise their head above the parapet to suggest issues or solutions to things that we're facing. And in turn, as a result of both of these things, we may see an impact on our team morale and in the worst case scenario, increased staff turnover. So that brings us to our third major consequence, which is the impact on our clients and the wider um Drupal ecosystem. Consistency and predictability are two fundamental pillars of any long-term successful client and agency partnership. Starting off delivery with clear inconsistencies between what was promised during the sales life cycle and then what becomes sort of immediately apparent uh once the contract gets started is a surefire way to cause an erosion of trust right from the offset. your delivery teams then have to work 10 times harder to bring those guard walls back down that have been put up by clients as a result of this practice. We have also um on a selection of occasions been unfortunate to see the damage that this misssold inconsistent delivery can do on the wider Drupal ecosystem. We've spoken to both clients and prospects of told who have told us of the uphill battle to even get Drupal considered as a solution when there are key stakeholders in the room who have previous negative experiences of misssold, expensive and overpromised Drupal delivery. So when we missell complex Drupal work, we might win the contract and that feels good in the short-term revenue, but long term, who is winning here? Because it's not us. it's not the client and it is almost certainly not Drupal. So, we're going to get a bit into why is this happening, but before I do that, I just want to do a quick show of hands to who we have in the room. So, please put your hand up if you were involved in sales. Quite a lot of you. Uh delivery, same hands going up. Uh leadership and I'm expecting a big turnout on this one. Who here has felt the consequences of a misaligned delivery? Right. So, we definitely got the right people in the room. So, I think it's important to go into potentially why is this happening? Well, first of all, you've got your key structural drivers at play. And the first one is sales incentives. When individuals in your sales team have these ambitious revenue and growth targets, these can encourage tunnel vision and individualized thinking. And to be absolutely frank about it, when your take-home pay is on the line, individuals are more likely to ignore clear red flags, obscure difficult details, and ultimately make unrealistic commitments just to secure the contract. This in turn then directly counters the targets of delivery teams who are keen to prioritize accurate and sustainable delivery. So what we're doing here is localized optimization. We're rewarding individuals or individual departments for localized success without linking this back to a wider global systems optimization approach. And this might be successful in an early startup agency environment. But with growth, the cracks really start to show in this operational immaturity. So alongside these structural uh gaps, we also have process gaps that are continuing to drive that misalignment between the two teams and potentially increase friction. The first that we have to consider is handovers. We've all probably uh paid the price of a poor handover where we've not received the full information or any partial information at that point and then had to have a difficult conversation with a client who's surprised to know that you didn't already know that. where these handovers are missing. We are introducing risk and we're causing friction between teams. Another area that is causing friction and I'm sure again we've all uh been privy to this is assumption driven scoping. Now we've all heard the phrase when you assume I won't finish that but the sentiment very much applies here. If we make assumptions in the sales process to drive our estimations, the people who are paying the price of the delivery team when they have to have the hard conversation with the client that the budget or the timeline that they want to meet just isn't quite there. And lastly, the other process gap that we have to call out is that delivery is almost always only involved at the very last moment at that point of handover. They are the ones on the cold face every day. They can spot a risk a mile off, but they're not given the opportunity to be involved earlier in the sales process in order to shape that outcome and perhaps make it an even better one than it would have been previously. So, getting back to the Drupal of it all, I guess, um, we've mentioned a few times that we believe Drupal is hit the hardest by this, and that is for a number of reasons. The first being the very nature of open- source projects that encourage variability and flexibility throughout delivery. Thinking of things such as third-party integrations or emerging complex functional requirements. Right. So at Zucha we really bang on about the importance of getting discovery right and it is for this reason. It's ensuring expectation and prioritization alignment from the offset allowing discovery to be able to reshape scope. When we overpromise just to win, this can have a restrictive impact on discovery and a negative impact on the rest of the project as a result. We all know as well that Drupal has a major presence in public sector and higher education institutions. In the UK at least, which is where we're from, if you can't really tell, um these sectors are bound by particularly strict procurement requirements around early commitments to both budget and scope. I am led to believe that it's a similar story here in the US, but if anyone wants to chat about that after the session, please come and grab me. But what we're trying to say here is that under these particularly restrictive procurement environments where Drupal so often finds itself, it is more important than ever to take extra care and be collaborative and transparent throughout this process in order to ensure an ultimate successful Drupal delivery. So, we've just laid out all of those root causes, but what we find is that often instead of addressing them, we fall back onto common tropes. So, some of the ones I'll talk through here, I'm sure you've heard before. So, things like sales over promise, delivery teams aren't commercially minded, friction is inevitable, and even worse, friction is necessary. But in order to see real change, we need to reframe these myths. So let's consider that friction is a system of this uh is a is the outcome of the systems and the processes that we put into place or that we allow to evolve in that way and that these systems ultimately produce the behavior that they incentivize. So let's take a little bit of a step back and talk about our experience with this at Zucha. For the sake of this session, it would be great if I could talk about a dramatic light bulb moment where all of these things came to the four. But the reality is is that an agency as an agency as our operational maturity increased the need for better alignment between sales and delivery also increased. When we look back over our reporting from uh the last few years the evidence that we can see is quite clear. One thing that we really wanted to improve was our confidence in our forecast. At one point we were unable to rely on it. it wasn't something that we could consider as an accurate picture because as I mentioned earlier in the session, one of the indicators was that it was subject to short term changes and uh could fluctuate month. We also had the uh burden of inconsistent recovery rates. So what this typically looked like was that we could be vulnerable to short-term impact of one particularly bad project. And we were seeing feedback flagged both internally and externally. So within our teams although they would felt safe to share they were raising concerns around uh things in the sales process and equally sometimes we would get client feedback that reflected the gaps between sales and delivery. Being able to look at this holistically and with hindsight we can see that sales and delivery were both independently trying to improve but they were doing so on their own rather than together. And as a result of that, Zucha as an organization wasn't optimizing globally. When we look at the operating models between the two departments, the delivery team had grown and matured and had a discipline and agile processes in place. But in comparison, pre-sales and new business was relatively informal. What we could consider here was the problem was not the communication or the people in the teams. The problem was the system design. So, as Helena just mentioned, there was no big overnight uh dramatic reset. This has been achieved over a process of continuous improvement, test and learn, and ultimately just failing forward. So, we're going to look a little bit into, you know, what we've done and the operating model at Zucha to be able to combat this. And the first step is the idea of a shared sales discovery. So early joint scoping and estimation uh with the developers that would actually be involved in the contract ensuring that our estimations are actually informed by the doers. These are then documented as key sales artifacts to be referred to back throughout delivery. This early engagement also enables explicit articulation of any unknowns, risks or clarifications that come out as a result of this engagement with our technical team. These are also then again documented and considered to be shared uh with the client to alleviate any of those areas of concern. So what I'm saying here repeatedly is that these are documented that does not mean they are then shared uh with the client uh without a second thought. Sales must be ambitious and it must be competitive. Strategic decisions are still being made to offer discounting pricing, be more competitive, or simply accept a higher degree of risk tolerance just to win the contract. These decisions are made with a view of what is best for the business as a whole and not what is best for individuals or individual departments. We consider factors such as, are there resource gaps we're looking to fill? Is this a sector or geography we're looking to be particularly competitive within? or are there opportunities for innovation within this project that we can take advantage of? All these factors and more are still, you know, informing our approach to sales from a strategic perspective. The difference is that these decisions are made transparently, collaboratively, and across departmentally acknowledged rather than discovered as a surprise later on down the line with no traceable accountability back to sales or whoever made those decisions. What this really is is working in the open. Decision making between our technical team, leadership, delivery and sales is flowing freely between one another with no closed doors behind which decisions are getting made. This ensures accountability, clearly understood expectations, and ultimately derisks those surprises later on down the line. So just because we've had everyone involved at this stage means we're ready to just kickstart and roll into delivery, right? No, poor handovers make for poor projects. Our own handovers at Suture are iteratively informed by both our delivery and sales team to ensure they're basically informed by the pain points and gaps that we're discovering. This ensures that all documentation is provided. There is clear expectation, clear commercial expectations. So things like has there been a discount or intentional underestimation that the delivery team needs to be aware of and also clear ownership throughout this transition preventing anything from falling through the cracks in what is often a very delicate phase of any client and agency partnership. This also provides an opportunity for delivery to challenge anything that comes out of the sales life cycle. Again, going back to the accountability I just mentioned, sales doesn't just disappear once the contract is signed. Go home and consider it a job well done. This um does also introduce a degree of risk um in doing this phased handover as there are simply more cooks in the kitchen. And this is where the checklists and the roles and responsibilities really come into their own. ensuring there is clarity on ownership of tasks and phases as we progress through this kind of emerging and exiting phase transition. Doing it like this has also had the unintended uh an positive impact on our clients who have also given us positive feedback on you know the phased handover that enables a friendly face to stick around during the project delivery rather than just a cold cut handover to a brand new team. So to give a little bit of an example on this I guess and these two bits that I've just discussed here what you know how we do it we are recently working with a UK university and use during that joint scoping and estavation phase uh that I mentioned our technical team were raising risks around potential gaps in the client's infrastructure we raised these with the university at the time again very on very early on in the sales life cycle but as it transpired they were also also suffering from kind of limited visibility into their infrastructure as well as a result of the working relationship with the incumbent. So we won the contract which is great and as we got started it sort of became obvious that our concerns around the infrastructure were matched up in reality once we had access to everything. We then raised these uh with the client once more. But our team were prepared to deal with this you know quickly and efficiently and the university themselves were also anticipating these gaps to come up as they'd had that earlier communication with us much earlier on. They also appreciated the speed at which we were basically able to offer solutions as our tech team already had an idea of the information and the gaps instead of having to basically messily at that time fumble around look for the information and come up with a solution on the spot. To take a view on this, if we hadn't have prioritized transparency and collaboration throughout this phase, our team would have been likely blindsided by these gaps that came up. we would have had to present the client with bad news during again what I said to be one of the most delicate phases of any client agency partnership and we would have been starting off from a point of friction rather than efficiency which is what we're all looking to avoid. So the final kind of pillar of this model that we implemented focused on the idea of shared forecasting accountability. What this meant was removing the silos and ensuring that we were integrating departments when we were considering our operational design. The first kind of key area that we focused on was how we thought about revenue and how we treated that within the business. So the key to this was aligning our metrics. We talked about metrics a lot today but it was alignment and simplification of those metrics that really was at the heart of this. So for us this meant focusing on a single number which was the budget for all teams sales, delivery, client services, the whole team to understand what they were aiming towards and also communicating that. That was something that was really key. And so now within our business, if you ask any member of those teams, what our budget is, where we are in the current month, within the current quarter, within the rest of the year, they'd be able to answer you. Alongside this, we made sure that forecasting accuracy was treated as a shared responsibility. We did this by implementing changes to roles and responsibilities across those teams and formally capturing that. So it was really clear what the expectations from me every member of the team was. And then we also connected the dots between new business resource management and delivery management so that we could align our pipeline visibility with our capacity planning. Now, this was really key because previously, and I'm sure everyone has experience with this, we would win business and hope that we would be able to deliver it. With this approach, what we could do is we could make smart decisions with our sales pipeline. We could understand where we were underutilizing capacity, where we were overutilizing, and we could make decisions on what we would pursue and what we maybe wouldn't pursue. We could ensure then we had the capability and the capacity to deliver for our clients. We also made sure that we had cross functional forums and we were facilitating that collaboration between teams. Our weekly operations meeting covers the entire client life cycle from sales through to onboarding, delivery, support and potentially offboarding if there are those occasions. This means it's the same forum where we discuss client outcomes, delivery issues and also sales pipeline with the same people. So we have the right people in the right room to have those right conversations. We also make sure that we're modeling the behavior we want to see in the scenario that things go wrong. Instead of saying who is to blame, we're looking at what. So what was it in the systems that we have in place that allowed this to happen and what we going to do about it? You may have heard of some structures such as the five W's. These are really helpful for moving the dial away from the personal to the structural and seeing real change. Talking of change, uh what did we see as a result of these changes? What were the positive impacts for us at Zucha? So to hearken back to the start where we talked about commercial and cultural consequences from a commercial point of view, the biggest outcome at least from my perspective was that we have real faith in our forecast. It is our single source of truth and it is where we would go to to understand how are we looking today, where will we be tomorrow and what do we need to do about it. Similarly, we have seen an increase in our account value. So the new business that we're winning is better and we can at least partly attribute that to things such as the shared sales discovery that Hannah mentioned. Involving delivery in those early stage conversations means that we've had higher quality output and therefore higher quality wins. We've also seen much smoother handovers between sales and delivery because delivery has been involved earlier. They have the knowledge. We also have the structured handovers to ensure that the right information is always flowing between the teams and also the expectation that sales will be involved post handover should there be any concerns. And as a result of all these things, we have seen an increase in our project recovery rates. So since we started reporting on them, we've seen a 14% increase. and we have a steady roll in average that we see not impacted by short-term or single client projects. At the same time, we've been able to sustain the culture as a an agency from where we started, which was, you know, a small very small startup to one that has three uh offices across the world. Our relationships are built on trust. So that means that the default mode of operation is collaboration rather than any form of blame or defensiveness. And overall that means the psychological safety of the team is preserved. They feel comfortable to share feedback and that's how we measure it is understanding where cl our team are participating in retrospectives where they're sharing feedback in formal formal forums and so forth. So the third positive impacts uh that we've seen have been across our clients and the wider ecosystem. Primarily we've been able to deliver higher quality Drupal development. This is only possible due to a culture of collaboration and transparency enabling us to work with our clients in genuinely open and collaborative budget management as well as get the opportunity to try new things allowing our team to experiment with innovation and the latest within Drupal and our clients to ultimately end up with a better quality Drupal product leading them to becoming Drupal evangelists themselves. This has also been impacted by better scope management. Our clients are able to see us as a genuine extension of other teams working towards one shared goal. This is only possible when you establish a firm foundation of trust, something that is risk being eroded by taking that siloed approach to sales and delivery that we're trying to avoid. And of course, it's very easy for us to stand here and say this. Um, and that's great, but and there are, you know, obviously still bumps in the road that we face every day. But I wanted to highlight this stat here and that's that 89% of our clients report either being very satisfied or extremely satisfied with Zucha since we started pulling this metric from our client services department. This includes clients that we have on boarded within the last you know 6 to 12 months. So new clients into the Zucha fold and also heritage clients that we've been able to retain for over 10 years. And it's really great to see that they are s both feeling similarly positive about their experience with Zucha. So just to have a little quote there which is obviously very nice to see. So this is actually from one of our clients that came on board in the late summer early autumn of last year and it's a large scale public sector organization in the UK. Um obviously lovely to see and it's great for team morale when they get feedback like this. But what we want to stress is that the process that we've been discussing today it is iterative. Hannah and I are still working on initiatives uh continuous improvement initiatives to ensure genuine alignment between these departments, but the stats that we've shared in this section today should hopefully demonstrate, you know, that we are working towards shared KPIs that are going positively and they're also a real marker of how we measure success as a business. So, we wanted to finish up today with just a few kind of practical recommendations, a universal model that you can look to take away. Doing things the same old way simply isn't enough anymore. I am very sure that you don't need me to stand here and say this, but I am going to anyway that the landscape has become more competitive than ever. Stagnation when everything feels like it is evolving around you is arguably one of the worst places to be. So three levels to these practice recommendations and the first one is very simply visibility. What can you do to make operations more transparent and more collaborative between your two teams start with sales sharing everything that comes out of the sales process. So whether that's opportunity forecasting the revenue forecast likelihood scoring and share those directly with your delivery team who then in turn can share recovery rates, pain points and resource management profiles. This is simply a place of transparency beginning to understand how one another are operating and ultimately look for those opportunities where enhanced collaboration lie. We would also stress the importance of a structured handover. Ensure is formalized and with clear roles and responsibilities documented. This is of course likely to be something that you already have in place, but we would argue maybe it's time to just dust off the cobwebs and ensure it is really fit for purpose and actually functional within your business and not just simply documentation for documentation's sake. Our own handovers are iteratively involved by our team and therefore they are always evolving and that's the key point here. The documentation needs to be consistently evolving by the new challenges that come up and never stagnating. And finally, we would recommend just running one joint scoping session. This is just an opportunity to really get uh establish the ground for collaboration. If nothing else, this makes people feel heard. It makes them feel supported and it ultimately builds confidence in the process that you are trying to grow, beginning to ease those very frictions that we started off the session by discussing today. So the second level of this um I guess maturity curve that we're talking about today really focuses on starting to implement the notion of a shared operating model between sales and delivery. So the first part of that I would suggest is looking at your sales life cycle and starting to think where could one point in that life cycle be that you involve the delivery team to start with. This could be quite close to the end of the process, but it provides an opportunity for the delivery team to catch any final gotchas, any extreme risk that you need to be aware of before that contract is signed. And by doing that, you'll already be ahead of the game compared to most other agencies who aren't doing that. And over time, you may find that you can then more fully integrate them earlier in the process as we talked around the the shared discovery, the estimation. But that's something that would typically evolve with the maturity of that model. The second thing to bring up metrics again is uh to make sure that you align at least one shared KPI. Now that might look different based on your business. It may be your budget. It may be the project recovery rate that everyone is working towards improving. Pick one, focus on it, communicate it, and integrate it in all the relevant conversations that you're having across those teams. That means that all those teams know what they're working towards and they can share that success when they achieve it. And finally, introducing joint forecast reviews. If you're not already doing it, make sure you are. Bring the people in from delivery and from sales who are relevant to discuss where are gaps, where are opportunities, where are risks. Allow them to have the conversations between themselves and you'll be very surprised at the positive outcomes that you'll see. And the kind of top tier pinnacle level of this uh proposed model is the point of reaching kind of fully integrated accountability across the organization. So this means that revenue is formally treated as a shared product by teams. I mentioned briefly earlier around how we integrated uh the notion of revenue management within roles and responsibilities. And I think this is really really important for making sure that the team are aware what their responsibility is and what that looks like based on their seniority based on their department and can be considered as part of their continual personal development. Similarly looking at your leadership structures as well to inform the team what you care about and why. Within my role, I now uh cover new business and delivery and that signals to the business that those two teams must work co you know co together and harmoniously. Um and that's really really important in terms of messaging. Again to talk about modeling behavior, we have to avoid falling into the trap of the blame game. So at this level of the model, we're ensuring that we're facilitating those collaborative conversations, whether that be new business and delivery retrospectives. We run a quarterly one where the delivery team are able to report back recovery rates, issues with the sales process, ways that they would suggest improving and have those collaborative conversations in order to move forward. The focus again is not on the personal, it is on the structural. So put in place those forums where the team can vent but also come up with solutions. And lastly, at this level, we would want to be seeing operating models that are fully embedded across sales and delivery. Not only does it ensure cultural parity, so the teams are talking the same language. They have the same or similar types of workflows, so they understand the needs of each other, but by having a mature operational workflow in sales, you're already setting yourself up for success for capturing the evidence uh of decisions made and making sure that your handovers are as easy as possible. From my perspective, I think we're missing a trick when we're not applying agile principles to our sales processes. We don't need to take it whole hog, but if we consider the tenant of inspect and adapt right now, that's more important than ever for our sales team to be able to pivot um and react to the world around them. And so we are ultimately uh losing out on that opportunity if we don't take that into consideration. So let's wrap this up. Um which is essentially what we've been talking about here is the idea of redefining what it means to win. Everything we've discussed today from the risks presented uh with uh misalignment and misselling in sales to the potential opportunities when you begin to treat revenue as a shared product should reinforce that winning is not just simply signing a contract. Winning is delivering sustainably and predictably. This is of course not at the expense of commercial ambition. Our experience actually highlights that commercial ambitions have been exceeded as a result of this practice while still being able to offer greater technical integrity and psychological safety to our team. Drupal is often the underdog when competing with these large-scale proprietary systems. We believe that commercial maturity can be a key arrow in our quiver to take these platforms on and really showcase what Drupal can do. Drupal certified partners are committed to delivering quality. Commercial maturity and treating revenue as a shared product is central to that commitment. So we'll finish just by recapping those key themes that we laid out at the start. One, revenue is a shared product. Two, operating models drive behavior. And three, alignment protects both margins and reputation. The reputation of the agency and the reputation of Drupal itself. Ultimately, no one wins if Drupal is missold. Thank you. Uh so the QR code for the session and if anybody has any questions at all, we will do our best to answer. What? What? Yeah. >> So I lead a technical team and as such it's my job often estimate the development part of the job part of the job and one thing that strikes me every time I'm given a new proposal is how much work is necessary just on my part to get my head around all of the spoken and unspoken expectations that are behind that. you talk about sharing out the work delivery team so that the delivery team can offer this uh shared sales discovery process and putting their their input on what it would take to build what is being asked for but >> what I'm experiencing is like I have a lot of mental overhead to do that they have targets to reach >> have you delivery team talk a lot about the tension that exists for them between those responsib as you've given them this discovery responsibility on top of their billable targets. >> Yeah. No, and that makes complete sense because obviously right it's billable resource. So we have individuals in our team who within their job description is responsible for them to feed into new business and therefore they have that time allotted within their day to be able to do that. And I also work with them pretty closely and it's you know and I take on that feedback which is quite often I'm like hey you know Reese or whoever it is in our team I need this estimate. Do I need it today? Um, and what we do is basically try and make it as easy as possible to reduce that mental load. So, one thing you could do is make it a responsibility for someone in your sales team to actually consolidate down that brief, the key points, you know, because you've got kind of repeatable stuff in projects. It's always going to be saying where you know the the big risks, things we need to be aware of, really large functional requirements, security implications, those kind of things. And you can send them over on a handover dock. And I think we'd be remiss if we didn't mention AI. We've got about 50 minutes in and we haven't. Um so to bring it up that is something that can really help with speeding up that process. You can you know share that and get those breakdowns relevant for each role because it's not just developers you've also got the creative team who also have to inform there and there's completely different aspects of that brief uh that's going to be important to them. So just making sure they have accurate consolidated information that's going to reduce the amount of time is going to need to provide those estimates. >> Yeah. Thank you very much for the talk. I feel and see myself in my company and everything you've described and all of the pain points that you've talked about and we try to address them in different ways. Um, one of the things that we've always struggled with is trying to connect very beginning of sales and forecasting to the very end of delivery capacity. >> So, I'm curious about what magical tools you guys are using to do that. Um I I I uh don't think we have anything magical. I would say that I think forecasting very much is an art and not a science. Um which is why it's so hard to get your your hands around particularly when you're starting from the sales process where there's the likelihood of win through to delivery. I mean for us this is something that we're working on at the moment um around what uh percentages we apply throughout the sales process to uh our sales pipeline forecast and how that's integrated into our main forecast. So that's something that we found really helpful is applying kind of risk factors throughout that um early stage engagement. Um so that means that the revenue is almost kind of tampered down into what we're reflecting in our forecast. So therefore, if something drops out short notice, the impact we feel is much much less than if we had been forecasting at its full uh figure. That makes sense. Um but it's definitely something that we're continuing to evolve. So unfortunately, I don't have a a magic answer for you on that. >> Are you using Jira or um Harvest or any other tools? >> So we use Jira and Confluence for all of our implementation and then we also integrate that with float for our resource management. Um so we'll use th those two systems will talk together um in order for us to understand our utilization and then we also integrate with our own separate reporting system that we pulled together that kind of pulls in all our other data sources. So things like zero for invoicing uh the forecasting which is done in Google Sheets and kind of all pulled together in that way. >> I just wanted to add to that actually um on something Hannah mentioned in the presentation which is those joint meetings. So like I am on the So I'm on sell side and I am on uh the same meeting with our resource manager who is going through you know the float numbers and you know the availability we have and we can map that against the forecast then I'm able to then immediately communicate with her like hey we've got something coming in I need to give a you know realistic expectation to the client here and that is happening kind of iteratively every week and there's always that visibility and it really helps. Y >> I actually have a context question which is how how large is the organization, how large is the sales team and what is your annual revenue target if you can tell us that last. >> Should I get my CEO in the crowd? Um so uh in terms of size of the organization, start with the easiest one. Um we're about 95 now and as Hannah mentioned that's across three key offices. So our headquarters is in the UK where we're based and we also have a team in Spain and we also have a team in Brazil. Everyone is in-house uh within that number. Um remind me again your second question. >> Sales team >> sales team sales team is just well >> two to three of us because as Hannah mentioned what we have is overlap in roles. So Hannah's role is equally involved in sales as it is in delivery as well. And as I mentioned with those individuals um such as Drupal director and you know head of front end they have that team time baked into their uh job role as well. So they're equally as part of the sales team even even if they don't have the word sales in their bio. And I will keep the revenue target to myself if you don't mind. >> Any Oh yeah. >> Uh first off thanks for this overview. It's good to for us all to like just step back and think, oh, where are we right now? So, thank you for that. I do have a question about you. You talked about how forecasting should be like a shared responsibility. Um, as I'm thinking about that, I wonder if I have some confusion forecasting. That could mean multiple different things. By that do you mean that um within the build of a project and we're trying to see are we on target to get to the scope within the budget are you saying that that should also involve the sales team or something? >> So I am simply talking about forecasting the revenue. So in uh for an example um for our delivery team, excuse me, our delivery managers would be responsible for based on the project plans that they put together that they are mirroring that within our revenue forecast. So based on the number of resources they're using with a in a month, they're also capturing the expected invoiced amount within our revenue forecast. So we understand exactly what we're predicting to bring in within that month. in terms of the the context you mentioned there, that would just be the responsibility of the delivery team. But of course, there may be then feedback loops to sales if actually you're unable to to hit those targets based on the reality of the scope. But yeah, that's that's slightly separate to this. >> Again, thank you for sharing some gaps in our own setup, but I I'm also like Ben um I lead the technology team at an agency. have a moment in the process after we receive the RFP, we have opportunity evaluation >> which allows various people to crash on it um and see which is great getting expensive because >> we have the billable time we're missing out on but um it's important to get a lot of perspectives on the technology or what's being asked by the client really clear on what they're asking for uh to be skeptical of some of our own uh initial reactions to it. um which comes in really handy, but also in that moment when you're doing that because there is this the university example that you have about well >> great we're building a website we know how to do that let's go and and to put that like we can do it by us in check >> and to ask those questions of well what sort of infrastructure are we working with I imagine there's like a list of things you can go down at this point uh what what's that look like though to you when you know you have a budget of this the things here but in fact all these other things it could be infrastructure it could be like when you do more proper discovery how do you how do you approach that you have that is that a wellwn >> yes definitely um because we found that was actually we know when we're doing this a large gap um and what it basically is is making those assumptions explicitly clear in whatever you submit as a result so you can ask all the questions you need to ask up front but the reality is the client is not always going to have all the answers and sometimes not actually provide the answer to the question that you actually asked. So you know you can only act with the information that you were given but it's transparency and sometimes it feels counterintuitive but it is actually really helpful because you can then have in your assumptions based scope like you know we assume that you know hosting infrastructure is going to be X or you know whatever and then when it comes to delivery if those assumptions are misaligned and therefore that's going to introduce extra cost or resource or just a difficult conversation Then the delivery team are prepared with the necessary resources and documentation they need to be able to have those conversations. They can go back and say hey look during the process we said you know simple website build whatever it's going to be this much and these were our assumptions but actually it's transpired that numbers two five and six aren't actually correct. What do we want to do about that? How do we want to approach it now? And it just gives them the tools they need to have those conversations. I think we got time for one more if anyone has any more questions. >> That was basically my my question kind of surrounding that. And um like I'm I'm curious how often you come across these sort of assumptions that are sort of buried in the client or the potential client request >> that maybe they don't want to talk about in the RFP because they know that it's kind of a sleeping bear >> and you kind of know that they know and you also don't want to talk about it because you don't want to uh increase your estimate too much. And so like what is >> is do you come across that like >> me? Yeah. >> Yeah, definitely. Like you know what we're saying here is this is it is such a tricky balance. I'm sure everyone here knows that on being competitive and being realistic and there are always going to be things that trip you up. we are not standing here and saying that this is a perfect process where sales estimates correctly that wins the work and then we deliver it at 100% recovery rate that sometimes doesn't happen I think one of the things I mentioned at the start is the strategic decisions get made sometimes you accept a higher degree of risk tolerance and you feel that something is going to happen and we just got to deal with it maybe you take a financial hit at the time but maybe it's a client that you want to win because that you know is going to help you break into that sector that's going to help you break into that geography but it's being really precise on those decisions So you don't make those decisions and accept that higher degree of risk tolerance for clients where it might not add too much value to your portfolio. You know, it's choosing the correct places to accept the risk tolerance that you said something might be buried. It might make it more difficult, but we know that going in and we're prepared to take that because of all the other things that we've decided of it being worth it. I think also just to add to that in terms of what you mentioned there around perhaps you're aware of the things that might be buried but you don't want to bring it up. I think even going into the process being on high alert means that the team are aware and maybe looking for that and are treading carefully and they're of the mindset to have those conversations perhaps in their early engagement or help shape the outputs and they're mindful of it already rather than it being like they're they're treading on a on a minefield. Um, and I think that really really helps even if it you may still feel the the repercussions of it slightly. >> Not not to overstep but the alternative alternative view on that generally a question and answer period. >> Yeah. >> Response. >> And if you actually dig into those giant risks that they don't want to talk about, you can really build instant trust >> and actually get a leg up. Exactly. >> If you're dealing with the right people, right, and you approach it with compassion. >> Yeah. >> And so I assume you do that as well. >> Yeah, definitely. And you know, it's a key part of everything we do. And I think but what you were saying uh in your question I picked up on was sometimes you feel like if you're going to ask a question, you're going to get the answer that's going to force you to then increase your rest of it beyond what is in the budget. And that's where that kind of strategic opportunity prioritization comes into play. Do we want to accept that or do we not? Yeah, I know really quick. I just want to circle back. I mean that building the trust thing I know strategically, but it's also giving away that consulting but really giving it away. I mean offering it up, getting clarity prices. We've been in situations where we see an RFP. These people aren't professionals at building the profession. They're really good at the strategic tactical work they do daytoday. >> And when they're building RP basically freelancing and so they may not know exactly what they're asking. We've been in situations where we walked in propos >> and that's been incredible. >> That raised the question, do you do you frequently include contingency budget? >> Yes. >> Yeah. Where where we can obviously as I said sometimes working within those restrictive procurement processes where it's not possible, but where we can we do. So I do think we're out of time, but thank you so much for everyone for coming for a chat.