 Is this supposed to start at five? Is that the deal? All right. I guess we'll get this show on the road. So, hi. Welcome to DrupalCon. Where are we? L.A.? Thanks for coming to my session, Demystify and Client Discovery. My name is Greg Dunlap. I can be found as Hey Rocker on Twitter and all of the other places on the Internet. I've been using Drupal for about eight years now. I just passed my eight-year Drupalversary on Drupal.org. For most of that time, I've been focused on configuration management and deployment stuff in Drupal. DrupalCon Chicago, Dreece asked if I would lead the configuration management initiative for Drupal8, which I did for a while, and that was pretty exciting. I got to travel lots of places and do lots of this at other DrupalCons. But most recently, for the last couple of years, I've been working at Lullabot as an architect. And one of the things that I do as an architect at Lullabot is I get involved with clients in the very early stages of their projects. And I get to go in there and help them determine what kind of a website they want to build and what kind of architecture they need and kind of get to the core of the problems that they're trying to solve and figure out how we're going to solve them. And then we figure that out, as developers who get to do all of the work. It's a great gig. I highly recommend it. So that's what we're here to talk about today is about the discovery process, the process by which you sit down with the clients and figure all that out. I already talked about... I work at Lullabot. This is our logo. We've been around in the Drupal. We were the very first-ever Drupal agency, and we work with a lot of really cool clients like MSNBC, currently one of my clients is working with the SpaceX. And we've also been doing a lot of work in just the media industry in general. Actually, we do a ton of work with. We've worked with Tesla. We've worked with a lot of cool things and launched a lot of cool sites. And I'm really happy to work at Lullabot because we're a great company. So at Lullabot, like I said, all of our major projects basically begin with an onsite. We go to the onsite with the client and we sit down with them and we do what's called discovery. And for me, it's my favorite part of a project because this is where real problems get solved. Ideally, all of the big problems should be solved during this process before you get to actual implementation. I would have thought that Morton was over there or something, but apparently they're really getting down next door. So... And you know, I'm a technology guy, but I've also been involved in technology for a really long time. I have years building applications. My first applications were built with Paradox for DOS, which really ages me, but somebody laughed and they get it. So there's somebody as old as me here. So... And while I really enjoy technology, I've also kind of gotten over implementation. One of the things I've realized after years of doing client projects is that if the stuff that happens at the beginning isn't done right and if the big questions there aren't answered, the project is screwed. And so I really like to get in there and solve those big questions and really dig into what the clients need. And one of the reasons that I really... that I decided to do this talk is that a lot of technology people like myself get thrown into this process. They say, okay, we've got this big project. Why don't you go out and meet the client and figure out what we're going to do? And after years of doing this, I've realized that there's kind of a way that a lot of technologists get into it and go about it. And it's a little backwards because the process of discovery is a lot different than the process of actually implementing technology. So let's talk about that. So what's the goal of a discovery process? So a client comes to you and says, I've got this website and it's kind of beaten down and it's falling apart after a few years and there's drug dealers outside and we really need to clean it up. We want to spruce it up. What I want is a gorgeous website. I want this nice Victorian with trees and clouds and I want you to come in and build it. And what a lot of people still do which is a mistake is to throw all their tools on the table and say, all right, let's get to work because you don't want to do that because you don't have an idea of what they want to build and why. You don't know why they want to build things and what they want to do. Client Discovery sets the stage for the implementation and lays down the rules that you need to go through to build the website and around which the website is going to be built. And you need to gather some essential information in order to do that and none of it has to do with servers or modules or RAM. What you really need to know is what are the main points with their system? Where are things falling apart? What day-to-day are they having trouble executing on? What is the thing that causes them to scream and throw things on a day-to-day basis? What are their goals out of getting to this? This is related but it's different. It's like what do they want to serve their business out of the new site? What are the things that they want to build? And what are the priorities around that? Everybody can get a group of people in there and talk about what the goals are but they have to be prioritized and this is the biggest problem because a lot of times you'll get a bunch of stakeholders in a room and all of them agree about different things that they want to do but none of them agree about what's most important because they all think that their own thing is most important. And solving priorities is where most of the knife fights on these projects happen. One of them is incredibly important to making the project. Building a website or a web project or any project without priorities is almost impossible and when we look at Drupal Core this is one of the things that we run into on a day-to-day basis. It's that we have a bunch of people who come in and they have a bunch of different ways to solve a problem but the product has never had a clear set of goals or priorities laid out. We don't name an initiative lead or sometimes Dries will do this but most of the time it's up to us to fight it out and figure out what happens and that decision-making process is really hampered because we can't say well we've got this set of goals and priorities and we've got this set of potential solutions so let's figure out which one matches the best and we'll go with that one. It comes down to a lot of philosophy it comes down to a lot of potential people saying this is what I want to do versus what they want to do blah blah blah and it's like there's no framework around which to build and make decisions. And just like that in a client project it's very important to get that information out of people and that is the most important part of any client discovery process. You can't build anything without this information. This is a quote from an old boss of mine. He said when it comes right down to it 90% of technical consulting is really business consulting because a lot of clients they know they have a solution in mind but they don't really know what it is or why it is. Most client discovery projects spend about two thirds of the time collecting all of those pain points the goals, the priorities, all of that information and a lot of the reason that it takes that long is because there's always a lot of conflict and disagreement within any group usually when they come in about what they're going to build and why and the process of getting it out of them is really the important process of discovery and it's a process that a lot of developers and technical people really lack or don't know what to get around. There's some tools that can help in getting that out and there's some ways to change your attitude about going into it which we can talk about here and set yourself up for success in the project. I think one of the biggest things is that you want to go in with a blank slate an empty notebook as it were you want to go in with as little information as possible. When I go into these projects I try and get only the barest information out of people. If they say, well, we've got 20 sites and we want to migrate them to Drupal five of them are running on WordPress and ten of them are running on Joomla and two of them are running on a proprietary system that we don't know how to get the information out of. That's like enough to get started actually. I don't want to know much more than that before I go into this project because if I start asking questions already around that and usually because I'm on the phone with a technical person at this point there'll be technical questions I'm already going to start architecting a solution in my mind and I don't want to do that until I've collected all of the appropriate information again about goals and priorities out of the clients going in with a technical solution in mind is one of the most common problems that people who walk into these walk into these things have as an example we recently had a client who all of their decisions were driven by their marketing department it was just like whatever the marketing department wants they get and it has to be pixel perfect. I'm sure nobody in this room knows anything about that kind of situation at all but because of the situation, because of the business needs and all of the other stuff that was going around at this client this was the way it had to be and so what they had done is they had built a panel site and with a bunch of custom panels panes and given the client and given the marketing department the opportunity to shove whatever custom HTML into it they wanted. That's a solution all right but of course the problem that they came up with is that then all of that stuff is tied into their features and every time the marketing people want to change anything the features have to be rebuilt and pushed out to the live site or even worse if the client wants to change things on the live site then all of those features are out of date and the stuff gets wiped out the next time the developers want to push that stuff out and so I made a suggestion which was controversial at first but which works which was that we could write a little custom panels plugin that does nothing but read from a specified HTML file off of the disk and we give marketing access to that HTML file and they can do whatever the hell that they want but it's decoupled from their panels and then everybody can they can push their stuff live and we can push our stuff live and everything separate from an architectural and technical standpoint it's a ridiculous solution I mean it's we're talking about like 1995 CMS technology at that point but on the other hand when you look at the client's goals and their pain points and their priorities it was exactly the right solution because it's not really up to us to judge what the client's goals and pain points are we're here to serve them and they're here to tell us what they need and so from that perspective it was a great solution they still didn't do it because their tech people thought it was ridiculous but I did my part another example of that is that one of our clients came to us and he was overwhelmed and he had a very hard deadline that he had to hit because of the school launching for the next semester hard deadlines are of course the most common problem that we struggle with as technologists a lot of the times and we had to talk through how he was going to get this done because he was also a very smart and adept and forward thinking web developer and he wanted to do everything really right and that was going to be a problem on the three to four month deadline that he had to launch by the next semester and one of the things that I had to do over time was talk him through that and how we were going to get through things and talk about descoping not just descoping and feature descoping but also about how he could build it and attack these problems after launch because again I knew from talking to him that his priorities were that deadline he had to hit that deadline and so anything we had to do to make that work was what it was up to us even though he didn't get to do a lot of things that I as a technologist would have loved to help him do on the project empathy is a big part of being a client of being a consultant and a technologist because you have to understand where they're coming from another important thing is that you want to make sure that when you're talking about these solutions you have all of the right people in the room obviously you want their technology staff and their design staff in the room because they're the people who have all of the information that you need to be able to build another business owners are important too though because they're the ones who understand the perspective of the business side of it versus the technology side they're the ones who are often the decision makers this can come in a lot of different forms and realms depending on the client that you're working with but if all you've got is tech people and designers in the room I can guarantee that you don't have all of the people that you need in order to discover what this client's goals and priorities are another really important thing that gets kind of lost in the shuffle on a lot of these projects is the editorial team part of the reason that it gets lost in the shuffle is because in a lot of these organizations those are just sort of the people who do the work every day they don't have a lot of representation in the leadership of the business but on the other hand they're the ones who do the work every day they're the ones who have to struggle with the CMS every day and they're the ones who probably know better than anyone on the leadership what the pain points and time consuming parts of doing the work on the day to day basis is having the editorial team or a leader from the editorial team in place is so important to making these projects work and having them in place at the beginning is so important because they're the ones who understand that if the project is not built properly then nobody's going to want to use it a classic example of that is image sharing so everybody wants like oh yeah we want to be able to take this one image and use it everywhere on the site that's great it's an image library and it's basically at that point you're building a digital management system and then they're like oh we've got so many images we can't find anything and so you add all of this tagging and categorization and stuff like that but then it means that anytime anybody adds an image to the site they've got to fill out like 15 fields so they can find the image it's like the kind of thing that everybody thinks oh it'd be great if we had this image library and all of these tags and blah blah blah but they don't think about the fact that it's useless and it's not only useless you're in a worse situation than you were before where you could just upload an image and use it and maybe once in a while you'd have to find the image in four places and replace it these are the kind of conversations that we have a lot with clients another classic one is automation versus curation of content because everybody wants to say oh I want every list of content on our site to be completely curated until they pass it down to the editorial staff who barely have time to enter the content that they enter on a day-to-day basis much less manage 150 lists of how that content is brought forth and things like that thinking about that and getting the editorial staff involved in the discovery process is super important and a lot of times it's really key to the success or failure of things here's another quote from my colleague Jeff Eaton successful consulting has as much common with therapy as it does with technology it's not entirely accurate but there's definitely a green of truth at it because having everyone in the room is just part of the problem but getting at the why of the project that you're building with everybody in the room is another part of the problem and that's really a people problem much more than a technology problem and drawing this stuff out of them has a lot of things in common with counseling and therapy and stuff like that here's some discovery techniques that I've used they work for me and they work for my personality they may not work for other people but perhaps they'll give you some ideas of how we can pull information out of our clients and how we can make these groups of people work one seems recently obvious you want to ask a lot of questions for me one of the best parts of being a consultant and working with a lot of clients is that I really love learning about people's businesses excuse me the vagaries of how people's businesses work and the different ways in which people work together is endlessly fascinating to me how people make money what their business models are in the end what their structures are all of this stuff and so when I'm in a discovery process and again if you've gone in without really any preconceptions in mind I'm just asking questions about anything just because I just think it's cool to learn about how people work together and so and I don't like draw lines I'll just like ask all sorts of weird stuff all the time and it's like I was recently working with the American Booksellers Association and they're a trade organization I spent a lot of time talking with them just about how they're funded and they came they talked about this really fascinating stuff about how about where their money comes from and how and how they serve their and how they serve their bookstores and this led into a really interesting discussion about the relationship of bookstores to publishers and all of this sort of stuff it was really really cool but a lot of it just came just because I started talking with them not about the project or anything just about who they are or what they do and that's one way because a lot of people love talking about their own business they love talking about the places where they work so just asking questions can bring them out of a lot of that information this is an interesting one don't break the awkward silences one of the things that therapists use and I think this is really what Eaton was talking about when he told me that client consulting is like therapy is that a lot of times you'll talk to a client and you're sure everyone's just staring at each other just let them do it eventually somebody's going to break the silence and it really shouldn't be you because the person who breaks the silence may be the person who proposes a solution who comes out with the core of what the problem that caused the awkward silence is who is going to bring up the thing that's really behind the scenes of all of this let them hash it out just stand back and let them go you can ask lots of questions but on the other hand you've got to know when to stand back and let them talk it out too a lot of times in these projects we come together and we get a lot of people who have conflicting views about what the end goals and priorities should be and sometimes you can direct them and sometimes you can just let them go at it and figure it out because a lot of times they might not even realize that the things that they have together are in conflict or that somebody else had the specific goals that were different than them you need to let them sort of talk that stuff out and figure it out and sort it out facing politics head on this can be tough a lot of situations obviously are very political a lot of times you may be at a company that has all sorts of other business stuff going on behind the scenes that you don't know about but when you see that stuff you really need to get at the core of the reality of it obviously the reality of it can be different depending on who you're talking to and some of these things can be sensitive and stuff like that but on the other hand sitting around and pretending that none of this exists that this guy doesn't hate this guy because he stole this guy from over here and stuff like that it doesn't help sitting around and pretending that all of these people are really in it together when they're not which is another thing that we'll talk about a little later doesn't help anybody at all being honest with everybody is really important and at Lollabot one of the things that we are really that we are really focused on is just being straightforward and honest with our clients and one of the things that's really amazing that comes out of that is that they end up being straightforward and honest with us in a way that's really rare actually in a client and consultant relationship so obviously there's ways to handle this more and gently but ignoring the politics behind the project that you're on isn't really going to help anybody there's a lot of different there's a lot of different sort of philosophies about note taking I was noticing me and Eaton were actually on a project just recently and I noticed that he was furiously taking notes in Evernote and mind mapping and doing all of this and I had a notebook out and I think I took up two pages of notes I think three of them were just quotes that I found interesting on the client's website and one was an idea for a presentation that came out of the talk that we were having it's like it was stuff that was like interesting to me that came out of the things that we were talking about it didn't really have anything to do with the project itself I would say that I don't focus on taking down every little detail because again I'm very big picture oriented when I go into these things but maybe you like taking down every little detail because it means that later you can start pulling them together and trying to see where the pieces fit together what commonalities different things have I tend to just like let it all flow in and let it sit in the back of my brain over a couple of days and let the pathways kind of find themselves for the eureka moment that makes me understand what's going on here or the pieces that form big themes that I wouldn't have really thought about I think if I had just like started writing that's one of those things that works for me it may not work for everybody but having some way to get down the things that are interesting or important to you is important again you may use the computer I like to write so that I can have my computer free to look at other things and stuff like that and I find that my brain responds differently to writing than it does to typing whatever you know what works for you is important but having a record of what's important to you is also important don't problem solve it's so easy for us as technologists when we find and I assume I didn't even ask I assume most of the people involved in here are involved in building websites on a day to day basis is that correct? I did get into the coding track after all it's really easy for us as technology people to problem solve because again we hear a problem and we start thinking of solutions and then we want to get into it because we're excited because we're excited to potentially have solutions but again problem solving before you have everything out sometimes like the core problems may not even come out until the second day of a discovery thing is really dangerous and so again I try and just let the process go as long as I can just talking just figuring out who they are and what they are and getting at the core of again goals and priorities because coming out with that is really important and like I said I always let the big picture find itself it's always it seems like really scary every time I go into one of these projects maybe this is going to be the time where I go through three days and suddenly I'm nowhere I've got nothing left than I did when I started but it's really interesting because a lot of clients they themselves get so involved in their day to day stuff that the big themes that drive them they don't even really realize and you sitting back watching them discuss stuff can pull that stuff out a lot easier than they can because you're much more separated from it let the big picture find itself and then we can drive into problem solving later that said there are a few technical things that are really important to get out of every discovery project and they're the kind of things that really really do impact things like server configuration and server architecture you need to get right right at the beginning in order for everything else to move on from these are things like content sharing let's say they come in and they say we've got 20 websites and we need to be able to display one story from one website on any of the other websites that's the kind of thing where it's like well are you going to go for a domain access or you're going to go for multi-site are you just going to feed RSS feeds everywhere getting to the core so questions is super important because they're the kind of stuff that you need to know before you can even start a single line of code what their third party integrations are is really important having a list of that stuff again it gives you a big picture view of it from the technology side that you need to have before you move on SSO LDAP stuff, permissioning stuff who can have access to what again I don't dive too deep into what is in their current organization and whether we're going to have to integrate with it at all these are the kinds of things that have to be done before project build can even begin at all and while there aren't many of these purely technical things I do want to get out of the room with these guys having them in hand before we go anywhere else sometimes there are some red flags that you can have before or as you're just getting involved in a discovery project and spotting them early and figuring out how to deal with them is pretty important because otherwise I mean the best case scenario of not spotting one of these and getting into a really sticky situation is that you end up with a website that has nothing but carousels on the front page again I don't know how many times I can quote Eaton in one talk but Eaton's great quote about carousels is that they're always the result of the world's worst knife fight in a meeting and everybody just gives up and says fine we'll just put everything up there but you know in the worst case this can be the kind of stuff that really causes a project to fall apart in the end I think the classic and most important example is the invisible stakeholder they're the person that everybody talks about but isn't there they say you know oh yeah we're gonna have to talk to George about that oh yeah Mary has that information we'll get back to you on that and you know their name is constantly coming up as somebody who has to be pulled into the discussions but they're not there that's bad you're in a situation where there's obviously somebody who's important enough that they're always on everybody's mind but if they're not there then the whole core of what you're after here can get to the center of handling this can be up to trying to get them in trying to get into contact with them about the questions that you're having while the project is still going at least figuring out at least who they are and what their role is so that you can kind of surround the problem from all angles and understand what pieces are missing but identifying that that person exists is really really important to know about that you can start managing it antagonistic political situations are hard to deal with they're even harder to deal with when you start truly empathizing with one side and not the other it happens it's tough I've done it but getting getting to a place where there's at least one common goal between all of these people or one thing that they can agree on is super important and a lot of times it's work that you don't even have the ability to solve and spotting somebody in the team who seems like who seems like they have a measure of respect from the sides involved can be really helpful because you can pull them aside and say hey we really need to solve this can you help me get through with these people or can you pull them together and try and get them on the same page at least to some extent because this project isn't going to work if all these people are finding every decision that we have to make every step of the way there are different techniques for handling it but it's usually pretty easy to spot early on and again if you spot it early on then you can start thinking about it as you start going through the process and thinking about it as ways to handle it and just realizing that it's there and building stuff around it can be really important some clients come in the same way that you do there you may have a very highly technical team that's running this on that side but all they want to dive into are the server questions and how much RAM they need I actually had a client like this recently where he was the director of technology and he really wanted to dive into all of the architectural questions very deeply without involving the rest of his team and I kept talking to him and they were in a situation where they had a lot of shared content and a lot of different sites that they were trying to integrate in a separate but equal way and I had to keep coming back to him saying we have a lot of questions that we haven't answered yet can we bring some of these other people in to discuss them and sort them out and he would say oh yeah sure and then the next day we'd be back to diagramming his network architecture that can be a problem just as it is with us diving too deeply into the weeds early on with a client that's diving too deeply in the weeds early on I wish I had spotted that in this client way earlier in our process and then I could have redirected it a lot better for instance when I had the client and I was able to meet with his other groups I could have reached out to them gotten more contact information gotten closer with them so that I had other places that I could reach out to rather than this one person that was one of those things that I had to fight with later on because I didn't see it but you know ultimately again what we're talking about here is that you need to realize that the client discovery process is a people problem you've got a technology project you're building a piece of technology but getting to the point where you know what and why you want to build is totally a people problem and even just going into your discovery with that in your mind you're going to help you immensely because if you do that and come out of it with all of the information you need then you can hand that off to your developers and if they have that then they can go and make the decisions about technology even the stuff that you haven't had to do really well when we did the American Booksellers Association project I did all of the discovery and helped them through a lot of the decision making that led to an architecture doing the migration and Dave Reed did that migration and as he was doing that migration he was saying hey you know based on all of the stuff that you've given me and about what they want to do and why and when I think this technology over here that I know a lot about that you didn't know anything about would be a really good fit for them and we talked it through and he was totally right but he could not have made that decision if I hadn't brought to him all of the information that he needed to know about why the project was and what its goals and priorities were and that stuff that's the stuff that drives all of our projects is so important to get done if you get it out together then we can all have a big high five at the end and everyone will have a lot of success and we'll party and then you can come to DrupalCon and talk about how cool your project was so that's my presentation and I'll be happy to take any questions from anybody if they have them how do you know when the discovery process is done, is there a finish? We typically don't do much more than three days for these sometimes we'll do two but usually our discoveries are three days I found that it's usually a good amount of time I would actually say that sometimes or even reasonably often about into the early or middle second day we will probably have the information that we need and I'll say that's a gut feeling more than anything but again if I'm starting to see the trends if I'm starting to see the big picture and if I'm repeating it back to them and they're nodding their heads and they're saying yeah that makes sense to me or based on what you all are saying I see you it seems like a lot of your focus is here is that really important to this project and then you know if we have some time left we actually will start diving into what we're going to do but you know having the time to make sure that you can get there is the important part but how do you know you're done you just kind of know Sure so he's asking about paid discovery versus unpaid discovery we only do paid discovery and especially the classic way that we'll do this is that we will come to a client and they'll have you know something on the order of maybe not much more than we have 20 sites and we want to migrate them to Drupal and here's what platforms they're on right now and maybe here's what traffic they're on and then maybe I'll get an hour with them in the sales process and ask them a few more questions and what we will usually do is pitch them the discovery as an individual project and then out of that discovery we'll come up with the information that they can take to another place to build if they want to but we get paid for the discovery it is an invoiced project but what we found actually is that usually we can establish a really good rapport with the client and we will end up getting the build as well if we want it and you know obviously at that point the client is motivated to work with us because we've gone we understand their business and everything that they're going through and things like that I'm not a fan of the unpaid discovery two questions first one do you have any techniques for flesh or kind of pulling out those goals from the organization that you're working with I mean one of the things is that all of the groups have their own goals and getting those out first is a starting point finding commonalities there starts to build the big picture a lot of times you'll start talking about excuse me you'll start talking to groups about what their goals or what happens in their group or what their business things are and you'll see certain themes develop that maybe they hadn't articulated as goals or hadn't thought about as goals but which really are goals for them as an organization but which they in their own little pockets hadn't figured out and that's when you start bringing that stuff up back to them saying you know I notice that you all mentioned you know this kind of thing is a problem and if they start nodding their heads and like wow you're right and then you start writing that down or you know it seems like you all think this is really important or like this is all you all seem to think that this class of problem is a real bummer and they'll be like yeah you're right you're right and that's where you can start that's where your value really comes in because you've got the 5000 foot view and they've got the you know 10 foot view and starting to pull all of that stuff together from high up is really key to what you're trying to do as part of that process I think and secondly after you're done this discovery process like what have you created like do you have a list of 200 user stories or like what have you got to pass on to the next phase usually what we'll have to pass on is you know we'll have a document it'll be about 15 pages it'll a lot of it will be summary of what we discussed it'll be our big picture view of the project it will have a lot of architecture stuff involved in it because again after we get involved with after we get all of this goals and priorities in place I will take it and say well based on what they've told me here is how I recommend that we build out this project and we usually have enough information to pull timelines and budgets together as well so I might say based on the information that you've given me I recommend that you build each of these sites individually with a content store on solar that they all have an API to access so that you can do federated search and then through this content store they can also pull out stories from each of the individual sites because the businesses deemed that it's important that while each site maintained their own identity they should be able to prioritize or bubble up stuff from the other sites that they wanted stuff like that that feeds from their priorities and goals but we have to talk about how to build it in a sustainable way we will often get into what modules will you use what version of Drupal will you use that you're going to start being a big one soon it's already people are starting to ask would you recommend that we do this now or would you recommend that we do it later well it depends how much do you need a solid web services foundation how much do you need to get it done by the end of the year you know all of these things feed into it and we'll have that document and it'll basically be you know here's what we've learned from you here's what you determine that you want and need here's how we would recommend that you would build it if you want us to do it then here is how much time it would take and what it would cost basically is what we come out of it with so at that high of a level like you're able to come up with a budget with any great certainty with a reasonable amount of certainty yeah I would say so okay you mentioned kind of dealing with Paul the political questions had on that works pretty well especially if you're an outside consultant yes that's right what's your perspective for insiders who are basically doing the in-house discovery oh that's hard it's really hard it's not the CTO's pet project right and it's tough because I was actually brought in on a project recently for just that reason where the CTO was dealing with a lot of rabble rousing within his organization and within his board of directors about topic X he didn't think that topic X was a good idea or he thought they should consider Y or whatever and would you come in and help us do an analysis of our business and our situation and say A what kind of stuff would you recommend to us but also specifically talk about topic X, Y and Z and it was interesting because when I presented that to their board they said you know this was stuff that had been sacrosanct for their board to discuss that they had just said no to 100% every time it came up but as soon as it came out of my mouth they're sitting there talking about it and so you're right as a third party consultant we have a lot of ways to dive through and cut through that stuff that you internally don't and I don't have a good answer for you I'm sorry maybe it's just convincing to bring in a third party person and actually sometimes you know sometimes you can use that person's confidence against them because if they really are that confident then why wouldn't they want to bring in an expert to talk about it to confirm them because then they've got this platform on which they can shove everything through right but on the other hand a lot of times they actually know what the real deal is too so that doesn't help you either I don't have a lot of good perspectives for you I'm sorry also very internal so I get a lot of pushback if we have a consultant and the consultant says we're going to do a discovery process then everybody's really happy about it and they participate fully but if I'm walking into the room I say okay first couple of days we're going to do a discovery process on this new project there's a resistance to it it's like oh it's a waste of time we already know what the goals are do you have any sort of tips and tricks for pitching this to get people to buy into the process well I mean let's say they say to you oh we already know what the goals are so ask them what are the goals and get a list and then go to all of the other people involved and say hey it's my understanding that the goals for this project are X Y and Z and that's what I've been told by this group over here that's building it is that right from the implication that I'm getting is that it's probably not now you've got a reason to say oh wow that's weird that's what they told me maybe we should all get together and talk about it probably won't ingratiate you that thought that they were going to that thought that they knew that they were doing but on the other hand it's probably going to ingratiate you with these groups over here that are like wow I'm really glad that this group over here didn't dive into a black hole and try and do that thing that's probably you know one thing that you could do but I understand again internally your politics are a lot different than mine are because I can say whatever I want to and walk away not whatever I want to I can say whatever I want to and get fired to of course but those dynamics are infinitely more complex than the ones that I have and a lot of times it'll really depend on your own situation and navigating that a lot more carefully than I can probably sit here and talk about does anybody else have any questions somebody else seems to be going up there do you guys have a predefined agenda for your discovery process so you said three days do you give an agenda to the client we usually try we usually do a pretty loose agenda sort of about you know the first quarter of the day we'll do introductions and who are you and what is your role on the project and then we'll dive into you know the topics will depend greatly on the project that's involved but maybe it'll be an inventory of the sites that they have or a let's you know why don't you take me through your site and let's look at what's there that can actually be really helpful because a lot of times they'll be like oh and so here's this page and god I hate this thing over here it drives me crazy or here's this page that has this bug that we've never been able to fix and it's really horrible you'll get a lot of insight into their pain points just naturally because everybody loves complaining about their existing website especially when they're going to build a brand new one and a lot of that stuff will end up feeding questions that again now we start driving into the stuff that we're really there for the agenda tends to be sort of really really big topics that we may or may not get to but the one thing that's really useful in the agenda is you can say here's this really big topic and for this really big topic it's really important for these people to be here because you know when you're talking about the things like what kind of content are we going to share that's a different big problem than what I've heard you guys are using want to have an SSO solution what do you have in place right now where you're going to need to get the system admin guys in there and it also helps because it means that you don't have to say a lot of these stakeholders are usually really busy and very appreciative of the chance to say oh I can take two hours away from this and go catch up on the rest of my life that so that is one part that's really good about having an agenda but again the agenda tends to be very broad and very generalized we don't dive into it too deeply hello hi so you talked quite a bit about goals and defining goals across the organization and across different stakeholders how do you incorporate kind of like the end user goals into that process so the people who actually be using the site and maybe not your client ideally those goals are built into their goals it's not always true I always like to joke that I've never seen a user study in which the users came out and said god I really wish I could have more advertising that was targeted at me more closely so you know obviously sometimes those things aren't in opposition but they are different ideally they will be bringing those things up and there's a lot of those goals that we end up bringing up to them especially now with things like responsive with front end work with front end performance where you know that will come out of our research either before or during but you know a lot of times it will be like you know is this important to you and they'll say you know oh no responsive is not important to us only 5% of our thing is mobile and then we'll say have you ever considered the fact that 5% of your thing is mobile is because when you bring it up on your website all you can see is this little logo in the corner and then you have to scroll and scroll everything down right we have a lot of those discussions although they're becoming rarer and rarer as time goes on obviously but if they don't bring them up I will usually bring them up as a matter of course but again you can't always control those priorities and at some level if they haven't determined that that stuff is their priority right now then it's kind of out of your hands I guess do you ever push for a component of like customer research to try to bring that into the conversation we definitely have it's usually for clients that are to some it depends on what point in the process you come through like a lot of our projects they may already have wireframes and designs in place if that happens then there's not a lot about things like customer research if we come in really early like right at the very beginning and we're starting to build that part of our business a lot more now especially as we repeat with clients because they come back to us and say you did a great job doing the build up for our website and we're just starting to think about our next website then we start talking about that kind of stuff a lot user research all sorts of like content strategy stuff and responsive and stuff that will help establish those goals again earlier in the process as early as humanly possible but sometimes we just don't have that opportunity because we're just brought in to do the build all right thank you so after you've built up this working body of knowledge around the business operations how do you transfer that to the development team after the solutions architect engagement as a discovery right usually we will have of course access to the document that we wrote but usually the person who does the architecture will at least to some extent continue to be involved through the life of the project we've talked about different ways in which that can reveal itself there are certain architects who are interested in actually taking the project and becoming the PM going forward that has a lot of advantages and a lot of ways if they're the kind of person who is good or interested in doing that it means an existing relationship with somebody some continuity between the people that they're working with for the client which is obviously helpful for them and you've got the body of knowledge that you can pass on to the developers especially if you yourself are a developer in the past and we only hire technical PMs we don't hire project managers who have never had any development experience before for the most part because of that very thing so they can communicate with the developers but even if the person has messed with a once a week meeting where they get together and say hey do you guys have any questions for me and they say no or yes this part of what we've been doing doesn't make any sense or I noticed this part is missing did you mean to fill something in there that you never got around to these two things were in opposition maybe was that something that got resolved later on or things like that but maintaining some level of presence in the project is important for us and we always do it we never just throw it over the wall and then walk away do you ever see yourself involved in requirements engineering or becoming more of a technical product owner as the project is move forward you mean in terms of translating some of that business value towards the project implementation we usually do that as part of what we deliver in the deliverable after the discovery we talked about implementation we talked about versions that we'd recommend one of the things that we talk a lot about with clients right now is whether decoupled makes sense for them or not depending again on their goals and what kind of staff they have and what kind of stuff that they're trying to put together we don't obviously get down into we're going to install these modules and you're going to have five views on this page but general concepts of their architecture and general big picture stuff that we get into as a part of as a part of the requirements document that we build how deeply we get into the implementation once the dev build starts depends wildly on the project and staffing and who's involved in the project over here and who was involved in the project over here and stuff like that one of the things that's great about lullabot is that we don't have a rigid established process we tend to be very fluid depending on the client and their needs and so in a lot of those cases we'll just see how it plays out to be honest. Yep and thanks everyone for coming I hope that this was useful to you and if you like this session or dislike this session or any other session that you attended this week please go to the evaluation URL and rate the session and leave comments as somebody who has previously organized Drupalcon and been a track chair for Drupalcon I cannot emphasize how much these evaluations are helpful to us in determining choices for speakers in the following years the stuff is really informative and really helpful both for our speakers and to the organizers thanks I'll upload my slides look on Twitter I'll post it do they have a place on the session on the session notes to upload slides for the con they usually do lately they'll be out there