 Hi everyone. Thanks for coming. This session is why estimations go wrong and how to avoid it, which I know is a fairly lofty title, but hopefully I can at least give you something useful to help you out with this problem. My name is Pamela Broan. I'm a client service manager at a Drupal shop based in Sydney. I'll talk a little bit more about our actual organization, but just a quick intro there. So just getting right to the point, the sort of hypothesis of this talk is that the estimate is not the problem. The scope is the problem. So if you're constantly finding that you're missing your estimates and your team is bad at estimating, it's highly likely that the problem is that you're not defining what they're estimating well enough. Because I mean estimating is just guessing how long something's going to take, right? So that's actually not that hard as long as you're estimating a specific thing. It's generally not that hard to get somewhat close. So I mean if that's true, then how come we mess it up so much? And I mean just looking back at some of the worst cases we've had, it's almost never because something took way longer than we thought. It's because whatever we estimated was not what the client was actually expecting and so we had to continue doing other things in order to satisfy their expectations. So the best way to get better at estimating is by getting better at defining what you're estimating. So this is kind of a real life disaster that I'll take you through. And it seems very simple, right? We got a request from a client on a site we built that they'd like to add ReadSpeaker. Can you please estimate this for us? If you don't know ReadSpeaker is a text to voice plug-in that you can add to your page and it just reads the page out. So there's sort of a play button and it just reads the page. So they had bought a license for the software and they wanted us to install it. So it's a pretty simple reasonable standard request like what could go wrong, right? This is how we interpreted it, right? So if you have ever used Drupal before you can probably see where this is already going off the rails. So what happened next was the project manager who's in charge made a ticket that actually said add ReadSpeaker module. The dev estimated adding the ReadSpeaker module at a whopping you know like four hours and then the project manager added some buffer making it 5.25 which is like really oddly precise. And then eight months later we had spent more than 60 hours implementing this feature and as you can imagine the client was really cranky and the devs were really cranky because this was like the never-ending story. So I mean as I said if you've ever dealt with a Drupal module before you can probably sort of guess where this went wrong. But what that took so long? Well a lot of things but basically the module provides a block. I'm not going to go into the graphic details but we couldn't place the block exactly where they wanted on every page because we were using panelizer and so you know Drupal, Drupal, Drupal. We had issues with regions where it was reliant on a region and the region didn't exist on certain pages so every time we thought we were done they kept coming back and going ah it's not on the search page, ah it's not on the landing page and so it was just like this never-ending cascade of continuing continuing effort. So a lot more things went wrong than I won't bore you with but the other final sort of nail in the coffin was they actually had two sites we had added to both sites in the five hours which just didn't work. So what did we do wrong? Well first of all we didn't ask seemingly any questions right? The client said we bought the thing we added to the site and we went yeah okay sure it's probably easy. We didn't account for never having done this before so read speaker was new to us it wasn't something we'd ever used we were completely unaware of what might go wrong but that obviously you need to kind of just look out for that and not just assume that it's gonna be easy. We should have assumed like I said it wasn't gonna be just a case of adding the module we probably should have downloaded the module installed it tested it out saw what it did and then kind of went back to them and said hey so this is all well and good but where do you want it you know what other kinds of customizations might we need to make and we didn't we didn't tell them honestly that this was what we were doing we're installing a module right we estimated installing a module that was nowhere near what they expected installing the module wasn't gonna give them what they wanted and then finally sort of a organizational issue we didn't we didn't push back on the requirements as they kind of kept coming at us we didn't sort of stop and say okay you know we've kind of met the original sort of the initial implementation let's step back see what what else you want how long it's gonna take and then kind of maybe re-estimate you know it took eight months for us to finally get to that point so then just to bring back a little bit about our team we're a very small mostly dev shop so about 15 to 20 total on our team depending and we're actually one of the top five core contributors by company so gotta mention that we're agile no sales team we have a couple of client service managers and we have just kind of like a small team everyone everyone helps out our projects vary in size from about 20 grand to about 500 grand and we have a lot of clients we've worked with for many years so it's a lot less of the procurement side and a lot more of kind of constant requests from existing clients to do new features new projects that kind of thing that kind of thing so what are we estimating on a daily basis just a couple of things quickly that we do right there's pricing a large project for a tender and you know in this case you don't want to estimate too high and lose the project but you also don't want to estimate too low and be on the hook to deliver something that you can't and you end up losing money so this is usually really high-level estimates based on sort of relative size and it's often really hard this type of estimating is really hard because you generally don't have a lot of detail about what they're expecting but you kind of have to come up with something and you can't workshop every single requirement in order to respond to a tender but I think the same strategy sort of still applies even though it's at a very high level the next thing is sort of is what we do a lot more often which is in sprint estimating after the project has started we're just trying to estimate the actual stories for planning purposes so the client can prioritize and so we can kind of plan out what we're going to do in each sprint this is obviously more detailed than a tender but it's not as important to be sort of accurate to the hour because you're doing you know say a hundred stories it kind of averages out so you might be high on some but hopefully you'll be low on others and then this is actually what we do the most of generally like this could happen every single day there's something we're estimating that's usually something pretty specific so it could be anything from a half day's work so you know we need add a new field or a new filter to we have a new site that we need to build we just need an estimate so that we can secure the budget but I mean I try to treat everything as sort of its own little project because there's really nothing that's too small not to spiral out of control as we saw it with the reed speaker example so this is as I said the bulk of the estimate that we do is kind of the daily back and forth with existing clients and this is kind of what I've arrived at as my guiding principles of estimating first I myself need to understand what the client is expecting us to deliver and how we're going to do it so I take that on as my responsibility as the client service manager I also try to be at least somewhat confident that what I think the client is expecting is actually what they're expecting because thinking that I know is not as good as actually knowing and then lastly I also think it's my responsibility to ensure that my developers have enough information to implement this feature successfully ideally on the first try but hopefully just without too much frustration when we get a request that comes in this is just generally what happens the client will contact me or one of my colleagues on the client service team will assess it ask any obvious questions we can think of send it on to dev they'll ask us questions we'll ask the client questions it's kind of a circle of communication and then finally when we think we all can agree on what we're doing we the dev will estimate it the project manager will add some buffer you know for testing and communication stuff like that and then the PM sends the estimate to the client so one thing I will stress here is all of our estimates are on some level at some point vetted by a developer so we don't have any sort of sales team that's coming to us and going here we pitch this project you you have to do it in this amount of time because that's what we said so we just don't have that dynamic at all any work we do is going to be estimated by a member of the team who's going to do the work I mean because we're a small team we're all accountable in this sense so you know if a dollar goes off and does a really bad estimate and then someone else is on the hook for it they're gonna feel like a jerk and so we kind of the size of our team enables us to really work together and collaborate and then I mean one other thing I mentioned is it can be really hard to find the time that's necessary to do this properly especially when we're really busy so we have to kind of keep reminding ourselves that work is more fun than estimates but the estimates are how we get the work so we do have to kind of remind ourselves to focus on that and I don't know if anybody's ever said this before I'm sure you've all heard it before but it's not just my company and it's not just Drupal and it's not just web development it's sort of software development in general you just hear this right devs are so bad at estimating but I mean I think that the critical thing here is like what's more likely that all developers are terrible at estimating or that something else is kind of going wrong in this process the read speaker example in that case the developer didn't estimate it badly he was told to estimate something and that's what he estimated it turned out that what he estimated was the bad thing so you know in that case we planned to do a thing that didn't actually satisfy what the client was after and then like to be sure some devs are kind of bad at estimating but I think that the ones who the ones on our team anyway who are consistently good are the ones who consistently ask questions and try to challenge and try to find out exactly what they're being expected to deliver and the ones who continually miss are the ones who kind of oversimplify assume that they know what it is and don't actually tell you that they're unclear about something until it's too late so I mean I think the key thing here is that we don't treat this as a one-sided process of like chuck a thing at them then they chuck it back and then you know I'm like well I don't know they they told me what it out there they told me what it was I don't need to worry about it the devs have got it covered I feel a serious responsibility to make sure that I'm not first of all wasting their time so that I'm not sending them something to estimate that makes no sense or isn't possible or just kind of is strange and I love the developers I work with who challenge me and say what the hell is this you know this makes no sense or even even better I actually don't know how to do this so we're gonna need to you know spend some more time in it or do some research or something like that so I mean I really rely on them to catch the things that I miss so I'll try to pick out the obvious things but I rely on them to catch the things that I miss and they know that and so I think because they know that I'm respecting their time and I'm respecting their advice they appreciate that and they sort of reciprocate by respecting my time and and respecting my advice so I think one of the things we've tried to do is talk to the team about what the typical pain points are with our estimations and for us one of the biggest ones is that oftentimes the developer who estimated isn't the one who does the work because so much time has passed and then by the time we won the job they were working on something else or even if it's just so much time has passed that the developer who estimated it can't remember what the hell they were thinking so one of the guidelines we have is make sure you leave notes about what you are planning to do and that way just as a refresher when you come back to it in three months time you don't have to start from scratch and do it all over again. The other thing that we find a lot is if it goes over the dev says well I actually forgot that I had to do this in order to do this so that's where the breaking it down comes from so anytime a dev estimates something that's more than four hours and it's not broken down I'll go back to them and say I need you to list this out for me just so that I'm sure that you're sure that this is going to be done in under eight hours and then if simple things like anything larger than 16 hours we want to get a kind of sanity check so get another developer to review it and then lastly we find anytime that there's a lot of custom code there's a greater chance of peer review sort of slowing things down so any feature that we do gets reviewed by another member of our team and in that process you know the review takes time and then if there's feedback on the code which if you've ever worked with developers they've always got some kind of feedback on each other's code that takes time as well so we try to factor that in and you know these are just some examples but these are things you can work with your team to come up with and it's like it's really simple and probably pretty obvious but it really does help just to kind of set that sort of foundation and when you're in doubt it always helps to actually spend some time trying to figure out you know more information so oftentimes the devs will say look I'm I think this module will do what we want but I've never used it before can I spend two hours installing it seeing what it does and of course please please spend two hours because if you spend two hours up front that might save you from spending 40 down the road because your estimate is more accurate and I have one dev that I don't know if he's here but he always asks me for a design and it drives me crazy sometimes but he's almost always right so it's annoying but helpful so I mean just on that I think it's really important that your developers feel comfortable challenging you and asking you for that extra information even if sometimes you might give them grief about it so I mean just to note sort of for the developers in the room that certainly in our company we try to make the developers feel like they're engaged in the process it's not a process that we're handing over to them and that they have to follow we need their feedback they're obviously critical to this entire operation so we want them to feel engaged we want them to feel involved we want them to feel valued so we encourage them if they ever have a problem tell us first and not last you know it's happened a number of times where we had something go really wrong and then at the end the developer said oh well you know I knew that was going to happen because such and such is like well why didn't you just say that if they feel comfortable saying it I think that you're you're better off and you know I think it also kind of trickles down so if they see me challenging the client and and trying to get more information they'll feel more comfortable that that's sort of the appropriate process and they'll feel better about doing it themselves so the other piece to this is the old my clients are impossible because they always change your mind they never know what they want they're always adding to scope so I've heard this a lot I've even said this a lot but I think it comes back to the dev question of like if this keeps happening maybe you should sort of have a look inward and try to figure out what is happening in your organization that is enabling this to continue to happen so I mean I think the key thing for me is that clients aren't doing it on purpose most of the time so like the big thing with with our clients especially as we work with a lot of government and sort of non really technical background-ish type people so they often don't really know what you need to know in order to figure something out so it could be that the request is really really vague and you know you kind of have to workshop it with them to figure out exactly what problem they're trying to solve or sometimes I get where the request will be really really specific like we need you to add a new fillable panel pane so that it's like wait wait wait like what hold on what are you trying to do and then we'll figure out like we'll tell you the best way to do this in Drupal that's our job sort of leave that to us so if you kind of distill it down into just what's the problem that we're trying to solve you can then kind of work up from there rather than just kind of going you know here estimate this and then hand it back so obviously asking questions is critical they will definitely have made some assumptions about how they thought it was going to work and we've I'm sure all had the situation where you deliver something and then they go oh that's not how I thought it was going to work the best way to avoid that is by asking them how they think it will work and I would say strongly to anybody who's on the client side if you ever ask for something and you get an estimate back without any questions or clarification or discussion don't trust it you might actually have to be the one that's challenging your vendor to prove that they understand what it is that you actually want the next sort of principle I try to follow is to be really specific so tell them exactly what the estimate includes and that's a way of flushing out what isn't included that they might have thought was included so I actually pick this up from my partner who's a painter he's a painting business and whenever he does an estimate he lists the specific tasks that he's going to be doing so it's prep two coats and then cleaning and then that gives the customer the opportunity to say well these you know this wall is going from dark to light so I actually think it's going to need three coats and he can say okay well then I'll charge you for three and you have a conversation at the beginning rather than at the end when the client says oh it needs three coats you should do it for free so you kind of completely avoid that conversation because you've been really specific at the beginning and then of course it does give you something to reference later if the scope does start to spiral you can refer back to the fact that you were really specific and so if they assumed something was there that wasn't there that's really on them not on you and then be really honest because sometimes we really don't know how to do something and it's totally fine to say this it doesn't happen often but sometimes we have to go to the client and say look I know what you want we actually have no idea how we're going to do it it might take 20 hours and it might take a hundred so is it okay with you if we spend four or if we spend eight doing a bit of a spike trying to figure out how we can get closer and then we have a better sense we can kind of come back to you and be more specific I mean they can then decide what to do based on this information so in some cases they might say you know what it's not that important it's not worth the risk forget about it which is fine or they might say well this is something that we really need we need you to do it anyway so yeah go ahead and spend a little bit of time up front and then we'll kind of reevaluate it once we have more information the next thing I would advise you to do is to profile your clients all of my clients are very different and the way I handle estimations with them as a result is very different so I have all different kinds of clients some of them prefer to spend a little bit of time up front and then iterate and provide feedback and continue to kind of estimate that process and get more budget throughout but I have other clients that are big government agencies where it's really challenging for them to get budget so they want to know what's the absolute worst case scenario give that to me I'll get that approved and then I know I have kind of some room to move there so we don't need to know everything up front but we know we have time to address whatever might come up in the future and if you have a new client just assume the absolute worst and you can't really go wrong there so I mean I kind of mentioned this before but it's not really just about kind of having some fine print that you can refer back to ideally you won't get to that point where you're kind of arguing with them about what you initially agreed to do so that is an element of it but for me it's really more about making the process more efficient so if you know at the start what the end is going to be you can do that from the beginning whereas if you do something and then hand it over and then they say oh actually it's not what I thought then you have to kind of go back and I mean a simple example of this was happening to us the other week where a client that wanted a new search page and so they listed all the fields to build and the developer went off estimated it built the search sent it over and the first feedback was the order is all wrong the layout is all wrong so you know now we were stuck with well it had already been implemented it's a lot harder to change it at that point than it would have been to just do a mock-up and the mock-up doesn't need to be a you know Photoshop file it can be just a sketch but at least then you're kind of setting their expectation and forcing them to think about things that they might not have otherwise thought about like obviously that's just more efficient to do at the beginning than at the end and also I mean if you if you handle it this way you're much less likely to have surprises and when you do have surprises they're a lot less frequent and they're a lot easier to manage because the client's not constantly you know being sort of provided with with bad news it's not just constant bad news occasionally you'll have something you weren't expecting but on the whole it's pretty smooth and and I mean everyone's happier like developers hate revisiting things five times and the developer who did that that search feature I spoke to the PM and he was saying oh well it's taking way longer than the dip said it would and I was like wait a minute let me check and I looked at the story and I thought well of course there's not enough information here for him to have been sure of what the client wanted nobody could have been sure and that wasn't you know an attempt on the client's part to be sneaky it was because the client didn't understand what information we needed in order to get it right on the first try and also just this might be obvious but we have a really awesome team and that helps a lot I think that anytime you have a team where the devs treat the PMs or the devs treat the BAs as the ones who are like responsible for this or you know it's one role and they're the ones on the hook and they're the ones doing all the work that's not going to be effective it's not collaborative it's probably not going to go well so I think everyone that's involved in this process or expected to be involved in this process should be thinking critically about it and thinking strategically and kind of providing assistance so as I said before I feel responsible for making sure I'm not wasting their time and for making sure that they have enough information to be able to achieve success and then I think you know they reciprocate with their responsibility to deliver what they said and be able to deliver what they said in the amount of time so that I don't look bad in front of the client so we really have that trust and I'm not going to lie we've had people in the past who work with us who just didn't really fit this model and so they they didn't actually care and that was that became really obvious really quickly I think it's it's not really just about like you know the greater good or wanting the company to be profitable or even like caring about your colleagues I feel like it's a self-preservation thing to just want to be able to do your job properly and if you if you have someone who isn't willing to kind of buy into that I don't know maybe you should find someone else so looking back at the read speaker example from the beginning there are a few things we could have done that would have made it less awful these are just two kind of alternative approaches to what we did the first one being that we could have explained we're estimating five hours what we're going to do is add the module and then we're going to go from there so cheap easy five hours is nothing it's it's not a drama I have no doubt that they would have been okay with paying for additional work as long as that expectation had been set up front so it wasn't in this case so they had no indication that it wasn't going to be done after five hours but if you go to them and say this five hours is initial setup we've never used this module before it's a new technology to us this will get us started and then we can go from there that's a better way of doing it and then the second approach obviously would have been just spending a little bit more time up front to find out exactly what they wanted us to build this can be time-consuming and oftentimes this time isn't paid for but we ended up spending a lot more time that wasn't paid for then we would have if we had just spent a couple of hours talking to them about it and I mean this also goes back to the client profiling idea where after you've worked with the client for a little while you can generally sense what kind of client they are and which of these approaches they prefer or you can just ask them or also you know kind of come up with something else where you're kind of being flexible and and doing whatever you can to make sure that their feet that they feel comfortable so just another example of a request we took that had a little bit of a better outcome this is an actual request so I know that this is a bit of an eye roll moment where you're like oh I heard Drupal has a plugin for that we hear that a lot but actually this is not a bad place to start because it's really open-ended so they didn't really know what they wanted but they weren't locked into something either so they didn't come at it with really specific expectations someone in the marketing team said they wanted a blog someone said Drupal does blogs okay let's let's see what we can do here so again I mean sometimes I get frustrated by these really kind of open-ended requests but it's actually a good opportunity to collaborate with them to establish what it is that they actually want so what we did here was I explained that yes Drupal does have a blog module and we could enable it so that's what we did we on their staging site we just enabled the module and showed them the content type and showed how it worked and this just gave them a sense of kind of what the plug-in that they had heard about was and you know that it wasn't just a case of switching something on it was going to do exactly what they wanted because that's not possible so this just gave us kind of a starting point to have the conversation about what the requirements were going to be for the blog so you know the other benefit to that was we were starting from the what does the Drupal blog do kind of perspective rather than I'm going to invent a blog that works nothing like the Drupal blog and you're gonna have to retrofit Drupal to make that happen now we can always do that and so if clients do come up with crazy things that kind of go against the grain that's fine but obviously we estimate it and price it accordingly and we would always encourage them to investigate the standard Drupal option which they can probably get to do what they want for less money which they tend to like so anyway in this case we enabled the content type explained how it worked talked through the requirements with them developed a long list of things that they thought they might want we estimated the features one by one and in the end we built them a blog that did exactly what they wanted for very little money and they decided in the end a lot of the features that they had wanted like subscriptions and notifications and all this stuff they just didn't need them in the end because they were happy with what we did in a very small amount of time so we didn't have to argue at all about what was in scope or what wasn't in scope the team weren't getting frustrated because the requirements were constantly changing we started with not really not any information at all and just kind of built up the information and then built up the estimates as we went and then sometimes this happens where you just got to say no this is a client request that I got from a client who we'd never worked with before they came to us unhappy with a site that was built by someone else so it wasn't quite a rescue project but it was sort of close and so they said we want a landing page that can do a lot of things and it's got to be totally flexible and showcase all these different content and it was like okay well what's the content we don't know what the content is yet just estimate it this was like a definite no go for me because as opposed to the previous example where they didn't have a lot of information but I didn't think they had really specific expectations in this case they did have really specific expectations but without any information on how we could actually achieve what they were sort of envisioning in their heads so I just didn't think we could do it and you know going back to the guidelines at the start I was absolutely not at all clear on what they wanted and I was not confident at all that we could deliver to their expectations so what happened next was we emailed back and forth a lot and I very painstakingly tried to extract the information that I needed in order to estimate it but they just continued to say we don't know yet we don't know yet and then I said okay well we can't estimate this feature for you we've never worked with you before I don't really understand what you're trying to get here so I just don't feel comfortable going any further with this and she was really unhappy she kind of said back that I was being really difficult and why couldn't I just do what they were saying and she said you know well we're a flexible organization and so you need to be flexible and I was like wait no no no like trust me trust me we're flexible you know the idea is like you're gonna have to figure out at some point what you want on the page and so once you've done that you can come to us and we'll give you an estimate for that but this kind of like you know it's that sort of like imaginary feature where you're like I just want a page that can do whatever I want anytime I want okay well yeah I'm afraid we can't build that you know I think there was some pressure with an organization to just make it work but I could see the you know this isn't how I thought to work or or the kind of you didn't tell me that wasn't included conversation I could just see that from a mile away and I mean I think the fact that this client was a rescue project was also a major red flag for me because I could already tell that the dynamic was you know I was thinking well if these are the request that you've given to the previous vendor no wonder the project didn't go like you thought because this is totally insane so that's pretty much it actually my closing advice is just do what you think is best no not really but you should follow your heart and I think that will never steer you wrong but I mean just to sort of sum up the points that I'd like to make is the first thing is just understand exactly what it is that you're estimating if you have an organization where you don't have a really specific structure which is like ours it shouldn't be up to one person to make sure that that's the case you kind of have a team that's working together to make sure that nobody's missed anything and that everybody's clear and it really open communication process with your with your clients as well do an honest assessment of your process so if you're finding that people within your organization are constantly blaming your developers for being bad at estimating just take a step back and and look at to take a closer look at why that might be happening so then from there make sure you're engaging your developers and bringing them in and making feel comfortable and and extend that collaborative attitude to the clients as well so it can be painful I know I absolutely sometimes just hate estimating but unfortunately it's just a part of the job and then again just be really open it if you can be really open and honest I don't really think that will ever backfire I think the more open and the more honest you are the better so I actually would love to have some engaging conversation at this point so I don't know if anybody has any questions or comments or anything they want to share I'm just go to the mic if you could so that it's recorded thanks yeah thanks for a great presentation and I have a question about your last pathological case I know you got a bad feeling about this person for understandable reasons but if you haven't got that bad feeling and they did have an open-ended requirement under what conditions would have been considered acceptable to proceed with them like on an hourly basis or just deal with the things as they came up or well that's actually so that's what I kept proposing I kept proposing that we would do like a you know they can buy 80 hours or 100 hours or something and then we can prioritize the specific features and work that way that's how we prefer to work and so in this case the problem was they weren't willing to do that because she kept saying her CTO needed of course a scope of work that we signed in blood and then would be held to for eternity so that's just not that's never gonna happen so I think yeah if you can propose a flexible way of working that works for you absolutely we would have been happy with that but I think with someone you've never worked with before it's really hard to trust that that's not gonna kind of come back on you somehow so maybe maybe you've talked about that but for us the biggest challenge is that people are so fully booked that even if I want them to take a look at some sophisticated requests I actually need to plan them in is that what you do yeah I mean because we have a small team it's pretty flexible but if there is something that needs like a day or a couple of days we obviously try to find the person who's the least booked but I mean I do think it's got to be sort of an organizational priority that you know our devs do hate estimating and as I said I hate it too but I think they do understand that that's the only way we're going to get more work coming in so I mean I think that you basically the answer is you just have to prioritize it you know if if that's the other thing we do is we make sure not to schedule our devs at a hundred percent so if we're in a sprint say and someone has to be pulled off onto something else that's actually accounted for in the sprint so it's not going to affect our ability to deliver because we always knew that something might come up and so if something if nothing comes up we can deliver more than we said which is never a problem so it's sort of like we we plan on 80 percent that way we're never disappointing the client if it happens to be 85 or 90 so thanks first of all that was a really great talk with a lot of insights I'm curious if you ever run into problems providing a good estimate when the client's really pushing a fast timeline so like they want that blog in you know week or three days and if so tips on dealing with that how to kind of help them step back so you can get those requirements even though they want it done really fast I think if they want it really fast the approach we talked about earlier was basically like if if you don't have time to properly scope it then what you can say to them is look we don't have enough time for this but what I can say is I don't think it's ever gonna take more than 60 hours to build the world's most complicated blog so let's budget for that if that's too much you know go off see if you can get that much money if you can't tell us what you tell us what you do have and we'll kind of really roughly tell you what we think we can deliver in that amount of time but I mean we we do honestly have the luxury of as I said most of the clients we've worked with for a number of years and so we have that level of trust and we almost never get pushback on not being specific enough like we never have to have that argument about like contractual fine print and all that kind of stuff so for me the communication is just more about avoiding frustration and making sure they're happy rather than you know getting sued so what I often do when I have clients asking open-ended questions is try to learn from example if a client asked for a block he or she probably has seen a few blocks he or she can point out and say okay this is the kind of stuff that I would like how difficult would it be to implement that and that in often that is quite helpful yeah and you can also do it the other way around if possible ask a client what he or she does not want so pointing at things they really don't like is quite informative as well very often and I have a lot of question though when the two scenarios you mentioned afterwards trying to prevent the the original disaster that that you mentioned and I think the third scenario of doing a short spike would probably have been sufficient often when I work with a new module just looking at the configuration page of that model tells me quite a lot about what scenarios what questions I need to ask the client yeah I mean I think to be perfectly honest that exact scenario was one of those developers we had who didn't actually care and so most of our developers would have done just that and would have wanted to know what the module does what the client wanted I mean the placement of the thing on the page is obviously a really important question and I think especially on a site we're using panelizer anytime you have like a global change so probably what happened was everyone on our side assumed it was going to go in the header that would have been fine then of course they didn't want it in the header so you know again asking that would have been fine but yeah I think it's safe to say any good Drupal developer would do just that download the module and make sure they knew what they were what they were doing yeah how do you use you said that the strategic plan is something the developers to keep in mind and how do you make that work especially when you the developer is only coming in for one estimate and maybe you already have been in the process of the project and have some insights on that well we wouldn't have a developer only come in for one estimate we would have so generally what that would be is like a client that's on a retainer so we do work for them ongoing for years and years so there's really never a case unless it's someone new to the company that they have absolutely no context or understanding of what this client is trying to do but I also think it's sort of comes down to the developer like if you're if you're a good developer who actually enjoys what you do you want to build something that's actually useful and not just something that gets the PM off your back and I mean I think that's a really important distinction of like okay yeah I know what she's talking about this is how long it would take to build it rather than someone that goes oh I kind of I think I know what she means but I also think there might be a better way to do this so let me ask what this is for and and for some background and and even sometimes the developers will ask me a question that I'm like oh that's a great question let's ask the client I actually didn't think of that so it's not necessarily that they're responsible for the strategic plan but they have insights that I don't have and that us as the client service team don't have and so I just think it's important to make sure that those insights are perceived as valuable and perceived as welcome and and they're not going to be sort of treated as a pest because they won't stop asking questions it's sort of like the client that I refuse to estimate it's like sometimes if your developers are are talking back it's because you're not doing the right thing you know like I think it's it's really important that you have developers who feel like they should and can make those kinds of you know make those kinds of recommendations does that answer your question yeah I mean I think again having I think we have 10 developers at the moment it's a lot easier to have that context because you don't have you know you only have 10 developers there aren't there isn't like a whole group of people that never heard of this client or never heard of this project so in a sense that's a luxury that we have that we can you know all be pretty much across what everyone else is doing so that definitely helps yeah yeah I mean I think one of the I mean I don't know whether this is true for you too but the way we do our estimation is all through Redminer project tracker so I never put them on the spot and I never just ring them up and say how long is going to take you to do this I'll send them a ticket with all the information that I think they need and then they can think about it send it back maybe they ask questions for me I send it back to them so it's never like a kind of on the spot do it now kind of thing I think oftentimes they'll probably read it think about it overnight and then come back to me and I mean we had we had we're doing estimates this week where the developer that's here he was like I wrote a comment but it's sort of my first thoughts let's have a chat about it when you have a sec and then I'll do like my final assessment so it's really a conversation rather than a task that they have to do thanks so much for your talk I really enjoyed it I have a question around process of one of the things that my team struggles with sometimes is feeding the dev machine so do you do with your retainer clients estimates a sprint ahead so that you're always providing work or do you do a large chunk of estimates and then that gets we actually do it in not the best way which is the requests come in really piecemeal so occasionally we'll get a whole batch of work that might be two or three months of retainer work on one thing but it's typically like really ad hoc you know like I need a new view or I need a new content type and so we just do it one off but ideally the same few developers are going to be doing that retainer for the whole year and occasionally you need to pull someone else in but it's actually quite nice because what that what that gives us so in a way it's not good because it's a lot of kind of context switching but what it does give us is a whole lot of work that is ready to go so they estimate it the client approves it and then it can sit there for as long as a month because or even a quarter some of our retainers are monthly some are quarterly we don't commit to doing it that day we just commit to delivering it at some point during that month so it's actually quite nice to have a batch of stories that can be kind of done in isolation so if another client you know the sprint that we're doing we have to take a three-day break because they're not ready that's great because we have all this other work over here that we actually need to get done anyway so it's actually kind of a nice way of feeding the machine in times when you don't have a big batch of work but I mean I think all of our developers would say they would much rather work in the sprint you know big chunk of work model but just practically for us that doesn't that's just not always possible I don't know if you have this kind of situation with your clients but if you have always a PM making the connection between the client and the dev and some clients try to send personal emails to the developers and try to avoid all the process my clients would never do that they know better now I think we don't try to put up a wall so all the communication in red mine unless like we can make private tickets but all the communication in red mine is there for the client to see so I think they never feel like they have to go around the process because the process works really well for them so if they write a comment on a ticket the developer can see that and if the developer writes a comment on a ticket the client can see that and so I don't have any problem at all with the client asking the developer a question or the developer asking the client a question you know I'm I don't need to be the middleman in that if if they can kind of work it out themselves so I mean in fact that's probably what we'd prefer I don't know if anyone as it was at my colleague session yesterday or Tuesday about not being a control freak I'm you know I'm totally happy with things being done without me that's actually great it means I have more time in the day so I would say if your clients are trying to get around the process there might be something wrong with the process thank you for your session however I have questioned that is related to big proposals and scopes so usually when you create really big proposals for thousand hours you have to put here some rough estimates and high-level details but you you really can clarify some really deep details only when you get to the step when you create specifications and you have a lot of discovery and communication with client and my question is how to avoid the gap between sales team or sales guys who are creating those proposals and technical team who is struggling with estimates well don't have your sales team to your proposals would be the first piece of advice no I don't I don't really mean that but I think the way we try to work and the contracts don't always necessarily represent this but if you're if you're pitching to your client that is going to be agile and you're pitching to them that it's not a fixed price fixed scope quote that it doesn't it's not really that much of a concern because the discovery and the whole sprint you know backlog grooming process is about figuring out what they want and making sure that you can deliver that so I think that I don't think we've ever had a situation where we pitched a big project and then like it came down to it and they had this crazy thing that we had never anticipated and we didn't have time to do it you know it's like basically you say all right well that the way you've described that directory is a lot more complicated than we thought so we're gonna have to probably deprioritize some other stuff that we estimated or either simplify it or drop something else and when you have that kind of dynamic established it becomes just completely not a problem and I mean I know that probably sounds simplistic but do you work in Agile methodology or you do? Sure yeah you know usually we try to recalculate in that case some user stories and make some suggestion that we can decrease estimates for that user story and put ours into another one because yeah I mean or they can or they can try to come up with more budget like it's kind of to be honest like the the way it works is like we provide them with the inputs to make business value calculations so you know we're doing our best effort to make sure you know we're not trying to swindle anybody we're not we're not purposely trying to underestimate things I think if anything I'm guilty of overestimating most of the time but I mean I I can't think of a time where we had like I said where we had that problem where we went to them and said this is going to take a little bit longer we might have to drop something else or you might have to get some more budget we I mean we've had some clients that were difficult but but I think when you frame it in that way it becomes not really a contentious or like a problematic thing it's just it's just a decision point basically you know here's the information it's some some things have changed how would you like to proceed thank you all right if there's nothing else I think actually there's an estimation bough right after this I don't know which room it's in but you can check the bough board right outside so if you want to continue discussion of estimations and I know it's thrilling you can do that there and also please evaluate the session this is really important which I'm sure you've heard all the other speakers say it's important for the Drupal Association and for us as well to kind of get feedback so please please evaluate it and thank you