 All right, I'm gonna go ahead and get started I get very excited about this topic So I make sure I have enough time to fit everything in here and still have time for some QA Hi, my name is Tom Martin. I am a senior technology consultant at metal toad We are a digital agency out of Portland, Oregon in the United States. We focus primarily on Drupal based projects. I Found my way into the internet back in the in mid late 90s got very excited about it And yet somehow became an animator instead And then somehow found my way back into doing web-based work and development and spent a lot of time doing e-commerce and At some point wound up at metal toad learned Drupal and I've been there ever since so this session summarized is Basically at metal toad we've been experiencing this phenomenon recently where a lot of clients are coming to us and they have these very big grand ideas But they don't necessarily know how to make these ideas reality. You know, what does the project actually look like? What does this actually mean to produce this thing that they have in their heads? And so we've been doing a lot of discovery projects lately And I wanted to come here today and share a little bit of this some of the things we've learned with you folks So what exactly am I talking about when I talk about a discovery project? Discovery project is essentially just a small project to define the big project You know, it's planning. It's defining the goals. It's doing requirements gathering. It's plotting out a road map And it's determining the scope so that you can actually estimate or even have some sense of how many sprints the big project is going to be More importantly than that. It's a fantastic opportunity to build trust between yourself and the client How many of you have ever done any of these types of things before? Right, I mean, I'm not you know reinventing the wheel here in any way All I'm simply doing is you know, we've we've taken a lot of these practices and processes and combined it into a Service that our company can provide to the client So which customers, you know, does this really apply to it's not every project. It's not every client, you know There's a little bit of a spectrum You know on one end you kind of have your fairly basic websites think of these as brochure wear sites I mean this could be a restaurant that needs to post their menu or locations. These are very easy You know typically they're going to be marketing based a lot of the requirements are going to be dictated by the design comps So do you really have to do a thorough discovery on these, you know, maybe not But of course on the other end of the spectrum you have these large monolithic ERP systems These are very very large architecture, you know think of Starbucks and you know internationally the types of systems that they have to support for You know, not only you know the point of sale, but supply chain You know HR, you know, these are massive systems And that's not really what I'm talking about here either because when you get into that scale You're starting to talk about some form of architecture framework What I'm talking about is what I like to refer to as our little discovery project Goldilocks zone. It's not too big It's not too small. It's somewhere right in the middle The way I like to think about it is as as the web Evolves and as we start to see more and more that what constitutes a web project is becoming more Complex those of us that were in the agencies of in in the business of building websites are starting to see these more complex Requirements coming in and as a result we have to do a little bit more thorough planning ahead of time to just make sure We know what exactly it is we're embarking on All right, so we need to do some planning and one thing that I absolutely love to do is to take lessons from other industries That's let's face it. We're a relatively young form of media I mean, we've matured a lot in recent years. We've been around for a while now, but in the grand scheme of the world Web is still pretty young and there's folks that have been doing things a lot longer than we have so Let me ask you this imagine if an animation studio went out and they just Wanted to make a movie and they decided on day one. They were just going to start animating Just right away, you know, they're starting to render stuff by day two How do you think that movie is going to turn out? It's going to be pretty terrible. It's it's safe to say What are the odds that they're going to be around to make another movie? Not very high and why do they do all this planning up front, you know Because simply it takes a lot of time and effort to make animation You know three seconds of film is going to take them a lot of time Now I think everyone in this room probably realizes the work we do takes a lot of time also I know probably most of us have been nights and weekends and we know very well how painful and how long these things can take so Again, let's take some lessons from these other folks One of my favorite quotes one of my animation professors used to say all the time Said if I had three days to animate a scene, I'd take two days to plan and one day to animate it This was from Eric Larson. He was one of the brilliant nine old men from Disney's golden years But this is just another way to say something you've heard many other ways many other times like in carpentry when they say, you know Measure twice cut once. It's the same thing And so how do they plan and animation? The very first thing they do is draft a script. This is the core of the story Basically, nothing moves forward until they feel like this is this is panning out At the end of Toy Story 3 or Inside Out or any of these recent Pixar movies It was not the ray tracing algorithms that made you teary-eyed at the end. It was the story. It was the characters The next thing they do an animation is conceptual design They develop the characters The layouts the color palettes locations and they start to figure out how all of these different objects are going to connect You know, basically what you know, where your objects? What are their methods? What are their properties sound familiar? Storyboarding is where most of the magic happens. They do quick sketches rapid ideation budget-friendly experimentation Something isn't working. They can throw it out. They can do it early and they can move on with production Once they have their storyboards, they can throw these together into an animatic They'd actually drop it in with the audio clips. So at this stage They pretty much know how long the movie is going to be they know Long all the shots are going to be and they can run this in front of a test audience So that by the time they actually get down to doing the animation They pretty much know whether or not the movie is going to be successful or not and if not they can change it So over a hundred years of grueling work is taught animators how to plan and in order to avoid costly budget failures So what can we do? You know, what's the equivalent in our industry? You know user stories Tech specs diagrams wireframes flowcharts, you know ia ux, you know prototypes These are all things you've heard of and done before So what is the Discovery project? It's our script. It's our conceptual design. It's our storyboards. It's our, you know, animatics It's basically our way of making sure that when we get down to building this thing We're on the right track and it's gonna most likely be successful and if not, we'll know before we start So let's take a quick couple quick brief looks at why we would do a Discovery project For me personally most this all boils down to one thing and that's narrowing the cone of uncertainty Have any of you heard of this concept? So essentially the cone of uncertainty is when you walk into a new project, especially with a new client there can be a massive amount of things you don't know and You basically want to try to whittle that down to some degree So that when you and your team start to actually go into production you have some level of confidence So if you're doing agile, do you still need to do a Discovery project? I get this question all the time and my answer is yeah, it's not a bad idea You know at metal toad we we try to do agile as best as any agency model can Of course the clients always throw a monkey wrench into agile when when you're dealing with many clients But yeah, absolutely. There's no reason why you can't do a little bit of discovery up front because if you think of agile You're kind of saying that at the very end of the project you're going to be the most informed to make decisions Well, if you think about how that plays with our animator friends, not very well, you know But there's nothing that says even with agile you can't do some Homework ahead of time some research to make sure you at least know how many sprints you're going to need or how about how many resources You're going to need do you have to narrow the cone of uncertainty very far in agile? Not necessarily you can start development maybe a little bit further down because agile is going to give you a lot more Flexibility when you get into your sprint structure But of course if you're doing waterfall, you're going to want to get that very very far down before you start Development you're not going to want to run into any surprises. Otherwise that's going to be on you You're going to be eating that budget Most important thing though is that you and the client are ready to move forward you both feel confident You both feel like you know what you're embarking on where that line between discovery and development Lands that's going to be variable. It's going to depend on how agile the client is going to be willing to be It's also going to depend on how many requirements are already set in stone and not flexible But you definitely want to be able to define some boundaries if you're doing agile like I was mentioning earlier You want to at least be able to know about how many resources you need and what skill sets they need to have And you're going to know about how many sprints that you're going to need them for Because if you want to be able to look at your pipeline and plan your future projects You got to have some sense of where this this big project is going to land and when it's going to be over And of course if you're doing waterfall, you're back to the old iron triangle scope cost and time And you're going to want to lock those down as best you can to protect yourself So what some of you may be thinking is this is all great and fine to think about all this planning But you have a business to run and you've got to be able to get paid And it is a lot of work But don't forget that I am saying project the word project is in discovery project And that's exactly how you should pitch it to your prop your clients. You should be able to get billable hours for this When you're trying to pitch this to a client if they don't like the term discovery project try where they might be more familiar with like Consultation or strategy when we go in and we try to pitch a discovery I mean, this is again the hard part you got to kind of guess how long is it going to take you to determine all the variables It's a little bit like what came first chicken or the egg because the whole point of discovery is to help find out How complex the big project is so it's a little hard to tell just how much time you need to spend up front It's an art form. I guess but what we try to think about is if We can ballpark how big we think the big project is we try to get at least three to ten percent of that is a discovery budget And there is a little bit of decent sized variants variants there and a lot of that depends on you know Just how much time where we think we think we're gonna have to spend doing R&D to research any of the components But believe it or not these projects can actually be very easy sales to large businesses like when you're talking to an enterprise Client someone who's used to doing digital projects. This is not a hard sell. I myself first coming into all this type of thing I thought it would be But but that's that's be blunt at least in the United States I don't know about here in Europe but in the United States there is a huge percentage of digital projects that fail and Enterprises that work with many vendors and do many digital projects are aware of this and so essentially When you go to pitch this to them You got to keep in mind that they love planning and documentation You know, they absolutely love narrowing, you know The estimate ranges and getting that ballpark to be something a little bit more tangible that they can take to the financial teams And they love minimizing risk, you know from their standpoint a discovery project It's gonna lower the cost most likely and lower the risk of the entire engagement You got to remember a lot of these c-sweets these directors that are putting You know, they're putting their butts on the line to get these projects through and they're people just like you and I They want to be comfortable and they want to know that these large engagements these large budgets that they're trying to get through through their Corporation are going to be successful and you're basically giving them an insurance policy that it will be and The process scales you don't have to think about as this huge monolithic thing. It can be fairly small You know for relatively, you know straightforward not complex sites that maybe just have one or two complex elements Maybe an integration or two, you know those we can just do some fairly quick Maybe just like a two-day discovery even where we were really just looking at that integration. We're looking at the API We're making sure we understand it that we understand the requirements and the communication methods and then from there You know the rest of it might be fairly easy We've also been pushing a lot lately for what we call you know sprint zero on our projects You know, this might be a very light sprint. It might only be one week It might not be full-time, but it brings the actual production team together and gets them in a room And a lot of this actually involves, you know starting to build out the backlog, you know Ideally, they've got a product owner available. I'll talk more about product owners in a minute But it's essentially, you know getting getting the planning phase together when maybe not a full-blown discovery is necessary but at least get the team planning and identifying some of the the complex situations or Or higher priority tasks Though of course on the opposing side of that we've done some discovery projects that have lasted multiple months These are very large engagements and they have decent sized budgets We've had some discovery projects where the budget for the discovery Was bigger than some of our smaller brochure where marketing sites All right enough with that. Let's get to the how So before we write our script You know, we got to go into step one and step one is we've got to actually go out and talk to people We've got to listen to some people Before we go Too deep we have to learn to accept our own limitations Most of us are developers by trade not all of us. I mean there's people that come into the Drupal road from from various ways But most of us are fairly technical minded and what we have to remember is that While we may know technology and software better than most people out on the street The people in these companies that we're working with they're gonna know their jobs a lot better than we do They know all the little details the gotchas the little things that we don't know and nor should we But if we really want to make magic happen, we've got to learn to meet in the middle We got to know where our institutional knowledge stops and where theirs picks up Before we run out and I did an interview just anybody because interviews are a huge part of this process You've got to be able to absorb and listen You got to be able to take in everything that they're saying before you make your opinions But before we go out and do that you got to identify who you want to talk to Of course, you're gonna want to talk to whoever's funding the project If there's a director involved someone in middle management. Yeah, they're there again. They're putting their their Reputation on the line with this project. You've got to make them happy. Of course However, are they gonna be the ones that actually use the software you build? Maybe but but maybe not you want to try to find the actual users of your system and talk to them and look at The users that are using whatever system they have today in an increasingly global world It's very important to pick how you're gonna communicate with these folks You know, I'm a huge fan of body language Not so much of doing it even though I make weird gestures But but I'm a huge fan of observing it You know, they say body language can be up to 55% of human communication and I think that is very true So if you can when you do these interviews go in person if it's possible to physically be there It's worth it. If you've got to add some budget to the discovery project for flights for travel do that It's very important that you're able to observe not just, you know, what they're saying, but what what are their eyes saying? What are they thinking of? What are their hand gestures? Do you know, are they you nervous? You're not going to know that if you're not there at the very least try to do a video chat But whatever you do don't try to conduct these interviews via email. That's that's essentially Almost insulting. It's it's a waste of time Do keep in mind that when you go out and do these interviews some of these stakeholders may need to be put at ease They may be a little nervous You know, whether we want to admit it or not people are very tribal and territorial by nature We just are and so when you walk into a corporation as an outside entity talking to them about how you're going to Introduce this new software this whole new solution that's going to change the way they do their jobs every day Some people are going to be nervous You know, if they seem hostile towards you, it's not don't take it personal. It's not you I went into a company recently where they had a team of eight people who their entire job was to manually take emails and believe it or not faxes and retype everything into one system and then they were also retyping it all again into Excel and Then emailing that out to people and then it walks me saying how I'm going to automate their entire process These people have job, you know, they're it's their job on the line. They have maybe children at home They may have to pay for their house for their cars Were they comfortable or happy to see me when I come in there to say I'm going to automate their job Of course not But you have to try to make them feel at ease because in the end you do need them and you need their help You have to be very humble with them. You have to let them know that you're going to work together and try to make things better You have no no ability. I mean hopefully it's not your responsibility What their supervisors or superiors tell them to do after you automate their job? But at the very least you need to to cultivate a relationship with them so that you can get through this process and and just hope that There is other work for them in the company that you're freeing them up to do something better Than manually retyping faxes All right, so we're going to interview and really the most important thing to do is to just be quiet To just listen and that's more difficult than it may sound In the end we we are very excited people a lot of us in Drupal We really want to talk about the solution we want to provide we really want to like have this plan of action But we have to remember that this is not the time for us to say those those plans This is our time to absorb. This is our time to take in what they're saying and After we've done that we can form our opinions Always remember if you're telling someone your plan at this stage, you're not listening to what they're telling you right now in that moment You're also going to be very surprised how much the more you hear The more your opinions of what that ultimate solutions are going to be are going to change I do recommend you take notes during all these but even better yet if you can record the conversations and follow up and take notes afterwards If you're if you're not having to look down at a device or even a pen and pencil and paper Then you're you're more freed up to view that body language those those non-verbal cues And you have to make sure you're actually asking the right questions, especially if you've like flown To see these people you don't want to just be asking them yes or no questions You want to be asking questions that make them have to think to make them have to explain to tell you a story You know you didn't fly all the way across for yes or no You have to think of yourself as a detective and you've got to you got to solve this this puzzle this this this case And you need to be looking for clues and you only get clues by making them tell you stories couple questions I like to always ask I mean of course there's whenever they start saying something and you sense that there's more there of course tell me more about that But a couple good ones are like, you know, what do you want at the end of all of this? Or another good one because a lot of you know, especially middle management. They're uneasy about the budget I'll ask them other than money. What does this cost you? Or what is the risk to you if and then propose a couple scenarios and just see how they respond to that You do want to go into these these interviews knowing what you want as an outcome You want to know what you want to have at the end when you walk away But you also want to step back a little bit and think of yourself is more like nudging or guiding the conversation But feel free to let it go wherever they take it More than anything if you have the opportunity have them give you a demo a lot of us go into these Enterprises and we think about how we're gonna demo something switch the mindset. Let them demo what they're already doing That's almost every single time. I have a client walk me through what they're doing today It radically alters my opinion of what I need to build for them tomorrow Bonus points When you do this you see the solution that you have to be better than you know You have to be better than this thing they have now and it gives you a target But more importantly as they walk you through everything It's a great opportunity for them to show you all the pain points for you to basically see it firsthand The things that take them a long time the things that are repetitive These are all opportunities to make their their next solution even better And when you're finished make sure you step back after all the interviews and you take some time to compare notes across them all When many times I go into these large corporations and you find out that one department doesn't even have any idea What the other one has been doing for years even though they work together? recently went to a very large distributor of foods and We talked to three different Branches of the organization and all three departments thought that one of the other three were the ones that actually entered all of their Customers into their their customer database Still to this day. We don't know who actually does It's got to be one of the three, but they all think it's someone else Sorry, we've listened to them and now it's our turn to make some deliverables some things. We're going to hand off My best advice is don't limit yourself out of anyone in your your organization if someone has to be flexible It's going to be you you're taking whatever it is that this client gives you this idea this concept Whatever it may be and you've now got to funnel that down and whittle it to something that your team can can actually make And so you have to have a very diverse tool set Now of course you're going to want to be have some tools that you use frequently you're going to want to get really good at certain ones You're going to want to have certain packages or Plans that you execute repeatedly and you get very efficient at it But when you notice that a client is is different be willing to go and an experiment to try different tools Every client is going to be their own unique Experience and even if they're building something similar to something you've done before Odds are something's going to be different Even down to you know, just communication styles Before we talk about some of the tools we use at metal toad just want to have an awareness or make sure that we we all know that You know, there are these larger architectural planning frameworks out there When I think about architectural planning, I like to think of city planning I Lived in Los Angeles for about ten years. I Lost years of my life driving on those roads Because if you think about it When you've gone through cities that have been very well planned where the infrastructure is very well organized You really notice that compared to cities where that is not the case But when we think of architectural ecosystems, I like to I think this is a great analogy because you've got all these different You know plumbing, you know architecture all these different connections different systems I think it's fairly similar But when we get to talking about these types of systems, I mean you're really going to want to basically opt for for some framework At metal toad we've been using togaf recently, you know the open group architecture framework We've been working with a fairly large client that has been using that for years And it did really improve our means of communicating with their internal teams These types of frameworks each one of them could have a talk here today. So obviously I'm not going to go through them But if you want to do further research, there's great resources online. They pretty much all have training programs and But that's again, not really this is when you're talking more of the larger ERP type systems the very very large Not really what we're talking about here today. So let's go back to talking about more Slightly smaller into our Goldilocks zone again All right so one of the favorite my favorite personal tools on my workbench is Whiteboarding metal toad we have whiteboards and every off every planning room We have whiteboards all the way down the hallways. We have every conference room We love whiteboarding Because again rapid ideation very quick sketches brainstorming If something isn't panning out you just erase it you move on, you know, if you can't draw It doesn't matter the client doesn't ever have to see these the world never has to see these that it's just the process of brainstorming very very low cost of failure Very high probability that you will stumble upon a great idea But whatever you do just make sure you're staying very energized and actively engaging the rest of your team get everyone involved All right, so we've done our interviews. We've done some brainstorming sessions and now it's time to write our script Our script is our user stories Now what you may be thinking is the product owner is supposed to write the user stories That's great in a perfect world But it's not a perfect world. We're agency life and a lot of times our product owners You know, they're not trained They're coming from the client a lot of times and they don't really know what it means to be a great product owner And at the beginning of the project, we usually have to help usher them into it We have to help train them on how to be a product owner. So a lot of times Very often we end up doing a lot of the initial User stories and we do it with the product owner. We work with them and we work from the interviews But but we end up drafting a lot of them It's not perfect world wish it was but but it's not and a lot of times You got to remember that these these large companies if they're coming to an outside vendor They probably don't have a resource available, you know, they're coming to you for a reason They're outsourcing work to you even if they know because they probably have their own teams But for whatever reason that person's either not available or already overworked And so they're counting on you for for many of these things One thing to keep in mind is you write your user stories write them for the audience that's going to read them We played around for a while doing gherkin So we do be had a metal toad and we realized that when we had to get approval from the people in the companies They weren't actually reading the stories because gherkin was still not close enough to English It still seemed a little Nonsensical or whimsical to them and so they would get partially down a few pages and just sort of zone out and not pay attention Well, if they're not actually looking at the stories and approving them and and moving forward Those stories are just for you and that's that's missing the point You want to make sure that whoever needs to read and approve these is going to read and approve them We do a lot of diagrams at metal toad because a lot of times, you know, it's just easier to To say something with pictures than it is with words So this is a lot like our conceptual design where we're talking about a lot of our connections between objects and our methods and properties But the first thing you kind of want to do again also looking at your audience You know, you want to write it you want to make the diagram specific to whoever you're going to have actually viewing them Is it going to be or is this diagram meant for your team during development? Is it meant for the client's it team or is it meant for the the stakeholders? Is it meant for executives? All those are going to require different styles of diagramming with different levels of complexity You certainly don't want to hand an executive a very detailed UML document if it's not the CTO You know if it's the you know the chief marketing officer, they're not going to understand what they're looking at most likely We do a lot of UML, you know, of course the bonus there Unified modeling language of the bonus being that pretty much anyone who's gone through computer science has is familiar with it you know people can read it and Especially if you're handing off to the client's it team, they're going to be able to work work their way through it But also don't be afraid to you know, touch it up make it look a little prettier No one ever really said that you can't Especially if these do need to send this off to some of the other teams We do a lot of process flows these come in handy, especially when we're doing anything that involves workflow You know business system portals We usually do a lot of these it really helps communicate You know the different user roles and how the flow is going to go across those different swim lanes to get to a bottom and End here a lot of times these can be referred to as user journeys We also do a lot of you know system flows user interface flows and decision trees, which are all Loosely similar to this It's great to show the clients it team how you see your system fitting into their existing ecosystem You know, they should be able to see how other systems are going to interact with it And you know basically what you're giving them some context around where you see your solution fitting into their Existing other solutions that they are already maintained The clients it team may also want to know exactly how this new system, but it's going to look like, you know They may have to maintain this thing after you're finished, you know, or Alternatively if they don't once they look at the architecture of the stack if they feel they're not capable of maintaining it They're going to have to have some heads up to to go out and find someone who can whether that be you or some other vendor If you're going to be integrating with their other systems It's probably a really good idea to give the clients it team some very decent details on Exactly what that connection is going to look like they're going to know what ports you want to use how you're going to authenticate How the data is going to flow You want to be able to map this stuff out for them way ahead of time? Keep in mind enterprises are going to move a lot slower than us quick nimble agency folks If they need to open up firewall rules or they need to set up things on their end to enable this integration You want to give them plenty of time and you're going to be able to tell them exactly what they need to do? So moving on to wire frames This is our equivalent of the storyboarding When we break out the wire frames at metal toad hands down we get the best feedback of any of our other tools the highest quality and quantity of comments from our stakeholders Ever hear that a picture is worth a thousand words You can talk to the client till you're blue in the face. You can show them all these are stores you want But as soon as you show them some diagrams they get it they understand it clicks They know what they're going to need to do with this software at that point. They don't have to use their imagination They're not filling in the gaps with their conceptions or potentially misconceptions of how software works You've you've essentially filled in all those gaps How high fidelity you make these can vary it depends on who's seeing them again, and it also of course You know how big is the budget? Do you have time to get detailed on these if you don't that's fine You can do them very rapidly But as long as you're conveying the information and it creates a springboard for further conversations Do you need to be artistic to do these? I'm not going to lie. It certainly helps It certainly helps if you have an artistic background or if you have a lot of user, you know UX experience You know if you've done a lot of UX But even if not, there are some tools out there that can help you. I'm a huge fan of OmniGraphil I like it even there's one reason I like it even better than using Adobe products for wireframing And that's the stencil kit library. You can very easily just drag and drop As fast as you can from the library right on into the page and make high fidelity wireframes incredibly rapidly almost as fast as I can think them up The other nice thing about that stencil kit is it allows you to make custom stencil kits So you can go in and make one. It's actually branded for your company I also do all the diagrams that I did previously that we were looking at I do all those in OmniGraphil as well and all those little icons were from our metal toad stencil kit So an added bonus there is if everyone on your team is using the same tool You can share a stencil kit. You have consistency across all your different team members So proof of concepts So sort of like the the animatic that the animators were doing Sometimes we do have to take all these things together and put them together in a proof of concept a Lot of times you're actually figuring out can your team actually do the thing that you think you're able to do For these we say roughly about 70% confidence is about all you need to achieve You don't want to be 50% sure that you can do this thing because 50% sure means you're taking a 50-50 shot on your team Have to work nights and weekends for there to be pain in their future But of course if you do 100% well, you've probably already built most of the thing so You're almost done So about 70% confidence means you're fairly sure you're going to be able to build this thing You you you're feeling pretty good about it. You're ready to move on but sometimes You don't have to write fully functional software There are instances where you're simply still trying to to prove that the whole concept is a good idea Sometimes clients will come to us. They've had that big crazy idea They we've started to talk about and we've realized what this would actually look like But they still need to you know push it up to their Executives to get approval to get budget and sometimes you just have to convey You know basically what is this thing going to look like for those types of prototypes make sure you time box them Don't spend too much time on it. Don't plan on it being something that's going to move into production my my baby brother is a civil engineer and You know when they go in and they make a prototype You know they're going to make with their they're building like a new bridge You know they're going to build a prototype. It's going to be a little four-foot wide balsa wood bridge They never intend for a truck to drive down this bridge That bridge that balsa wood is never going to go and be a real bridge It serves a very important purpose, but it's temporary by nature and I encourage, you know You know folks in our industry treat prototypes as temporary We do a lot of stuff in envision If you haven't checked it out you can I believe there's a free demo You can do like one project for free. It's really cool. You can upload a lot of photos You can walk through but most importantly the thing I love about envision that you know I love I love doing demos and actual code, but What actual code doesn't give you that envision does is commenting You're you can invite the client and the stakeholders into envision They can browse around in the little mock-ups that you make and they can comment right on top of things and you can actually have conversations as you're going through the the Process of making the wireframes and prototypes Sometimes you just need a little bit more pop You know sometimes you just really got that get to get that project sold So here's a case for a discovery project that we had done this was for a large Fortune 500 company and The end of the discovery project was to actually give a presentation to a whole like a big shark tank style panel of C suites and and directors and So what we really wanted to do when we walked in there Was to to allow them to actually touch it to have it on an iPad that we could pass it around that they could Actually play with a mock-up a prototype of what the system might be You just can't be tactile and so yeah, we went in we did a great presentation We did some had some leave-behinds and it all the stuff, but honestly the the prototype is what sold it You know, that's the thing that that made it happen now The dirty little secret is is that prototype is nothing but HTML CSS and JavaScript We did not put a lot of time into this You know we put more time into the design and the concept than we did into the prototype that was just a Movie prop more than anything documents, so This you know, I know we kind of talked about our script being our user stories, but these are documents are also part of our script So depending on the size and nature of your project you might deliver several other documents You know the most important being the big discovery document And then of course a statement of work because if you've done all this work to plan for a big project You're gonna want to be able to actually say okay now Here's what it's gonna take to build it and here's the basically the contractual agreement In addition to these depending on the situation you might be doing also a pitch deck risk assessment API contracts comparative analysis data migration plans Any dozen of the available? Deliverables that you have in your workbench Our tool of choice for all of these is Google Docs Beyond our team we generally share our documents with our clients. We'd like to have full transparency the entire time We highly value this transparency. We love it when our clients give us comments right down on the side The sooner we know we're going down the wrong path the sooner we can fix it It's a general rule of thumb for documents again. I love taking lessons from other industries like journalism Have any of you ever heard of the inverted pyramid? Inverted pyramid is basically putting the most important stuff at the very top and working your way down to the stuff that if someone's not really Reading it's not very important that they don't see it So one of the very very first things I like to put at the very top of the things that we absolutely need to make sure that Everybody sees the critical stuff the content that you absolutely have to have conveyed to these stakeholders Below that anything that's going to require them to take action again as I was saying they're going to be slower moving than us So give them the heads up as fast as you can on anything you need from them From there the bulk of the actual implementation plan. What are you going to actually do? What does this look like? What are all the topics and then at the very very bottom the stuff? That's really mostly for your team. It might be even be stuff that they all the client already kind of knows So the discovery document, this is the big one. This is the big thing that we deliver You know we whatever we call it changes depending on the client whatever they want to hear we don't care We'll change the title But whatever you call it this acts as the the binder of everything that you found it pulls everything together Definitely keep the audience in mind when you're writing it. Who do you need to read this? Don't use jargon if they're not going to understand jargon if they don't know Drupalisms don't put Drupalisms in it You know or at least you know keep it You know to to a point that they're going to be able to follow When I start on one of these documents I Usually start by writing my outline first at the very beginning of my project I'll do the outline all my I'll start by doing all my h1s and these are usually the biggest questions I have about this project and then within each h1. I'll do some h2s and if I have to do h3s I'll do that too, but usually try not to go down that deep From there I actually use this as my guide as I do my discovery project basically. I'm filling in the blanks I'm asking all the hard questions all the things I didn't know and throughout the course of my discovery project. I'm filling in all the content Does my outline change by the end of the discovery project probably and that's fine That just means you've had insights gained and that's that's perfectly acceptable But it does kind of like set the the whole path of the discovery project Oops, I was supposed to show you that slide first The very next thing I like to show are you know basically some of the links to the other Other things they need to see make sure they know that other stuff exist If you've got other documents some of them may be too large to include in this one like the user stories document Usually that's fairly large or I'll link out to like the envision so they can see the prototypes You know also very important and at the very very top. I like to do the project goals I usually keep these very very simple not even sentences These can be very simple like you know provide an interface for editing their catalog or increase hit rate by improving search results very simple From there I'll usually involve Some of the diagrams usually very basic high-level diagrams not technical This would be something that an executive could look at in one glance and understand what's happening Then I'll do some technical not again probably not the most technical ones that we've got You know a lot of those are going to come a little bit further down in the document But again higher level is someone at a glance even if the IT team is now looking at this at a glance They understand what's going to happen. What are we going to build? What's the stack going to look like? I've kept this all very simple up to this point I've kept it very visual. I've had very few words It's because when the C-suites are looking down through this You want them to be able to get it at a glance you want them to feel comfortable And then you want them to be able to feel like they can move on that they don't have to sit through their next 30-some pages of Document that you're going to have because once this thing gets moving. There's going to be a lot of information in this particular document You know we covered quite a bit of ground and we were looking at various API's we had to integrate We had system security user roles and permissions connections to some other business-to-business portals You know tons of things how they wanted to handle revisioning all that stuff But at the very bottom the very last thing I like to add are some calls to action and it much like the project The basic objectives at the very top very simple not even sentences these could be things like Sign the yes, you know receive and sign you this statement of work So the statement of work Kind of at a glance the way we handle this at metal toad We usually do these are about six to ten page documents depending on the complexity We're going to cover usually the project overview, you know the purpose statement the business objectives Overall the deliverables and like the success criteria. What does it actually mean to succeed in this project? You know and then we'll also be able to look at our timeline and milestones and how many resources we plan to work on this Those two things together are going to help us dictate the scope and the cost We usually define roles and responsibilities, especially if there's another one or more other third parties involved You know where does our work end and where does their work pick up? We talk about how we're going to do quality assurance How we handle our maintenance support and warranty and then one of my favorite sections is actually the assumptions and exclusions This is where you kind of get to draw a nice little safety circle around your project To kind of define where you as far as you're aware according to this contract This is what the project is not going to entail You know a couple good topics to have in there would be you know handling around multilingual You know that that's one that's that's bit us in the past You know and another great one is you know just down to what level of Internet Explorer are you willing to suffer? But at the very bottom, you know, we go through some of our boilerplate We go through the terms and agreements, you know, maybe some there's some other key features specific to this project And then of course at the very bottom is the signature I mean this is where they sign off and you do your big project. All right, so we've delivered everything It's time to hand it off to the client Wait, that doesn't Make sense The end of discovery project. There should be no surprises Ideally you've had the client in there fully transparent the entire time, you know, they like I was showing you earlier on the Google Docs They've been commenting they've been making, you know, it's been fully transparent So the handoff really should be fairly informal. There should be no surprises had not even in the SOW They should already know about what budget, you know, because they've been in there looking at the dock Maybe not the executives or the C suites, but at least the directors you're working with So guess the big reveal is not for us We don't want to you know walk by and be like here's our master plan last thing we wouldn't have happened as them Say that's totally off the mark. So all right time to celebrate You've given them your your You know your your discovery document your SOW and they signed they're ready to come in and do the big project But your work isn't done you still have to work with your team So turn around and look at all of your team and you've got to be able to set them up for success Make sure you share everything with them everything you did during your findings, you know all the documents everything you've got Make sure you walk them through with those documents and that they understand everything and they know where the important stuff is I share my whole Google Drive directory with my team and You need to make sure that they're they're not lost in the weeds that they know where the important stuff is located If you happen to have known that the project was looking like it was going to be to go through Start to involve the team early bring them in on the discovery have them sit on some of the interviews and some of the meetings That way they're already partially informed because in the end when all this is said and done if your job like in my role I'm a consultant. I'm not going to be a developer on the project You know, I'm going to phase out as they start to actually build this project and as I phase out I've got to transition all that knowledge. I've got to transition the ownership and more importantly. I've got to transition the energy Because that entire discovery project you've been up on a stage and everyone's been looking at you from the client They've been talking to you. They're used to talking to you They're giving you all their questions and now you're going to phase out and you're going to walk away If you don't have someone else from the the actual development team carry that energy Then they're going to keep coming back to you their clients going to keep wanting to talk to you about things And that's fine to an degree, but you might have other work to do like in my role I've got to move on to the next discovery project So it's very important that you identify, you know a project lead or a senior developer You know someone who's ideally got experience working with clients that they're going to step up and be That representation of your company with this client Maybe it's a project manager Just just someone who's going to be willing to carry that and you're going to have some frequent check-ins You're going to remember that you planned this project You you were there for the form formulation of what was going to be executed So you have to be your team's compass you have to make sure that they're following the true north that the client Wants to head towards that they've they've got the right idea and continue on that path so show up at some of the sprint planning sessions show up at the demos and Certainly show up at the retros and just make sure that everybody is is still continuing in the right direction So that seemed like a lot of work, but was it actually worth it? first off let's go back and Back to reality all that stuff. I talked about you're probably not going to do all of it for every discovery project Most discovery projects are going to be fairly small I mean a lot of the stuff I walk through that like that 30-page document that was for one of those You know multiple weeks small almost a month-long discoveries, so there was a lot more work to that You know depending on the budget and the size of the project that's going to dictate how long you actually spend on these things But was it actually worth it? That's a very hard question to answer because frankly you Don't know how many icebergs the ship did not hit You didn't waste an entire sprint building something that wasn't necessary And you knew about that crazy integration to some custom built system that they had before you started development So you planned for it, so whether or not it's worth it is very hard to gauge But it's a safe bet that you're doing things right if You see a sharp decline in project escalations pre-launch blockers Change orders and developer face-palming The client trusts you and feels that you have a rich understanding of their business goals Your internal champion within the client gets a promotion a Stakeholder buys you a beer Remember these are the people that were afraid nervous when you first walked in if you've taken the relationship to a Point where they're willing to buy you a beer You've worked some magic And most importantly you're definitely doing it right if the client becomes a partner Thank you very much So I'd open up for any QA if anyone has any questions or I Think if you could use the mic because I believe they record so the the mic will actually go through Hi a lot. That's a lot of what you said really rings true for me One of the questions I have is around when you're doing User research is a huge part of your discovery process one of the difficulties I've had selling this in is that you know in your heart when you get a request from a client and They don't understand their users what they have asked for is totally stupid And you're going to have to go in there and say in the most polite terms possible When this touches an actual user you all of your assumptions in this document are going to change radically There's no point me pitching for what you've got now. So what I'd like to Hear if you've had any experience of that kind of pitch where you're going to have to radically alter what they're What their business goals are what their assumptions are with users? Absolutely, and you're right. That is a huge challenge and it does come up very frequently a great example I have of this just happened recently where I'm working with a fairly new client and we're doing one system for them, but then we started talking about this other one and To put it in perspective, you know, they're gonna a lot of times these stakeholders and the clients They're gonna stick with what they know and in this case they knew FileMaker 4 And so they were they've been spending the last three years building this system based on FileMaker 4 And when you put that in perspective FileMaker 4 came out in I think 1997 But it's what they know and so you're in that case it was a terrible idea and that's what they thought that their users were gonna want to use it was an internal tool and they had a lot of users internal to the company and You're right. It was a delicate situation because I knew it was just a terrible terrible terrible terrible idea And it's like how do you communicate that and you know the first thing? I think you got to do is you've got to you got to be somewhat humble and you can't just shoot them down because they've Been working very hard or they've it's their idea and they cherish it and you have to be sensitive to that you have to have empathy and You got to get them to explain certain things about that and maybe as you start to have them explain ask questions Not necessarily pointed but directional that get them to kind of start to admit some of the potential downfalls And if they can see those holes themselves if they if they even steer the direction towards them saying Some of those holes in their plan out of their own mouths You know a lot of times that's gonna go a long way and then once they've kind of started to to question things You know a lot of times it's I find it very useful to start to discuss well Have you thought about these other solutions? Have you checked this out? You know and start to like feed them? better ideas and Ideally if you do it right, they almost think it's their idea to switch it up to this other thing It's not really manipulation Parse Because you're actually helping them you're helping steer them towards you're steering them towards a better solution But yes, it's incredibly challenging Very sensitive any other questions all right guess we're all set. Thank you all very much