 Good morning. Just started the timer. I'm in Switzerland. I need to make sure I really finish this on time My name is Marius Vetrić. I'm from WP Riders Agency and today we are going to talk about how to price WordPress projects and software projects in general and when we talk about pricing, I always connect that to estimates Now before we move on into the presentation, I would like you to raise your hand Have you ever told somebody it's going to take me one hour to reinstall my laptop? Now, please keep up your hand Those of you who really managed to do it in one hour Indeed estimates are hard. There are no hands up Estimates are hard both in real life as well as when we talk about software projects and actually there are two case studies Famous case came famous researchers one from standard group the other one from Wellington showing that only 36 Percent of the projects are delivered as successful How do they define success in this case? They say project is successful if it's delivered on time in In budget with in budget and within scope right in the Software prep in the software industry. There's an even harder practice best practice I Found out that people do estimate a project and they they just multiplied The total effort by two or by three Well, we've developed a methodology that for this eel for it this year. It yields an under 25 Percent's rate of Estimation error and when the next few minutes I'm going to discuss with you. How are we doing it? What is the process that we are following? It's a very thorough process besides besides the estimates Besides estimating the software For for pricing. I found out there are three other reasons to estimate a software project Whenever you estimate You really dive into the tails. You need to understand What's in that software project? I'm going to have five pages ten pages Maybe a WooCommerce installed maybe a learn-dash and so on so you really need to understand the requirements So you get clarity by by estimating next once you get clarity you can break down the project to milestones And once you have milestones, you are able to properly plan your resources your project You can calculate how many developers do you need? How many testers? How many back-end developers front-end? designers and so on So before moving into the actual process of estimation I found out there are Three types of things that we generally estimate when we estimate the software project the first one is estimating the things that we know Generally speaking, this is very easy to estimate for instance You need to develop the header of a new website But you have been developing headers like this one 50 times in the past So it's going to take you in just a few moments to estimate the new header Right now moving on we have to estimate things that We know we don't know What it's all about in there? Taking the same example With with the header supposedly our customer says well, I need this header and the map menu To work really fine on Kindle fire. Have you ever developed on Kindle fire? Me neither now. This is a known unknown. I know that I don't know how will that thing work out? It's very hard. It's hard to estimate these kind of things and the next one is the unknown Unknowns these are the things that we are not even aware that we don't know The same Kindle fire example Let's say we don't even know that the HTML set is half of the normal HTML set You don't know that so we will have to hand code everything from scratch For that particular browser. That's very very hard to properly estimate and the process that we've developed Handles all the three cases with unknown unknowns Unknown unknowns and the things that you know. Okay ready to move into the process There are seven steps. I'll quickly go through them and then we will dive deep into every step The first thing is to qualify the client Do you know what? qualifying a client Okay, briefly explained. It's deciding if that customer and project. It's a good fit for you. Okay Next we do a pre-scoping phrase Scoping comes from the word scoping comes from the word project scope Do you know what's a project scope? Okay, the project scope is a written document Which lays out all the requirements that come from the customer That's like ensuring you're on the same page before you actually dive into the project and into the coding Next we offer a ballpark estimate. This is an optional step Just to ensure we're on the same page about the budget and next in case there are any Any unclearities about the scope we do discuss About the entire set of requirements in the project and the deliverable is a requirements document or the project scope Now at this level we have clarity over what has to over the what that's the keyword has to be delivered Next There might be some technical risks as in the case with the Kindle fire Here we run a few micro prototypes which Have the goal of Uncovering the technical risk of mitigating the technical risks. This phase is called the discovery phase That was a preparation now We are safe to make the estimate because we've hopefully uncovered all the known unknowns And eventually all the known unknowns and then we can communicate it to the client. Okay Let's move on Qualify the client. How do how are we doing it? We discovered that it's quite easy to work with the customers who know what they want They have clarity over that feature over that requirement. For instance, if there's a customer who needs a custom Payment gateway, they are very clear about the fact that we need This only for normal orders. We don't need for subscriptions. Now that means we have clarity there Okay, or there are a second type of customers. They don't know what they need and what they want But they are willing to be consulted Compared compared to this type of customers There are customers and we've got this kind of requirements who say just build a new website and they'll tell you if I like it Or even worse build me two websites and I'll choose one of them We discover that it's very very hard to impossible for us to work with these kind of customers However, there are agencies which are very good at handholding this kind of customers So I'm not saying the customers are bad or something. No, it's just finding the fit. That's what it qualification is all about and Next quickly mentioning client is interested in the quality of the process of the deliverable not merely in the price We ensure the project size is of the right type for us although we can tackle with projects of Thousands of hours, but if that project is not breakable to small 50-hour milestones we just don't take on that project because we know at 50 hours batches 50-hour milestones or sprints Our estimation error is the lowest Because we keep statistics And last but not least we work with the clients. We choose to work with the clients who are in tune with our values For instance, we avoid and we refuse customers who are selling ammunition who are doing Creating adult websites who are harming animals Or other beings. It's just a matter of a choice. I'm not saying that's bad in itself. It's a choice Next pre-scoping phase. Okay, as I mentioned The deliverable here is a requirements document. So we basically understand quickly understand the client's requirements By asking a few questions to clarify What's what's on his mind? What is his business context and what are his business goals? Once we have clarity High-level clarity at a high level detail over his requirements We do check if we are on the same page about the budget. Why are we doing this? Because the estimation process it takes time to properly estimate the project. It takes time How are you doing it? You can ask the customer directly. Do you have a budget on your mind for this project? Some of the customers will answer that openly But some will just say no, I can't tell you or I don't know in this case We just uh based on our estimate quick estimate the ballpark estimate We ask is your budget above or below a certain figure and by merely observing the reaction of the customer Even in writing you can tell if You're on the same within the same ballpark or on the same page If the customer wants a website for 500 francs And you know that's going to cost him at least five thousands Then it's clearly that you'd better recommend him another agency Okay Page-scoping phase. This is the phase where we actually take the time to fully understand What what does this customer want to build? This is a consultancy project Where we do interview the customer we write down all the details What do I mean by the details? I mean we enumerate all the user roles This is a separate talk in itself, but just to quickly mention user roles Uh website or product or plugin objective None objectives things which we Clearly and mindfully know that we are not going to build Into this current version Next for every user role we go into details about the user stories Everybody knows what's user story Okay, the term quickly mentioning the term comes from the agile Methodal agile philosophy And it has a format like this As a user role as an admin I want to be able to dot dot dot for instance to create new users because reason because We need These users to be able to log in On their website. Okay, so that's an example of a thin sliced user story Once you have this user story it becomes much easier to estimate Next we deliver This requirements document or the scope document which Can contain some diagrams some schemas some entity relationship diagrams you name it It contains everything That you need in order to provide the clarity of the project Once you know the what what you need to build You might discover that there are some technical risks. There are those Known unknowns you know that's something new in there that you don't know how to tackle it with how to tackle it To take my my similar previous example with a custom payment gateway for a Third party for another country you have never worked with that api to process credit cards But here you might assume. Well, I'm going to read the code from the Stripey from the stripe commerce extension and I'm going to reuse the code Well, that's an assumption if you fail at that assumption if in reality Things turn out to be much different Between the two payment gateways you will have to rewrite everything from scratch now the goal of of the discovery Proto discovery phase is to eliminate these technical risks by shading the light On those technical areas that you don't have experience with We deliver a micro prototype which is generally speaking a very small sized piece of work which has The goal of eliminating one technical risk Okay, so the focus is very narrow. You might Run several Micro prototypes for for the same project I can give you now a quick case study of of micro prototype. We had to build a learning management system Where tutors needed to post their courses And then the students need to come on the website to choose a course and to sign up for the course Okay, these courses are online courses in the so-called virtual rooms. Do you know what's a virtual room? It's like a video chat group video chat, but it's specifically designed for For learning online learning now we ran a successful micro prototype Which used learn cube? It's an api which offer virtual class rooms And we needed to grab a link to an iframe With a virtual classroom Guess what? This was the second micro prototype the first one failed. We used whiz iq Now imagine if we were to estimate the entire project based on whiz iq whiz iq workplace plugin It would have probably tripled the entire time because we would have Allocated time and resources to use whiz iq and then you've properly heard of escalation of commitment We've invested so much time into this we cannot give up on it That's why we provide visibility upfront by eliminating testing technical risks with micro prototypes And now before we move into the actual process of the of the how do we estimate? This is only the preparation. I'll show you our template This is the template that we are using to create an estimate. We have here a list of tasks We have expected best and worst estimates. It's a three-point estimate for every task There's an assumption notes column where we for every task when we make we note down What are the assumptions that we made? For this particular estimate then we have the total for development for the three-point estimate We add up some coefficients and we get the total Ready to move forward? Let's do it So Now that we are prepared to estimate the project we have clarity We've eliminated all the technical risks We are ready to break down our project to tasks of maximum six hours Why six hours? Because both from our practice and from other software companies from empirical evidence It became clear that if a task That you you've estimated takes more than six hours Then that's a clear sign. There's the there is an unknown unknown It's something like oh, it's going to take me 20 hours. Take it out of here. Get rid get it get get it out of here That's a clear sign that you don't know. It's a black box And the empirical evidence show that whenever you know what's in that black box, you are able to break down the task further Now if you are not able To break it down, then that's a clear red flag. You need the discovery phase, which I've mentioned earlier Does it make sense? good moving on For every task from that template from that list we provide a three-point estimate. Have you ever worked with three-point estimates? This comes from from pert pert that's a years old methodology for project management and What does it say it says? The expected estimate is the number of hours it's in hours That I expect this task to normally take if I have previously worked on something similar Now the best case is it will turn out if things will will go really really smooth Okay coming back to my earlier example with a custom development custom payment gateway. I'm assuming That that ABC payment gateway Will be a more or less clone of the stripe. Do you know about stripe or paypal? Let's use paypal as an example paypal. Have you heard of paypal? Good. So that's that's a paypal clone Okay For the new abc Payment gateway now that's an assumption and the expected estimate Says yeah, I've probably worked on something similar in this case, it's um Most of the code will just work right away I just have to Change some things here and there now imagine the worst case estimate is the case when you will need to code everything from scratch which means If the expected estimate can be five hours, this one can be easily 50 hours Let's come back to the same header example I need to to code a header of the on the website if that header will take me six hours but then I know that I need to create some some very Spectacular menu for mobile's and then I need another menu for kindle fire Then I will need to hand code everything for mobile The html I might be able to reuse it or not and then for kindle fire. All right And then we calculate the three point estimate And then we add up Add up all the values to get the dev total. This is the development total but this is not everything We have a few coefficients that we apply on top of the development total The first one is the coefficient for pm and testing which In the industry can range between 10 percent and up to 40 percent and it depends on the project type The country the customer comes from if the customer is very very picky. There are customers Which which will We'll really really want everything neatly aligned Others are fine with Things well done then You choose your own pm coefficient and next you add up your team's mean estimate error. What is the mean estimate error? This is a figure which tells you by how many Percents or hours on average you over or underestimated? I have here an example of 29 percents. What does that mean? That means for For 100 hours estimated the estimated time on average This company delivers In 129 hours like by 29 hours on top So 120 9 minus 100 Okay divided by 100 the original estimate it gives you the original estimate the estimate error Next we confirm the estimate with a senior developer Then Multiply by the hourly rate for the project and we communicate the offer to the client That was the process a few things a few takeaways for you And a few key things to consider when estimating The first one might be surprising but it works really really well and that is be mindful Be present when estimating projects and what do I mean by that? I mean when you have a design Really look at that design Really see all the small and big important and unimportant details Okay Make the estimate with a assigned developer If it's possible Make uh making sure that you make all the estimates auditable. What do I call auditable? If the senior developer looks at the estimate and that the design He or she should be able to understand the estimate without asking anything That means you have clarity That's a very very good sign that you have clarity over the estimate and the project Make sure you write all your assumption notes in the column and Be be be aware that quality estimates will take time So do plan for them and carefully choose the projects by qualifying the projects and the clients Carefully choose the projects you you want to go into And last but not least if you want to have a learning process Do keep track of your estimates versus actuals Estimates actuals estimates actuals that will allow you to have that mean estimate error for your team or for your team member Good Enough with the theory Let me show you two case studies of how we are applying this process And the first one is for a work safety management company They needed a project where they go with a handheld on a construction website and they check the compliance Do all the workers wear their helmets or not and they report that And so on and the compliance is quite quite a complex area and they needed afterwards to print to generate and print Some pdf reports with the results of the compliance check The the fields in yellow are placeholders now This is the estimate for one of the features which is non-compliance form and report This is how uh, this is not the entire project. It's much bigger, but I need to fit it in one screen So, uh, if you look at the this feature create non-compliance gravity form Add autocomplete for drop-down fields where needed 2.75 2.5 3.5 Now if we look here, we will see our assumption We will use gravity forms and the autocomplete fields will work fine on mobile But here is a technical risk because This autocomplete field with search in the case of gravity forms surprise surprise they don't work on mobiles Luckily in this case we were aware of this requirement. We were Mindfully enough to notice and to test it on mobile before we actually entered into the project we've discovered that gravity forms uses chosen For the searches which is completely disabled on mobiles now imagine how much time will it take you to to build From scratch a drop-down with search And we ran a quick microprototype which we which replaced chosen with select two in gravity forms Then we were able to safely Add here 3.5 hours. Okay. That was my case study number one and case study number two This focuses more on front end development And it's a case study about the unknown unknowns Here, uh, you can see a product page For a easy digital download shop And if you look at this tiny unimportant drop-down here Yeah You probably won't say much about it However in the psd designs that we received there were some hidden layers, which we unfortunately didn't notice which looked like this Now this thing is a much more complex thing to build because Um This is a completely non-standard edd feature. It has custom html here. This sidebar is fixed. It has a peculiar user experience It starts to move as you scroll then it stops and then it moves So this drop-down should work fine while it's open While you scroll and that sidebar does all these tricks and to make the things even funnier these Discounts should be dynamically calculated Okay Now let me show you a bad estimate. This is the original estimate Versus a mindful estimate which I would Do now after we finish the project So section number one title 2.5 hours section number two. It's the middle Title is the header content is the the central part and sidebar is the sidebar In reality, this should have looked like this Point number one and number two the same point number three is broken down to three points to three sub points Create a sticky sidebar as per design Create add custom html to product drop-down and made the product selector dynamic and you can compare the totals Okay, that's one point. We were not mindful enough and we've just missed some unknown unknowns Moving on to the conclusions and some takeaways for you for today Good estimates provide you with clarity which in the end brings reliability Be mindful when estimating WordPress projects be as present as possible And last but not least Do break down your projects to six hour must maximum tasks Otherwise, there are some unknown unknowns that you're not even aware you don't know Thank you very much Any question Hi, thank you so much for this very amazing presentation very interesting. My question is about what is a p.m. Coefficient project management coefficient Thank you so much Hi, thank you for the presentation I was wondering about the paid scoping phase. How do you Sell it to customer because it's more likely that they have asked other agencies to To scope and code the project and how yeah, how do you do I sell basically this This this these paid scoping phases We do this by doing a bit of pre-sales work. How does that work for us? We ask that's the keyword some smart questions and they see that we really Understand what's in there? We quickly understand but we only ask enough questions To make the customer aware that he doesn't or she doesn't have all the answers And then that's the moment Usually takes a maximum of one hour because we need to make this efficient when we say well I will need you to write down all the details If you're not able to do that we can help you with that at the end You will get every another keyword reusable Requirements document that you can reuse with other agencies to get prices to get price quotes. That's how it works Thank you. I like very much your presentation. It's it's a kind of question. We ask ourselves all the time also for me what it's very difficult is to estimate the The communication skill of the client in advance Because some clients are very very bad in communication But it means during the project you don't have the feedbacks or they change their minds or they are free to decide but in different times so Do you have a technique to kind of assess or do you have a Rating system like to add some coefficient for the bad communications of the client that you are expecting? Um, the short answer is no, we don't have a system for that But that could be a good idea. However, how we are doing it now Is and you've mentioned two things Delays in communication and changes Mind change changes of mind like they they change their mind Yeah They will change their mind if you go into the project without clarity Unless you have clarity and whenever they move outside of the boundaries of the project And that's a clear sign and you need to you need to calibrate their expectations upfront This is the requirements document. This is what I'm estimating for if you will need anything else We will need to update the project requirements document and the quote So that's how we manage the out-of-scope things now when it comes to the delays in communication Here We do discuss with the clients certain specific deliveral delivery delivery dates like by 10 of the month we will deliver the project by 20 of the month We will need your feedback and by 30 of the month We will provide you with the bug fixing and I would expect you the payment to be made on 30 of them Of that they say first of the next month, okay If the client cannot deliver his feedback by 20 of the month What you can do and you'd rather Sign this in a contract again by calibrating expectations by upfront Telling telling upfront the customer you're going to do that Like hey after starting on 21st day I'm going just to move further with the project based on the feedback that I got And if you don't provide me with a picture with the texts Okay, I will just put some dummy text and images because I need to move forward If the if you are upfront about that and the customer accepts it That's okay for everybody if he says no, that's not okay Then you need to create another customer agreement between you two which really depends on your case But the keyword here is calibrated expectations Hi, thanks for your presentation just to put it in context and because The method is very interesting But I'm just interested to know how big the company is in terms of Sure, the number of developers you work with the kind of volume of business that you do We are now 10 people 10 people company 10 people full-time employees Thank you for the question. It's one more thing. Excuse me. I have been using this where when I was a freelancer as well So it worked fine and then I scaled it up