 We have a couple of minutes till 2.15, but I think we're gonna go ahead and get started if you guys don't mind. So welcome to the last session of DrupalCon. I'm kind of amazed that there's anyone in this room, actually, so thank you all for coming. We're talking today about the rescue project. Someone mentioned earlier that this is unfortunately an all too common scenario. So I hope that there's some lessons we've learned from a particular disaster that you might be able to apply in your own experience. So I just wanna get started by mentioning sort of who I am and where I'm from. So my name is Marcus Ianaltzi. I'm the principal and founder of Message Agency. We are a full service dev shop, design development strategy shop in Philadelphia. And we're also a B Corporation. How many people know what a B Corporation is? Okay, a few. We happen to, for those of you who know, we also happen to be a best for the world B Corporation. So we have a score that's in the top 10% of all B Corps. So we're super proud of that. And that's because we only focus on the nonprofit, higher ed foundation and government markets. So we can start ourselves a social enterprise. And this is a case study about a fairly large national nonprofit. And again, we have tried to scrub all identifying information because this is a particularly gnarly case. So some things I'll speak in general, generalities unfortunately, I'm sorry, but I have to do that. And it's really about a nonprofit organization, their budget to us is very precious. They're not coming by that money very easily. And it's really tough when a project has, they've already undertaken a project and it's been scuttled and they've sunk a lot of money into that, that sort of lost revenue for them really has an impact on what they can do. So there's a very heightened tension going into a rescue project for the vendor. And we're really talking a lot about how we negotiated that sort of those waters and how we turned the project around. So a little bit first about hindsight. So we all know that Drupal is super powerful, super flexible. Sometimes it's too flexible, especially for the uninitiated. And unfortunately what we've seen many times actually is folks who say, yeah, I can do Drupal. And they'll, there'll be a freelancer or a small shop and they wanna get into this space and they don't take the time to learn the tool. And so they bring to the platform a lot of assumptions and they don't bother to learn best practices and they really, you know, we all know hacking core and all of the other gnarly things that they do. Even for us though, for seasoned dev shops and we've been working with Drupal since four seven. So we've been working with it for quite a long time. You know, sometimes we have to take shortcuts, right? Sometimes the project is not a perfect project. Sometimes the client doesn't have the budget. They really need something that maybe the project wasn't managed as well as it could have been. And there are things you do that you might have done otherwise under different conditions. And we all kinda like to complain about how the other guy does it too. I mean, there's, you know, various degrees of bad and a shop who does really good work now maybe didn't do great work before and they got there. And, you know, so there's a lot of that that goes on. But, you know, the real sort of decision point here is as a firm or as a freelancer, you know, when one of these types of projects crosses your path, you know, what do you do about it? How do you evaluate whether or not you should take it? How do you think about what impact it's going to have on you and your firm? As well as whether or not it's really worth doing. So one of the things that, you know, that we didn't realize, especially with this project is the profound impact it was going to have on not only the current workload that we had but our potential to bring on new work. And it's something that, you know, you really do need to consider. These take a lot of care and feeding and it might actually limit your potential for bringing on other projects down the line. So that's something you don't always think about. So here's the scenario. You know, you come across this project, you're kind of excited. Maybe it was a project that your competitor did and you're excited to get your hands on it or maybe it's a project that, you know, you, you know, it's a great organization or you think it's something you want to add to your portfolio and you really want to do it because you want to be a superhero and you feel like, yeah, we can sweep in and we can save the day. You know, maybe there's a great budget too so that you're feeling like it's worth pursuing. For us, the way the scenario unfolded is we're very well known for doing Drupal and Salesforce integrations and actually back in 2007, we wrote the original Drupal Salesforce suite. So about 75% of what we do involves this. So folks come to us with these problems and they were migrating basically a custom CRM and it was built in ASP. It was terrible. It had been iterated on many, many times and so it was definitely, we knew once we started looking at that it was going to be very messy and it had a dot net front end but really the site was just a shell. I mean, it was just sort of spitting out queries to that really gnarly database. They had spent two years and we believe hundreds of thousands of dollars on both the Salesforce implementation and on a Drupal site that was built by a firm that the client never met. The firm was actually the Drupal firm. It was an overseas firm and that's no comment on overseas firms but the client actually never had a relationship really with that firm and wasn't involved in selecting them. It was the Salesforce, the shop that was customizing Salesforce that brought them on board and they were trying to take this, again, very gnarly database, put it in Salesforce and build a site around it. So the client was really unhappy with the result and I can't show you the site but I think if I did, you'd all be pretty horrified and they came to us saying, okay, we've got this, we've got Salesforce. I knew that would get a laugh and it's amazing how that percentage in particular is used and there's no rationale whatsoever for that value but that's what they said to us. It's 75% done and we kind of looked and we thought, okay and we saw the, there was a site, it was Drupal. There were a lot of views and some things that it was displaying. There was a Salesforce implementation. Data had been migrated but we weren't really quite sure where things were because there was no documentation and I'll talk about this a little later. So when we asked the client just in the initial conversation with them about whether or not we wanted to do the project, we said, hey, do you have any documentation? Do you have any kind of models, objects to find anything? And they said, well, we may have at one point. This was two years ago. So we were very, very skeptical and the first thing that we did, especially again, given the, how complex Drupal and Salesforce integrations can get and given the fact that this ran their entire business process and essentially what was happening, this project was going to have to replace wholesale their website and their CRM all at the same time. And that was a huge red flag and we thought there's a lot of risk there. So we were very, very skeptical. So there were other warning signs that we came across. Again, I mentioned, this was an all or nothing implementation. They had fired the Drupal developer and wisely so because it was pretty bad. They had an unclear relationship with their Salesforce consultant. And when I say unclear, they weren't being clear with us about what that relationship was. And it was very strange. And we had detected that there were some problems there, but they insisted that, yes, this consultant was going to continue on. They knew how Salesforce had been customized. They understood. Maybe if they didn't have the documentation, they had the institutional knowledge. And then they had this terrible lack of documentation. And finally, rescuing this project was actually deemed impossible by stakeholders on the board. And what we learned later and didn't know then the executive director's job was on the line for this project. He did not disclose that to us until much later. So there were many, many warning signs. There were a few good signs though. And it was enough for us to say, okay, this is very dangerous, but let's see if we can make this work. One was that the client did understand that there was going to be substantial ramp up and that they were going to have to invest in us, really doing a lot of digging and a lot of questioning and a lot of discovery. And they were willing to fund that. They also didn't insist that a rebuild was out of the question. And this was something that if they, we all decided as a team, if they said that was out of the question, we weren't going to take the project because we didn't want to be stuck in a contract where we were forced to work with what was there. They were also willing to rethink what we knew were very antiquated processes. They had been working again with this custom CRM written in ASP for over, I think at this point, 14 years. And they did disclose to us, as I mentioned, there were a number of iterations. So we knew that they had probably, their process probably followed how the system worked instead of the system working how their process should. And in fact, we found that it did. And they understood that and were ready, or seemingly ready to move that forward. So that's sort of the scenario. The things that at this point were really critical also for us to understand are what we kind of call the pinch points because you're having these conversations with folks, but there are constraints that you have to keep in mind. And this is some of the lessons we've learned that I hope you can take with you. The first is the pressures on the budget. So this is an obvious one. They've already spent and wasted a lot of money. And there's going to be more pressure than in a typical project for you to cut costs. And when you actually might need more. So you actually may need more resources than the average project. And I'll also talk a little bit about why. But you're still gonna have that pressure and you're gonna have to deal with that. Your project managers are gonna have to deal with that. And the project owner at least, if there is an internal project owner will as well. The other is pressures on the schedule, another obvious one. The original projects is stalled. So they may say it's 75% done and they've told their board, well, it took two years to get to 75%. So it'll probably only take five or six months to finish out the project. So they've likely already set up expectations to the people that they're accountable to. And then they're in turn gonna hold you accountable. And you have to be very, very clear when you're negotiating about the schedule. And another is wounded trust. And I can't underscore this enough. How many folks have dealt, how many folks here are vendors, by the way, or are developers? Okay. And how many of you have dealt with a situation like this where you've, yeah. The client is wounded. It is a relationship, that metaphor. It extends to the sort of vendor-client relationship. It is a relationship. And once someone's been burned, they're really, really skeptical and they're suspicious. And even if you are, you know, you have the best of intentions, you're being honest, you're being upfront, you will still be questioned. And, you know, your judgment will be questioned, your reasoning will be questioned. People are gonna be afraid, not only that you're not going to deliver, but that you're trying to take advantage of them. And you have to be aware of that going into the project. And then the other is client fatigue. This isn't as obvious, but it's a really important dynamic as well. So the other thing that's going to affect this project is, you know, the client has been following this path for a long time, possibly. Hopefully they figured it out early enough and changed the relationship soon into that project. But sometimes it takes a while and they're going to be disappointed. There's been very little progress. And in some ways they're just, they're exhausted because it's not their, you know, especially with nonprofits, it's not their full-time job. They're not, you know, necessarily responsible for this, you know, and they're taking time away from other tasks that they do. And they're gonna have to start over. So they're gonna have to start over with a new developer. They're gonna have to start the clock over. There are all of these things that they are facing that they know. And, you know, they are really going to push you to work with an existing solution. So those are some of the things that you just have to keep in mind. So before you sign that contract, a few things that you should consider, especially with your staff. We took this project to our staff. And we usually do, we usually talk about projects because we have a really collaborative work environment and a very collaborative team. And this one, though, was definitely a big decision point. So some of the things that we talked about, technical debt and supportability. So the question is, you know, can you and will you support the solution after it's launched? If they don't expect you to support it, you know, maybe it's that reduces some risk for you. But if you are going to support it, and for us, we support 80% of the sites that we build. So we have a formal support arm. And, you know, it's why we try to build things right because we know we're going to inherit that at the other end and we're going to have our own technical debt to pay down. And, you know, while you might be able to fix what's broken and get something off the ground, maybe you don't have to rebuild. Maybe you can complete the project. You know, can you commit to supporting it in the long run? So you might be able to put the Band-Aid on it, but, you know, is it something you want to continue to support? The second is employee morale. You know, there's no, I guess, other real soul killer for developers or even design staff when you're working on something terrible that you didn't build yourself. It's bad enough if you're working on something terrible that you built, but if it's someone else's, it's, you know, it's pretty painful for people. The other is, can you take credit for this project? So for us, this was a project that we actually don't even list as a case study. It was the biggest project that we've ever undertaken and we don't even list it as a case study. And, you know, and so that's a big challenge on the other end when you're thinking about, you know, this is a huge investment of our firm's effort, is it going to be worth it, not just for our budget, but, you know, to use it again in marketing? And also, again, if it's something you're building and you're using someone else's designs, you know, maybe you can finish out the development. Maybe it isn't that bad, but is it something you can put on your site? Is it worth it? The other is the state of the documentation. So in this case, there was none. Well, there was some. It was terrible. But what's the state of it? So it's one thing for the client to hand you a document, but is it current, does it reflect the current state of what was built? We all have been in that situation, I'm sure, even with our own projects where, you know, something's documented prior to build, maybe. And it gets built, there's implementation decisions, and, you know, that document doesn't get updated to reflect the build spec doesn't get updated. What, you know, where is the divergence? And can that client tell you where that divergence is, especially before you move ahead? Cause you, you know, probably aren't gonna have a lot of time or a chance even to really dig, you know, dig into what's been built at this point. The other part of this is about the real story of the project. So clients are not likely to disclose the truly bad bits. For example, the executive director's job on the line, he didn't wanna tell us that, but had, you know, we tried to have as frank conversations as we could up front and tried to get as much, you have to read between the lines sometimes, but we tried to get as much out of them as possible and engage them as much as we could to get the back story. They also might not even recognize their own role in creating the problem, because the problem might not have been the developer. The problem might have been the client. And this, this is another piece of, and I'll sort of describe to you how we mitigated some of this, but this is a piece that is, you know, we even see it sometimes with projects where we know we've done well by the client and, you know, they still don't wanna take responsibility for their sort of part in it. And then it becomes, you know, when it moves on it's like, oh, it was all the developer's fault. So we all kinda know that a little bit. And they're definitely gonna be blaming the vendor more than themselves. And then the other one is rescue projects are super messy. They are super detailed. There's so much to do. It's, you're not starting with your own patterns, right? You're starting with someone else's patterns and you need to have the project management talent to make it work. Your, you know, your Rockstar PM may not want to take this project, but they're the person who's probably best suited to deal with it. So those are the things that we considered. So the way that we decided to move ahead was to do a formal discovery engagement. How many of you folks actually do that routinely? Does anyone not aware of what a discovery engagement is or an audit? Okay, well, someone's raising their hand really, really high. You know, it's basically saying to the client, look, we can't give you a proposal because we don't know really what it is that we have to do. So we need you to enter into an agreement with us where we will investigate what you have. We're going to do an audit. We're gonna do a technical audit. We're going to look at the, you know, where is everything that's been built, right? Look at the documentation, scour everything, look at the code and really do an analysis. And it could, you know, for a regular project you do the discovery just to get to a budget and a scope and get the client to prioritize what it is that they want in that budget. But for a rescue project like this, it's really to evaluate how are we going to structure this relationship? Ken, is it really 75% done? You have your suspicions, but you need facts. So definitely look before you leap. The other part of this is don't do an unpaid audit. Insist that it's paid. I don't know, but don't do it, don't do it. And also ask for unfettered access. So if they're not going to, you know, to give you shallow access, if you're not going to get everything, then walk away. The other thing we also considered asking for was a question and answer, sort of Q and A back and forth with the previous vendor. That sometimes works if the relationship isn't too damaged. And, you know, you can sometimes get some interesting information from this. Their sales force consultant called me one day. This was after one of the first meetings we had. And he spilled his guts about this project. And in particular, he was very, very, he blamed their PM, I mean, it was pretty extreme, the language he was using. I was like, okay, this was a bad relationship. And it made us look at, we had some concerns about the PM on their side. I'll get to the rest of that story too. But, you know, it was enough to make us pause because we said, look, there's two sides to every story. And we got as much information out of him as we could, but we also realized there is no way we can move ahead with this project with this partner because their relationship was too damaged. And we only realized that by actually talking to the vendor. Make sure you do it and ask for it at least. Also, ask for the requirements that the client has documented, even if they were the original ones and or require the client let you develop requirements in user stories before you proceed. Either you're working from existing ones or they're going, if there aren't any that they will let you do that. That's, I mean, that's pretty straightforward. Also do a debrief with the senior leadership to determine what the problems were. Because one of the things, and I mentioned this down the line but it bears noting here, one of the things that has saved this relationship was that I had a direct role in this project, not as a project manager essentially, but I did all the relationship management for this. And as the principal that was a really, that was pretty time consuming for me, but I had a direct relationship with the executive director. And he and I would talk if there were hard questions or things that were coming up, we had a regularly scheduled meeting that was just the two of us where we could talk about what was happening with our staff and that helped actually keep the project afloat when it got very difficult. And the other part of this, and we're talking after the audit, you really do need to provide formal recommendations and that's really kind of the key to why this succeeded. I'll get to that in a minute. So what did we examine? They had project notes, artifacts, things were kind of a mess. They did have scopes of work and it wasn't until the later scopes of work actually that we noticed something, like that's where they started actually defining things later. There was no sort of foundational documents. They started using scopes of work to actually define what had been done and what needed to get done. There were no project really meeting notes, so we had no evidence of what happened during the process and most of the documents were really of little to no value. And as I mentioned before, the most valuable document was that third scope of work we looked at and that was the first time we saw a comprehensive set of requirements. So what we walked away from that understanding is that the client just kept getting scope after scope after scope from this vendor. There was never a process in place. There was never a plan. It was just sort of, I guess maybe the worst version of Agile ever because they just were sort of diving in, doing things, trying things, failing, getting change requests from the client and just continuing to build. So what did, when we looked under the hood after doing all of this, oh, sorry, we looked at sort of the Drupal code base, obviously in the database. Then we also looked at Salesforce and it was what did we find? And while this is an exaggeration, it's not much of one. This was the Salesforce, the entity relationship diagram in Salesforce. I don't know if you guys have ever looked at this tool in Salesforce, but it literally, I mean it was almost inscrutable. It was kind of crazy. So other Easter eggs that we found, there had been PM turnover. There was actually no continuity within the organization. There were two PMs within the organization who had worked on this project and there were multiple PMs on the developer side and four different development teams had worked on this. So I think at this point, so the current developer, there was 10,000 lines of custom code and the current developer had only worked on 50% of it. So there was absolutely no documentation. And the other thing we realized is that the vendor had used their existing custom database as the model. So all they did was reproduce the mess that was already existing in their custom database. They didn't stop to re-envision any of it or think about how that custom database would fit into Salesforce's conventions. There were in Drupal, 37 content types, 365 distinct Drupal fields, 730 SQL tables, obviously, performance was going to be a big issue. There were 135 fields on the user object. I mentioned the lines of custom code. There were 1301 lines of direct hacks to the Salesforce suite itself. So it wasn't that they were just hacking core. They were hacking the Salesforce suite module. And we realized what that 75% measure reflected. It was that 75% of the site map existed on the website. There were links to 75% of the planned site map. There at least was a site map. So definitely a big mess. So how do you turn something like this around? I think the biggest, the most important thing we did was spend a good deal of time preparing a very thorough report for the client. This was before we even signed a contract for implementation. So we tried to state things very, very plainly because we knew that the staff was very non-technical and we could give them, we gave them this, you know, the list and sort of the technical, we gave them the, we backed everything up with that assessment, a technical assessment, but we spent the time in writing to analyze what was there in very plain language. So we actually, it was a little forensic and because we kind of described in this report what we think went wrong with the project and we were able to actually get it pretty, pretty right. And what we did was present two different scenarios to the client because we wanted to respect the fact that their stakeholders felt this was impossible. They had sunk all that money in and they really would have wanted us to move forward. They would be lobbying for us to move forward with the existing site. So we gave them both scenarios. Here's a rebuild, here's a complete rebuild and what that might look like and here is what we'll have to do if we move ahead with this. And because we gave them scenarios that considered the entire life cycle of the project not just from when we would pick it up to launch, they realized it would cost more in the long run to keep what they had and that it would limit their ability to continue to evolve this site and what it did. And the good news is that they actually, they got it. The other thing that we did that helped us convince them was we spent a lot of time with their stakeholders or internal stakeholders during this discovery engagement. We sat with them for days listening to their needs and that in itself built a tremendous, not only did it give us the information we needed but it built a tremendous amount of trust and we had a lot of staff members doing that. It wasn't just one account manager or a PM and one other person. We had a lot, we threw a lot of staff at this project. And so it gave them the evidence that they needed as well to go to the board. And they could put this report in front of the board and say this is an independent analysis. It's very clear, it's about, even if the board members did not understand a word of the technical analysis, they could see that that work had been done and it was very thought out. So that's great. We've got a contract but now you have to deliver. And this is always the hard part. So as I mentioned earlier, the bar is really gonna be set high for your performance and in fact higher than probably on projects you just start off on a fresh start. So fatigue is set in, budgets are gonna be watched closely and then even the typical difficulties you run into, every project has its challenges. No project is perfect, there's always going to be challenges. It's how you deal with them. And the problem with this is even routine difficulties you might have are going to erode trust faster. It's going to have more of an impact because you're already operating from kind of negative trust here, right? So you can build it and then something happens and you can sort of drop you down rapidly. So you have to run the project with a tremendous amount of integrity. Goes without saying impeccable project management, right? So if you do not have the staff that you know can run a project, don't do this. Don't say well, maybe they'll figure it out, maybe they'll learn, maybe this will be a learning opportunity, it's way too risky. The other thing that was really important was stakeholder representation and stakeholder management. It turned, we are usually very good at doing this and making sure that all the stakeholders that need to be a part of a discovery are around the table. But it turned out that the project manager and this person will come back up, project manager on the client side and she'll come back up frequently about one of the key problems of the project is she told us that we had that full representation. She said she had gotten ambassadors from all of their major departments and we also trusted that she was going to include them in user acceptance testing and review. Unfortunately, she really didn't do that and we, I mean I'm trying to put this in a nice way but she kinda misled us a little bit and we found out that she didn't have the trust of her team and the people who needed, she actually was unable to act as a product owner on their side. She's really, folks didn't trust her. They didn't feel that she was working in their best interests and so some people who were critical to the success of that project actually weren't included or opted out because of her role and it was, yeah, that burned us a little bit towards the end as well. We also did a combination of Waterfall and Agile for this because we knew that they were kind of, they didn't understand Agile and we knew that they really wanted assurances so we took the time to do a lot of design and documentation first and walk them through everything and I know it's painful and we're all trying not to do that but it really was valuable in this case and a lot of times even with regular projects we find that some combination of Waterfall and Agile is really needed to manage the process well and in particular for us budgets well. In terms of transparency, we do this anyway. We're super transparent with our clients. They have, they know where we are on budget line items by an epic or by sort of a domain right or if it's a design budget, et cetera. They know exactly where we are at any given point but for this client and for these types of projects it's really important to be really forthcoming. You know, if you're a firm or a person that holds your cards close to the chest and you just say yes, yes, yes, this kind of project won't work because someone on the other side is going to, again, going to be suspicious and they want to see and we always feel like it's better to be really blunt and straightforward and talk about the problems than to pretend that they're not there. We also were forced to provide a formal monthly progress report to their board and that was a pain for me in particular because I was the one who had to do it and I was really super annoyed by it but I knew it was important and we had to give them an analysis of all of the hours that we used. It was really, really difficult and because it was monthly, the sort of continuity report to report was really important. They were scrutinizing everything. So because this was so difficult in many ways, we knew we had to focus on some quick wins. So while we needed to build as we went and we couldn't really be, you know, they weren't going to sort of get a site quickly and start prototyping, we made sure that we gave them something at every meeting to review and they saw progress always and we always made sure that there was a deliverable, no matter how small there was a work product. Also expectation management, that goes without saying. And again, being really, really blunt and honest and then continuous communication. So that was really what I mentioned earlier where I had that meeting with the executive director. And what happened, what was interesting about that, we knew we needed him to see our interests as aligned with him and because of that, we became more of a coach and a confidant and that really changed things. He was able to reach out to me and be frank in ways that I don't think he would have if we didn't have that open line of communication. So, you know, the kind of, the emotional intelligence here is really, really important. So how did it turn out? Well, sometimes mostly it felt like this. Yeah, it was a little hairy, but it was kind of a mixed bag. So I'll go through these quickly and we'll get to some questions. So the good, we launched a new Salesforce instance. We found a good partner and that's sort of an aside, but we actually had them fire their Salesforce consultant and we found a better consultant for them and that's when the project picked up traction. But we got a new Salesforce instance and website completed in roughly a year, even though it was deemed impossible. And again, that was despite firing the Salesforce vendor. We were able to make sure that there were some key stakeholders around the table, but in general, just talking to the staff, kind of re-energize them and it really raised their confidence that the project would ultimately benefit them. And that was really important because it's a huge lift to try to transform and completely transform a system at once. It literally was working one day, both their CRM and the website and the next day, it was a totally new system. And the transition was a little rough, but the things that we put in place helped to smooth out some of those edges. And then we also successfully negotiated a large enough budget and it handled all the contingencies we expected or we thought might happen and we launched with 7% of the budget left. And so that was a big deal. Now they also thought they were going to get a lot more for that budget than they did, but they got a very decent MVP, so it was helpful. For us, it was the largest project we'd ever tackled in terms of the complexity and the budget. So it was beneficial to us for those reasons. And then we did win a lot of trust and good faith and we're gonna have this client for many, many years. Whether we want them or not, we will probably have them for many years. One of the things we didn't consider, again, as I mentioned, that the PM for the client would leave out key stakeholders. And the other thing we didn't anticipate is the executive director kept promising his, making promises to his board to placate them, things like deadlines and without really talking to us or half listening or they were loosely, there were things we talked about that might be possible, but it wasn't down on paper and he would latch on to them and he was kind of part of the problem too there. And we were waiting a little too long to make sure that nothing was ever promised that we didn't have explicitly set out. So there were a few bumps in the road and we kind of met the challenge, but we didn't stop it early enough. And that kept happening and that really put stress on our development team. And it also meant that sometimes testing wasn't getting done as thoroughly as it needed to because we just had that pressure of the deadline that he had promised. Also, the other thing that was really troubling for us and the Salesforce consultant, we actually couldn't examine the structure of the source data from their custom software. We could only see what had been imported to Salesforce because it was kind of behind several firewalls and it was just, you couldn't get to it remotely. And no one, including the Salesforce consultant, knew how bad the state of their data was. So there was a complete redo of their Salesforce org and a complete re-migration of the data. And we had tried to mitigate that risk by having actually incremental migration. We were going to migrate key data points along the way and have the client validate that with the system. And because it was such an intricate integration, we kind of needed the real data for them to test anyway. It was gonna be really hard to use dummy data. But for a few reasons, that didn't happen as timely as it needed to. And it was just not adequately tested. So when the site launched, because so much of the functionality rested on good data and good valid status, valid statuses for particular for memberships and other things, the data was so bad, there was no way we could have anticipated that it would be missing. And the client and their PM did not take the steps they needed to scrub their own data ahead of time. So when it did launch, there was a challenge. Some users didn't have the right status, couldn't get access to certain things because those statuses in Salesforce were driving user experience in Drupal. And that was a big challenge for us in them. The ugly. So as I mentioned, the Salesforce vendor got fired and we didn't anticipate they would get fired six months into the project. So we kept trying to build, waiting for them and there was a lot of negotiation between the client and the vendor. And there were some questions about budgets and money that was left over and that actually stalled our progress. We had to start building to keep, to continue momentum, but we had to ultimately rebuild a lot of stuff because once we actually got a good Salesforce consultant on board and they took responsibility for redoing the org. I mean, we actually came up with a great structure together, but we had to do some rebuild. So that was a really bad part of the project. And this is one of the reasons that there really wasn't a lot left in the budget beyond the MVP. We couldn't give them everything they wanted. The client also fired the PM. Probably should have happened before the project even started. It might have been a really good thing, but they waited until after the project launched about three weeks exactly, after the project launched. And so that created other problems after the fact that we're still kind of dealing with. And then based on some of the problems with the partner, the schedule did have to slip. And that was a challenge for them. So just real quick, in terms of kind of our final thoughts, don't underestimate the amount of time you're gonna need for project management and time and budget for project management. At the end of this project, the number of hours that were billed on the project management line item equaled development and theming combined. So it was tremendous. And if we hadn't put that amount of time in, the project would not have succeeded. Also, performing well on relationship management was more important than the actual quality of the development to get the project to the finish line. Unless there is the potential for a future relationship, it might just might not be worth it. Might not be worth doing these types of projects. Also, each firm's gonna have their own set of metrics and considerations. For us, we actually almost didn't take this project because of the kind of nonprofit this was. It was a nonprofit that wasn't really in, I mean, looking back on it, not quite mission aligned for us. And for that reason alone, maybe we should have said no. We saw that really big budget and we were like, well, let's try. And it fueled our growth. I mean, we were actually able to add, even though it stressed us a little bit, we were able to add staff that we might not have been able to do otherwise. So we're still a little on the fence about, ultimately, whether it was a good thing. But it did have, there was cost there. And one of those is what I mentioned earlier. There were some projects that we may have been able to take on that we didn't because we knew we wouldn't have the capacity because we had to get this out the door. And then, I guess, I think that's about it. So thank you guys very much for listening to me. I'd love for us to just open it up for conversation or people comparing their own experiences. I'm on a rescue project. Thanks. Go ahead. He did not. In fact, I got a call from him today. So no, he did not. So far, anyway. Well, go ahead. Someone in the back and then you. No. I would not have taken this project. I think it, yes, we did grow. And yes, it did help us. But there were two other projects that I think would have been better for us to have taken. And we probably would have won. And there was one we didn't win because I couldn't spend time on, you know, cultivating that client. And it was one we would have wanted. So I think, yeah, would have made a different decision. Yes. This was so because we work for nonprofits, we're actually kind of liberal a lot with not charging for things like that. But for this client, we did. So that was all project management time. Yeah. And this gentleman in the blue shirt. Oh, oh, sorry. So there were many, there were many times in this project where we not only just had to tell a client, no, we had to explain to them that they weren't going to get what they wanted. Like that they just had expectations that they were going to launch with things that they just assumed either they had it before, but it was kind of a ridiculous scenario. Or it was going to take too much to build it. And what we had to do was always offer an alternative. And sometimes more than one alternative. When we'd have to say you can't have X, but you can't have Y and Z. Or there's not enough budget for that and this is why. And one of the, I think this is one of the reasons the PM got fired, but we spent over 100 hours just talking about how we might integrate, how we might actually deliver real online payments for them and how it would work across Drupal, Salesforce, and then they have something called Solomon, which is Microsoft Dynamics. But how that triangle would work. And the PM kept asking us for calls and we would explain everything and we documented things and we did, I did really kind of cheeky diagrams with clouds and drops just so she kind of would get the idea about how things were going to work and as plain as we could. And she wasted 100 hours just on that. And we were able to clearly display that. So it was being able to say, look, you may want this, you can't have it, you can have this, and this is why you don't have more time left. And being able to document that and point to documentation is really important. We had, so we don't have high turnover and we had one member of our team leave. And it was not related specifically to this project, but this was, yeah, this was part of it. And I think, yeah, I think you, yeah. And we, and our visual designer also left, but for different reasons. But I think that, yeah, I think there were, it was a tough year for us. We both contracted and grew. It was, yeah, we, yeah. There were a lot of happy hours and other things that we had to do to get through this. And we did have a little party after it launched. Yeah. Over there, sorry. You mean in terms of our internal processing or our processing vis-a-vis the client? Yeah, we had, and that is one thing I can underscore enough. I mean, we are, I have probably, I was probably the most frank ever in my career with this executive director and their team. You know, we were extremely straight up and we knew we had to be because we had to be super clear. And even when we were being super clear, he still was, you know, hearing what he wanted to hear, right? So we not only had an open dialogue internally about this and let people vent about it because they had to. When that PM was fired and we had to regroup with the client, we had an open conversation. And we said, look, these are the problems. The other benefit that we had was the Salesforce partner. You know, we're, we've worked with them many times and we have, we are very well aligned. So we were both able to articulate those concerns in a way that they heard and they got it. We didn't feel like we could walk away from this. Actually, either. But yeah, because these guys have the kind of lawyers that I think would have scared us. But wow, for, that's really tough. What's your sort of position in that, what would be your role in that scenario? And so it's tough. So the question was if you're part of an internal team and it's not a vendor-client relationship and you want to turn things around and you're kind of stuck in that role, how do you do it? And you're also only two or three weeks on the job. It's actually an advantage, honestly, that you're new because you're bringing a fresh perspective and I think most employers and most teams expect that from new folks or hopefully it's welcome. I would really recommend finding a person higher up who you can make the case to, but make a case. Don't just sort of say, hey, I've got some ideas. Actually take some time and formalize that proposal. You know, talk about how if you redesign this it's going to save, you know, it might cost a little bit of an investment now but look at what it's going to save for maintenance or we can easily add new features and it's gonna save hours. If you put, if you try to articulate the case in dollars and hours, you will likely get a better response and there are things that people probably haven't even thought of. Yeah. Go ahead. Answer all the questions before we get this call like, this is not a, hey, you can start in two weeks to get this thing done and say, we needed this thing done six months ago. We need you in today to get it fixed. We actually try to reinforce our value and the value add that we bring to a problem and we try to make the client understand why our process is important and then we also say, we're not gonna do this unless you let us do, you know, unless you sanction this and pay for this. We can't because we'd be irresponsible. We'd be irresponsible to you because we're gonna promise things that we can't keep and we're going to be irresponsible for our business because we're likely going to not structure the project well. There was also, yes, and then you. We didn't run into that just because we, that's how we operate and actually 50% of our staff come from nonprofits. So they understand why it's important to be transparent and sometimes it does not work to our advantage to be so transparent. I mean, you can imagine the scenarios where it doesn't but we'd rather err on that side and we're just, we're human and that's how we relate to our clients. Yes. Yes, that's you. Yes. Well, actually funny enough, I'm gonna take the second part of your question first. This launched four or five months ago and a month and a half after we launched this, another rescue project came across my desk. Now, the problem with that rescue project is that it was one, it was a project we had bid on two years prior and we were a runner up and we didn't get the contract. So there was a little bit of pride there and I was kind of a little bit of, and I told you so, but they, I actually brought it to the staff and it was a much more attractive project and we ended up bidding on it but what we did because we were so gun shy is we actually bid very high and we said, first of all, we said, we think this is gonna be a redesign and they kind of insisted that it wasn't and we said that we felt very, like we recommended that and we had a budget accordingly and so we did not get that, we didn't get that second bid and I talked to the developer who did recently and he actually convinced them to do a redesign but so I'm glad that they're doing it regardless of who's doing it but it made us very, very gun shy so we weren't as like, we weren't willing to be as competitive and as risky even though it would have been a great client for us and I forget the first part of your question so I can't, oh what was worse? Sometimes I think the technical challenges are more surmountable than the human ones because we can always find an approach or a solution, it's how you communicate that and being able to have the skill and kind of their delicate situations and so I think the technical ones are actually easier to solve, yeah. Yes. Maybe our stakeholders will say, oh here, I brought in Jim and he's gonna handle this for you and it's like, do we manage Jim? No. You mean there's a... We don't have our budget now. So there's a resource that the client sort of wants you to work with and sort of insert into your process. How do you manage Jim? Oh God, yeah, that's a tough one. We've never had to deal with that. We have dealt with, when we work with universities usually there's an IT team on the university side whether it's like the, even if, say we're working with a small department that's part of a larger school, the school will likely have an IT department and a whole bunch of regulations that are annoying that we have to follow and so in that scenario, yes, we'll have to kind of interface with them and sort of deal with delivering something that they're ultimately gonna manage but we've never had to deal with someone kind of working with us alongside our team, only PMs. So yeah, I'm sorry, I don't have a good answer for that one. Yes, yes, so they're a partner. Yeah, they're a partner on the project but it's not like they would give us a web developer and say, here this guy's gonna theme what you guys build, right? So we've never had that. The Salesforce consultant, that was the other reason the project succeeded is we already knew a very, very strong partner there and I've partnered with them on many, many projects because it's too much for our firm to take all of that on at once and that is critical. I mean, there was a Salesforce consultant we worked with for years and again, we've been doing this since like 2007 and he kind of couldn't handle a project of this caliber so it was good that we had someone else to also bring on but being able, that relationship is very strong. If that relationship wasn't strong I don't think this would have worked. Go ahead. I think it's making sure that they can wrangle their staff to do what needs to be done and closing that loop and being as meticulous about the follow up in the open items and the things that we need because there are lots of PMs who can be pleasant and helpful but if they can't wrangle their team and there's critical information that we need that's gonna hold a process up that's when we start running into problems. There's a critical piece of information we can't continue working on a feature because or even the design of something because if we don't have that answer it could take us down the wrong path and so I think that's a really important piece and then also treating the vendor first of all like an expert. Sometimes clients don't do that and they don't listen to what we're saying and we're saying these things for a reason and yeah, we're gonna back it up if we need to back it up but you've gotta trust us and we're saying this to you because we want the project to work out well and we know that this particular request or this direction is gonna take us down the wrong path. That's definitely another one and also the projects that do work well for us is when the PM sees us as an ally and will tell us things that are frank and will say you know what there's this problem here and that problem there and I need to tell you guys about it because if you're in a meeting with this person and you bring this up or you don't present it in this way it's going to create tension and we don't care about the gossip we wanna know is there information that's going to help us run this better and that's gonna help you so rather than feeling like you have to be a gatekeeper it's like opening that gate a little bit wider and letting us kind of understand the dynamics. You'll actually, this lady first please. No. And I'm terrified that this is being recorded. I realize this is, yes. I know, I know. That's why I've tried to be as agnostic as I could be and then I'm sorry, your question. Yeah, go to that guy, yeah. That's exactly right and we were, you know, when we were smaller we also, you know, we're guilty of that because you don't wanna say no when you wanna please the client but we learned that lesson for sure. Yeah, yeah, you can't. That's a great point, it's a really great point. Anything else? Guys, thank you so very much for sticking around. It was a great conversation. I thought there wasn't gonna be anyone here so thanks and I hope you had a great conference.