 We do have a full hour. I am an American native English speaker, so I'm going to try very hard actually to speak as slowly as I can, which is about at this level. Is that okay for most folks? Yes. Because I could talk a lot faster, but I'm never going to hit corey doctoral levels of speed. But, yeah, if he had been actually British, I wouldn't have understood him. So, English is such a fun language. I'm Ken Rickard. I'm famous in this little corner of the Internet. I've been around the Drupal community since 2005. This is actually my 14th Drupal Con. I've spoken at probably 11 of them on a wide array of topics. I am most famous for some module development work and for being a co-author of Drupal 7 Module Development, which is a book that some of your folks probably own. Which is great, because I get 83 cents for every copy that gets sold. A couple of years ago, I was actually promoted. I work for a company called Palantir.net out of Chicago, which is not to be confused with Palantir Technologies. That is a separate company. Please don't ask me about them. Palantir.net, we've been around since 1996, serving mostly non-profit clients, but we do a lot of work in the for-profit publishing sector as well. We have some very interesting clients. We like to do good work. I got promoted about two years ago. I'm now the Director of Development and Professional Services, which basically means I oversee all of our project work. I do all of our sales engineering, which is the technical side of our sales process. I do an awful lot of internal wrangling of an awful lot of things. What's really interesting about what we've been doing at Palantir is that the way we look at the work we do and the services we provide have changed fairly radically in the last two years. I'm going to walk through some of that and why that is, and hopefully it will be applicable to your situation. The assumption here, how many of you run your own firm? No pressure there. How many of you manage someone else's firm? How many of you are developers? One of the first talks I ever gave was at a newspaper conference, and it was, how coders should talk to managers and how managers should talk to coders. It was a lot of fun, and we had eight people in the room, four were coders, four were managers, and we both. So I have some experience on many sides of that. So that's enough about me. I did want to start with this big question. It's a very common thing to start with, which is what is consulting? I want to assume that that's what everyone in this room is engaged in in some form or fashion. I did want to go at some of the stereotypes. There are a lot of very, very big consulting firms. Does anyone work through one of those really big firms like Anderson? I don't know the big European firms, I hate to say. But in the States we have Capgemini, who is a sponsor. Capgemini has tens of thousands of employees. IBM does Drupal Consultants. IBM has tens of thousands of employees. We have 40. I know Drupal, I was going to talk yesterday, a woman giving the talk, her firm had ten. I met a man yesterday, he's a Drupal Consultant, he's one person. So there is sometimes this sense that consultancies are these huge agencies. They're not, and I think that's going to be critical to some of the things I want to talk about, because you're dealing with a huge organization like IBM or an Accenture. You can't begin to use them as faceless interchangeable parts. One of the great criticisms of consulting in the States is that you hire these big firms. They send an army of recent college graduates out to find a problem. They're all recent college graduates and they don't really know what they're doing. The other big myth about consulting is that all they do is sit around congress tables and talk to them in suits. And they don't actually do any work. I think it's very, very rare in this Drupal space that you have consultants who don't know how to do implementation work. Certainly, we have people who run firms, who do sales, who are not responsible for making the pitch, and putting the ideas in place. There's a lot of hands-on work here. And this relationship is, again, something that I come back to. One of the points I want to make, one of the things I do want to say as I consult this, is that they are very often responding and bringing a very, very, very focused vision into a thing. A lot of times, there are clients who have multiple responses. They have multiple problems. You may get into a business. They have some conversations. You can actually acknowledge an officer to find out that they're dealing with a lot of side-to-side, set-off problems. You're designed to focus on one thing. You have to help that person as they have to get into one hand. I think that's important. What they're expecting, they're expecting to get into that hand. There's a series of methods. They're expecting to come up with some plan strategy. There's some best practice that they might implement before. It's a very, very violent challenge. We haven't consulted consultants before. I was recently interested in the last six sales. It was a great thing because at the end, the person who was making the final decision to learn to update the sales are created correctly. He said, Well, you're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. You're always alone. organization, how to make sure that they're sysoldered and open. Which is kind of fascinating, as it has to come in and come outside. I have the option to switch to people in certain directions. All the great things, right, Corey? Dr. Ockney, about this story. This sort of value, value being open, all the important support, all the existing support, these are the ones that are not in the right place. You as a consultant, you're a very, very, very strong person. You make those hard-earned, hard-earned, hard-earned, into that organization and they can make a good look. Is in your best interest to adopt, to open this platform for the following reasons. We do all the work that we're doing, so we're as we're happy and happy and replace those systems. We've opened both, in particular, we're a frequently asked team. I gather a lot of those systems, they don't talk to each other. But we do a lot of, lot of placing, placing, so on and so on. This is always something that's going to be in your mind. How can you help them improve by adopting lots of practices that will make the internet internet, that will make those people work better, that sort of, that sort of thing. So the thing to remember when you're about work consultants, they're always out of that research is, there are no such things as internal consultants, it doesn't quite work that way. You can't have internal think tanks and things like that. Consultants have a special ability because they come from the outside. They're always temporary, no such thing as a long-term consultant. Certainly, you might have a client to work with for 10 years, but that's always on a project specific thing. And that is something important to keep in mind. You're expected to be expert in something, we'll talk about that in some depth. You're expected to be politically neutral. Now, again, not being from Europe. I'm just going to assume that this is true in Europe as it is in the United States. If you come to a farm and there might be three members of the C-Level, one of the chief technology officers, the chief operating officer, and the chief financial officer, they may all have very different visions for the company, very different agendas for what goes on. Does this happen in Europe? Please tell me this happens in Europe. Yes, or we do want to work with universities, right? Universities are great for this. The university has 80 departments and 10 of the departments want to go over here, and 10 of the departments want to go over here, and 40 of the departments just want to go to, you know, Barcelona for the weekend and they don't care. So when you come in from the outside, you have the opportunity to be politically neutral in those internal arguments. I'm actually in a bad relationship right now because I am perceived as not politically neutral in one of those arguments for a big client that has four warring stakeholders. That is a very big problem. You also get the opportunity to come in as agents of change. Very frequently consultants are brought in to do that, to make big changes, right? Because the organizations tend to lack the inertia to start. I mean, the inertia problem, right? It's very hard to move an object at rest, particularly if it's a larger organization. And so you're almost, we're almost always brought in to change things, right? And it's sometimes a very interesting process to figure out exactly what they want to change, right? The big education I have to do with this client that's at war with itself is to teach the business people and the technical people how to speak the exact same language so that they stop getting their signals crossed, so they stop confusing each other about requirements and about deadlines and things like that. So the big piece in all that, and I'll say is that consulting is fundamentally a trust relationship. And again, I'll go back to stereotypes. This is what many people think consultants sell. It's wind in a can, yay! I want some of that. I want a wind in a can, that'd be great. And they're very, very expensive, right? And there are folks around, and I think most people in the room will tell you right now if your client only sees you as an expense, your relationship is going to look like this the entire time, right? It is absolutely crucial that you put a value on that relationship that is not simply monetary. And because I like to try to localize things, we're in Holland, people love to ride bikes, and they love to ride bikes in large groups. So my point as a consultant is you're gonna have to figure out where in this peloton you actually are. It's very rare that you're gonna be out in front by yourself. You might be stuck in the middle, you might be on the edge, and if you watch any of these bike races, the peloton is a really dangerous place. It's very, very easy for one person to make a mistake and everyone to go tumbling down, right? So this is the relationship I want you to think about in terms of where do you fit into that organization? You're not coming in to drive everything. You're in there to move that peloton along smoothly. Okay, so we're gonna try to talk about how we might do that. The big thing that I wanna touch on here has to do with how you get paid and how people perceive that pay structure. There are two basic ways to do consulting payments. The most common is retainer or fixed fee where you're hired to do a certain amount of work in a certain amount of time for a certain amount of money and that money might be per hour, it might be per week, it might be whatever. There's a huge movement, and I love this movement actually, to try to move to outcome-based contracts. My father was a consultant for years and he was very, very successful and all of his contracts were outcome-based. That's exactly what he did. And what that means is if we hit this goal, you pay me this much. And if we hit this other goal, you pay me this much. And if we hit this great big goal over here, you pay me a lot. So if you can do outcome-based consulting, you're already in the win column. If you saw Vessa's talk at the end of yesterday, talked about incentivizing project payment terms by changing your payment terms based on when the project gets completed. It was really fascinating. But the big one, and this is something that we focus on a lot at Palantir, is this concept between transactional or relational interactions, right? Is my role here to be paid to give you something? Or is my role here to help you achieve something? And the big piece that I want everyone to take away, if you take away nothing else, is your job is to help other people achieve things. It's not about you at all. You are in there to make sure that people are successful. What that means is that the primary goal when you start your consulting engagement is what does success look like to these people? I'll go off on a small tangent. One of the first things we do with clients is we bring them all in a room and sometimes we'll have as many as 20 people in this first stakeholders meeting. These are all the people who are involved in the outcome of the project. And we asked them a very, very simple question. We make them write it on a post-it note and we stick them all on the wall. The question is this. Six months after we leave, how will you know this project was a success? If you're lucky, all of their answers will cluster in two or three categories. Like we'll have more revenue or we'll have fewer user complaints or something like that. Sometimes you have outliers and that's where things get really, really interesting. We did one, like I said, with 20 people in the room. 19 of them were all in agreement on everything and the 20th person was from a different department that hadn't been involved. She had been on the job for three months and she didn't really want to say, but we asked her to. We actually read her answer on her behalf because she was responsible for fundraising at this hospital. And she said, well, we'll be more successful if we get more funds coming if people are making more donations to the hospital, of course. And no one was looking out for that. That is actually critical to their strategy. So little tips like that. What I say, and I think it sounds intimidating, so you have to come in with strategies, you have to come in with plans. Some of those plans are very, very simple. Hey, let's put everyone in a room for 30 minutes and ask them one question. And tabulate the results and tell them, okay, this is what you said was important and then we use that to drive the entire project. So this leads to the next question. Why do firms hire consultants? And how many of you know the answer to this question, by the way? I assume most of you actually know some of this. I'm not sure how much of what I'm gonna say today is actually new to people, but hopefully it's a refresher. But if you've never thought about this, I mean, really, why do people hire you? And I'm gonna go back to my Peloton. They really actually want you to do this. They want you to be the support car in the back in case they fall off the bike, right? They wanna be the support car in case you blow a tire, right? The CTO doesn't bring you in to win the race. The CTO brings you in so he can win the race, or she can win the race. The other thing that they're looking for is what makes you stand out amongst everyone else, right? This is when you, I mean, how many of you people are here to hire someone to do some work for you after this conference? Anybody? That's sad. Oh, well. So we can talk openly. That's great. There was an interesting part in the talk they did yesterday about selling Agile. A lot of the people they talked to were CTOs, and Dick Olson, who works for Pfizer, and they were all talking about how do they evaluate consultants who make pitches to them? And so my question to you as a consultant is, yeah, what makes you unique? What value do you bring to an organization that no one else can? Typically for us, that's domain expertise. Expertise in something that the firm either has not mastered or has not had time to master, or in many cases cannot afford to hire people who already have mastered, right? These are very, very common things that we're asked to do, technical architecture. Drupal is a complex system. CMSs are complex systems. Knowing how to architect that so that you don't get yourself in a bad position every years from now is very, very important. Content strategy is the new big thing. Everyone's, excuse me, interested in content strategy. I am interested in water. Data migration, we do so much data migration. It's one of the talks I usually give, actually. It's, what is it, 2014? 2014, most of these people have been on the internet since at least 2000, right? I've been doing this professionally since 1998, right? You'll deal with people on projects who are on their sixth or seventh iteration of their website. Nobody starts from scratch anymore, right? You're always dealing with legacy data. In some cases, we deal with legacy data back to 1922. In one of the cases I will show you, it's data back to the 60s, which is really, really exciting. A lot of people need project management. You could make a lot of money right now being project management consultants for web projects because, particularly if you're doing Agile, a lot of folks get themselves into that situation where they don't know how to run an Agile project. They don't know how to be a product owner. This is a separate topic we could talk a lot about. Systems integration, security review. These are all big things that Drupal firms do. And there are firms in the community that have made very good livings by specializing in one part of this. You're there also to help the client get over the hurdles, and so some of these hurdles have to do with the way organizations work. People coming in from the outside do have some operational freedom. You've hired me to do a job. You don't tell me how to do it. You certainly don't tell my staff how to do it. You certainly don't tell me how to staff, how many people to put on a project, things like that. We have some operational freedom that perhaps the organization itself does not. They'll hire you because there's a business opportunity. They'll hire you because they need to get to market. They need to get there very, very quickly. This is a very frequent driver for bringing folks in. They hire consultants because it's too expensive to hire employees. This is particularly true. There's a big race on for Drupal talent in particular. I went through a period where I was trying to hire and everyone I talked to wanted essentially 15,000 euros more than they were worth. I turned down four people in a row because they were just like, I was like, that's more than I make. You can't have that much money, I'm sorry. The big one here that I do wanna highlight is this last bullet point. Sometimes, unfortunately, people hire consultants to transfer responsibility for project success and failure. There's a sad man nodding slowly in the fourth row. Sorry. Plausible deniability. Do they say that in Europe? That's a big American political phrase. Plausible deniability means I did not know that could go wrong. I didn't know. And people believe you and you don't get blamed for it. I'm in this situation right now. I have a project that's gone very poorly. We were brought in halfway through it and they're mad at us. They're very, very mad at us. There's not a whole lot we can do about that except try to build the trust back up, which is why we talk about things being relationships. So that does lead me to the risks of coming in as a consultant, right? And that transfer of responsibility is a huge risk, right? Particularly because a lot of the projects you'll end up doing have blended teams, and we'll talk about that a little bit too, where it's not just your team working on it, it's your team with some of their team. I talked to someone this morning and he said, yeah, I just had to have a phone call with someone that said, yep, we're behind. We need to do another sprint because you didn't give us the API documentation that we asked you for four months ago so we weren't able to complete that work. Whose fault is that? Well, that's the client's fault. It's never good to be able to have to tell the client that it's their fault. So transfer of responsibility. So risks, these are the biggest risks that we see coming in. This is the risk I call the high flying risk, where especially when you're dealing with large organizations or large groups of stakeholders, they have some really great, really awesome, really, really, really aspirational ideas. They've got, they wanna build the next Facebook. They wanna build an iPhone app that's gonna take your temperature and call the doctor when you're sick. I'm sorry, I had someone once who, well, recently who had someone who wanted us to migrate all of their data that was in PDF form, do OCR scanning on it, put it in a search database and make their entire back archive searchable, even though probably 60% of their PDFs weren't OCR scannable because they weren't saved that way. And when we told them how much it would cost, they quickly removed that from scope. Even if they removed that from scope, they still may have these aspirational ideals in the background, in the back of their heads. It's like, oh, I wish it would do this. And then when it never will, they still don't give up on that. The other one that we see quite frequently is what I would consider a fetish for new technology. There's this idea in many, many industries. I spent a lot of time in the newspaper industry, and they believe this, some folks believe this in that industry, but there's this hope very frequently when you undertake a new project, the company I used to work for installed SAP, for instance, and SAP was gonna solve all their problems and it solved some of their problems and then created a whole bunch of new problems. So there's this technology fetish that says, if we just do X with this piece of technology, it will make everything better. That's never true and your technology solutions always end up looking kind of like this. It's just a fact. So you gotta watch that. And I do love, since we are talking about Drupal, it's a CMS. Mark Bolton, who did the redesign of Drupal.org, he did the seven theme for Drupal. Yeah, people spend a whole lot of time on technology when usually it's not about that. It's usually about people and process. Speaking of people and process, couple more warnings or risks you'll run into, silos. I talked to somebody yesterday, we were sharing migration horror stories and he said, oh no, I've got that beat. I worked with one organization where one group was allowed to write things to the database and another group was allowed to read things from the database. What? He was having to do imports and exports. And so he'd have to go to one group and say, can you export this for me? Then he'd go to the other group and say, can you import this for me? And it would take three days to do something he could have done in 10 minutes, but silos, right? Identifying silos becomes very, very important when you're brought in from the outside. And as an outsider again, because you have some operational freedom, you can help break those silos down. You can reach across and say, you know what, this project's not gonna be successful without that database administrator. Yes, I know she works in another group, but I really need her. Can we get her on this project? And then the other thing you'll run into are just plain brick walls where people just say, no, you can't have that, we won't do that. These are bigger challenges. There are two sort of personality types that we run into as well. Again, if you're not a native English speaker, you probably don't use the term hippo. Do you know what the hippo is? One guy in the front row going, yeah, I know what the hippo is. The highest paid person's opinion. The hippo is the single most dangerous thing on most projects. Have you ever been in those meeting rooms where there's like 10 people around the room and you put an idea forward and everyone turns to Sally and says, Sally, what do you think? That's because Sally is the hippo. And hippos can go wherever they want and get whatever they want because they're huge. Yeah, how to solve this? I'm not sure I'm here to tell you that answer. We'll have a breakout session afterwards. How do you solve the problem of the hippo? Actually, usually the way you solve the problem with the hippos is to get them to publicly delegate responsibility and authority and then hold them to it. The other one we see a lot is what we call the eagle and the eagle is a stakeholder who doesn't participate in the project but swoops in every once in a while and makes big sweeping announcements. Like, we need that demo for FOSDEM next week. What, no, that's not on the project plan. I don't care, we need it for FOSDEM, it's a big deal. I did, eagles I know how to deal with. I mean, I actually went to someone's office, he pulled me in for a private conversation. He was a stakeholder, very important person in this project and he was telling me his concerns and I told him my concerns. I said, let me tell you what the eagle is. And I told him and I said, please don't be the eagle on this project. Please don't do that. Please let us do our job. Let's get all your concerns out now and we will address them. But please don't come to me in three months and upset the entire project. That is the worst thing you can do if you want this to be successful. Yeah, hippos and eagles, these are fun. I have a friend, Nicole Lind does a whole talk about this. I think she did it maybe in Drupalcon, Chicago. Nicole works for phase two, she's a VP. She has a whole presentation about personality types you find on projects and how to win them over. So if you Google it, you can find those. So yeah, risks, aspirational ideas that really don't meet with reality. I mean, literally, we finished doing an evaluation of a client's designs, they came to us with designs. And when we finished, it turns out that the budget is three times larger than what they hoped for. But they don't want to cut scope. So that's an interesting one. The technology fetus, the warning of complex systems, the sort of idea that what you're gonna put in place will remove the need for complexity. I don't think that's true. Again, silos of responsibility, internal barriers and these hippos and eagles. So, okay, let's talk strategy. Here's where I'm gonna try to give you some practical advice. Let's try. Number one, again, they do expect you to be experts. People expect you to be professional. And the single biggest thing you can do is to draft schedules and hold to them. I've told you some horror stories. Let me tell you my proudest moment as a consultant. We were working for a very, very large company and they were trying to launch a very large website on a deadline. And the whole thing was sponsored by a credit card company. And at one point, the project manager on their side said, well, we're pushing the deadline back for a week because the credit card company missed a deadline to give us advertising creative. The ad people didn't get their creative to us and they pushed the schedule. I was, I have never been happier on a project. It's really sad. But having schedules and having rules around how those schedules are built, right? The schedules are dependent on these things. If we don't have these things, this will be the outcome. Which goes to my sort of second slide, which is you have to put rules in place. The first thing we do with clients is we sit down and we say, hey, how will you know this project will be a success? The second thing we like to do with clients is sit down and say, okay, what are the rules of engagement for this process? How are we going to do X and Y and Z? We use risk logs a lot. Risk logs are great if you've never seen them. I don't have any slides about risk log. But risk logs simply say, here are all the things we think that might go wrong on this project. Here's the likelihood that they might occur. Here's how bad it will be if they do occur. Here's how we're going to prevent them from occurring. And here's who's responsible for that prevention, right? And so one thing may, the classic example of something that goes in the risk log is the servers won't be ready in time for launch. And the classic mitigation for that is, you make sure the servers are built out six weeks before you want to go live. So you have plenty of time to test on a live server. And the mitigation strategy may be, if it's not done six weeks out, we push the launch back. Sometimes you do punitive things or incentive things. You'll say things like, we're going to push the launch back one week for every day the server is late. That's a mitigation strategy. That is a risk mitigation strategy. Milestones, milestones are the other big things that people want. And frequently, I said you could make a pretty good living by doing project management consulting. Many of the folks that you will work with have never built a website before. Even though they have one, they might not have been involved in it. Or they're not technical. They don't know how these projects are supposed to go. You have to give them milestones. You have to give them checkpoints that say, here's how we know we're being successful. And if you were at the Agile session yesterday, Agile can help with this quite a bit. But frequent demos for clients just check-ins that say, hey, four weeks into this project, we're going to let your editors look at the back end and start playing around with content. It won't be permanent, but we'll let them come in and look. And we'll let them see what it'd be like and make any recommendations for changes, right? Yeah, milestone-driven development. And then the last big thing, and I said I would come back to it and I came back to it, is people. People are actually the single most critical thing on the entire project. Having the right people in the right role, and in particular, setting up the organization for success after you're gone. I said that we've had some big changes come over the way we think about things in the last couple of years. And again, I'll walk you through some examples of that. But we used to think of our job is to come in and build a website and leave. Well, that's a transactional relationship. That says, you're giving me money in exchange for a thing. People don't really like that. I mean, sometimes people like that, not to make fun of too many people. The Swedes love that. The Swedes love it if you're transactional. They don't want to talk to you about small talk. Sorry, I like the Swedes. But they're not that friendly. It's just strangers. I mean, they don't want to be. I don't like the Danes. The Danes, they love everybody. Anyway, I got to stop making Europe jokes. I can see my comments. My comments on the website now. He doesn't know anything about Europe, the people. So, I mean, on two of the big projects that we just did, I'm gonna actually show you. The most important person on both projects was an Oracle database administrator. Because in both cases, they had to pull a bunch of data out of Oracle, right? And understanding what that means from a technical perspective and from a personnel perspective is huge. And I was able to say to the stakeholders in both cases, oh, that's great, you have all this data in Oracle. Number one, people who write software for Oracle like to hide their stuff. So it's very hard for us to pull data out of Oracle because there's usually no documentation. And number two, people who install Oracle tend to be kind of security paranoid. And so they put their Oracle instances behind big security firewalls and you literally have to be in the same room with it to interact with it. And so I said to them like, one of the collides was in Philadelphia and we're in Chicago and that's reasonably far away. It's like here to Paris. And so we're not gonna be able to talk to the Oracle database unless we're in the Philadelphia office, right? And the DBA went, yep. It's like, yeah, that's not gonna happen, is it? Nope. So that meant that he had to commit to the project or the project was over. So making that identification becomes crucial. The one that I don't have a pithy slide for is this idea of finding out what that overall vision for the whole thing is, right? What's, and that's where that strategic planning comes in the beginning. What do we know will make this successful? So, yeah, what's the vision? What's the thing that unifies everyone in that room, right? Yeah, set your schedule, put some boundaries on things. That's what the rules are for. Therefore, making sure that you have ways of conducting yourself that people expect, right? One of the worst things that can happen to you on a project actually is a situation arises that no one anticipated and no one knows how to deal with. And then you have to negotiate how you're gonna deal with it. And that's when relationships get broken. But you're engaging people and you're going to be building processes but the processes mean nothing without the people. So let's talk about some approaches then. This is the sort of, hopefully the meat of things. This is stuff that we've been testing. It comes out through actual success and actual failure on real projects. The biggest thing that I wanted to get out of the way sort of first is if we're talking about engaging clients to be successful, one of the biggest things that they have to deal with is this issue of training, particularly in Drupal training. Drupal is a fairly large, fairly complex system. It's, at least Drupal 7 is very different from a lot of programming systems. It's a mix of different programming styles and it's written by a thousand different people. So it's got some idiosyncrasies. There are people who do a lot of upfront training. There are firms that will come in and spend two weeks with you and train your staff. You can also buy some good online courses which I recommend. But I've found that the upfront personal training doesn't actually work largely because there's too much to try to learn. There's too much to try to anticipate that they might need to do or might need to know. And so what we'll talk about in some of these models is engagement-based training where you literally look at the project, you schedule it out, you schedule out the milestones, and then you build training that maps to the schedule. And I'll give you some practical examples of that. But this is, I think, key to what I'll be saying is something that works. So the primary consulting model for most of us is what I call building. This is what we're used to doing in most cases, right? Someone issues a request for proposal or what do you call that in Europe, anyway? We have requests for, but when someone asks for a service, just RFPs, okay. Yay, it's called an RFP. I'm gonna do more research next time. Okay. When you're building something, you define the scope, you build the plan, you manage the plan, you implement all the details, and you launch. You're responsible for every single part of it. They've brought you in, this is the one that is in most in danger of becoming transactional, actually, this paradigm, because it's a very clear I brought you in to do this thing. It's like, I hired you to come in and put a shower in my bathtub. And that's the way people often think about this. That's the way RFPs are actually written. RFPs are horrible, by the way. There's a great talk, there's a great talk that a friend of mine, Todd Neinkirk, does called, like, death to RFPs. He does a big talk about how we shouldn't respond to RFPs anymore, we should just refuse because they're horrible. And they're horrible because they force us into transactional modes. I think that's really kind of fascinating. So, again, examples of, I had promised in the session notes that we'd talk about big sites, small sites, some different stuff. So this is a building example. This is the Martin Luther King Center in Atlanta. This was a fun project. They have Dr. King's archives, all his letters, all his personal notes, backed throughout his entire life. And they're all sitting in an alfresco database somewhere. And then we got brought in to build the front end where people can interact with all that archive. And this was an interesting case, actually, because the funding for that came from one of the museum's donors, not from the museum itself, right? You want to talk transactional. We don't even talk to the museum. We talk to the funder. And the funder is promising things on our behalf. And not the greatest relationship to be in, but it was a great project, I'm very, very proud of it. It's entirely a build. This is another one, the University of Michigan, a very large hospital system they have. They educate a lot of doctors and they have their own hospitals. And again, they brought us in to build the site. This is one of those projects that was transitional for us because we finished this project about four years ago and the site's still running and they still need consulting services from us. And they've never quite been able to take ownership of it. And I know this is being recorded and hopefully they won't see this and get mad at me, but they still have problems that they can't solve from a technical perspective, which makes me realize that we actually failed them a little bit on that project, right? Because we handed them something that they could not maintain themselves, right? So this is what started us thinking about, hey, just this build model where we come in and do all the work for you and leave you nothing but an object, nothing but a thing, isn't necessarily the best way to go. This is another one. This is Augustana Small University in North Dakota. Coldest place we ever did business. We set a team to Augustana in early February. Should kind of like be going to Finland in early February. Not real pleasant. Nice people, though. Consulting, this is one, so our history was we're builders, right? And most of the people you'll meet at this conference tend to be builders. That's what they do, that's what they like, that's what they're used to. But that can, as I said, put you in this very transactional state. And we kind of hit on this consulting model that I like a lot, that basically says, look, your team is perfectly capable. Your team is professional. Your team can accomplish things. You just don't quite know how to do it in this technology space. So we'll come in as consultants and help you. This is that sort of pure consulting model. We'll come in and make the plan. We actually come in and do three days. We don't try to teach them everything they need to know about Drupal in three days. We try to teach them everything they know about planning a Drupal project in three days, including doing the technical architecture with them. So we set it up and say, okay, here's what you're going to be building. Here are the things you're gonna need. And what we can do from that is then spin out a training plan and a project schedule that says, okay, the first week of the project, you're gonna be building content types. And we can do a one-hour session on what content types are and how to build them. The next week, you're gonna be building views from those content types. We can do a one-hour session on how to build views and what the important things about views are, and then you can build them. So we just do guidance in that case. We can supplement capacity, and this is a really fascinating model actually. Particularly if I were to start my own solo consulting firm, this is the model that I would take because I could probably take on six or seven clients at a time this way. Where you get a little bit of my time to help you. Anyway, I'm dreaming now. My boss is gonna see this, and she's gonna go, what? Sorry. This is an example of that site. This is the National Rural Health Resource Center based in Minneapolis, Minnesota. This was one person who was tasked with moving a site from Drupal 6 to Drupal 7 and implementing a new design. One person, and we consulted with him for four months. And he did 99% of the work and 90% of it he got right on the first try. And when he stumbled, we'd go in and say, okay, well, what went wrong? And then we'd show him or help him find the mistake more accurately. We'd literally do debugging sessions. We'd go, okay, this isn't behaving the way you expect. Why not? And then we'd tell him, we'd help him learn how to fix it. But I consulted with this client for three months and never wrote a line of code. And he sent me, like a month after we finished the engagement, he sent me an email. I said, hey, we launched the site. And they were so excited. And that's just great. This is Hampshire College. Hampshire is another small college. Same basic situation. That was, they launched that about three months ago. That was about a nine month consulting engagement. They did the entire thing. I consulted with them for six months. Once a week for six months, I wrote three hours worth of code once because they asked a question that I could not answer without trying to write code. It's a very, very empowering model. It's funny, I was talking about, well, that's my next slide. We'll talk about empowering here in a second. I was talking to a firm before I left the country and they didn't have enough money to pay for our normal services. But they could have paid for this kind of consulting. And they said, well, how happy are your clients who do this consulting? And I said, they're thrilled because we didn't actually do any of the work. They did all the work. They have all the ownership. They have all the pride in it, right? It's just our job to help them achieve what they're trying to achieve. So this is the one that I really like to focus on is this concept of empowering the client. This is what I think we've failed to do with the University of Michigan, right? Where we go in with them and, hey, we'll define the scope for you. We'll manage the plan with you and we will train your people and we will supplement your capacity, right? But we're not the first line of defense on that. The great example of that, this is a site that's about to launch. This is the Children's Hospital of Philadelphia, which is one of the finest hospitals in the entire world, actually. When we took this project on, they had a team of Java developers who had never written any PHP code. And these were the folks who had to get data out of Oracle. So they gave us a Java programmer who knew Oracle to get the data out. And then, and originally they just hired us to design and build, right? It was purely transactional. And then when we got into their process, when we got into the project, the person doing the data export out of Oracle was like, okay, now what can I do? So we set her on the data migration. And so we did, I literally did two hours of training with her on how to write a data migration in Drupal, in PHP, a language she had never used before. She wrote the entire data migration, it took her about three weeks. Excuse me, it took her about three weeks, but she wrote it and she implemented it. And she owned it. It turned out that that was a great way for her to learn how Drupal thinks about things. And then once she got that, once the rest of the team saw the success, some of the other programmers came to the boss and said, we wanna work on this thing too, which is a fascinating piece that I didn't really touch on and I wanna go back to. One of those big risks that you face coming in as a consultant. And the reason I say that you don't have consultants inside of firms is that I used to be a consultant inside my own firm, technically. And everyone was mad at me because I got to work on all the fun stuff, right? Think about it. I mean, we'll go to places like Children's Hospital. Well, they have people who've been on staff for 20 years as programmers, but you go to implement a new website and leave them out and don't give them anything to do. They're gonna hate that project and they're gonna sabotage that project, right? It's human nature. Nothing you can do about it, except get them on the team. So that's what the empowering model is about. It's about recognizing the skills that are present and helping them move forward. I'm gonna run through this very quickly. And we have 15 minutes left. I did wanna do time for questions and I never like to take my full time. So similar example, University of Vermont, the small university, small 20,000 students. We did the same model with them. We wrote about 40 hours of code for them. They were on this project for four months. We wrote 40 hours of code simply because they didn't know how to do it and didn't have time to learn. I mean, they had someone they wanted to do it. He was assigned to another project. And we did a bigger project for the University of Minnesota. The University of Minnesota runs 1,000 websites and has over its system about 65,000 students. And they needed a common platform for all of it. And we did this project with Acquia and... Sorry? It's not an open scholar now. It's a custom distribution for them because open scholar doesn't hit their requirements, unfortunately. We're about to do a big open scholar implementation but that's a separate story. So it goes back to the why do people hire consultants? What do they actually need? Very typically, they need project management. That is almost always the case. Unless you're dealing with a very large firm or a very experienced firm that does a lot of web work. You need to know if they need long term or short term solutions. Are they just looking for gap filling? Sometimes that's all they want. We have a project right now and it's literally we're just supplementing someone else's team. So one of our developers is sitting with their team. Yeah, do they need training, do they need strategy? It's funny of all these things. It's usually the strategy that our people, our clients usually come to us with really good strategy and not the rest of it. We fill in the rest of it. But it's when I said, you have to find what your team is good at, what you can bring to the table. These are things you can bring. I will give you one model. This is the model that's worked for us. And this is the last thing, this sort of, how do we do these sort of empowering consultations? And this was a real breakthrough for me. And I said I could do six or seven of these at once. And this is why. We literally go out and do a three-day, hey, let's learn about your project, let's meet the players, let's put a plan together, let's sketch out your Drupal architecture. And then it's literally two meetings a week. On Monday, we like to meet as early as we can, 30-minute meeting. Hey, what problems are you trying to solve this week? Oh, you're gonna be implementing an integration with Salesforce. Great. Here are the three most common things that go wrong when you try to integrate with Salesforce. Do you have this piece of information? Do you have this piece of information? Do you have whatever? This is where we share our expertise to help them plan their week. And then we meet for 60 minutes at the end of the week, usually on Thursday or Friday. And it's in that longer session, we say, okay, show me what you did. Did you have any problems? Does it work the way you expect to? And in that Monday planning meeting, we also ask, is there anything you're trying to do that you need some help with? Do you need me to go research something? Do you need module suggestions? That sort of thing. And the point I wanna make is why this works. This works because you're setting the client up to do independent problem solving. It's very much like the faculty advisor model of higher education. I'm just helping them set problems up. I'm not solving them for them, but I'm helping them clearly define what those problems are. Yeah, you're empowering the client and you're giving them this gradual learning. You're not trying to learn all of Drupal in one go. It's peace at a time. And then there's this piece, I don't know if this is a phrase we have here. The canary in the coal mine. Not canaries in coal mines. They used to have canaries in the coal mines because canaries are more susceptible to the toxic gases that coal releases. So the canary would die before the men. And so if the mine was unsafe, the canary would die and you'd leave. The canary in the coal mine here is just early warning system for that supplemental capacity because you're following along with what the project, what's happening on the project, what the client needs. And you may see an opportunity for a larger engagement. You may see an opportunity to extend that business relationship. This is what we really like about doing, we really like doing this model after launch. Hey, your site's launched. And for the next year, we're just gonna meet for an hour a week and see how you're doing. Oh, now you've got a big alumni event coming up in November. Do you need any help with that? And you have that relationship. You have that long-term trust and you're in better position to get that work. So that's my formal presentation. It is time for QA, it's according to the clock I have, we have 10 minutes, which is fine. There is a microphone and I've been asked to ask you to use the microphone if you have questions. If you don't have questions, this is all of my contact information. And if you don't wanna get up and use the microphone, I will repeat your question. If you wanna use these 10 minutes as a chance to get a break on the lines, feel free. I wanna thank everyone for coming and for your kind attention. Please, they do ask you to rate the proposal or the presentation so that they can plan next year's event. So please go back to the website and give them some feedback. Thank you. And I have lots of cards too, if you need cards.