 All right, everyone, I'm gonna get started because I've got a lot to say and I've only got 45 minutes. So thank you for coming to my session which is called why estimations go wrong and how to avoid it. I know that's a very kind of lofty goals I have at the end of the session but hopefully I can give you some pointers and some tips to help improve things if nothing else. My name is Pamela Verone, I'm a client service manager at Previous Next which is an Australia sort of remote based Drupal Services Company. I'll talk a little bit more about our team later on but I've been doing Drupal for like five, 10 and a half years now I think. Been at Previous Next for almost five years so I've had a long time to make mistakes and learn from them. So the kind of hypothesis or I guess my thinking around this is that it's not the estimate that is the problem, normally it's the scope. So I mean estimating is simply trying to guess how long something's gonna take which it should be pretty easy as long as you know what the thing is that you're trying to guess. So if that's true, why do we screw it up so often? And I mean I think the thing I've found is that it's almost never because we totally guessed wrong and something took way longer than we originally thought although that does happen. Most of the time it's because whatever we estimated was not actually what we were supposed to be delivering. So the best way to get better at estimating is by getting better at defining what you're estimating so that's the point I'll try to get across here. So I'm gonna start with a real-life example of where this went horribly wrong. This probably looks like a really straightforward request. We'd like to add ReadSpeaker to our site. Can we get a message for that? And if you've never heard of ReadSpeaker it's a text to voice plugin that reads out webpages. They bought a license and they wanted us to add it to their site. Sounds pretty simple, right? But this is how we interpreted it and if you can already spot the problem, then well done. But we said okay, we need to add the ReadSpeaker module. There's a module for that. Install the module, turn it on. What could go wrong? But obviously that's not what happened. So the actual ticket that we had that sort of tracked this request was called add ReadSpeaker module. So the developer estimated adding the ReadSpeaker module. You know, came up with a massive total of 5.25 hours which is so precise, but so wrong. And in the end we spent over 60 hours implementing this request and nobody was happy about it. Why did it take so long? Well, a lot of reasons. But I mean, I could talk a lot about sort of in this specific example what went wrong but the module provided a block. They wanted it to be under the header, not in the header and we were using panels and in place editors so we had to write this crazy update hook that moved the block into the right spot on every single page. And anyway, that was like one of the things that kind of took this request totally off the rails. And then also there were actually two sites that we had to do this on and I highly doubt that that was factored in. So what did we do wrong here? Well, first of all, it doesn't seem that we asked any questions whatsoever. We want the ReadSpeaker module. We want ReadSpeaker, we'll add the ReadSpeaker module if that's what we did. We'd never done ReadSpeaker before so we had no idea of what things could possibly go wrong. And based on that we should have probably assumed it wasn't gonna be just a simple case of adding the module. And also, we didn't specify to the client that what we were estimating was adding the module. We said, we didn't clarify it all. We took their request and we said, that's gonna be five hours. So they said in their heads, okay, the thing we want is gonna take five hours. And then the last mistake we made was throughout this process of eight months there was very little pushback on them to say, hang on a minute, I understand that you want to keep doing more and more work on this but that's definitely not what we originally discussed and we're kind of feeling like this is going a little bit above and beyond. And I think once you start heading down that path it can be really hard to catch much later. You have to kind of nip it in the bud straight away and say, hang on a minute. I understand that this wasn't clear but what we were actually estimating was just adding the module. Anything that we need to do further than that we're gonna have to discuss that. So just a little bit about my team. We're a small company of about 15 to 20 people, mostly devs. And I have to mention that we are our top five core contributor by company which is, we're pretty proud of just because we're small so compared to a lot of the big shops we probably punch above our weight. We're Drupal specialists as well so we do a lot of integrations with our systems but we don't develop in other systems. And we take an agile approach so we don't really have a sales team. We have a few client service managers. We do sort of all of the selling, new business definition, basically all of the client management stuff. We do begin small projects so they can vary in size from 20 grand to 500 grand. And we have a lot of long-term clients which means we have a lot of ongoing work that requires a lot of estimating. So just to talk through some of the things we estimate and why, this example is probably the one everyone's familiar with. You've got a 10 very, you have to guess how much it's gonna cost to build this site. In this case you kind of have to find a balance between estimating too much and losing the project and estimating too low and then being on hook to deliver something that you can't. So these are usually high-level estimates. We try to do relative size, so 32, 16, 8, that whole thing. This is often the hardest to nail down because you don't usually have a lot of detail and you have to come up with something but you don't wanna spend six months working on a tender. You don't wanna bother the client too much but you kind of have to just take a stab in the dark, really. The next one is once you've won the project you have to actually estimate the broken down features. In this case the project's been approved and you just need to basically figure out how much you can get done in a single sprint so you break it down to stories and you estimate those. We try to do relative size for those but you have a lot more information there, it's a lot more specific. But the other thing to note here is it's usually not critical to be accurate to the hour on each ticket because if you have 100 tickets in a sprint some will go over, some will go under, we don't really labor over this too much. And this is the thing we do the most. It's the most tedious, it's the most frustrating and it's sometimes the most agonizing but it's usually something really specific and this will come from a client that we've been working with for a long time. We've probably done a big project for them, we've got a number of littler projects, sometimes they're not that little, sometimes they are, that come up kind of all the time and your client will say, hey we wanna start running ads on our site, how long is that gonna take? It can be anything from half days work or a couple of months of a mini project. But I mean I think the key thing here is that there's no feature that's too small to be properly defined because as we saw with the Reed Speaker example, the little ones can be the biggest problems. And again as I said, this is actually the bulk of estimating that we do, this is definitely what I spend the most of my time on. So this is kind of what I came up with as guiding principles of how this should all work and this all should happen before you even start to talk about numbers or cost or estimating at all. So the first thing that I sort of strongly believe is I need to understand what the client is expecting us to deliver and how we're gonna deliver it. The second thing is I need to be confident that what I think the client is expecting is actually what they're expecting. And the third thing is I need to ensure that the developers have enough information to implement the feature successfully. So I think these are really useful to kind of come back to before you send it over to a developer or a team to look at, just think have I met these three principles? And I mean obviously the degree to which you can confidently say you have it might change and you might not be super worried about it because it's a client that you've worked with and you trust and you're not really stressed, but it's really good to kind of think back and go, wait a minute, before I go any further here, have I met these guiding principles? And this is just a really kind of, it's just a description of how we do this. So we spend a lot of time estimating and as I said, I do this a lot, like pretty much every day I'll get some kind of request. So I try to make it as painless as possible for everyone. It can be really challenging to spend the time that's necessary to do this because you're busy doing work that's being paid for so no one wants to drop that and deal with estimates. I mean I'm sure that you've all had this experience where you ask someone to estimate and you get an eye roll. I mean I roll my eyes often when I get those requests too so I can't really talk. But anyway, what happens is the request will come in, the project manager who works with that client will assess it, ask the questions that are really obvious, send it back to the client, get some information back, send it on to a dev, dev hopefully asks a couple of questions, sends an estimate back and then we add some buffer for testing and we do peer review and we have automated tests. So we always add a little bit of extra time for that and for communications and that kind of thing. And then we send the estimate on to the client. But just one thing to note as well, probably can't say this is entirely true but we try to make sure that all of our estimates are vetted by devs so we don't have a situation where someone went off and said, oh yeah, I've heard of a module for that, that'll be fine and then the dev team guessed it and was like what the hell, there's no way we can do this. So we try to avoid that at all costs. And this is a quote that I'm sure all actually said if we haven't said it ourselves, we've heard it, not just in my company, I think in the software world in general, this is something you hear a lot. But the thing is, what's more likely, right, that every develop in the world is terrible estimating or there's some other point of failure in the system? And I think that it's really important to kind of think about where you're going wrong. And I mean the read speaker example is a good example because the developer didn't necessarily give a bad estimate but he was estimating the wrong thing. I mean but he was specifically told I had the read speaker module so he went okay, that's easy. That's not gonna take me more than a couple of hours. But of course the problem that we planned to solve was not the problem that the client needed us to solve. So I think it's really important to engage your developers in this kind of discovery definition process and ask them questions, challenge them, and say you okay, you said four hours. If I ever get an estimate that's just a number, I'm like wait a minute, tell me what are you actually planning to do here because I need to know what it is before I can go and tell the client that this is actually a reasonable estimate. And I mean I think obviously it's important to note that some developers are better at estimating than others. I think some are probably better at understanding their limitations and what could go wrong and the kind of common problems but the ones who consistently estimate poorly are the ones who never ask any questions. So I think that again this should be ideally not a one-sided process of me trying to extract the information that I need. I don't wanna be constantly being the one to challenge. I love the developers who come back to me and say I don't think you've thought this through. There's these three things that I've already thought of that could go wrong. You should find out what they wanna do here. I don't think this is the best way to do it. I love getting that back. I mean in an ideal world I wouldn't have to because I would have done it perfectly but I know that I don't always. So when I have that interaction back and forth and I'm getting a challenge I feel much more confident that we're actually doing the right thing by our clients. So I mean, yeah? Sure. What does that mean in the US that you're in the city or are you fully aware of the city or are you trying to see the possibility of that? The question was whether we engage with a single developer or go to the team. It depends if it's a project that's actively happening. We do team estimates but if it's something where it's a retainer or it's a mini project I'll just pick the developer who I think knows most about it and then also will probably be the developer who implements it because that's another thing that I'll mention later. But yeah, I mean it just depends on the situation but because we're a small team we don't really have sort of hard and fast rules. It's just kind of like I need to get this done. What's the fastest, most efficient way to do it and then I'll sort of figure it out on the spot usually. But I mean I think the thing here again is that there's open communication and I'm not gonna get mad at them for asking questions and I'm not gonna yell at them for not just doing it and I mean I really rely on them to help me and make sure that I haven't missed anything. And I mean I think that the fact that I try to respect their time by making sure I'm not passing them a totally insane request that makes no sense I think that they kind of reciprocate that by trying to help me out and not making me look like an idiot so that's useful. And then also I kind of alluded to this before but it's good to create some just general guidelines. Like I said this is not hard and fast. We don't have specific rules but these are just some things that we've come up with which by figuring out the pain points that we've had we've kind of tried to come up with some sort of guidelines. So the first one is whoever does the estimate leaves notes. As many notes like a bit gives as much of a detailed synopsis as possible what they're planning to do and that's for two reasons. The first reason being they might not be the developer who implements it but the other thing is sometimes it's like four or five months before the thing gets approved and then you go back to it and you're like what the hell are we talking about? How the hell are we planning to do this? You know it happens to us all the time so this is just kind of a you know make sure you've written notes about it. And the other thing that I often find happens is if someone estimates something as eight hours or 10 hours it turns into 16 really quickly because they go oh well I forgot about this thing that I will have to do you know I forgot about this. So anything more than four hours just break it down and say these are the things that make up the eight hours and you'll often find that it's maybe actually 10 or it might be 12 and that's a much better way to get an accurate estimate. And then anything longer than 16 hours this is probably the thing we've heard to least but anything larger than 16 hours should be sort of standing checked by another developer because we often have where one developer will say oh that's 100 and then another will go no that's 20 and then it's like oh well that guy knew a way to do it but the first guy didn't and they can talk about it and say oh okay actually I see now how you could do that in 20 hours. So these are just oh yeah in the review this is one that I always have to try to remind myself. The review time is proportional to the amount of custom code so if you're estimating a feature that's just adding a module or just updating some configuration adding a content type you probably don't need massive peer review but if the task requires developing a huge custom module there's probably gonna be about five rounds of review and arguing over the best way to do it in core and just make sure you factor that in. So these are just some examples of things I've kind of come up with along the way as I've noticed patterns of things going wrong repeatedly. And so when in doubt allow your developers to spend some time up front to do some spikes or whatever it is so I gave this talk at a camp in Sydney and one of my developers was in the audience and he asked me at the end or he kind of raised his hand and I said well you know estimation's hard and you don't always know the answer and I was like yeah I know that's totally fine so if you I mean if you didn't already feel comfortable just coming back to me and saying I've never done this before maybe you should ask someone else or I've never done this before can I spend a couple of hours on it and make sure that the approach that I'd like to take will work. I say absolutely do it now that's not a problem and I mean you will find that you're maybe spending time digging into estimates that then don't get approved but it will more than pay for itself by kind of avoiding that read speaker situation where we spent 60, we got paid for five, we could have done a lot of spikes in that time to avoid that problem. So I mean you know whenever it's a new module if it's a new feature if it's something that no one's ever done before just spend some time on it ask around to the team probably someone else has done it before or has made some mistakes and kind of learned things that will decrease the time it's gonna take a second time. And the other thing I'll say is I have one developer who always asks me for a design and it absolutely drives me crazy but he's right like nine out of 10 times that we should do and not necessarily a fully you know pixel perfect design but we should do some kind of mock up to say this is what this page is generally going to look like and then the client can't see it and say yes that seems right or no just rearrange these things because it's a lot easier to do that in the design process then after you've implemented it. So encourage your developers to feel totally comfortable suggesting any of this and if they ask you for it then let them do it. And then just if there are any developers in the audience I would just urge you to try to take charge and try to push some of these changes through. So if you're a developer in an organization where you're constantly being held to unreasonable estimates or being made to estimate without enough information just push back and try to enlighten the people above you and I would say that if you work in a place where you aren't empowered to do this and you're gonna say well my boss doesn't care it's like well you should probably get a different job we're hiring so talk to me after. So yeah if you don't have enough info don't estimate it. So this is the next sort of piece of the puzzle is the impossible clients who are always changing their minds and adding to the scope. So I've heard this so many times I've said it myself but I think the thing to really remember here is clients aren't doing this on purpose most of the time. I mean we have some clients that you're like really but most of the time they're not trying to do the wrong thing they're not trying to withhold information from you. They just really don't know what to ask for. So I mean most of my clients are not tech savvy they're not they don't have digital backgrounds. When they ask for something sometimes it makes sense sometimes I have no idea what they're talking about but the thing is they don't necessarily know how to phrase it in such a way that they're gonna get back exactly what they want. So it's really on me to interpret what that is and not just do the thing they say to do. So I always try to reframe the request. Sometimes there's gonna be really specific requests like we need a new fieldable panel pane type that will do X and I say wait a minute what are you actually trying to solve? Like what's the problem that you're trying to solve? Don't talk to me about fieldable panel panes. Step back what's the problem? Let's talk about the best way to solve it. And I mean this is not enough on my clients but the best way to solve it is almost never the way they thought it should be solved but that's because they don't spend their whole lives in Drupal building websites so I don't expect them to know the best way to do it. In fact if they could tell me the best way to do it then probably I should get a different job. So like I said I haven't yet requested a really specific and they might not make sense to me so I just try to step back and say what's going on internally? What process is this for? What process is it part of? And then we can come up with a much better way to solve it. So if we just estimate the thing that they've asked for we've done something but we haven't really done our jobs which is to play that role of interpreter and deliver the best value. So I mean I've mentioned this already but definitely ask questions. I mean I can't even think of a thing that we've ever done where we didn't have to ask any questions to get some better idea of what we had to do. So ask things like how did you envision this working? How will you use it? Who will use it? How often will you use it? Why do you even need this? Are you sure you need it? Is there something else we already have built that might actually solve this problem? And a quick note to the client. If you get an estimate back without having been asked any questions you should be very wary because it's unlikely that you're gonna get what you want. And then the other thing I've sort of found is that you should be really specific and this is something that I kind of picked up from my partner who has a painting business and whenever he does a quote he specifies exactly what's included so prep two coats of paint, cleanup or standing, whatever. And the reason that he does this is because sometimes he'll give that quote to the client and the client will say I actually think it needs three coats and he can say okay sure, I'll add that to the quote. But then you're not in a situation where he goes in and does the work, does two coats and then they're saying I think it needs three coats and you're arguing about what you had said you were gonna do because it wasn't actually totally clear what you were gonna do. So provide specific detail of what you're planning to do and again in the Reed Speaker example that would have helped because it might have triggered it might have, I don't know if it would have but it might have triggered a conversation with the client to say well adding the module that sounds really easy, why do I have to pay you $2,000 for that, which is a valid question. And it gives them an opportunity as I said to spot things that might be missing. So oh I can see you've put these five things in but we also thought we would get this and then you say okay sure we can add that and we can estimate that. And then also it gives you something to reference if you need to push back on scope later. And again as I said with the developers it's really important to just be honest. Sometimes you really don't know how long something's gonna take and it's totally fine to say this. If you don't have that kind of relationship with your client where you can admit that it's something you're not familiar with that's probably as much of a similar problem. So if we're unsure it's up to them to decide maybe they'll approve a small amount of time to do some investigation or maybe they'll say you know what it's not that important don't worry about it. One other thing that I think is really important is I think a lot of processes try to paint all clients with the same brush. And I know for a fact that every single one of my clients works completely differently whether it's just their personality or the environment they work in, who their boss is, all those kinds of things. You need to use your previous experience with clients to assess what type of client they are and what type of estimate they're after. So we have some clients who don't mind iterating they'll they're happy to pay for the MVP and then keep building on it as they go. But then I have other clients who it's a huge pain in the ass to get budget approved so they'd rather have me double it, try to do it in as little time as possible and then they can use that extra time on something else that they want. But the thing is they'd much rather go over than go under. So I just know that and I factor that into the estimate that I deliver. And if it's a new client of course you should assume the worst. Yeah. Can you have like any specific way like how to put on a client? Some people like they have this, they don't like to see and they put on a client. No. No, so the question is, do I have a process for how to do it? No, it's just to, do you just get to know them? I mean, again, I think that's basically what my job is, is to make sure that I'm doing the right thing for them. And I think if you have a client's first manager that can't do that just in their head, maybe you should give them a different job. I don't know. So the thing with this is that it's not just about covering your ass and saying we had it on paper so you can't sue us now. That's really, really not the point. But the point is that having it down and having it established before you start it makes everything so much easier and smoother and more efficient. So as I said earlier, it's much easier to make a change to a design, to move something and change the layout than it is to change that post-implementation. So you're much less likely to have surprises and have that kind of awkward, all this isn't how I thought it was gonna work, conversation, because you've already established how everyone thinks it's gonna work. So this just makes everyone happier because even if you do have enough time in the estimate to make the five changes that came up because you didn't do a design, that's just not really fun. I mean, no one really wants to work in that kind of environment. So I mean, like I said, this really isn't about forcing someone to sign a piece of paper that says they agreed to a certain scope. It's about trying to establish the scope to get the best result. How long does it take for all of this to be possible to talk about versus how do you think it will be possible to do the right balance and do the right balance? Well, I mean. The question was about how to balance feedback on designs versus feedback on so forth. And I mean, I think that's obviously, we're not doing pixel-perfect full-page designs for every single feature. It's really just about like, it could even be just drawing on a piece of paper to say, this is the order that the filters are gonna go in or this is where this field is gonna sit. I mean, we had a pretty small task recently that totally exploded because the client wanted to search, should we establish all the fields that they wanted searched and then when we built the page they were like, oh, well this should be here and this should be here and I don't think this should happen at all. There were all these things that if we had just drawn a picture we could have delivered it so much faster. And again, the developer had the shits because he's like, well no one told me that's what you needed and the PM was getting should be with the developer and the developer's not happy either so it's just a totally losing proposition. But I mean, I think we don't do full-page pixel-perfect designs really ever anyway. We do design components so we don't really have that problem but maybe I'll talk a little bit more about that later. I still have a lot to get on with. So just lastly in terms of process you do need a really good team of people to kind of execute this properly and we have an awesome team so they make it really easy for me. I think the key thing with us is that we all feel like we're in it together so I feel responsible for making their jobs easier they feel responsible for making my job easier and kind of ensuring that we're all working toward the ideal outcome. Not everyone fits this model. We've had developers in the past who didn't fit this model and didn't work out so I think didn't really work out for either side because the person in that position didn't want to have that obligation to the rest of the team and we felt like they weren't contributing equally because they weren't providing that interaction. So for me, I think, and I think with a lot of us in my company this is a lot about self-preservation and not necessarily because we all feel an overwhelming desire to make the business succeed even though we do but the thing is, as I said it just makes your job a lot easier if you have clarity and you have confidence and you have that understanding among your team. It makes your day-to-day life better which is much bigger of a concern for me than the profit share or whatever that the kind of money side of it. But the profit share is nice to have. Again, talk to me after if you want a job. So just going back to the Reed Speaker example there are a few ways we could have done it better. These are basically two different approaches we could have taken. So the first approach would have been to explain we were only estimating for adding the module because we didn't really know what was gonna happen after that. It might work. There might be more stuff that we need to do. This would have been really cheap. Five hours is really not a lot of time and it would give them a chance to kind of see what they're getting and then take it from there. But the second thing we could have done is just spent some time up front working with them to establish what the details were including that they wanted the button to sit under the page title which was the sort of critical piece that we missed. This would have taken some time on our part but we probably should have just even installed the module on the pull request site and shown it to them for free and then we could have charged them for the time we spent and the additional work after the fact once we'd known what it was. So like I said with the client profiling which option you choose and you might have a totally different approach just depends on what type of client they are and again if it's a new client then make sure you've done the second one. Don't do the first time. So looking at a more successful approach that we took to a kind of open-ended feature this is an actual request that I got. We'd like to add a blog for our site. Someone told me Drupal has a plugin for that. And when I get these requests this is like a definite eye roll triggering request but actually this is a really good opportunity because the way I interpreted this was they know they want a blog but they don't really know much more than that. Their expectations are really non-specific and this is a great opportunity to collaborate with them and work incrementally to deliver something really well suited to what they needed. So what happened next was I explained that this blog plugin was in fact a module that enabled a content type. So we turned the module on on the Dev site explained how the content type worked showed them exactly what a blog in Drupal gives you out of the box and this gave us a foundation to basically start the conversation from okay this is what you get for free now what extra do we need to add to make this blog viable for you to make it achieve your goals. And we came up with a list of requirements like tagging and landing pages and topic pages and all this kind of stuff and we estimated each feature separately gave it back to them they decided that some of the features they asked for like subscription and notifications oh we don't really need that yet let's see if people are actually reading this thing first and go ahead with the basics. So we didn't end up arguing it all about what was included, what wasn't included there were absolutely no surprises it probably took a little bit longer because there was a lot of back and forth with them but on the other hand this gave them the opportunity to showcase it with their stakeholders and show people and that way again none of the stakeholders were shocked by this thing that they had paid a bunch of money for because they knew exactly what it was going to be. So in this case the client was really happy and the team was also really happy because they knew what they had to deliver and they were able to deliver it well. Yeah. So the question was if we spent two hours installing a module would that be done as a paid constitution? In this example they had a monthly retainer and that's actually something we try to set up with all of our clients because just a couple of hours a month to do minor things like that and I would say if we didn't have a retainer I probably would have done it for free because I knew they wanted a blog and I knew there wasn't gonna be like a fishing exercise of it wasn't a competitive tender so it wasn't like they were gonna go get five quotes and I knew they were probably gonna go ahead with it so I would have spent the time anyway spent the two hours or whatever it would have taken to set it up, talked to them and then that would have been we would have been able to recoup that cost in the actual implementation. So something like two hours would never bother me about doing it for free. And then the last thing I'll say is that you should just know when to say no so some estimates just can't be done. So this is another request we got for a new page for events where we can add lots of different content and lots of different layouts. We don't really know what it is yet but it has to be totally flexible. So Chuckles suggests that you've all been there before. So the way I interpreted this was basically the polar opposite of the previous requests it's really vague still but they seem to know exactly what they're expecting whereas I have no idea how to deliver what they're expecting. So this is a huge red flag for me, right? Expectations are clear but details are not there. So what ended up happening with this was we communicated about Comfort in a lot and I really tried so hard to try to get the information because I knew they really wanted it but I just in the end said look I can't estimate this for you come back to me when you've got some more details you'll need to know the details anyway if we're gonna implement it so I'm not gonna give you this open-ended estimate that could totally blow up in our faces. They were not really happy about it because they just wanted us to do it but I think that kind of relationship where you're getting and taking orders from your clients and then just giving back something kind of rubber stamped is a really bad working relationship and you should try to reshape that into something a lot more collaborative anyway. So we didn't get this work but totally not a problem nobody's unhappy about this because I could see the train wreck coming from a mile away. So just to wrap things up, this is cheesy but it's kind of speaks to what I said earlier which is that I really don't think that there's black and white process or a set of rules or spreadsheet that you can make that's gonna make this process perfect. I think it's really about following your instincts and employing people who have good instincts, employing teams that can work together really well and just to kind of summarize, I mean the key thing again is just to understand what you're estimating. So make sure everyone understands it, make sure the client understands it, make sure the client service manager understands it and make sure the devs understand it and if you're finding that you're having a lot of problems with your estimates, do an honest assessment of your process and don't just blame it on your developers because it might not be their fault, just a possibility that might not be their fault. So really try to engage your team, make them feel empowered and collaborate with your clients, there's nothing scary about it. Like I said, I do roll my eyes sometimes but it's obviously a really necessary part of the job that we do and I wish we didn't have to do it, but we do. So yeah, just be open and be honest and that's it. So any more questions? Yeah. In the beginning of the video, my choice seems to weigh in on the future of the job, do you agree to adopt these terms and why we don't follow them? Well, I mean, we use agile processes but we sort of loosely use scrum, we don't really subscribe to a single agile philosophy because as I said, I think having a one-size-fits-all process for all your clients, it doesn't work for me for sure, it might work for some people but I find it much easier to just tailor the process to whatever it works for the client. So we are agile in the sense that basically we don't do fixed price quotes when we are quoting something, we're estimating hours and then we burn down from those hours. So that's really what I meant. I don't know if you had more. Yeah, which is a small part of what you're talking about. My control was when you say the explanation but the goal was to do the explanations and the explanation was normal. Yeah. It usually makes sense to be multiple developers and they can change the context. Yeah, I think, so the question is about just how you estimate it and whether it's one developer. I agree that it's better to have a team but we couldn't feasibly get a team to estimate everything that we're doing because that would take the entire week, would be estimating. If every developer had to be involved in every estimate, it just wouldn't work. So there are definitely times where we have to go to a single person but I mean again, I think, I trust that if I give it to a person who doesn't know that much about it or feels like they aren't confident, they'll go ping someone and say, hey, how does this sound? Or they'll say to me, I'm not sure you should probably run this by someone else. So I feel like again, it's not a case of like, everybody job everything we need three people to argue over an estimate because I think oftentimes that isn't really productive. It's just more about like sanity checks and making sure that it's not totally crazy because like I said, you know, it doesn't have to be down to the hour accurate. It just has to be accurate enough to get you over the line. That's like to make a comment. Sure. If you're interested in a question like, we use a process where we go through a similar estimation process for going with one where we consider factors to be colluding with that your equation is more complex than ever. And then we use a new term, strong process, to do this summation in regulating the execution. Yeah. We're actually assisting the person to take his progress against the result. Yeah, so the comment was just that there's kind of a re-estimation process after you do the big estimation among the team, because yeah, when we do a tender, we obviously don't get our whole team to estimate it. We get a single dev and our tech director to make sure it's not wildly inaccurate. But because we work in an agile way when we do an estimate for a project, like I said, we don't really care if the content migration was estimated at 100 hours and it takes 120 because we're banking on that 20 hours being made up somewhere else where we overestimated. So that's kind of a confidence that we had that is not gonna go, it's not gonna go too wrong. Any more questions? Yeah. I'm hearing one of these estimating problems that the wrong people are estimating. Yeah, but I don't mind that. I mean I think, so the question is about overestimating and the reason I don't mind it is that we don't charge a fixed price. So I don't feel bad if we estimate it at 50 and it took 25 because the client can either not pay for those extra 25 hours or they can use them for something else. So there's really no, I mean you wanna be accurate because you don't wanna put them off of a feature because you've scared them off because you thought it was gonna take twice as long as it did. But I don't really see a huge downside in overestimating and I often find that developers will say, oh, you know, is it okay if I say 16 and I'm like, make it 24. You know, like it doesn't really matter because we're only charging for the time we spend so it's not like we're scamming or we're trying to steal from people. We're just trying to make sure, you know, I'd much rather be 10 hours over than the four hours under, you know. In the human way, when you estimate five and they're just 16, how would you deal with the client once you go to the client for the entire hour? Well, I have to say I was not actively involved until it hit about 50 hours because I sort of saw it happening and then I jumped in and was like, hey, hi, everybody, stop what you're doing. This can't go any further. So we should have stopped at five but we didn't. So definitely that's what should have happened and I mean that's another point to make is if we estimate eight and then after four, we know, oh my god, it's actually gonna take 40. Just stop at four, go back to the client and say we were completely wrong about this. I understand that's really frustrating but let us know if you wanna proceed and if you don't, that's totally fine. We will eat those four hours. So that's another kind of example of where you need your team to be putting their hand up and going, crap, I was way wrong, I'm really sorry, what do you wanna do? And it's not a case of like, how could you do that? It's a case of like, oh, okay, thank you so much for telling me before I got out of hand. Now let's just deal with it. Yeah. Well, I think people on the planet's going to be able to do their hours so they can go to the United States Department and so on. Yeah. And if you go out and find out, I think we're gonna have to go to the United States Department. Well, we would never have committed to like, you could have all of your wildest dreams for five hours. When we give an estimate, we're gonna say, we will spend up to five hours on this. So like, if they were gonna come back and say, that's not what you promised, then like I said, kind of before, that's really a relationship issue and we hopefully don't have any clients who would have that expectation that it's not gonna become a fight because we've been really upfront about the fact that all along we were gonna spend five, see where we were at that point and then adjust from there. I mean, if we said five and it's gonna take seven, it's not a huge deal. We might just choose to wear that cost. It's really a case by case basis. Sorry? No, just potentially. I mean, it's a case by case thing. Like there are sometimes where the review went a little bit over and we spent two extra hours and if it's a client we've worked with forever, I'm not gonna quibble over that amount of money. It's just not worth rocking the boat. But if it's happening 10 or 20 times a month, then obviously that can add up. So I think if it's not happening a lot, then I wouldn't worry about it. Did you have a question? I was sort of interested in what would happen. Sure. So what are some of the five that you're trying to see in person that you're trying to ask, and does that have a positive impact on you? Well, I think, so the question was if you get to five and you haven't gotten to what they wanted because the scope was, or the deliverables hadn't been firmly established. I mean, I think that, like in that example, we definitely could have known that we could have installed the modules in five hours. So that's why I say that we should have said that's what we're doing is installing the modules and that way there's no, so you can't be completely open-ended about it unless you have a client that's totally agile and totally on board. You do have to establish some kinds of, you know, yeah, boundaries exactly. Murray's waving at me, I think we're out of time. Okay, thanks everyone.