 and I started talking about it, I experienced this still, what it was, avoid them. And that's how we got this session. So, for those of you that are interested, really long URL, not that false. But here's a shortcut. These are some of the things that we felt were the most common, yeah. Yeah. These are the things that we felt were most common and it's not like, well, they're the most common for us. We've been doing it for a hundred years. But for clients who are either new to Drupal or trying to get the most out of Drupal, these were some real challenges, you know, multisites. There's a terrific pull from multisites for efficiencies and lots of different reasons and discoveries, so easy to skip because subject matter experts know their subject so well, right? So, but this is not so much about the pitfalls as how to avoid them because what we really do is put together a list, but we really can't anticipate when you are going to encounter these. Handy dandy road signs are difficult to come by. And, you know, we talked about these pitfalls specifically because of their inexorable quality, right? They have a way of sneaking up on us. Constraints prevent us from steering clear of them. Time, scope, budget sometimes force us in our projects to take risks and pull us in closer than we really are comfortable with being. So what do we do? What we figured out through our conversations with one another and our staff is that we needed and we usually employed early warning systems in our projects and that our practice that had evolved over time. Early warning systems come in different shapes and sizes, but they are systems. Now, neither, none of us have the luxury of having a fully functional character programmed in multiple technologies as data was, but he's still an early warning system and he had certain sensitivities. His character was written to have certain sensitivities that the next generation could rely upon to ward them away from danger before it got too catastrophic. We don't have data, but we do have early warning systems. We've had them for a long time. Miners used to bring canaries into the coal mines to warn them of dangerous gases, right? So the concept of an early warning system is one that we're very familiar with. Yeah, so, and we can't really bring a canary onto a Drupal project and it might be very sweet, but they wouldn't be a very good early warning system, right? And we don't have this guy as much as we'd like him, right? So what do we have? What's a more common analogy or metaphor for an early warning system? Ever notice how your crash test dummies on television are always the most talkative, right? And of course they're getting banged around and the purpose of a crash test dummy is really to prevent worse injuries as the concept of harm reduction. They are a type of early warning system and they ask lots of questions. They're very talkative. So where we're going with this is a concept of early warning systems or personas. And this is not something that I think is really very intuitive for us on our teams. You know, we wanna have folks ask lots of questions in front of the client? Asking lots of questions, that gets a little scary sometimes because we're supposed to be the folks that know the answers, right? And if you're a client and you have a vendor that asks a lot of questions, you might say, well, why are they asking so many questions, aren't they? The ones that are supposed to know the answers? Personas will be different people at different times. They might be a developer, a designer, they're pretty much concerned. They're trying to conversation with a client and they're telling you about a migration they have to deal with and you just have to ignore stuff like that. It's not a question for a reason. And the question is, do you need to be able to answer during that phase? Don't. If into those details you discover that it's something far more complex than you realize, then that's something that bites you and then chances are, that's something that requires additional work and you have to pay attention to that and you're concerned that, you know, a low level person in a project you will bring up, maybe there's a content editor or a standing comment. And all the people in the room are like, oh, who cares? That's just so-and-so being dressed and you might just be in a feature or something like change of the heart or it's just giving you a very small insight into maybe a problem that's that person knows about that you might want to dive into the ego, right? They're asking these questions and they're pointing out these different things. Don't ignore that stuff. Don't assume people ask you the questions. Let's say somebody asks you a stupid question and you should be able to answer it. And sometimes there's essentially a line of inquiry that may resemble one thing at the beginning upon the first question and then may evolve into something else a few questions later. And if you shut that process down at the beginning, you don't get to realize the potential value of those questions. Implicit in this equation is that you have some system, some persona, some processes asking and some system, some process, some persona listening and analyzing and thinking these things through. And we developed this particularly because we didn't want to put anyone in a position of we wanted to develop something authentic, right? So we have in our projects, the limitations, the famous iron triangle of time, scope and budget. It wouldn't be fair to come and present a solution that involved you moving any one of those three points. Your limitations are what they are, right? The only time any one of those can move is when there's a real authentic reason. So we had to develop a way of avoiding these pitfalls that could function within your time, your budget and your scope requirements. And really what we came to after talking to enough folks was that this is something that had to become a habit within our teams and each member of the team had to internalize it and support it and embrace. And we developed this and then the first time we gave this session was at the Drupal Camp New Jersey at the beginning of the year and we had one of our most awesome staff members, Marias Boyanova who's a program director at FFW and used to be a project manager. And we gave the presentation and she came up to us afterwards and she says, I'm the crash test dog! Because she recognized it immediately because Maria is famous for always asking questions and always zeroing in on it. So what we thought we would do is go through each of these pitfalls and sort of have like a call and response, what you might listen for and some questions that you might ask. And what we thought we'd do is we'd run through the list really quickly and then time permitting, go back and have some kind of discussion. We're a big group but I think we can still have a discussion about how you might approach these different pitfalls. So the idea is to develop sensitivities to the pitfalls that we listed at the beginning of the session. And then furthering that, if you buy into this idea of an early warning system, what you wanna do is you wanna develop your own list of pitfalls. Maybe you'll have some in common. Maybe you'll have some that are special for your service organization or for your university, your university, your enterprise, your small business. And they'll be, you'll have a particular set of pitfalls based upon your strengths and your weaknesses. So the idea is to take this concept, internalize it, customize it and make it resonate and be relevant for everyone. So you're ready to go through each of the 10 pitfalls, put our crash test dummy and our canary to work. Mistake number one, planning without performing a thorough discovery. Who's never done that? Skipping discovery is really bad, okay? It's been really easy because you're working all the time with folks that know your stuff. They know their stuff, that's what they do all the time. But we forget things, we lose track of things. There are things that different stakeholders care about, that others care less about. So never, ever, ever skip discovery. You're kind of, they tend to know their system and their people, so they're very kind. And so everybody knows that discovery is so important. So everybody in this room is gonna have a discovery in the next project. You know you're headed for a pitfall if when in the middle of that discovery, someone asks, where is so-and-so? Shouldn't they be here? And then, of course you've budgeted for three days or three weeks for discovery on site. You go home, your time is up. You track the fact that your stakeholder wasn't around the table. It's an early warning sign. Hold the marketing on the site only at the top. Never happened? Neglecting the content audit, often a part of discovery, often bigger than the discovery itself, right? Depending upon the size and scope of the project. Who would ever ignore a content audit? No problem. We know what it can give us, how much trouble it can get us in if we don't pay attention. But you know you're headed for a pitfall if I thought that this might ring true for some folks, right? Well, what are you gonna do with those PDFs and how many of them are there? What's in them and can it be structured? Do you want it to be a web page or do you want it to live forever as a PDF? I'm old school. The same used to be free the bound to periodicals and issue the important to you and me. PDFs, how do they live? Are they gonna be searchable? What's gonna happen? Who's gonna break them down? Who's gonna do that work? Oh, just a couple of PDFs turns out to be thousands and thousands of pages. You have a really good one on this. This is like an entire session. So, each accrete, sometimes get it wrong in the sense that they think about what it is. We all understand a scope of work. We wanna find comes to you and want conditions to that scope of work. And so, I decided I wanted to also add this to that. And that's what we're already affecting for a particular future. If you make assumptions about what something's gonna do, you and maybe a project manager can really make assumptions about what this future's gonna do. So, you make all this wasn't exactly what I thought it was gonna be. Now, you're sitting there negotiating with the client trying to fix it, trying to get them exactly what they want. Paying attention to the query, they're asking questions like, I brought up earlier, a developer saying, well, what exactly do you do that thing? What's that supposed to do? They're asking proper questions about, well, is that supposed to be a sign challenge? Well, whatever that future's supposed to be, you have an image that shows up in a box. Am I supposed to go to click on that image? I don't think. Because when you send it back to them, they look at it and they try to come across an additional two hours, five hours, six hours, 10 hours. And it's another example of future creep, all right? Is when either a member of your own team or the client is excited, this is good. We're all, we love to use Drupal and we love to talk about all the amazing things it can do. I was in business for years before I realized that I was responsible for half of the Ogridges, right? Because I kept talking about how great it would be. So. Just honestly, what's on the website? So the point is, somebody's listening out for this warning sign and then someone's acting to qualify and ask questions about it. Maybe it's a legitimate future that needs to be added to the scope or the backlog. But we never go into it without being very wary of what it can do to our scope, our other items on the scope, our budget and our timeline. User stories, we can't talk enough about not defining user stories. And this is something where on simple sites people say, oh, it's a simple site, what do I need a user story for? I need user stories for every level of your project, especially for the folks actually putting the content in. Your user experience always benefits from a clear set of user stories. The warning sign might be, oh, they're just gonna have to do that, put it naturally off there or not. So, we're gonna run through these and then we wanna hear from you. What might be some warning signs that you'd watch out for? What are some experiences that you encountered? Do you think this early warning system is gonna work for you or would you do something else? Skipping or skipping entirely? Testing. Everyone has a proper QA concept here? Who here has got six people on their QA team? How many people have one person on their QA team? Awesome, right. How many people are the developers of the QA lead? Honest, honesty, that's what we need, okay? Time, budget, scope pushes us. Into these conditions. We know it's a problem. We know it's not the best way to do things, okay? But we've got a long standing client and they need some help. Is it gonna be a case of no good deed goes unpunished, okay? Or are we going to be able to avoid the worst of these problems? So sometimes you can't steer clear of these pitfalls completely, but that's how we have the concept of harm reduction, right? I'll take a broken leg, please. I don't want a broken head. QA and testing, you know? When was the last time somebody saw that actually working? And this is a pretty common thing, you know? A lot of us are working in agile environments and we're sprinting and we're iterating. Well, when was the last time that thing that we sprinted on three sprints ago worked? That's why we have... Oh, there was a change order. I don't know, did we change the project management project? What percentage of our development time is project management? How's it gonna change? Is it gonna be part of the discovery, not part of the discovery? Part of the creator, part of the strategy? The code can be rewritten. Lots of code will take more time to rewrite. You're more likely to get, have to rewrite lots of code if you don't have enough project management. So is your lead developer gonna be your project manager? Hopefully not. Chances are, been there, done that. What are you going to do to mitigate the risks, to reduce the harm? What are you going to do to avoid the worst of these pitfalls? How many folks have worked or dreamt of working? Dream or nightmare with multi-sites, right? What type of experiences have you had? Good experiences, so-so experiences, bad experiences. Okay, it's about even. We want to change that ratio, right? So there has never been a multi-site, both the old kind and the new kind, launched in Drupal that didn't require careful, careful thought. Not every one of those projects got the careful thought it needed. Multi-sites, especially some time ago, were a really appealing option. They saved a lot of time, they saved a lot of money, and some of the complications weren't readily apparent. Now, we have a lot of technology that has come about that makes the old kind of multi-site where we shared a single code base. Only one of the options that we can take if we want to get some efficiencies across many different sites. But those new strategies and new options have a different set of considerations and risks, right? Oh, those great rings, you know? So, you know, like anything else, there's two sides to this. I mean, we were talking about how we had a presentation last year in New Orleans with General Electric, and General Electric raved and loved and still raves and loves their multi-site setup that we proudly built for them. A lot of time and effort was put into planning that multi-site, and it is a traditional multi-site, right? And but we've got a lot of other stories out there where people have called us and said, oh, I've got this multi-site, please get me out. Skipping the specialists. How many people have a webmaster on their staff? How many people have advertised for a webmaster recently hired one? Seen any unicorns walking around? There are. But webmaster, webmeister, used to be ubiquitous when the web was a very simple place. It's not a simple place anymore. There's so many different technologies. How often have you worked with organizations that have said, yeah, we're trying to decide whether or not to hire one person who really knows everything or a firm that has lots of different people, and we're like, oh, okay, let me know how that goes, right? So there's a tendency to really not embrace and understand that everything is a specialty. And yeah, we do have awesome full-stack developers, but we need our specialists. Because the world, the web, the internet is just too big and too specialized. So warning sign. Why can't David just do it? He's a full-stack awesome Drupal contributor developer been at it for many years. Why can't you do everything, David? Depends on what else we have you're doing. So I'm sorry, these are a little difficult to read, right? Neglecting to plan for continuous development policies, tools, and workflows. So you just have to build a site, right? That's all you're doing. You're gonna deliver the site and then it's over, right? Not so much. Warranty period is over. And this is the typical thing we hear. And it happens just as often. We hear it just as often from the client as anybody else, right? And I'm sure clients have heard vendors say it. And if you haven't heard them, they've said it, right? So in all these things, you're listening out and you're asking questions to qualify these things. So if you're in a project and there's a crunch, okay? And you've got, you're sprinting literally to the finish line. You've still gotta have this discussion in order to avoid the worst of your problems. You've gotta take the time out for the discussion, okay? Build a series of if, then, else statements, right? Let this discussion surface those statements. Well, if when we go to launch and we've only got a 24-hour window on a Monday, to go live, what are we gonna do if this happens? If then, else, right? So not an ideal situation. It's easy to give you a list of pitfalls. One of them could be, you know, don't go live on X-Day. Make sure you're going to have a team who's showing up to work the day after a go live. What does that mean? Well, you test most things. So the point being that, you know, harm reduction. You know, if you've got a launch in a week, if you possibly can, you should launch three times before the real actual launch day. Right, and build that into the project plan. So, and finally, not engaging with the awesome Drupal community. So you guys are light ears ahead of the curve because you're here and you're talking to one another, but a lot of folks are not. And, you know, you might have some developers that are lone wolves, and they're a really great Martin out there, and they may not be that comfortable talking on anything other than IRC. But there are some things that need to happen face to face. And if not at a big con, then at a local meetup, your clients in particular, all right? And it's to your benefit, the more your client knows. So what we just take as gospel is that liaising and joining up with the community accelerates everything. It greases everything, and it really accelerates your project toward success in so many different ways. So, and so remember, you're out there and you're sniffing, you're establishing this mentality in your team of an early warning system. And if you find that you're a client, you've been talking for a couple of months now, they should be pretty enthusiastic about learning Drupal and meeting other people in the community because it's part of the value equation. And if you find a couple of months into it that they are not into it, that's an early warning sign. That means they're gonna be resistant to understanding certain realities. They're not gonna be a partner in helping you solve certain issues. All these things should flag a call and response inside of your early warning system. Let's question what's going on here? Is it people's schedules? Do you not have anyone particular on staff that can do that? Is it something I said? And so these are ours. These are what we've identified as some issues folks and clients that we work with. This is our response to helping us and we think others avoid some of these pitfalls. What do you think that in your experience has been some common pitfalls are and how we can go about avoiding them? So we're interested in having everybody here, hear from as many different people as possible and not just our experience with avoiding these pitfalls. So I noticed some heads nodding up and down here when we talked about discovery and content audits way back at the beginning of the list. We can pick a pitfall, feature creep. How many times have folks fallen prey to what David has said by failing to precisely identify a driver or a spec and then finding that you've all had to build it more than once? Yeah? No? If you want. I just had a question, I'm sorry, a question about feature creep versus scope creep. In my mind as you were first introducing it I saw feature creep as more something that's driven by your internal team. Your developers saying, oh, look what I can do. I just came back from DrupalCon, I learned about this. Is scope creep a different thing? Is that what's being presented by the clients and saying, oh, we forgot to tell you about XYZ? Or in your mind is feature creep everything and are you watching the entire team to try and mitigate that? No, you've been a really great one. Okay. I think it's really helpful to think of any kind of creep as not necessarily a good thing. Might be, might be a benevolent. But so feature creep would be really specific around certain behaviors, applications inside your web and they can certainly come from your own development team and the client. Scope creep is very similar, but I think a much broader category where you're forgetting or not aware that there are certain major portions of your project that were not adequately planned, right? And you're realizing that in order to accomplish the things that you nailed down in your scope you've got to do all these other things first. There are certain larger dependencies. Well, someone's got to pay for that, right? And there might be budget, there might not be budget. Now, sometimes there's a limited amount of funds. Folks have to be willing to take things off the table when that happens. So the interplay between scope and features are important because if you find that you've missed something in scope that can't be accomplished any other way you might have to take some features off the table in order to accomplish that. That would be my response. What do you think, dude? How side of that? You're like, oh, that's great. That sounds like a really cool thing that we want to talk about, not in the scope of this. Backload. Thank you. Yeah, kind of following on with that. I think I would add to your list there one of your warnings is not having a clear enough or defined scope because those are the problems that we've seen in the past that you run into where we talked about a lot of cool ideas. They didn't talk about some things that they actually need but never mentioned. And then we thought of a bunch of things that maybe they didn't need, but we had it anyway. One of the things we found to control that is that we do, at the start of the project, write a really painfully nauseatingly detailed scope. I hate doing those, but it's like eating your vegetables in terms of health for the bottom line. Those are the most important things because I heard you guys say a couple of times, you're gonna have to eat that cost. If it's defined in the scope as to what it is we're building in such a way that both the client understands, when I click this button, this is what it does, and the developer understands, we're using the paragraphs module and we're putting this field in there or we're making a custom block that does exactly this with this database field. Like, that sucks to write, but when it comes down later to negotiate about what we thought it would do this, well, before we started we gave you a whole scope and said what it does, and so it's a lot easier to manage that expectation and have, like you said, that budget conversation about, okay, well, what do we, we miss this part collectively. It's not just, hey, developer, you missed it. We all missed it together. What are we gonna do to still get under budget and still get this done? Knock something else off the back, add more budget, something else, but the answer's not, well, the developer will eat it because it's their fault, so. Yeah, I think that's what Maria said. I wanna ask a slide, what has it done you've done? Done something really done. Oh, okay, now we get it. How do you define done? So I would say, how do you define your scope? When do you know your scope is done? When do you know it's complete? And I think that, I think, Say again? Except it's criteria. Except it's criteria. But again, suppose the folks that you're working with don't have a clear vision for just how precise the scope should be, right? So there needs to be, how it's a month, and given one example of it, words will avoid pitfall, but your teams need to be so adept, not just technically, but at communication of this process of call and response. And when you've got a scope and you think it's done, you have someone on your team that says, hmm, does that mean that we're not going to do this? And somebody's listening for this response, and they're sort of distilling it and zeroing in on it. And so you're developing these, nail thing down, really put them in company. And it's a big challenge, right? Because we're often working in these agile environments where we're helping our clients understand what they want. They don't know what they want, and they see something that we produce and spread. And they're like, wow, it's not very effective at all. I love it, you know, let's have more. All right, so we have to, so you're not, in that case, was that in scope? Where's it going? Is it change order? Is it in the backlog? You know, what assumption would you make about it? So I think that's a little bit of an answer. James Titter. Eight, 16. You're a part of the subject matter expertise. Yeah. I understand that. It's better than they think. And I think your point is really important, especially when we think about budgeting project management, right? So often those project managers are best things, but often when we think about project management, I think one purchasing part of a shared service project management is on both sides of it, particularly because the project manager on the inside has that business experience. Something like that can help avert scope treatment. Right? You know, I was going to say, oh, but we don't have, you know, folks who are going to do that. It's a foundation where we're going to talk about projects next month down the road and not going to be thinking about doing it. Yes. Sorry. That's a tally for you. Okay. I can say that. All right. So. Thank you. For me, one thing that I look at. So, this morning, I said it then, and I'll say it now, I had a privilege of being up on stage and doing some things, and we talked about three different things, right? We talked about communication, sharing, leadership. And I think when you're engaging clients, you know, those three things are really important, right? So, we talked about communication all the time. Like David says, what does that mean? Does that mean that your partner is volunteering information that they are sharing willingly and generously with information that they may or may not expect to be helpful, right? Because they don't know your business. They are willingly sharing it because it might be relevant. Like, that is a habit of mine. That is a cultural issue with organizations. And that's not always something that is present in a renovation. You can tease that out and draw that out. I think that it increases the likelihood of everyone's success. So, I think that leadership, sharing, communication, like we talked about for our community, right, is extremely important in the relationship between a vendor and a client as well. Leadership is actually consulted through the influencer. You know, we've sat around meetings before, and you get this really passionate individual around the table, and you realize that it's got this great title. They're articulate, but they're an influencer. They're not an owner of the project, right? And there's all sorts of internal struggles going on that we're not aware of, or somebody's not aware of. So, to that end, structure is a part of that. So, communication is good, but there's different types of communication, unstructured and structured. And when you get down to that scope, that's a very precise form of structured communication. Your stakeholders may not say, again, your stakeholders, your stakeholders may seem negative. Your stakeholders are not necessarily the audience of the website that's in the line. So true. When we get that a lot and not the profits, right, because we have, this is the benefit of our sense. And you know, when it's any diversity, it's right, where you have this deferred, you know, staggered sort of, I don't want to say misplaced, but outsized structure in others, and not the profit of a university that are your stakeholders. But who's the audience, and are their needs being met? And guess who gets the benefit? We're talking about a race, a race, who's responsible for the capital, who needs to be consulted, who will discover it, who will find it. Again, it doesn't matter whether it's a non-shared, right? It's just thinking, well, I'm sure of my budget. Who's cars, right? Some completely backed teams. Both on the client side and on the open. No continuity, no consistency. And I've seen projects stretch, either out there, particularly in the audience. It helps you when you have a stable reserve of bearing on how you structure, all right? So you try as much as you can to break things up into very logical things. Something other than native stuff. So, this list of stuff. What about sharing this? Yeah. I mean, you talk about being transparent, being real. That's great. Yeah. I mean, you know, internally, I don't know if we've had that discussion. I've been on both sides of this. I've been on both sides of this. Maybe soft. Thank you all very much. I realize you're actually right on the...