Thank you for coming, this is a large workshop, so we'll be here for one hour and a half. I think we don't have anything after that, all in lunch, so you can ask me any questions that you like. So this workshop is mostly about management, and as management is kind of messy thing, you can ask me anything, anytime. I will try to answer all of your questions about tips, tricks, workplace management, software management. We will not cover everything, we will not cover communication parts, we will not cover all of the soft skill parts. I will try to answer all of your, like, objective down-to-earth tech tips questions. So this workshop is about that. So do you have any questions about that? So, I will just set up the, so what is the audience here? Are you developers? Who is a developer? And project managers, agency owners, business folks? Great. So we have, like, a half. Okay, I just have one more thing. Sorry, sorry for the tech trouble. Can you see me here? Can I sit? So, did you have a fiery Friday night? Did you try, should we move it some maybe? Here in Serbia? Fiery water, stuff like that. So, okay, great. So, intro about me. I started to code around, when I was 15, so this was 20 years ago. And a couple of my partners and I started the company 10 years ago. We are focused on workers, on book commerce. We are book commerce experts. So we are now working with, with workers and book commerce solely. So this is our core focus. I have spent a lot of years coding, then managing projects, then managing clients, managing contracts, quotes, estimates. So my current line of business right now is mostly sales and marketing. I would like to code, but I don't have the time or just my code to just say, get away from us. So this is a little intro about me. So, fun fact. What do you think is the percentage of failed IT projects? Just take a while, yes. 60%. 90%. This is a specific number. So 60. 75. So it's around two thirds of all IT projects are failed projects. So what is a failed category? It's either over time or over budget. So the thing is that I have observed throughout the 10 years that you have two major problems. First major problem is communication. You all agree probably about that. So it's always, it's about communication mostly. The second largest problem is not having a plan. So not having a clear right plan about what to do. So these are two main problems. We will talk mostly on this version about the second problem. So I cannot cover the communication parts as I said earlier. We will talk about the planning part, what to write, how to manage tasks, how to manage a software project, how to manage your team from a technical perspective.  So we will not cover main communication parts. So as I said earlier, having a clear plan about what to do and having a clear path about what to do and who will do what will solve 80% of your problems, 80% of your child problems on your IT projects and this applies to all IT projects. WordPress, WooCommerce, Joomla, Kentico, custom software, custom design, anything. So I've seen a lot that you have a big project and team just doesn't know what to do. They don't have it in writing, they don't have a plan, they don't have estimations, they don't have priorities. So does anybody know what the backlog is? Are you familiar with it? How much? 40% people know so backlog is a software dev term for task list. It's a plain task list. It has around four or five major elements. It has what is the name of the task? What is the description of the task? What is the estimate? How much work will you put into one task? And who will do it? We will now go through the major elements of the backlog. It's one of the simplest things that you can do in your IT project and this is the most overlooked one. So we will go first with how to tackle description of one. So description of one task in software development can be done I'm a user that needs to do something so that I can complete some tasks. So for instance, I'm an anonymous user that wants to leave his email address so that I could receive blog post entries on a newsletter. So this is a typical description of one software developer task. So we now have one workshop assignment. Do we have maybe some papers and they said it will be here. So can you pass down some papers? We have some questions so far about the structure of the backlog. Do we have papers? So this is the task. We need to estimate how much hours will be put into design development and content of this task. As an anonymous user, I want to subscribe to a newsletter leaving only my email address so that I could receive new blog posts for the topics of my interest. This is a typical task when you're doing a WordPress site and for instance, the client wants to have a newsletter subscribed in the footer area. So this is one of the first requirements for the client and developers and designers need to estimate this task. So we will do the estimations in the amount of hours. So you need to come up with how much do you think how many production hours will this task take. And you need to take into account everything that you know whether it's backend, front-end, design, copyrighting so anything that you can come up with how many hours will this task take for your crew to make. Is this clear? I have one tip for you. So this room has 50% of this and around 75% of people are doing business there. You can pair up. So if you can pair up with a developer, he can help you with that. So you can make like joint estimations. Like you say, okay, I think I will need x amount of hours and I will need y amount of hours. So if you can pair up, that would be great. We can have around 10 minutes for this task. So just try to come up with some number. And if you have some questions, just shout at me. That's fine. So first question. Which categories are the topics of my interest? So I would say the WordPress platform has three blog post categories. So the question was how many categories does the WordPress install have? So the WordPress implementation has three categories, three blog post categories. So let's say there are news, events, articles. GDPR compliance? So the second question was GDPR compliance, yes or no? I don't have a cookie, sorry. So the answer is yes, GDPR compliance, yes. But that's a really good question. If your client doesn't sell to the EU customers, then this question will be no. But for the purpose of this workshop, the answer is yes. You can ask me anything. Okay, if the client... Wait a second. Everything needs to be on the front end. So it is up to you whether you want to have like radio buttons of topic choices or check boxes of topics, but everything needs to be on the front end. Okay. I mean next to the forum. If somebody is done, he can just shout, no, sorry, sorry, that's a bad idea. Nothing, ignore it. Okay. Okay. Okay. Third party. So the question was, are we using the third party mail chain or a controller? So the answer is this up to you. One more question. We are reasoning just about registering users or taking them their email, not constructing the newsletter and managing the newsletter. Good question. So we need to register email addresses so that we can later send or post these email addresses. But now we are just evaluating the registration kind of process, right? But you need to store something into the database. Yeah. I don't know how to handle this test without it. So I would say include it in your estimation. The data is managing. Aha, you mean like managing users? Yeah. No, no, no, okay. Okay. It was about managing the user itself. Yeah. Afterwards is not considered. Yeah. So do we have some estimations done? So how many of you have something done? Okay. So we will have three more minutes. Okay. Okay. Okay. Okay. Okay. Okay. So I hope you have something. Can you just start to shoot from this row table by table? What's your hourly estimation? Just shut. And don't change the hourly estimation if you hear something that's more like... Don't. Don't. Just the total sum, total sum. Five and a half. Ten. Okay. Everything. Okay, quick, quick. How much? Five volts. Five? Five volts. Okay. Nine. Nine. Fourteen. Fourteen. Eight. One. One.  Is this? Two. No, so you? Twenty-seven. Twenty-seven. One. Okay. Twenty-seven. Okay. Twenty-seven and a fifteen. Seven. Seven. Seven. Two hours. Two hours. Eight. Eight. Eight. Okay. You. Six. Next. Ten. So four and ten. It's fourteen? So we would write like... 7, 7, 20, 20, 14, 27, you guys, 25, okay, 4, 16, 14, 20, 20, 20, 20, 20, 20, 20, 20, 8, 9 hours of the bet, 10, 8, 5, and the last one, 8, so you see the problem here, so this is like, when you're talking to a client and they say, okay, I need a MailChimp newsletter something, so this is a pretty simple function, right? It's not like I'm analyzing big data orders of magnitude, so it's a pretty simple function, and you have hourly scope from one hour to 27, so when you're buying the apartment, you say, okay, I'm gonna buy the apartment for 10,000 euros and for 2.5 million euros, so do you see the business problem here? So the backlog is a list of tasks, nothing more, but this list of tasks have hourly rates inside, so you see this is a big difference, it's one of the biggest problems in the whole software industry are estimations, estimations of work, estimations of cost, estimations of functions, estimations of implementation, estimations of teamwork, estimations of what to do with the client, and this is the perfect example for one footer newsletter subscription, which is like the tech from the 80s, so if I would ask you a question to build one pager, WooCommerce, that have only one product, we would also get into this like, oh, it's simple thing, you just listen to the team, we just connect to the team, we have a lot of questions, we had around 10 questions here for this simple function, so my first point, you need to communicate with the client, you need to ask questions a lot, so okay, we covered GDPR, this is a good question, we covered categories, this is also a good question, it's a basic WordPress question, I mean WordPress evolved from blogging platform, but we still have blogs, and we still have categories, so this is also a good question, you didn't ask anything about design, where to place the form, what is the button, what is the copywriting, what are the states of the button, what are the like, so for instance when you click a button, but you didn't input the email address, you know, you get some notifications errors, if the JavaScript is not working you will not get them, so it's kind of a, you know, there are a lot of moving parts here for this simple form, so I would say that 27 is fine, 27 is totally fine, in the end of the project, you will spend that amount of hours, if you think that you will just implement the plugin, activate it, and this will work off the bed, you are completely wrong, then you should go to some other toxic, so one hour is no go, one hour is no go, five hours is no go, everything under two days of work is no go, for this, yeah. So you are going to break down at 27, that's like a lot of hours, yeah, please break down to 27 hours. Okay, so first you have, yeah, so this is this, be pessimistic, so first you need a meeting with the client, co-operator, designer, and the client, so if the meeting is one and a half hours long, this is three hours of meeting time, co-operator, designer, and client, so this is three hours, then you need to take into account that developer will ask questions about okay, with what do we integrate this form, it's active campaign, it's mail chip, it's SendGrid, I don't know, there are tons of platforms, so developers will spend one hour on your backend implementation, then the developer will ask okay, to what list do I need to assign these users, and how do we group these users, and how do we segment these users, because this is connected to this, I could receive new blog posts for the topics of my interest, so the user needs to have some kind of selection on the form, whether it's radio buttons, or check boxes, or some kind of control to determine that she or he wants to assign himself to I know articles, or only events, so developers will have questions okay, but what if the user doesn't want any of the categories, and wants all the categories, so this raises new questions, and when you spend time on meetings and questions and stuff like that, this costs time, okay. The project manager or sales person's job is to actually understand everything that you've just mentioned, and read everyone, so nobody has to ask those questions at every stage, so you're not wasting time, so you'll actually do all of that at the beginning, and everyone will know exactly what to do, and it should take each person, like designer from backend, copywriter, hour or two per person, and testing, and that, but it's like a very simple task, it's not a major project, so a simple task shouldn't take, but that's not good management in my eyes, it's a simple task taken, 27 hours, and everyone is asking questions to each other, so you're right, this is a task for a project manager, that he needs to write down together with the developer and the client a clear functional specs, so you need to have a clear backlog about what to do, so this is your first step, because if you don't do it, you will do it later, because you will need to do it, because the client will ask you at the end of the project, okay, but where are my users, and how are they segmented, and then your developers will start to ask questions, then you will spend 55 hours, so this is the idea of destruction, it's not a bad thing to spend 27 hours at the start, you need to plan it, exactly, this is a good question, I will have some later slides about that, I will have some later slides about that, I will get you, so this is a sales question, this is a sales question and this is also a communication question where sales team needs to explain to the client that his project is not a one-page that you can do in one day, that it's a big IT project that this client will have benefits from, so it's an investment, but we'll get later to that, okay, who? Yeah, I think what everybody is trying to mention is just like, it would probably be easier to see, or maybe that's the next paper, to see all the acceptance criteria which is required in order to build this simple feature, then it would make it easier for everybody to understand that this is like 20 hours, 25 hours to build, and this is also like the whole user story with all the materials which you can present to the customer and then they will probably understand that it's not as simple as they think it should be. Exactly, yeah, we'll have some topics later about the level of details of the end types of documentation, so we will get back to that. The idea of this test is just to show you, yeah, the idea of this test is just to show you in one group of people and we all know WordPress and we all have some kind of experience that's, estimations vary a lot, a lot, so this is not like cars, house, building a garden or cooking a meal, so this is a lot, so this, so we have from one hour to 27 hours, this is a lot and this is for a simple function, so this is, I just want to tell you that the reason of the backlog is that you break down all of these little tasks and you estimate them because this will just be a starting point for your project, this is our backbone, you know, the backlog is backbone, you need to remember that it's the basis for all of your projects. So, this is a good question, so this is called in software industry a change request, so this is defined as a change request, yeah of course we all do it. Change requests are easily handled if the client need is a new thing, so if client want something new and he didn't say it and you have it in writing that you didn't say it, so then you're probably in a good spot and you should you should build this, you should estimate this desk and you should enter into the contract or your project management software and you should build it for sure, this is a no-brainer. The trouble is, the trouble is misunderstandings about functional specification and what the colleague said, acceptance criteria, what is good enough for the client, I mean, sorry, not for the client for the end user. If does our form for mail chain subscription does its work real business benefit, so does the client have a real business benefit? If the client says, okay, this is what I need, this is accepted, then this desk is checked as done. The other no-brainer issue is bugs, clients can ask you for, they see some bug or they see some bug in form handling or error message or something like that, so you should estimate this but do not build the client for it. There is also one other thing, our clients sometimes tend to push change requests as bugs, so you should be aware of that. This is a, I would say human thing, this is not connected to any type of client, they say, okay, I thought that this form will work in a debt in that way, this is a bug that needs to be fixed. You should be really aware of this wording, so wording in soft development is everything. So first tell the client, okay, it's not broken, it's doing its job like we wrote in this estimation and then you say we can do like you want, this is a change request and I will tell you it's a lot of hours after you estimate it. So no-brainers are pure bugs that are your fault, new change requests that are new functions and were never in the documentation. Great area is when clients submit bugs like change requests. So this is great area, this is project management stuff, this is communication stuff that I'm afraid we don't have time for this but it's kind of like soft skill. There are a couple of tricks about this. So 27 hours, 27 hours is a lot, this is a whole week of network, if you go to meetings and lunch and everything, this is one week of work. First, break down your tasks to smallest possible grains, like if you have decision about the backend, whether it's Mailchimp, Sendgrid, Active Campaign, this is a separate sub-task. Questions about copywriting, so what is the name of the form, what is the error message on button submit, what are the states of the button? This is one task, so the button has mouse over, mouse in, mouse out, like four or five typical states. This is a separate task, break down your tasks. If you have a task that is over 20 hours long, you should break it down. You can also use one trick, it's called Fibonacci sequencing for the tasks. So you estimate the test with this, either one hour, two hour, three hour, five hour, eight hour, 13 hour, 21 hour. So what is the tip of this? When you estimate, when you see that the task is complex and its complexity rises, complexity of the software tasks rises exponentially.  Don't place six hours, place eight hours. And this will mathematically include all of your meetings and emails and design iterations and other questions. So don't estimate like linearly, estimate like Fibonacci sequence. After 21, don't do the estimation. You need to break down the task. Don't place the test that is 40 hours long. This is not realistic. You cannot plan for this. Nobody can. There is one big topic currently in software industry. You probably heard about edge islands, crumb, waterfall project management methods, right? So clients can ask you that your estimations are in hours, days, weeks, months, and edge islands introduce story points. So it's kind of a cloudy concept. If you are a beginner, freelancer studio that is all starting into software that use hours, hours are understandable by clients, by designers, by developers, and they are clearly multiplied by your hourly rate. So the client will know the list of your tasks and he will probably know the list of your hours. And this is understandable. This is pretty important. Estimations in days are not realistic. So what is a day? A day for one team is something different for another team. Estimations in weeks are no-go. So don't estimate in weeks. Client can ask you that. So client can ask, okay, give me that in weeks. How many weeks would be needed? Months also. Do not go into this. You are the expert.  You need to, if you are a beginner or intermediate, use hours. Because they are simple. They are understandable. Just use them. There are story points. There are software project management articles. Some teams use story points. Story point is a virtual token that explains what is the complexity of the task. You can use it if you are advanced project manager. And you know, you have gone through project management methods like waterfall, calmbound, and angel. And you know what you are talking about. But for the purpose of this workshop, do not use story points. Has anybody come to turn this story points? You know this? We have some better explanation than me. What you said, how hard? It is basically what you said, the complexity of the task. How hard it is to do it. If it is like the newsletter, you would say one story point. It is not connected to a number of hours. Just how difficult it is to do it. How would you connect it to some billing or how many hours do you need for one story point? I am not sure because I am a developer. And I only learned about it in the agile class, but I haven't used it in a project. Okay, thanks. So for the purpose of this workshop I just wanted to tell you that there are story points flying around for some project. Some clients could ask you please give me an estimate in story points, you just say no. I will give you the estimate in hours. For WordPress projects, which are like web application projects, you need to work all the time with web designers and operators and content people. They need to understand your work also. So this is a tool for communication. Yes. How are story points a sort of milestones? No, no. Milestone is a date of your phase of the project. So when the design is done, this is a milestone. Done design. Okay, so one caveat. You see the scope? Remember that. And be careful when estimating. Be pessimistic.  Communicate. Like the slide said, always ask more. You had really great questions. But these are not all questions. Your goal is to ask all possible questions. And yes, this is the test of the project manager and sales team and client and senior developers to work on the whole specs. Because if you don't do it, you will have chaos later. So you will need to do it and then this test will be 55 hours. This is empirical evidence. One more thing about story points, it's actually when you create a sprint and then you say, for example in a sprint 20 story points can go. So you estimate based on that. You add as many tasks and then you estimate and then you have to have 20 story points in the sprint. So we will come to basic concepts of agile later. So we now covered the test list, the backlog. And all of your web projects and all of your WordPress projects need to have as granular as possible. So this is the basis, this is our cornerstone. So what can also help you with estimations? So do you use time tracking? How many of you? Time tracking? Great. So around 75%. What do you use? Harvest. Harvest? Jira? Another tool. So you have Harvest is the, I think, biggest player. We use it for around 8 years I think. It's really great. I'm not selling Harvest here. I mean you can also use Zocco people, FreshBooks, Harvest. Jira also has time tracking inside. Use time tracking. So this is the second caveat. If you want to take something from this workshop, if you don't use time tracking, use time tracking. Time tracking will solve three things. First, it will give you the answer on how many hours did you need for one similar function? So if you complete one project with one client. So let's say you had full commerce with FESF being integrated. And you needed to make some 30 filters with 30 taxonomies and it was a big task. Harvest will give you the exact amount of hours for this task. And when you do the next sale and when you do the next project this will help you a lot. So this takes out all the guesstimate, you know out of the equation. So this is the first thing when you use time tracking. It will give you an answer on similar tasks what you did before. It will also of course give you the scope on what types of tasks does your team work? Because so one example time shift in Harvest looks like this. So we have database development. So this is a billable task. It's for the client. We also have internal tasks, sales offers. So this is not billable. And then you this is up to you how would you structure your time shift tables. But write everything inside. If you have a meeting with the client, write it down. If you're doing a sales offer, write it down. If you're doing database development or GDPR audit or anything, write it down. Most time tracking tools can be brought down. You have a client. The client has projects. Projects have tasks. We have done it internally. Our tasks are back in development, front in development design, comp writing, content making sales offers meetings. So these are our tasks. So this is the type of tasks. Based on this we can see based on that we can see if the company is doing mostly design work or front end work or how much meetings overall do we take. So use time tracking. We have questions about this or the reasons why not to use time tracking. Okay, great. So when doing the estimations, second tip. So do you know the ratio between bug fixing and code writing? Ten or twelve percent. In favor of what? It goes for testing and bug correction. Ten percent. Okay, anybody else? Come on. Reverse. You have experience with this. Come on. Nothing? Okay. So it's one over one. So they're the same. So this is from a book. It's one of the best books that you can ever read about software depth. It's Mythical Man Month. It's a book from old IBM professor that did some Navy software back in the 50s and 60s. You'll be amazed that nothing has changed from these times. Nothing. Developers don't write documentation. Documentation is not clear enough. Estimations don't change. So read this book. This is a really, really great book. I think it's a recommended book for all software depth classes. It's Mythical Man Month. So the answer is one over one. They are the same. You can include this into your estimations. If you know that you will have some complexity about the test and you are doing it for the first time. So for instance, in WordPress, typical first time typical forms. So you will have these types of tests. We had also internally changing filtering on WooCommerce to FastTPP or changing search engines from native WordPress to SearchVP or something like that. So you have experienced team but they are first time doing SearchVP, FastTPP, ACF, you know. So you will have some first time use cases and you will have it all the time. So you can include this into your buffer. It's better to include it than not. And this is not connected to sales because you have some other tool that we will talk about this year, hourly rate. So there are after you are done with your backlog and after you went with the client about what needs to be done on your site. There are mainly two types of that will handle your project. So it's functional specification and technical specification. Functional specification is a business document. It will tell this as mission that we now worked that the user needs to subscribe to MailChimp to several blog posts. So this is one function. This goes into functional specs. Into technical specs. You will explain to your developers and to your whole team how we have done this. So this is technical implementation. Ideally technical specs should not influence the sales and business part.  So this would be written inside the technical specs. We don't send technical specs to clients. This is our choice. Sometimes you are obligatory to send it but we don't talk with our clients about our technology choice because this is not on them. We are the experts and you are the experts. So you need to decide what is your tech choice about it. There are a lot of WordPress projects that clients say I won't grant the forms. For instance, this is a technical request. You need to be aware of that and you mustn't allow that kind to talk with your client. You need to talk with your client about the content, business, their goals what the end user needs to experience. But clients they shouldn't talk with you about the plugin choice, the server choice hosting platform choice, the CDN choice, you know. All these things. This is up to you. So you asked the question about how do you make the sale. So this is the mission that we talked about. It's basically not connected to the sale. This is your internal plan. This is connected to how many hours and how many hours we need to finish something. But you have some other tool that will influence the sale. It's the hourly rate. So you also know as we danced around like from one hour to 27 hours about one little function of the quotes. You know in our industry that hourly rates also dance a lot. So you have guys on Fiverr, guys on Codable are much more expensive agencies in New York are charging 200 bucks per hour. So we have a lot of scope, a lot of scope. So you will of course get questions. So our question is, we have an office in New York. Our hourly rate currently is 150 bucks. This is in my opinion, and this is subjective opinion, the hourly rate that you need for making the agency work. I would say it's very minimal. I know this is kind of a lot for the whole region. In Croatia for instance, the hourly rate is around 50 bucks per hour. But the thing is that this is the problem. The quality of the 50 bucks per hour in Croatia can be larger than some agency in the States. And this is the problem in our industry. So of course, my recommendation for you is charges more as you can. This is connected to your knowledge. If you know more, if you are the expert and you are the only one in the field, of course you should charge more because you need to include the education, the conferences, the meetings, the brainstorms, your company tools. So for instance if you use Kinsta hosting, you know which is like a premium purpose hosting, it costs a lot. It's not cheap. You can fire up Google Cloud server for three bucks for one month. But this is not the solution, you know. So I don't have like clear tips about how to charge more. But don't back down on this. Don't back down on your estimations of work. Don't over your estimations to make the sale. Don't do it. It's a bad practice. You can over this. So if you want to sale and the project is great, it's for a great client and you are doing some good work for some non-profit that they need great WordPress and donations and you want to do it then lower your rates. This is a good tool for you. If you want the project to pass don't lower your hourly estimates and charge more. Charge as much as you can. I don't know. This is a sales process. It's not a sales workshop. I would say that one thing that can help you, what I see in our company always get the client on Skype. Always. Don't sell over emails. This is typical that some agencies do. They receive RFP because of proposal and they send the estimate in one hour through mail. This is my estimate for WordPress implementation. This is hundreds of thousands of dollars in one hour. This is not real. When you get the content from a client as for a Skype meeting this is your first sentence. That's it. If the client doesn't want to have a Skype meeting with you then you have alerts over your head. So this is a client that you don't want to work with. So this is really simple. The thing is that web projects are complex projects. You know that. But one thing that separates us from other accountants for instance or engineers. We solve a problem for a client and they will receive extra cash flow based on our solutions. So if you're building a Google Congress, if you're building a WordPress with a donation section, our solutions, our design, our copywriting, our development, speed of the site influences their future revenue. So you need to put yourself in that mindset and tell the client, you have a Skype. I need to see what is your business, what is the size of your team, what is your size of your company, what are your revenues, what is your currently monthly visits or so what is the general scope of the work. After that meeting you write down the notes and then you can have some basic proposal of what you want to do. Then you have another Skype meeting. So if you're selling, I know Google Congress projects for $20,000 or $30,000. It's normal to have four Skype meetings. So this is normal. You cannot sell your expertise and that amount of hours like $150 per hour with these estimations without having communication with the client. So this is one of the most important things. Of course. On a project basis. And it also can depend on the plan. So for instance you can sell a similar website for $10,000 for one time and this side of the scene is we have the plan for let's say $50,000. So it also depends from which one the plan comes and a lot of variables. Yeah. This is basically this. So you will over your based on the origin of the client country, their business model, their size of the team, your wish to participate in this project, everything. So you can, I mean this is only one way of looking of course. But I just want to tell this is like down to earth simple way of looking at it because in the end you will spend hours. So you will spend some hours on this. So yeah, you are right.  There is one concept that some agencies are pushing. I know I'm not happy with it. Charging based on the value given. So this is kind of so if I see that that Nike has contacted us and I see that they will have like large e-commerce revenue, then some agencies try to determine what will be the value of this project. This is also for advanced talk. This is not so much simple thing. It raises the question of ethics like Morton talked yesterday. If you're charging one client like large premium is it ethical? Is it you can?  We will work a lot we will have a lot of expertise. Then our rate is 165 bucks. So this is your tool to include all of the client variables. And it's a simple tool, it's understandable tool for all of your team members. Charging based on some kind of implicit value that you cannot measure. It's a shady business. You can try to do it in some objective ethical way. I just want to point you out that when we were doing web apps I have not seen this kind of project be like objective price. There are some agencies that are taking for full coverage installs. You can take the percentage of revenue. This is kind of measurable thing. You can do that but you need to be aware of one thing. You are not controlling the product price. You are not controlling the product quality. You are not controlling the client's customer service. So you are not controlling these factors. So basically you can tell the client ok we will optimize the site we will do conversion rate optimizations we will scan analytics every day. We will optimize the server so we have increased conversions everything. But mainly the revenues will not be up to you. And there is also the fact that depending on the business there are clients that make an order through phone or email and you can't have that number. Exactly. So this all complicate things and you all know that software development in itself by design is really complicated. So this is the reason why the book Medical Man Month the concept is having change in 50 years is complicated. You should also educate your team about the basic concepts of service industry. Like service industry has something that is called permissibility. When you are done something that is in the air vanishes. It also has something that is service that you provide is connected to the authors work to designer developer. So every designer has some kind of personal input into the project. So this is also something that is connected to services. Because of that services are complex. And software industry in itself is really complex and you need to utilize the tool to make this simpler. So if you agree with the client that you will have your revenues based on their revenues you are making it more complicated. Because of what you said. You also have for instance you have one website and you will sell the same website to some other client. Good luck. Of course productization of the service is making things simpler. So in our lab we have one service called VP watch. We combined hosting backups security, anti malware it's everything in one package. We described it internally it's really simple for the client you pay 100 dollars or 1000 dollars per month based on your largest of the site. And we charge it to be a credit card. The whole process is pretty simple. So productization of the service is great. But it means making things simpler. Not more complicated. This is the caveat. Okay. So I don't know why I place this here. So it's a screenshot of harvest you know that. So it basically tells you on what kind of tasks is your company working. I placed it here because you can then analyze how many billable hours do you have in one year. So you can take that also into account when you are making the estimations in your sales projects. So this is also really a good way of tracking tasks. So you see that we have done a lot of design work but front and back and combined is around 5000 hours. So it's more than design. On project management we spent 1000 dollars. So we should all analyze this throughout the year. Our billable rate is 68%. This was in 2014. Our team was then pretty smaller. We have now 20 people right now. Our billable rate is 50%. So this is just some kind of feedback from me to you. I mean I'm not happy with it of course but it's the cost of having a team of more than 7 people. When you have a team of 7 people then you can coordinate really easily. And 7 is a number in all psychologists and all industrial engineering experts say that 7 is the maximum amount of people in one team. When you go over this number, when you have 10 people, 20 people, 30 people, 50 people, then things tend to get complicated. And you have billable rate around 50%. This is also up to you. So we placed design, dev, content, so everything that is creative and pure production this is billable hours for us. Everything that is meetings, project management, administration is non-billable for us. This is our setting I don't know if it's right. It works for us because it helps to separate the two. But this is up to you. So when you are done with the backlog, in all of your estimations and all of your functional specs and all of your technical specs then these are basically I wouldn't say copied but they are kind of merged into a contract. What I have seen with contracts and digital agencies they place fixed dates of launching the site or launching the app. This is really bad practice. So if you have fixed date in a contract it does not allow any iterations on design, on copywriting, on bug fixing, on changes or anything that the client will ask. So first tip, do not place fixed dates into your contract. This is really bad practice. What you can do with this is of course working hours and we help our clients for their planning that we say we will need five working days for something. Working days for something. So this is our way of telling the client so they can plan from the business side. We don't place fixed dates inside the contract. We say, okay, our vibrant will take five days, design first iteration, 20 days and then after we approve it then we will need 40 days for software dev. So this is how we do it. Do you have some questions about this? Yeah. What's your favorite tool for mock-ups, wireframes, whatever? We have a couple of them. It's a real-time board. Real-time board is perfect for collaboration and we're doing wireframes and we use a vision for mood boards because they're really easy to send to clients and I think that's it for mock-ups. Our crew uses Figma for web design so Figma inside they can play around with wireframes whether they're low-fi or high-fi wireframes. We use Figma and real-time board for communication with the client in vision. I have one more question for you. Do you use with the customer who doesn't like the design, for example? Do you I, for example, I write down okay, twice I will do some slight changes to the design and then if you want even more then you have to change. Yeah. So this is a typical question. In the contract we include one design iteration. So we say we will send you a template of the home page because home page defines pretty much everything like footer and the menu and the whole visual style. We always place that the client will have one iteration and it's working okay. It's working okay. Yeah. How do you handle when you make a backlog, make the plan, make everything and the client doesn't want to go on with it? For example, he says this is too expensive okay, I'll find someone else. In a big team, I guess it's easy to there is things that can be that cost a lot. It depends on the type of the project. If you really want to do it then lower the hourly rate to your bare minimum. So you as a team you have a bare minimum for your cold engine you know what it's called, I know what it's called. So you need to determine your bare minimum. So for instance in Croatia your bare minimum is probably around 20 bucks. So this is your lower rate if you want to go with the project. So for instance we had a client who is UNICEF and we wanted to work on this project and we said okay we will do it and we just talk with the client what's their budget and this was it. So you need to know your bare minimum and you need to know if the project is interesting. That's it. I've got a question. My clients have fixed prices always. How do you deal with that? What do you mean fixed prices for what? They have a budget. So they'll say we'll have this much money for our website. You have one good tip. You can cancel some functions out. So for instance if your client has okay I have $40,000 for it, okay fine. You will not have advanced filtering on the sidebar because this makes a lot of worries. So you can cancel functions out and then you tell the client okay we will launch the website without these functions and later in the next year when you will have the budget we will include these new functions on your website. So this is our product roadmap. That's basically what we do. We tell them we can do anything for any budget and then just make it really simple if they want something. We set the expectations instead of the client. This is fine. This is fine. So we are doing mostly book commerce. 80% of our projects are e-commerce based. We cancel the functions. So for instance client wants integration with Salesforce. Now this is a big thing. And we say okay you don't have the budget for it we will do it in 2019. And this works. You can also simplify existing functions. So for instance cancel the newsletter subscription and make it on the checkout. Maybe it's simple enough. So you can do that. You can also tell the client no. Yes this is also one tool that a lot of folks don't use. You can also do spring cleaning. You can also so for instance based on the harvest estimated hours. What I do on spring I look all of the same devices for the client I say okay this is not working. They are having too much change requests and iterations. We don't have any value of providing our expertise to them. During one year we tell our clients sorry but we have to part ways. So this is also normal. Say no. Cancel functions. But don't lower your estimations. You can make them simpler. But don't lower it. You will always have You can So do you know the number of meetings to close one sale? So after you done the functional specs the contract and you need to sign it. Do you know the number how many meetings and projects do you need to close one sale? This is objective measuring throughout the whole sales process. But this is like industry average. So seven. Five. Three. The one to work with us. So it's basically ten. In sales industry you always have ten. You need to make ten calls to make one meeting and you need to make ten meetings to make one sale. Of course this varies a lot with agency expertise with your market position your sales constraint who is doing the selling. So if your selling team doesn't know what they are talking about they will probably have twenty. Ten is industry average. Oh my god we don't have time. Sorry about this. So I will just really be fast with this. So after you close the sale make the project team this is a typical team you have team members designers, co-writers, developers, team leaders of these developers larger agencies have project manager so one person that is dedicated to this project and of course you have the product owner this is the client. One thing for this workshop I mean it's not basically tip it's something that is a problem. It's called player manager syndrome player manager syndrome nobody? Do we have developers that need to manage something? Yeah? Yeah? This is a big problem in our industry we have developers that are seniors and they need to manage juniors they need to manage documentation they need to manage me as an owner they need to manage designers, co-writers they need to manage clients because they are the only ones that can give the actual answer it's called in psychology it's called player manager syndrome it's a it's highly it's highly connected to our industry when senior developers are becoming managers and 50% of them want to become managers or system marketers and 50% of them want to just quote and then you have a problem in your team so this is a problem I don't have answers for you so right now we have four senior developers that are really good guys and they tell me I don't want to handle clients I can't handle juniors if they are good but they they don't want to handle so in our company it's the project manager we have some we have a concept that's based on the book the person who is doing the tasks should talk with the client so we abandoned account management on purpose, we had account manager it was not working we had a dedicated project manager it was not working so right now we assemble a team we assemble a team that is based on client developer that will do the work and his junior and the designer so this is our team and this works this really works this is me we have one team that is basically I would say operations so we handle billing, invasions, estimates there are four of us in the team and we handle this but we talk a lot with our developers and our designers when we are doing the sale everybody is on it so this is something that if you rise from 7 people to 10 people and 12 people or 20 people you will see this syndrome happening ways to deal with this is of course communication, mentoring, coaching talking with your developers talking with your team constantly constant change so this is something that so this is not easily soluble we cannot solve this on this we just need to be aware of it that most developers don't come to the management but from the team perspective they need to do management and this is a problem it has its name you should always have one product owner if you have multiple product owners multiple clients telling you their feedback this is a big problem so you place in your contract you always place in a contract one product owner this is pretty important it's the same importance as not having a fixed base so you say okay Kelly you will be the product owner you will be feedback all the comments all the approvals from you and you are the product owner and that's it, if you have multiple then you will have chaos what for this is happening in WordPress projects is the CEO comes to the later stages of the project you need to have a meeting with him on the skype like like please we are working a lot of this we need to take care of all of these tasks could you please send your feedback first to Kelly she is the product owner you need to have a talk with the CEO because this will happen on all large projects CEO will try to jump into it and say this is bad this is not what we wanted but Kelly knows what she wanted okay you know what waterfall is okay I will skip through that so okay I will not skip through that it's so waterfall when your project passes when your contract passes you are doing the project waterfall is a project management methodology that is understandable to everybody you have phases of work and you have a lot of blockers design team cannot start to work if they don't have content and developers cannot start to work if they don't have design typical blockers of waterfall so agile try to solve that with sprints and it's a kind of a mess for most of the teams say that implementing agile is a mess in their team so what we use we use Kanban it's a pretty simple methodology it just say what needs to be done what are we doing and what is done Kanban is basically under agile umbrella of project management methodologies I can only tell you my experience it really works it works for small teams it works for teams to 30 people it's understandable it's visible to everybody and it's kind of you know like go to method if you are a team under 30 people agile can be implemented on larger projects if you have like agile team needs function to do in one sprint so I think you cannot do this in smaller work based projects in smaller work based projects you can have if you set a fixed date you have some purpose for the fixed date you can set it up I mean so we use Trello we have a swim lines in Trello and sometimes we set up dates it's not usual we set up dates and then the client says oh no wait we need some copy changes change the date so it's a you can set it up if you want this is up to you we share board with the client we first used Google Sheets for backlogs we now use Trello it's great we are monitoring it a lot so it doesn't happen I mean this is connected to changing question we see it and then we say no this is on ideation so it's like what is this okay seniors effectiveness juniors effectiveness what do you think is the right way 2 to 1 4 to 1 4 to 1 4 to 1 so this book is 10 to 1 I have seen it I think it's 10 to 1 so this book is in my opinion empirical opinion it's correct so this is pure project management and who will you assign to one task what is the big problem don't assign multiple persons to one task so come on board if you have one task when you come on board one assign in one task remember that if you have two assignies for one task the shit will not get done you have a saying here in Serbia so means multiple grannies they will not get done so it's don't place the soul one task one assigny okay so these are the typical tools all of them are great we use them all asana base cap and trello are for mixed things if you have developers, designers, contact makers you can use them Gira is great we use it internally so we copy trello tasks into Gira project management tool Gira is mostly for assorted development but it's really great yes so we place all the functional specs in trello board we kind of have some integration with Gira they are copied to Gira and technical discussion and technical specs in Gira and we also connect harvest with Gira so Gira has a really great budget you can connect harvest time track inside Gira issue and when you track time it connects what is the task done really granular okay so this is for support tasks we use zendesk, we now use trello for support and alerts and notifications also for handling monitoring of your hosting so we take care of all the hosting and backups and security and monitoring and alerts for our VP clients we track servers with New Relic, PHP layers with robar and the whole application held with zendesk these are all these feeds are all connected to Slack so whenever we have a problem the whole team can receive notifications and act on it so these tools will cover all of your WordPress stack so from the database to your frontend around time and around time and everything and these works so this is like typical how do we monitor one WordPress install and we largely use Google Data Studio for client reporting it's really great tool, you can do a lot with it you can ingest database entries, Google Sheets analytics data you can insert all sorts of data in Google Data Studio and mix and match it and do functions and graphs and send it to client it's free, so it's really great so what's the purpose of all this we always take care of our clients and our apps so when we finish the project we always maintain it and we always evolve it through Trello and through Google Data Studio the thing is this you need to keep your clients this is pretty important in the service business do you know what is the ratio of customer acquisition cost and customer retention cost 4 to 1 ok it's 10 to 1 so it's also the sales thing it's 10 times more cost to attain new clients than the keep team existing ones this is the basis of service industry of all service industries especially word principle commerce web app industry you need to keep your clients this is pure math of course you need to provide value this is another topic here I just want to tell you that this number is real it's really hard to attain good quality clients you probably know that so you need to keep them like not only in Atlanta this is also ok ok can we just have 5 minutes more ok so tips for getting paid tip 1 break your project budget and your contract into as many rates as possible don't have like ok this website will cost 100,000 bucks you will pay me at the end of the project don't do this so break your project budget with the clients in the contract into as many rates as possible so what we do we have monthly payments we say ok this project will be 3000 hours or 4000 hours and you say you will pay every month 400 hours so we try to break apart the budget into as many rates as possible second use pyramid types not schemes sorry payments take the first rate to be 40% then 30% then 20% if the project is down the client will owe you just a little fraction of the money so this is also pretty important do you take any advance payments yes of course so this is the project start is a rate this is 40% is good 50% is ok don't charge over 50 I don't think it's ethical to charge more than double of your project when you didn't start it 40 is ok 30 is ok if the client wants to pay only 20% don't go into this I mean go into negotiation you need to explain all of your upfront cost and all of your allocation because allocation in our business is pretty important so go with 50 if the client next then go with 40 35 ok any more questions about this since then for planning if product is unsure that you go on but he needs a lot of help from your side to make work clear to charge him for that yes so this is called MVP so this is minimum viable product we provide UX and UI services so we just provide some viable friends and some quick mockups in HTML and we estimate this work we say ok this will be 20 hours of consulting and then we charge this this is a good approach by the way so tip 3 don't connect payment rates with milestones so this is one thing that is pretty important client will want to connect so when you're done with design I will pay you this when you're done with backend I will pay you this so don't go into this because you're basically never done with milestones design is always working progress front end is always working progress backend is always working progress project can have milestones so we launch version 1.9 2.0 2.1 these are milestones don't connect payment rates with this do connect transfer of intellectual property rights after the last payment this is pretty important so tell the client when you pay me the last rate for the project I will then transfer the intellectual rights for you you will have some clients that will ask you typical contractual thing when the work is done automatically the code becomes the property of the client you should not go into this HTML code design or content operating our authors work really easily describable by our industry and by our law this is authors work you have rights to it by the pure definition of making it so when you make something this is automatically yours it can be transferred to clients only by a written document do this written document after the client has paid you everything this is tip 4 if you have some questions about this then we are done thank you very much


This is Professor Gerald Friedman, Department of Economics, University of Massachusetts at Amherst. And we're here today to talk about is inequality good? Last time, if you saw and remember, we talked about utilitarian arguments for an equal distribution of income. Now, one of the most prominent utilitarian economists of the 20th century United States was a man named Arthur Oaken, O-K-U-N. And in 1975, he presented a series of lectures at Harvard that he were published as a book that has been very widely cited, one of the most widely referenced works in economics in the late 20th century America called Equality versus Efficiency, The Great Trade-Off. Now, 1975 was an interesting year because it's arguable that that was the year things changed. For 30 years, the period that the French called the Glorious 30, Western societies, Western Europe, the United States, Japan, grew very rapidly and income distribution became more egalitarian, more equal. The poor gained on the rich until just about 75. And it's not all Oaken's fault, but since 75, more so in the United States than in Britain, more in Britain than the rest of Europe or Japan, income inequality has grown. We have moved away from an egalitarian distribution, especially in the United States. Now, Oaken, even in 75, raised the issue. If we are an egalitarian democracy, if we believe that everybody should have equal rights and be treated equally, then why do we tolerate what even in 1975 were very large disparities in income and life chances?  Why don't we do more to equalize these disparities? Oaken's argument in a nutshell was that we tolerate inequality. We accept inequality because it's the price we pay for efficiency. We can reduce inequality, he says, only in a leaky bucket. Some of what we take from the rich to give to the poor will be lost through these leaks. As a society, we will be worse off. It may be, and Oaken believed it would be the case, that if we take from the rich and give to the poor, it's still worth it up to a very far point, but it will reduce total output. He identified three leaks. First, the loss of work incentives for the rich and the poor. The rich, he argued, won't work because of the high taxes that they'll pay to finance redistribution. The poor, he argues, won't work because they can just live off of what they're getting from the government. So that's the first leak. The second, the bureaucracy to administer this transfer. You have to have tax collectors, you have to have social workers, you have to have bureaucrats processing paper, moving checks from one person to another. And third is the loss of the big incentives, the types of incentives that spark major creative enterprises. Oaken would argue that somebody like Steve Jobs or Bill Gates would not, or Larry Page at Google, these people would not have created great new enterprises and new ideas, except for the possibility of making a big killing.  Because of them, we're in a situation, Oaken argues, where society faces a downward sloping trade-off between equality and efficiency. We can maximize efficiency at a very low level of equality, or we can maximize equality at a very low level of efficiency. You have to choose where we're going to be in between, he argues. Because of these trade-offs, more equality, moving up the equality, you have to move in that direction and reduce efficiency. That's Oaken's argument. And this has been very popular. Economists have jumped on this. Businesses have jumped on it.  It would be nice if we could do more for the poor, but we just can't afford it because it would reduce efficiency too much. I'd like to help the poor. I'd like to pay more taxes for the poor, but ah, sigh. It would reduce efficiency. It would be bad for society. Unfortunately for Oaken, well, a couple of unfortunate things for Oaken. First is he died very soon after writing this. Yeah, he wasn't that old either. Fortunately for him, he didn't get to see what was done with his work because he would have put himself over here. But unfortunately for Oaken, he's just wrong. It's amazing how much research has been done on the Oaken effect. And nobody finds it. If you look across states in the United States, you don't get a downward slope. I mean, up here with high equality, you have Lamont. Down here with low equality, you have Mississippi. And you know what it looks like? It looks a little bit like this, the 50 states. More equalities associated with faster growth, more efficiency, higher income. The wealthiest, most productive parts of the country are the blue states, New England and the Pacific Coast and the upper Midwest in New York. The states down here with low equality, Mississippi, Alabama, they're like the third world compared to Vermont and California. You look within counties, same effect. More equality, higher productivity growth, higher income within the county. You look across countries, economic growth by countries. The fastest growth comes in the countries with more equality. The slowest growth comes in countries like Zaire and other third world countries where a few people control everything. Oaken is wrong. There is no association between inequality and greater efficiency. If anything, the effect goes the other way. More equality is associated with greater efficiency and there are good reasons for this. First, more inequality leads to more violence, more crime, distrust and more money being spent on incarceration and prison guards and police, etc. Wasteful spending. Transactions costs are higher in places with more inequality. More inequality, you want to make sure you're on top even if it means stealing and cheating. Second, competition, more inequality, the use of financial incentives undermines cooperation and team production. You want your team to work together well, they have to share, they have to cooperate, they have to believe that everybody's working together, not that everybody's working for one person. Third, more inequality is associated with poorer people. Those poor people are not able to care for their children as well, are not able to produce good human capital because they don't have the money for books, for medicines, for Suzuki violin lessons, etc. You take those together and what we have is Oaken was just wrong and the economic policies that for 30 years have been built on Oaken's recommendations are not only policies that he would have aboard, but they're policies that are misfounded. If we want more growth, if we want more productivity, if we want a happier society, we should be reducing not promoting inequality. Thank you and have a nice day.


I mean, how much do you take that as a as a personal challenge, especially considering some of your past matches, right? I wouldn't say it's personal, but I want to go out there, you know, try my best, prove that I can be on that level of a center in the league.  So I just want to prove that I'm on his level. Christian Winfield, New York Daily News. Hey, Jarrod, it wasn't too long ago where I believe I would ask you after every game or so just what's it like learning after playing against an elite center.  I don't think there's any way around that. So can you just quantify your growth over the last few years and kind of talk about what you've learned that you've been able to apply at this point in your career?  You had a lot come where I had a lot coming at me and just looking at all the bigs that came for me looking out of the bigs. I had to play against like being thrown into the fire in the 19 and then after that playoffs and just having to learn on the job. And finally, this year, I'm starting to put it all together and knowing what I have to do, knowing I can still be more physical out there and not being able to call fouls, getting respect from the refs, you know, that's, that's the thing. Just going out there and playing my game and being comfortable over the past couple of years. Here's another look at it bears repeating this graphic because we heard it during Jared Allen sound right there. He definitely outplayed Rudy Gobert, two time NBA defensive player of the year. 19 points, 18 boards. He must have had the end of the pregame on Frank when we were talking about how Gold Bear absolutely destroyed him in the previous four meetings.