 I've been given the signal to start, so I think we'll begin. So hello, everyone. Good morning. First session of the day, very daunting for me to set the tone, but hopefully we'll crack through it. Titled this talk, I like to be a little bit provocative, and I called it the scientific wild ass guess. It sounds a little bit better than guesstimations. A little bit about me and what I do and who I am. So I'm Adam Malone, I'm a senior manager at Deloitte Digital in Sydney. My background is definitely very technology focused, but over the last couple of years I've kind of moved away from technology and more into client relationship, management, and kind of leading open source projects in Deloitte. What do we do at Deloitte? There's a little bit of a misconception around Deloitte that everyone wears suits and they study accounting. That's maybe one fraction of things. Really, we kind of do everything as a consulting organization. So that would encompass technology, it would encompass obviously accounting, financial services, and now Deloitte Digital as well. So that's the digital arm. And within Deloitte Digital, we again do everything as well. So that would go from the strategy around digital implementation and digital transformation all the way through to running clients managed services. So that's kind of a little bit of the sales pitch about us. Now, what people here are probably a little bit more interested in is what we do in terms of open source and Drupal. So globally Deloitte has around 50 practitioners of Drupal and open source technology centered mainly in Australia. So our practice in Melbourne and Sydney consists of a bunch of technical specialists all aligned with Drupal open source technology. That's all contributing to clients and obviously the open source ecosystem. So on to the meat of the talk. This is a saying I really hate. And it's something that I hear quite a lot when people say, oh, how do we do something? The answer often comes at how long is a piece of string? And I think that's kind of stupid because strings have length. You don't ever have a string that doesn't have a length. And the reason that strings have length in terms of project and project estimations is we need to put costs on things. We need to be able to accurately identify prior to beginning work how long that work will take so we can effectively charge for it, effectively resource for it and effectively deliver the project at the end of the day. Now that is both prior to when projects exist when before they begin, but also during projects as well and even at a micro level within your sprint delivery cycles. It's really good to have estimations because we don't want to be burning teams out by giving them too much work within an individual sprint for the amount of time that they have. So estimation is really important and it's actually fundamental to Agile as well. There's I think a bit of a misconception that with some people that when you do Agile you just kind of keep going until you finish. But that's often not the case because clients have requirements around when things are delivered, around project delivery, around costs. So we need to align them to that. Now, I know I've said that strings have length but it is sometimes difficult to find that length because clients may not give us all that information. They may give us the wrong information accidentally or on purpose. Projects may last for months or even years and again, it's really hard to estimate when we don't have all of that information. And I know especially when working with developers and BAs those people like to be really exact about requirements. They want everything documented quite often because when you have everything documented then you can go great with confidence. I can say that this will take me four hours, two days, two weeks or something like that. So quite often we're juggling with this tension of wanting to be able to put a number on something and having to identify how long that string is but at the same time not really knowing how to measure it, what units we're measuring in or even the full information around that thing. So this is really around how we do that and a couple of the different methods that we will estimate. Hopefully I can share some ideas and learn a little bit from you folks too. So the important thing to realize with estimation is that as I mentioned before, it does align with agile. And this is really the difference between that top down and bottom up estimation process or project estimation process. With your typical waterfall project you would estimate everything bottom up. You go down into really deep detail through that detailed design period prior to a project starting. You uncover all of the requirements, all of the different caveats and dependencies and from there you build your big long project plan. Now with agile we don't typically want to be defining everything upfront because there's lots to uncover as we go along and clients' requirements may change. So taking a top down estimate where we break things down into individual features which are kind of discrete units of functionality and I'll show you that in our swag template later on. Discrete units of functionality helps us to take a kind of a rough finger in the air measure of how long things will take. Quite often this leads to what I like to call agile projects. So kind of you know roughly where you're getting to. Roughly how long it's gonna take. You know roughly how much money it's gonna cost but within that kind of circle you can deliver things completely in an agile fashion. And again estimations are really key towards providing those guardrails around the overall length and cost and things. The other thing as well as we mentioned earlier is during those sprints and during that delivery and development cycle we wanna be really sure that we're gonna be accurate around what we can actually deliver because again it's really common to be optimistic and try and fit everything in if you think that things are easy and don't take into account some of the other dependencies and issues on that. So different estimation methodologies and these are some things that you might have seen before. Have you ever gone to a fair or something and seen at a stall where people ask how many jelly beans are in a tub or even this one here. How many stars are in the sky? How many grains of sand are on a beach? How likely is the chance of intelligent life in the universe? This is a Fermi estimation or a Fermi calculation. Essentially with Fermi calculations you take an approximate answer from little to no information using what you know and intelligent guesses. And really this is the heart of what a swag estimate is. These are really great for top down estimations because you don't know all the information. You have no idea about the deep dependencies or that Peter's going on vacation in two months or that API over there is gonna be hugely problematic. You don't know all this information but you can kind of roughly assume a bunch of things to meet the estimation. I think the common example for Fermi estimates is how many piano tuners are in Chicago and there's something on the Wikipedia page that I encourage you to take a look at around how that calculation is actually made because a Fermi estimation or a Fermi calculation is completely transferable across software development, across buying houses or whatever really. It's basically a broad strokes approach to estimating something based on what are called priors which is things that you've done before as well as the information that you have to hand. Where they fall down is where you actually require that detailed precise information and that would be a completely different type of estimation and not something that we're looking to do. An application of a Fermi calculation is a swag. Swag is a scientific wild ass guess and I really like that term because you apply a little bit of science to it but a lot of it is just art. A lot of it is just taking a lot of assumptions around things that you've done before, subject matter expertise and putting a number on something and kind of forcing yourself to put a number on something. Swag was actually invented in the 1960s as a term and I think the story goes that General Westmoreland in the Vietnam War was asked, how do you know that there are this many people or how do you know that it will take this long and his answer was often swag? And it came out later that it just meant scientific wild ass guess using prior knowledge and a little bit of guesswork to come out with a result. The interesting thing though is that swags are actually usually pretty accurate as long as you have a defined methodology surrounding them and one of the key things that I like to include in a swag estimate is an uncertainty metric and this is really that counterpoint to when you try and get someone to put a number on something and they go well, it could be two weeks, it could be three weeks, it all depends on these other factors, that's your uncertainty metric that allows you to then provide a more accurate estimate or more accurate range to allow kind of an overall calculation of effort. So we'll take a look at how we estimate and the process that we use to estimate and then I'll show you a little guide for one of our swag estimate templates and this is something that I'd encourage everyone here to make as well. It's all gonna be unique depending on who you are, who you work for, the kind of work you do and I think creating some kind of swag template so you're not just, so you have a proven methodology internally is something that you can then repeat, learn from and evolve. So this is our process to estimation starting in the top left. So as I mentioned earlier on, what we like to do is break everything down into features. So you might have an entire list of user requirements, an entire list of functional specifications but really we don't need to go that deep. If we've got all of that information, yes we can do that but I prefer to kind of create discrete units of functionality called a feature. The reason we don't use journeys or customer journeys for this kind of thing is that in a journey, that's a very user-focused way of estimating and you start missing out on some of the technical aspects of things which are behind the scenes, examples of which could be things like operational readiness or penetration testing or load testing. So a customer journey could be made up of a number of features, but also features are gonna include things that don't exist in your customer journeys. I'll show you some features in a little while as well but the ones I mentioned were examples of that. One of the things that we then can do is ensure that we have traceability between journeys and features. So when a client is asking for X number of user journeys, we can then say great, these journeys have these features in, this allows us to break down our journeys into what's actually deliverable within individual sprints and make it really efficient to deliver a journey rather than have, well, this journey's this much, this journey's this much, this journey's this much, and then not sharing any of the features or functionality that could be co-delivered in both of those. From there, we create our swag document and if you've already got one, great, you just put those features straight in that swag doc and estimate from there. The swag doc, the way that I like to create swag documents is to break down into functional areas and to capabilities and that just allows us to have that one-to-one parity between resources that we have on those projects. So if we have an amount of effort for a particular feature to go to front end specialists, to back end specialists, to site builders, to integration engineers, to content specialists and other things, we're then able to stratify by each capability what level of effort it will take for each of those. Now, this doesn't allow you to put dependencies in, but it does allow you to say overall, I think it's gonna be 100 days for this capability, for this feature and that kind of thing. The other thing that I like to point out as well is I estimate in days, it's really easy to underestimate if you do things in hours. So typically taking an approach where we have a day minimum granularity of half a day allows us just to ensure that we add any extra contingency for things that might not be typically estimated as part of estimation of a feature. An example of that would be, if we're creating different content templates or if we're creating different features, what are all the other extraneous meetings that need to be added in the other deployment activities, liaising with stakeholders, estimating days, and then we're not just limiting things to a two hour or a two and a half hour block. So the days estimate really helps us to kind of just automatically get into a frame of mind where we're adding contingency automatically. The other thing I like to add as well is the uncertainty factor. So two exactly the same requirements for two different clients may have two completely different uncertainty factors purely based on the amount of information that we've been provided. The uncertainty factor basically acts as a multiplier and gives us a low high range. So then when we're looking at our contingency later on, our overall project contingency, we can see where our resourcing fits in between the low and the high range and how much risk we're willing to assume on that. From there, we map it into our resource plan, measure overall contingency, ensure it passes the POP test, i.e. oh, I think that 100 days is roughly okay for that. And again, that's that gut feel coming back in and then deliver the project and revisit those swag estimates to make sure that what we delivered was accurate to the swag. The reason that I like to maintain the same swag through subsequent projects is because we learn from things and that then informs the gut feel part of what the swag is. If we do 10 projects and each project has active directory integration and we learn that our swag estimate is inaccurate to start with, we can tweak that, use the same spreadsheet to continue with and then we start being able to increase our level of certainty. So eventually, we can effectively have a templated approach to estimation that removes uncertainty and gets real clarity on the estimates. The benefit of having good estimates is quite simply, we're able to lower risk and we're able to deliver with a smaller margin of error. So on fixed price projects, we're then not having to put on massive amounts of contingency because we're not certain in our ability to deliver things. We have a good understanding internally of the effort required for a feature and can more accurately estimate for our clients. So before I switch over to the swag template, a few myths and truths. Heading down the myths column with our flat earth theory, estimation is hard, it's really not hard. I think the hard part of it is just sitting down and putting a number on things. Once you start getting into the mindset that it doesn't have to be accurate, it's just a guess. Estimation starts to become easy and having those two metrics of I think it will take this long and I'm this certain it will take this long helps to smooth over that process. Another myth is that one person is responsible. Every single person on the project should be able to estimate. And the reason for that is because each capability needs to be able to estimate their own time. Not only at the beginning of the project, but also throughout the project as we're doing estimates to complete and estimates versus actuals. Estimates versus actuals are really important because it allows us to see what our sprint velocity is and whether we're estimating accurately if everyone is estimating incorrectly, then we need to lower the amount of story points or whatever that we apply to sprints. I also don't believe deep subject matter expertise is required. Some subject matter expertise is required, but if you've delivered a content management system in X, you're probably gonna be able to estimate it in Y as well. So if you've not got a lot of Drupal knowledge but you really understand Sitecore, you're probably gonna be able to estimate in both systems. Yes, there'll be uncertainty, but at the same time, creating a page is probably gonna be similar in a lot of different systems. And as I've mentioned before, Agile needs estimates is a myth. You absolutely need to be able to estimate in Agile because otherwise you're just gonna be throwing money down the toilet. Some truths on this estimate reduces risk. As mentioned, if you're estimating accurately and able to continue putting estimates based on previous projects, you then don't have that uncertainty of not knowing exactly whether your pricing projects in a good way or in a completely, completely off way. Swag estimates are accurate. They're not meant to be completely accurate. Kind of, you know, they're accurate-ish. So, you know, again, it's one of those things where it's not meant to be an exact representation of this is how long it will take. It's more that approach where you say it's gonna be roughly this much and then evolve from there. Quality through reuse, use the swag template over and over again and trust your gut. If at the end of a swag process, you look at your estimates and you go, I think this is gonna take longer than three months. Trust your gut because that's what part of the swag is. It's using those priors to be able to inform future projects. So, take a little look at what a swag template looks like and I'll run you through an example here. This is all fake. What we've got here, oh, casting the wrong thing. What you've got here, man, this is something that I've gained a deep love for in the last couple of years. I've gained a deep love for Excel. This is our swag template that we start to look at. If I zoom in on this, what you can see down the left-hand side is our features. So, I'm not going into deep granularity around what each of these things entails. It's literally just a one-word thing. It's resource library. It's integration with Instagram. It's creating news. And news could be pages, content templates, views, listing pages, blocks. It could be all of these things. Across the top, we have our capability areas. So, it's not just the breakdown of a feature into how long it will take to develop or configure or site build or anything like that. There's a lot of different functionality and a lot of different people and players, especially in large projects for enterprises that will be involved in the creation of one of these things. So, you know, there'll be some BA effort and that could be process documentation. It could be how do we get news articles on the website where we need to connect to our internal system. We need to syndicate to other things. It will be the creation of the UX wireframes. It will be the creation of visual design and theming of those wireframes all the way through to the actual development, the back end, the front end, integration, analytics, personalization and other things. Now, this is just an example. So, you can add or remove different capability areas as you see fit. If you have a team of, you know, content designers and people who will be creating IAs and copywriters or content migrators, then add different streams because this all flows through into your resource plan. The metric that you see there just on our UX example down here is, again, just day's effort. Complete, you know, finger in the wind. This is not based on a real project. So, we're assuming that we'll take four days to do UX wireframes for this job search functionality, whatever that entails, with a confidence level of four over here. And this is a very simple one to six scale. Adjust uncertainty to your needs, but effectively, uncertainty adds a multiplier on this. So, I've just said, you know, if I'm 100% certain I know all of the requirements, I know everything about this, it's a six. And that just means that the estimate, the low-high estimates, will be exactly the same based on the original estimates. So, this goes all the way across, it goes all the way down, all of our features, all of our capabilities, and it boils down into these estimates here. So, we've got our low, we've got our high, low, high, and so on. The lowest is gonna be at a six uncertainty or a six certainty for everything. Everything goes right. This is what it's gonna be. The high estimate is gonna be if you take the kind of the pessimistic approach and you say this is what it's probably gonna be if we run into all the problems that we could run into and we don't have any of the information that we have. Smooshing over over to this slide here, and again, just example information, we can then use that to inform a resource plan. So, pulling all of those numbers in and again, create your swag templates as you see fit, pulling all of the other information in into lows and highs. We then get what our contingency is based on the actuals from our resource plan. Again, resourced in days. Ignore these numbers, completely fictitious. This then allows us one view where we can see how much everyone costs as well as how long the project will take because we know our estimates, we know our actuals. That then allows us to build in what our contingency is and the risk level that we're comfortable taking. So, that's really it. Take a methodical approach, pull in your estimates, apply your actuals, apply any level of additional contingency you want, and then deliver the project. Thank you. Thanks very much for that. We're just in a few minutes to set up for the next talk, so unfortunately, no time for questions. But please approach Adam today if you have any questions. Thanks.