 Thank you for joining us. Susan is with us from Drupal Anywhere. She's going to be talking today about how to Gordon Ramsay your Drupal Shop, the best recipe for business success. So we're really excited. Hopefully she won't chop us or whatever Gordon Ramsay does. But I'm not sure. But I think he's the one with the spiky hair, Susan. But she'll be here to give us some great advice on how to best do that. And just a quick introduction about Susan, our guest speaker today. Susan's been involved in Drupal for eight years. And she's, you know, she's the Jackie of all trades, shop owner, salesperson, marketer, project manager, operations, design and site builders. So she's got clearly a long, a long history of, you know, being involved in many different parts of business. So she can really speak to the whole process and how to best fit the scale of your successes for your shop. So we're really excited to have her. And we will start with her now, Susan. So I'm going to switch screens for you. And then we can get started. Thank you. All right. There you go, Susan. So it's showing your screen. There we go. Hey, does everybody see my screen? It's just empty right now. So maybe do you have your slideshow up? I do. Let's try this. There we go. It says on show. Okay, great. Wonderful. Good morning. I have done everything from a $50 website to a $500,000 scaling in my eight years. And I did it all the hard way. And it wasn't kind of towards until towards the very end that I started to see, oh, there's a process to this, no matter how big or small. So I hope that no matter what size shop you are, or what size projects you work with that you realize that what I'm talking about today, you can do a tiny bit or a lot of all of these things. So good morning. Thank you for being here. It's really exciting to be part of this program with the Drupal Association. So now my keynote won't. Okay. So thank you for surveying who's here because it helps me. Susan, it sounds like we out my workshop because they aren't getting sold. Yeah, it sounds like you're having some audio option difficulties. So maybe start from the beginning. Yeah. Okay, Lauren. Yes, I can hear you now. Okay. So I've been consulting for the last four years, but I have really done everything from a $50 web project to a $500,000 web project. So I hope that you get nearer to skew it more to whomever it is in the audience. Susan, I hate to interrupt you again. Your audio keeps going in and out. Yeah. I'm not sure how to alleviate that. Are you using a headset or? I am using a headset on the platform. So do you have everything else closed out on your computer other than keynote? Sorry, everyone listening. We're having a little difficulties just with technology, technology, technology. You want to try one more time, Susan, and let's see how it goes. Thanks everyone for being patient. We're just working on getting the audio to work correctly. Can I end the room now? Yes. Hi, Susan. You sound great. I just, I decided to call in on the phone because I think that there are so many people here that we're stressing the bandwidth of the computer. Got it. Okay. All right. Okay. So, all right. Well, let's, was everything I said intermittent in the beginning? Yeah, unfortunately. Okay. That's okay. We'll edit this out. We'll edit it out. Don't worry. Okay. All right. So basically, while I was gone, if you guys had the time to answer the WHO survey, that's really helpful. And then I find that people come to my workshop because they aren't getting the results they want. Sometimes they're working very hard, but they're not making money. Projects are hit and miss. A lot of times you think you're delivering great, but then you're blindsided by the client. I hear a lot of owners sometimes saying, well, I think my team next is not quite right. If I had better developers or better project managers or better clients, everything would be better. But that's not usually the case. There's usually something else that's missing. And I generally find that businesses are funded by cash flow rather than margins. And they're unsure of how to make a useful change, how to empower teams. I hear, if only my teams would take ownership. But they're not doing the thing that Gordon Ramsay does, which is they give people authority. He comes in and says, you have the authority to do your job. And so what does that look like? But the reason I'm passionate about this topic, and I spend all my time trying to resolve and make companies better, is that failure hurts Drupal. It's not happening in one place. Weak delivery is happening in a lot of places for a lot of people. And so what that does is that poor implementation hurts all of us. And I'm passionate about this because if we can become more successfully and deliver better value to customers, we can see this number grow rather than kind of flat line. And the secret to a successful Drupal shop, or really any shop, it doesn't, I'm actually working with another company that's not in Drupal and we're doing the same thing. The secret to a successful shop is process. As an owner, process gives you control without having to micromanage. Process allows people to take ownership. It allows teams to be energized, to deliver quality. And it unleashes all of that talent you have sitting out there. And so if you have the right people doing the right things within a good process, you create ease and profitability. So how do we get there? We're going to actually go back to a long time ago and think about this as schoolhouse rock. And if you remember, there was a great little cartoon and it talked about the story of a bill. And so I'm going to tell you the story of an SOW and how this little SOW travels through its entire journey to become a successful project. So basically what happens is that there's one document to rule them all. It starts out as a slide on a report and it turns into a user guide. So one of the complaints that I get is that, oh, updating documents is very expensive. And I'm going to suppose that not updating the document is more expensive. You're spending more money, more time, more energy not doing this than you are if you did it. So I'm a big fan of reverse engineering. That's how we decide what to build with truples like reverse engineer. And so I'm going to break my keynote and I'm going to show you where we're trying to get to this morning. So is this the screen that you see? Yeah. Okay. So perfect. So let's start with the architecture document. This is done in Omni-Grassel, but you can do it in anything that your team is comfortable with. But at the end of architecture, before you start development, you should have something along this line. Obviously, for a very small project, this might only be one or two pages. For a very large project, it might be 60 pages. I did a very large project with a division over at ETSC. And their Drupal team brought three pages of written text, and it was good. But when we really went through discovery, it turned into a 39-page document that looked like this. And so you cover all kinds of details. You cover user storyboards. You cover roles, permissions, content types, taxonomy. This document looks more impressive when there's a bunch of stuff in it that I didn't want to share any client information. You can also do it in a spreadsheet. And so if you look down here at the very bottom, which I think it's hard for you to see, so I'll read out the tabs. You call out your fields. You call out your view modes. You call out your views, all the fields in the views. And you can see in the shade name, title, filter, sort. You call out flags, no cues, image styles. I can't tell you the number of sites that bus QA, because at the very end, nobody in the beginning had predefined image styles. That's such a basic practical best practice. There's menus, panels, panes, taxonomy, field collections, user roles, modules, integration, content. How many of you haven't been paid for a site because the content never got there? Migration strategy, launch strategy, performance needs, training, and documentation. So this is the ideal information that every project should start with. So your ticket has something to have in them. And we'll talk about tickets at the very end a little bit. So here we are. And this is a storyboard. And I'll go more into detail about this later. But this is, to me, the genesis and the simplicity of how to talk to clients. So now I'm going to go back to the keynote. So that was starting at the end. So now you know where we're trying to get to. What I see, though, is sometimes shops are doing that, but they didn't bring their clients along with them. And the clients find off on something they didn't understand, makes no sense to them. And therefore, we're still unhappy at the end. And so it's kind of like if I find off back for a submarine, I really don't know what I'm signing off on. And so that's why it's important for you to bring the client so that when you write those engineering facts, they also have understood what they're getting. Now I see my screen isn't displaying. I'm back to my keynote. So hang on here. There we go. Okay. So let's go back now to the beginning. And I have five golden rules. If you can't win, don't play. Don't take jobs that you're not going to knock out of the park. Take them in your sweet spot, your realm of expertise, and create upstream and downstream partners to share work with. You should know shops smaller than you, and you should know shops bigger than you, and you should collaborate. You should decide as a business what kind of group will you do? Do you have a specialty? Maybe you do commerce. Maybe you do nonprofit. And then become a subject matter expert. It's good for you from a marketing strategy, which we can talk about another day. But decide these answers as a company, and then incentivize your sales people on these business objectives. It takes discipline to say no to projects, but there's an opportunity cost when you say yes to the wrong project. I am working with a client now, and they were going back and forth on a big project. And he said, oh, well, the client gave me specs. And so we're going to go try my materials. I said, great, let me see them. So I know all of you have seen these. They're a rambling 12-page document of wishes, dreams, hopes, desires, and weirdly specific ways to implement something. And you cannot confuse a client document with a scope of work. They're very, very different. And so then the idea was that, oh, well, we'll go time and materials with this client, and then everything will be okay. But it's actually a separate bet. Because what you're doing is you're agreeing with the client that you're going to build the weird things in that document for the money that he has. That's the way he's hearing it. You're hearing agile methodology, but he's hearing something very different. So it's important that you don't use a client's back to begin agile development. One of the strange things that I see when I work with companies and projects is that the client starts to learn a little bit about Drupal. Maybe they go to a couple of cons. They spin up some sites, and they hack around a bit, or they have an internal person that knows some Drupal, and they start to dictate how you deliver Drupal. No matter how much I've read about Rupanel, I never go into my dentist and then start dictating how he's going to do that Rupanel and what kind of billing I'm going to get. So remember that you're the expert, and don't let that relationship start being the other way. It's a partnership, and so this is the first red flag. And it's up to you to manage their expectations. You have to teach them how to succeed at a web project. Sometimes you get a great client who's gone through several web projects, and then they're very good partners. Most of the time, just like these little chicks, it's the first time they're crossing the road. Let your process and experience lead the way to success. Don't let them drive the cart. And at the end of the day, just saying no, they can't make you code. I can't stand in front of an engineer and go, write me something right now. It doesn't work that way. So if you don't have a deposit, if you don't have a clear process, if you don't have a good relationship, if you don't have your scope of work, and you don't have your team's buy-in, just don't do it. Don't start working. Often when someone's in one of my workshops, I say, who's had a really bad retail project or struggling with something? And when they raise their hands, I always ask them, when did you know that this was going to go off the rails? And it's surprisingly early, like most of the time before deposits. So listen to your instincts and don't put your team through the agony of going through a bad project for money because you usually don't make any. So I want to talk not about genes, but about a gap. Clients and engineers do not talk the same language. And it's not that the technology fails us. Our communication fails us. There's a communication gap, not a technology gap. And we need to understand that, and we need to understand how important it is for us to manage that gap. The client cannot. This is all on us. Unfortunately, a web project is often the catalyst for a complete rewrite of the business rules. So here they are. They've already got the whole team running towards this web project, and then you ask them, so how do you enroll and become a member? And everybody has to come to a grinding halt because nobody knows what that means. Nobody knows how it's done. Nobody knows what the benefits of being a member are. And so the whole project, your team and theirs, comes to a grinding halt because nobody sat down and made them write their business rules before development started. Sometimes you get a client that's all ducks in a row. But mostly clients are either very manual, and they type it up on the typewriter in the basement, they bring it up, someone scans it in, and then they fact it somewhere, and it somehow becomes a PDF. That isn't the business process. That's just how they're doing it. We have to translate that into Drupal for them. It makes them uncomfortable, they don't understand the technology. But that is what our job is. One of the biggest places I see this happen very early on is clients start saying, what can I have? What does Drupal do? I saw this thing over here. I look at this site and we answer, oh, you can have anything you want. And so what we've done is we've created this. We've made that gap bigger because now their dreams, hopes, and desires fit nowhere into what they can afford. And so it's important that we actually control how we speak about what they can have. So in closing the gap, one of the things we have to have is common language. And so how do we do that? We start out with a site audit. I'd be curious to know how many of you actually do site audits, but site audits are very big and they start the relationship with open. And we can talk about the structure of a site audit later. And from the site audit, after you've reviewed their site, you've explained to them what is great, what isn't great, and made recommendations. You can now, they love you, you're the expert. And you can now go into the next phase. One of the things that I do is we were looking at that gap between now their dreams, hopes, and desires because you told them they could have anything they want. Is that I stress through a lot of the box. So you've all heard the saying when you're a hammer, everything looks like a nail. When you're a Drupal engineer, everything looks like great custom code. But from a business and technology standpoint, we have to get to a minimum viable product with this little customization as we can. Team phase one. And so why would I say that? Like you're leaving money on the table. The client doesn't want to get pushed into Drupal out of the box into a minimum viable product. Well, there are a lot of good reasons for that. The first is that you get an early win and you establish yourself as the expert. You also get to test the water to see if this is a good client and a good project. Maybe everything just comes wheels off the bus. And if you have engaged into a big, long, expensive thing that you can't terminate, you're stuck there. But if you can get them successfully launched with a little small product, then you have the opportunity to go into phase two or not. The other thing, it's about delivering value for the client. How many of you have gone through a project, built very expensive features, and then you go back into expense. They never launched organic groups. They never did that. They'd use paper-y kind of content site thing that you build all this customization and workflow for. And it's because their imagined needs before launch are very different after launch. They don't often understand how Drupal works and how hard it is to get people to contribute and to use a new site. And so pre-building all of those wishes and bells and whistles isn't really in their best interest. And I've ever done a project where the client could afford all the features they wanted. So it's good for you and it's part of Agile Methodology to help prioritize that and develop a minimum viable product for them. Remember, we're trying to close this gap. What you really want is this green side to be very small and then the blue side to be very big because that's your margin. In this scenario here where you're looking at this slide, there's no margin for you as a business owner. It's only when it's inverted that you can then be covered for all the change orders and get the margin that you want out of a project. So look at the site audit and discovery look like. You go through and look at all of these things together with the client. In the site audit, you're doing it more yourself, but then this framework for the site audit also becomes the framework for discovery. And because now you're starting to use this language all the way through this communication process, you start to train them in the language. Site Audits and Discovery prioritizes ideas in the class. It helps to identify hidden stakeholders. I know of a few projects where the CEO actually came in and they were the visionary. They set the scope of the project and then the trouble was then when the site launched, hidden stakeholders showed up all over the place. Well, I can't do my work. Where's this? Where's that? They had all kinds of needs that were hidden all the way through the process on the content management side of it. And so if the site audit and discovery had gone through user stories and storyboards and interviewed all those hidden stakeholders, that project wouldn't have failed in that way. But now what we're doing with this is we're beginning to map their vision and ideas into Drupal language. So we're taking their rambling 15-page manifesto and we're turning it into Drupal. So this is my favorite part. The truth of the matter is nobody reads anymore that sometimes least of all are clients because what we're giving them to read is very technical. Drupal is hard to understand. We forget people don't know what a block is. They don't know what a note is. They don't know what text on a NEO. So we give them this document to sign off on. And again, it's like me buying a submarine. It's pretty worthless documentation. The other thing that I don't like about Word documents to describe technology is that somewhere, sometime, you're going to put in language about video management and then that feature is going to come out except somewhere in this document in one paragraph is said and you'll be able to manage videos. And then the client's going to bring that back to you at the end and goes, Steve, you said we'll be able to manage videos. So those straight sentences and words in a Word document will come back to haunt you. So I like pictures. One picture is a thousand words, but really one picture is clarity. And what a storyboard does is it illustrates the life cycle of each content type, user and feature. And they're based on the user's stories gathered during discovery. And you can give this back to the client and they understand what you're trying to accomplish. And more importantly sometimes is I can create this in minutes, put it in front of an architect, and they can redline it in minutes. There's no parsing, did I mean this? What do I mean by notifications? Who did it go to? All of those questions that engineers like to button down. So I'm going to go through this in a little bit more detail here because I think it's so much fun. There's a little bit of a lag between my computer and what you're seeing. So let me see if we can get that to happen. Okay. So I start with, let me make this a little bigger for you. I start with a little legend. Nothing magical here. You can pick your own icon set. You can do this however you want. And then I define user roles. I can't tell you the number of times people go, oh, we just have two users. And then as you walk through the story of their website, many, many users and many, many needs start to surface. We go through their content type. And then we put it into this very simple framework. So anybody here who's different in Drupal can understand what happens. An editor creates an organic group which sends out an invitation to a teacher who logs into Drupal and goes to my account. Really straightforward. And then you can narrate that a little bit if you like. And now we can see the next step. The teacher sends out email notifications to the student who logs into Drupal who goes to my account and now is part of the organic group. And let's talk about that in terms of a piece of content. So a teacher creates a content type. They're able to upload a picture, some content, a video, and a bio. They save it and it goes through workflow. Then if I continue this storyline, then the next one would show the editor moderating this piece of content and publishing it to the web. But what's so great about this is you can see right here if you look at where my cursor is. If I didn't have bio and video on this document, it's very evident that it's not here. And then later, because this document becomes the user acceptance testing and the scope of work and everything else, when the client comes back and goes, where's my video and bio? You can go back to this document and you can say, oh, it's not a problem that we can add it. However, it was never part of the original scope of work. This is your protection against scope creeper. And I think that is pretty cool. If you don't take away anything else besides this, it'll be great. Okay. I see you're not back yet. Let's see if we can get I'm back on my keynote, but I think there's still a lag. So I'm going to keep talking. So one of the things that are very important is actually user dashboards. We have a strange thing in Drupal where we are building a content management system. And as companies, we forget that Drupal doesn't natively and intuitively provide the m part. It's common for us to build out a Drupal site where the user can't actually get to managing content part. And so we have to actually start by building the dashboard. I've worked on many sites where I'm like, how do I get here? And they're like, oh, well, you have to go edit blocks. Well, this role doesn't have permission to do that. Or, oh, we put that in the template. Or, yeah, that's still some HTML. And all those things, no matter how brilliantly you deliver the product, it's the client, stakeholders, the people who live and breathe on the site for a living, can't get to their content. They're not going to be happy. And this is one of the areas where Drupal gets a black eye. So how do we fix that? Well, one of the things we do in discovery is we build out the dashboard. And what the dashboard does, it does two things. One, it helps the client start to understand what they're going to get and how they're going to manage it. And this reduces fear and risk. The second thing is they are often terrible at explaining their own processes. And by building the dashboard and reverse engineering this for them, you can help surface problems that are going to come back later. And so sometimes the more complex the site is, the more value this will have for you. Like who has to edit what plants? And they don't know about workflow. They don't know about revisioning. They don't know about Drupal views. And so by building the dashboard and letting them see how they're going to manage it, they can start to express, oh, well, where do I edit my logbook? What do you mean logbook? Oh, we have this thing. It's the most important thing we do on the site. Where do I manage my journeys? What are journeys? We never talked about that. So these are the kinds of things that having the dashboard engages the client because they do know how they're doing their work now. They just don't know how they'll be doing it in Drupal. And this dashboard helps make sure that you close the gap and you're creating common language around that. So one of the things that I see happen quite commonly is that everyone starts out with a very good intention. They get maybe to this point and then there's some sign off somewhere and then this becomes a dusty moldy piece of paper way back in Google Drive. And no one looks at it again. That is a terrible way to manage this process. And what has to happen is however you do it, whether you put it on a wall, you have binders, you pull it up in elephant notes, in base camp, inside the ticketing thing. But all of these things have to be present at every meeting along the way. It's a living, breathing document that has to constantly be touched against. So your team might be discussing something, but they better be discussing it along the framework of what's already been approved. And this is where I see a lot of straying up the path and the kind of fork development without needing to. It's like, oh, this is a really great idea and this would be better this way, but it actually deviate from what the client is expecting and has paid for. And maybe this new better way is something that you can get a change order for and get paid to do. So now we're going to take a little sidebar. This is where one of the basic tenants of technology is you approve technical debt. And nobody has this conversation with clients. So you need to explain to them what technical debt is and who owns it. And they're going to be very surprised that they own it. But where we fall down is that we don't share with them each time they incur technical debt and let them make a choice between option A and option B. So what happens is like that slide where the engineer says to the client, you can have anything you want. And so the client says, oh, I want to integrate with Twitter and I want to do it like this. And they go, okay, great. And you flip out a change order for it. But you don't explain to them that if they had done it this way, it's drew a lot of the box and space within their minimum type of product parameters. If they make it with this subtle request, it becomes a custom module that they have to maintain over time. We ran into that with a very big client and they wanted the little overlay on the photograph. So you roll over the photograph and then you get a modal box. Great. Tons of modules do that. But then they wanted the caption. And that choice to have the caption was what made it a custom module. And it doesn't seem like it should be that hard, but it was. And so they asked for it. The team started running to build it and they're like, time out. Did they actually approve the technical debt and the complexity of having this? And they're like, no, but they said it was really important. So we had to roll back and then offer the client the choice. Free now, and of course not free, but I mean no technical debt now. And you can have it now. Or technical debt and custom and delay of project. And they chose to go free now and take on the technical debt later. So that's a good example of where not letting the client drive development is really important. And letting them make this choice. And some good examples of that is implementing solar over-duple search for panels versus blocks. And several things in that genre. So how I do that is I love doing this. These are three-by-three grids. They're used everywhere. But I use them with the client because you're not trying to argue with them. You're letting them make an informed choice. And so what you do is you ask them with all of that 15-page document. Which are the must-haves? Which are the wanted? Which are the like-to-have? And then you explain to them which are the minimal debt things and which are the high debt issues. So you can see in this scenario that something that they would like to have, but a very high technical debt, they will likely forego. If you give your clients this matrix to make decisions from, they themselves will navigate themselves into safe waters. So very important. You can also do it with risk. They might be asking for something that is very risky. No one has done it. Not only have you not done it, but no one has done it. And it falls into this heavy custom high risk area. Sometimes it's essential. So if you look at it across here, it's a must-have with a very high debt. But helping clients understand your Drupal technology decisions is key. Too many times I see companies drive forward with very custom high risk decisions without really letting the customer know that that's what's happening. Another little slide bar is design. I know it happens and it can be okay, but I really do not like design that precedes engineering. I don't mind a home page or looking for all kinds of things, but sometimes you'll get 25 Photoshop files of every single page mapped out, wireframes galore, and the trouble is nothing's been engineered. What the heck is wireframed if there has been no functionality defined? It's kind of like to me, because I used to actually be in contracting and interior design, is like why would I order all my wallpaper before it's the house that's been laid out on a blueprint. I can do all of that after there's a blueprint, but I can't do it in advance with a blueprint. So your engineering facts are the blueprint. And then on to that, you do your wireframes and your design. Susan, we have a question really quickly. Yeah, I'm sorry. When I think keynote, I can't see my thing, so thanks for interrupting me. No, no problem at all. How do you manage fixed price projects, in particular ones that are through public tendering processes, and you have to put in a fixed price and promise to deliver everything within the client spec? So that's always tricky, but what I would do, because when you get those RFPs, ideally you get to a point where you don't have to do those, but that's not a reality for everybody. And sometimes they're really good. They're high-profile and things like that. But what you can do is actually take that document and counter-proposal it. In other words, sometimes what's in those things don't exactly have to be that way. And so what I would do, let's say the budget is $200,000 or $100,000. I would actually look and see what you can build for that and reverse engineer it and make that your offer. And maybe you don't get paid and you don't win the bid, but the trouble is if it was a $300,000 project inside of a $100,000 budget, I'm not really sure that's worth winning anyway. Is it really worth $100,000? Like if you took $100,000 and did awesome marketing, wouldn't that get you more better work? So I'm not sure that losing money on a project is ever really a good idea. But I would take that. I would do the storyboards. I would do the other stories. I would wow them with your presentation on what they can really have for that money. And a simplified version at MVP of it. And I've seen that be successful because they don't know. Like when you're writing the RSP, you don't know what the actual costs are. And so I say that you tailor that, that you're comfortable and proud to deliver it. Nobody likes to work on a project where you're losing money, you're burning development hours, you have to turn away some other cool projects that came in because you're in the hole for this project. You have to finish. All that happens is that everybody hates working on it. And then this is where you as the business owner making this decision really burdened your team. You made them unhappy on purpose. And that's not good. It's not necessarily a good business decision to go after those things that aren't actually winnable. Remember, that was one of my first rules. I'll link eight projects where you can win and there are many reasons why projects fail. And that is one of them. You see this quite often in the Drupal community. A shop blows up to 20, 30, 40 people and then they're back down to five. Well, you know why they check on one of those projects is usually the answer is that something didn't look like a big magic wish that happened. But what really happened is that at the end of the day, it's sponsorship. And so I always say like it's either a good business or it's not. It's either a good client relationship or it's not. And anybody who puts out an RFP and it's really determined to squeeze the blood out of a rock, why do you want to do that rock? So that's what I would say. Okay, let's go to estimating. So most shops are very good at estimating this. Like they understand who built what and when it's delivered. I have all kinds of opinions about how to do that better, but that's not part of this workshop. But the problem is that a real project has these three phases. And we've spent, you know, 40 shunt slides and most of the time this morning talking about the other two. Because they're more important than development. If you don't do analysis and project planning, development is just group growth. And you're just burning hours that you don't need to. So these are the steps inside of those three areas. There's a lot to understand before you get into development. And what we're really talking about is closing this gap, right? And that's what we're doing by going through business and analysis and project planning, is that now we have created common language. You understand their stuff. They understand your stuff. And I will say, whenever you take clients through business analysis and project planning, the light bulb comes on for them. How complex the thing that you're building, because, you know, there's this, oh, Drupal is free. Why am I paying you so much if I can get the code for free? Well, you're explaining this to them and you're helping them understand that the expensive part is translating their business model into Drupal. Get a lot of pushback from people because they say, what I'm talking about is too expensive and time consuming. Especially like a smaller shop, you know, maybe you're two or three people and you're like, I don't have time to do this. But ignoring this step doesn't mean you were successful at bypassing them. It just means that you spent the time and money somewhere else when it's built with more expensive money. So if you spend the time upfront, you might have one person doing it at one or two people at $200 an hour. But if you do it later and your team is in group growth mode, you might be burning five or $800 an hour. So you burn the time whether you charge for it or not and whether you do it or not. And that's why projects often don't have any margin. And the question you have to ask yourself is how valuable is it to me to finish quicker without impediments and without errors? Because we're talking about velocity and velocity is where your margin is. The other thing that I see, and I'm working with a company right now on this, is they're bidding at a very large project with 17,000 different little side projects. And they're looking at it as how much actual manpower is this going to take? And what they forgot to do is, because they're now taking this $100,000 project and trying to throw $100,000 at the group. Well, that's the wrong metric because you have to take out something for margin. And these are just rough numbers. You take out what you actually have. Your overhead might be 50% of your business. You have to know what your overhead is and what margin you want at the end of the year. But let's just say your margin is 10%, that's the padding you'd like to have on every project. Your overhead is running at 20%. And so now what you have left to throw at the project is development. You go, great. That should be about 700 dev hours. Well, it doesn't work out like that either. So this is more how you should allocate that $70,000. And this is where I see a lot of companies get in trouble. The project budget was okay, but they didn't pre-plan to allocate resources in the right manner. So this is what it should look like in my mind. And if you look down here at the very end, I have 15% UAT from Buzz. And you can make this 10 or you can make it five. You can make it whatever you like. However, you must have something last at the end after user acceptance testing to do what I call feature college. There are things that are not going to be wrong, but there are things that they're going to legitimately want to be different. And you have to give them the budget to do that. You can't try to get another 1500 out of them. I've never seen a project launch without this. So why is it that we don't have a line item to allocate to it? And I actually put this in the scope of work that we have allocated for Buzz and feature polish, not new features, feature polish. And believe it or not, clients don't question this because if they've gone through any kind of development, they know, and once you explain it to them, they understand. But launching a site to help them has a lot of great areas. Let's just be honest about that, acknowledge it, and put it in as a line item and cover ourselves. If you feel really weird about it, say if we don't use it, we'll refund it, but allocate for it. So the quarterback. Every good team has to have a quarterback. Gordon Ramsey comes in and he acts as the temporary quarterback. But the quarterback is calling the shots, but they're not running down the field and doing things. So as an owner or as the lead engineer, think about how much you're quarterbacking and how much you're doing. But the quarterback in a Drupal shop is the project manager. And this really surprises people. And it's why if you're an engineer, if you're a Drupal guy and you're working with two or three people and you're doing pretty well, the first person you have to scale up to if you want to grow is the project manager. They're as valuable as engineers. They're the heart of every project. The reason project managers fail is because they're always given a lot of responsibility but no true authority. I'll say that five more times if it helps. Project managers impact every part of your company. And done well, this is the key position for profitable projects. So if you look at this, they sit at the center of sales, engineering, the customer, although you might also have account managers, they're part of the QA demo and they're responsible for change orders. And so without them, the project pretty much comes to a grinding halt. They're also overworked. If you look at what they're supposed to do, they can't manage six or eight projects as ridiculous. But how do you know if your project manager is doing a good job? Well, the first thing is have a good process. And this is what allows you to give them the authority to manage client expectations, teams, and tasks. If you don't give them true authority, all they are doing is running back and forth, putting out fires, conveying weak messages, and they're holding the project together, but they're not doing their job effectively. And this creates burnout and stress for everybody. So at the end of the sprint, and if you don't do sprints at the end of your project or milestone or whatever you do is the project manager has a lot of work. They create the top line tickets for the next sprint. They allocate resources to those tickets. They monitor the bill along the way. They watch the burn rate for the company owner. They do QA and testing. They demo to the client. They get the feedback. They update the docs. It's a very, very important role. This is what keeps your project on track. And so without control, you have no velocity. This is kind of good loss that I see in a lot of projects. They run late, be behind, they're over budget, and this is why. So the important part about a project manager is that they measure sprints, and they are empowered to look at three things for you. The first is what are the hours that we sold? What are the hours the engineer has estimated? And what are the actual hours used? And then they have to try and match that to how far along you are in the actual bill. So that you can see that you've actually burned through 50% of the money, and you're a 30% of the way done. And this is your early warning signal that a project is going to be off track. They also are responsible for tracking and making sure that change orders happen. And I'd be curious to know how many of you put in change orders as a process. Maybe we can add that as a question. The other thing is language. So in Agile, they have this great word called backlog. Backlog works when you get paid to show up for work regardless of what you do. It doesn't work inside of our trying to deliver projects for money environment. What you do when you say put things in backlog is everything you ever talked about with a client in that backlog is a promise that you will deliver it in the original scope. So you're promising to do work for free when you use the term backlog. You have to create clarity and parse things into four separate packets. There are the things that are basic. There are the things that are in scope that you're going to cover in another sprint. There are things that are out of scope, but you're going to do them now like it makes sense. Maybe adding the photo gallery or laying the groundwork for translation. But they're not in scope, and you have to create a change order. And there are other things that are out of scope that you're going to do in the next phase because they're too big to bring on. They require discovering architecture and really break out of the MVP box. Or that they're just not important to do now for the project. If you'd lump all of that into backlog, the client will come back to you at the end of the project and say, if you recall, we talked about, still in the blank here, and you said you would do it. That's what backlog turns into. So be sure that all of the conversations at the end of every sprint get parsed into one of these four buckets. So now, by this time, we are now all the way into the scope of work. And a living scope of work is your insurance against scope creep and the unmet client expectations. The FOW is updated at the end of every sprint. Then that needs to be sure that engineering signs off on them, and then they're sent to the client. And you don't move into the next sprint until that's signed. So your sprints have to actually allow for this document lifecycle to happen, along with change orders. So you might end the sprint on Friday, and you might not start the next sprint until Wednesday. And so you have to work that into the cycle. So I'm almost done. But one of the things that I see is ticketing problems. So now we're going to have to talk about development. And if you notice, I'm almost completely out of time and look how long it took us to get to this part. So most of you are familiar with the development cycle. But before you begin development, you've done discovery, you've done the audit, you've done architecture. It's actually a good time to really assess if the project should move forward. If your team really hates this client or hates the project, and they're not sure that they can deliver, it's a really good time to bail. It's a really good time to say to the client, here are your docs. Let's put this out for an RSP. And because we don't think that we can deliver good product to you. It's actually okay to say that. And then if you have an upstream or downstream partner, you can recommend, look, this other company, they're much better at this kind of development. Maybe it's because it's a giant integration with an Oracle database. It's a good time to do it. And especially if they're a bad client, if they're not coachable, if they haven't paid on time, and you can see that there's some shaky vegetarian issues, there's no reason you have to go into development. So tickets. I get a lot of pushback about this. I'm not exactly sure why, but if tickets aren't accurate, a Drupal shop is running their business off self-data because everything rolls up from what's happening at the engineer's desk. And so if you don't have accurate tickets, you don't really know if you've made money on the project. And the reason for that is this is what I often see. I'll open up JIRA, and then you can all show me his tickets for the day, and they mostly look like this. There's a title, and they tied it to a project, and they allocated some hours. Well, what are you building? A view can take 30 minutes? A view can take two days? So that's an imaginary number. So if we just look at some of the things a view has to have, you have to know what content type, you have to know what seals, you have to know whether the labels are hidden, you have to know what images, we have to know if there's keywords or titles or articles. Just look on for a long time. If you somehow are in Drupal and have never looked at the interface for views, every option in that views interface has to be on the ticket. And I get engineers saying all the time, well, if I write all that stuff down, I could have built the view, which is sometimes true. And then I always say, well, what happens if you're not in and somebody else has to build that view? What happens when we have to build that view again? What happens when we're asking someone to QA that view? What are they QAing? Yep, that was a view. I saw it. Like, there's no, there's no there, there. One thing that can help shortcut this is that as a company, what you do is you build content types and views. Define what a view is in your company. And then train everybody. So then we can say build standard view. But then we all know what that means. So you can shortcut it. I actually build snippets. And so you can reuse them like a checklist. But the goal is to just touch a view once. What I find happens is that a view is built. It goes to QA. QA goes, yep, that's a view. The client gets, it goes, oh, I needed to have an image. It goes back to the engineer. You put in an image. It goes to QA. Yep, there's an image. And then the client says, oh, but I need that to be a smaller image and can you make it square? So it goes back to the engineer. So now that that, so it goes back and forth. So that view that was supposed to take two hours takes two days. And that's where a lot of the bleeding happens is that the tickets are poor and work gets done two and three and four times. And you paid an engineer. You paid the QA person and you exhausted your client. So it's very bad business methodology to have people running around off of bad tickets. Now we've gotten all the way to here. And it's sad to say goodbye. But you are now going to go to phase two. And you're going to repeat all the steps. It's very tempting to skip discovering architecture in phase two and three. And you don't have to do it as heavily but you do have to append the documentation. You do have to make sure you got your storyboards right and continue to upgrade the user dashboard wireframe. Follow your process. So we close the gap. We've done a side audit. We've done training. We've done discovery. We've done architecture. We've done UAP. And we have a user guide because we have our documents all the way through the process. Our little SOW has been with us every step of the way. And then for you, you've managed your client expectations. We've delivered a win with an MVP. You know about technical debt. And you've now delivered a fabulous project to make money. So I will stay around for as long as people want to ask questions. So I hope you got a lot of value out of this. And I'd like to thank the Drupal Association for all of their help and support and the opportunity to speak with you today. Thank you. Thanks so much, Susan. We got a really a lot of good feedback. We do have one question from earlier. I didn't want to interrupt you. Excuse me. How much do you put into winning a pitch? Do you have a percentage of the budget that you like to use? Say a budget is $100,000 and you want to put 10% into winning projects you really want. Therefore, you put in the equivalent of $10,000 to get that project. I know those are such difficult questions, aren't they? Business questions. But what I'd like to do is think of it like this. That what you're doing is discovering architecture. So you are putting that 10% at risk. But rather than it just being a pitch, what would be really nice is what you delivered was actually discovery. So that when you win, which if you do often discovery you will, because what you're showing them is all of the information that needs to be in consideration. So it shows your expertise. That when you do that, you now have your discovery documents. And so you've just preloaded that work. So the closer you can get to ending up with the discovery docs with the storyboard concept, then the less wasted effort and money it is. And especially with storyboards, if you remember that's the one with the icons, that goes together blazingly fast. I usually have someone that's more in the design teaming side do it. I use Omni-Graffle just because they're more facile with the tools over there than the engineers and they actually care that it looks pretty. Those things go together. Amazing is that. And if you can get your storyboards in there along with everything else, you're a little far way into that process. Great. We actually had a lot of requests for your templates. So I let people know that they could probably contact you separately and you could discuss that further. Yeah, I don't have them on my website that I put up yesterday and I hope it's up today. What a delayed project. I know. Never heard of it. I've done this consulting and I've never needed a website. People use my LinkedIn page. But you can email me at Susan at DrupalAnywhere.com and then once I have them up. I do have slides up on SlideShare. You can Google that. And then I'll put, I think this will be available too. But yes, I will definitely share my template. The one spreadsheet actually is one I modified from Palantir and I'm assuming that they meant to share that because I got that from someone who said they got it from a Palantir workshop. And then the other one is one that I put together for when I do business consulting with DrupalShops. So I'm free to share that one. Great. A couple more questions. Can you give a description again of SOW and what that stands for? Oh, I am so sorry. So SOW is Scope of Work. And the way that I think of it is that these are engineering docs. That's what we, those are the documents that we looked at in the beginning. So Scope of Work is a compilation of those engineering docs, like the Palantir and that Omnigraphal document and the storyboard. So when you combine all of those elements together with the user cashboards and wire frames, that's the scope of work. It's what is the legally binding part of the contract for work. Cool. We have another really fantastic question. Presumably you charge for discovery and architecture. How do you estimate or quote for it, especially since it's the most valuable bit of work and it's often very unknown how much time will go into it? Yeah. So when you look through this presentation again, I do have a slide that shows percentages of how to allocate your $100,000 project. And so what I can do, let me pull that up on my screen again, Lauren, and we can look it back because that is a good question. Yeah. Let me switch screen share really quickly. Yeah. So in the beginning, you'll be very hesitant and tentative to like ask for the money because it's sometimes a new way. And I would definitely train your salespeople. But what I love about selling at Honor is that it's a really small bite and people are like, oh, okay, I'll do that. Like it's a very low risk engagement. And so, you know, you might lose money on the line item called discovery, but you are losing money on the line item called discovery anyway. So just the fact that can everybody, is that come up yet? Yeah, it's a little bit of a delay, but it'll be there. So if you look at the slide, it can be a little more or less. You can figure out like what is comfortable for you. But I would train your salespeople to sell off these little engagements. You can sell off an audit, you can sell off discovery, you can sell architecture, you can actually sell design, right? Like, you don't have to do that totally tied to development. Yeah, it's not. That's fine. I'm sure. But anyway, yeah, I can publish this slide separately if we need to. But it was 5% audit, 10% discovery, 10% architecture, 30% development, 30% design, and 30% UAT. So you work out like what's good for you, and then you'll be able to start selling that. Okay. Okay. Last question. If the client won't or can't sign up for an agile process, what do you do? Do you say no to the project, or do you run with it more like a waterfall, or run it agile internally, but not with the client? So agile is tricky. I see a lot of people say they're working agile, and what they mean is time and materials. Because delivering agile is a very specific thing, and I don't see too many companies that actually deliver agile. So what they often mean is I work time and materials because agile means you're actually developing deliverable products all along the way, and that takes some pretty deep talent to do that. What I see is people taking a waterfall project, working on it, time and materials internally, and like that. So I don't think it's that important for you. I think it's important for you to work the way that you're comfortable doing. I think it's more important to look and see if you're making money doing it that way. Like it doesn't matter what you do, like you can do waterfall, and actually if you do waterfall correctly, you can get to value-based pricing really quickly. So it took you 100 hours to build the project, but you sold it for 300% of what you actually did. So waterfall can be very successful. So if that's helpful, the other thing that I see is that people sell waterfall, which means I've agreed to do this project for $20,000, but then they show the client their hours, and then somehow bill like their agile. So if you sell waterfall, you don't have to show time and materials. They've agreed to this project at this price. You're done. Internally, you should track hours so that you know that you made money, but the client doesn't get to have the best of both worlds. You don't get to do a waterfall project and then pay you on time and materials. So be sure that whatever methodology you're doing, it's the correct way to do it. Awesome. Thanks so much, Susan. Just a reminder, thanks everyone for joining us. This was really informative. We got a lot of positive feedback. And of course, we really appreciate you participating and asking questions and for Susan for joining us and helping out with the Triple Association webcast series. So just a reminder to take the survey at the end of this webcast, it really helps with our content selection, and then of course, improving the sessions that we can provide for you. A lot of people ask if there's going to be a recording and if they could share this recording. There is going to be a recording. We'll have it probably around Monday or Tuesday just to edit and make it more streamlined, but we'll tweet about it. We'll email all of the attendees and I'm sure Susan will also promote it as well on her channels. So thanks everyone for joining us, and I hope you have a great rest of the day and a lovely weekend. Thanks, Susan. Thank you. It was so much fun. Yes, absolutely. Take care.