 Hello. All right, welcome to this session on discovery projects. My name is Tom. I'm a senior technology consultant with metal toad up in Portland, Oregon. Originally got sucked into the internet way back in the mid 90s. Spent a little bit of time as an animator. And then I found my way back to the web via e-commerce while I was living right here in Los Angeles. At some point, had 2.5 kids, including the pug. Moved up to Portland, learned a whole lot about business. And at some point, I woke up one morning in a Drupal shop, been there ever since. So a little bit about this session. We've been experiencing this phenomenon at metal toad the last couple of years, where we've got a lot of big clients coming to us with some very exciting ideas. But they haven't necessarily been able to figure out how to make them a tangible project. And as a result, we've been doing a lot of these little discovery projects. We've learned a whole lot along the way. And I came here today hoping that I can share some of these lessons that we've learned with you folks. So as you leave DrupalCon and go back out into the real world, you can take these with you back to your companies. So what exactly is a discovery project? What are we talking about here? Discovery project is a small project that the whole purpose is to define the big project. It's planning. It's defining the goals. It's requirements gathering. It's plotting out a roadmap for the project. Nearing down your estimates, actually figuring out the scope. And it's creating an alignment between all the project stakeholders. It's also a great opportunity for trust building in both directions between you and the client. Raise your hands if you've ever done any of these activities before. Yeah, pretty much everybody. I'm not inventing anything new here. All I'm doing is wrapping it up into a process. Or actually, more applicably, it's a service that you can provide. So just who are the customers out there that could really use this service? There's a little bit of a spectrum. One end is your standard website. Think of this as a brochure where this could be a nice restaurant downtown or a ski resort. Planning here, it's going to be relatively minimal. Visitor interaction is not going to be overly involved. And given that this is a marketing vehicle, it's pretty good odds that most of the projects are going to be dictated by the design comms. So discovery here might be a little bit of overkill. On the other end, we have these full blown ERP systems, these monolithic, heavy lifting systems that large corporations have. Think of Starbucks. Think of how they have to operate on an international scale, not just point of sales, but even getting into business intelligence, human resourcing, supply chain. Those systems are a little bit bigger than what we're talking about here today. Those are going to typically have some form of prescribed framework for requirements gathering. Back in the 90s, I got to witness this beautiful thing. I saw the disciplines of design and computer science make a baby. And that baby is us, the web industry. Today, we're kind of in the middle of another one of these mergings. Or maybe it's just a little bit of a refinement between the web industry and the software engineers. Maybe the web's just kind of leaning back a little bit towards the software side of its heritage. More and more companies are taking their systems and their data up into the cloud. As a result, the bar of what constitutes a web project just continues to go up and up. As this complexity grows, with a metal toad and a lot of our similar agencies, we're having more of a need to dive deeper into what exactly is this project that we're building. So when I talk about a discovery project, they're gonna be larger. They're gonna have a lot of interaction. We're talking about things like a portal for customers of an insurance agency so that they can go in and find out the healthcare provider. Or an online system that allows the employees of a company to process thousands of requests each day with a nice workflow process before the data goes into the ERP system. So we're not talking about the relatively easy projects. We're also not talking about taking on the ERP systems directly. What we're talking about is the Goldilocks zone in between the two. All right, so we know we need to do some planning. Well, as I said, I spent some time in animation and I absolutely love taking lessons from other industries. We're still a relatively young industry in the grand scheme of things. We have matured a lot in recent years, but I still think there's some very valuable, hard-learned lessons from other mediums out there that we can still take a lot of inspiration from. So let me ask you this. Imagine if a studio full of animators just went in and started animating on day one of the production. No planning at all. They just sat down. It started just straight into the animation process. Fire up the render farm. They too, they've already got some footage piling up. How would that movie play out? Do you think the audience is gonna be into that movie? More importantly, do you think that studio is gonna be around to make a sequel? They never just start animating. Why? Because just to do three seconds of animation footage takes a tremendous amount of effort, timeline, budget. Frankly, they can't afford to get it wrong. As such, their industry has kind of made planning a required part of their craft. One of my favorite quotes that my animation professor always used to say, if I had three days to animate a scene, I'd take two days to plan and one day to animate it. Eric Larson, one of the brilliant nine old men, Disney Animations Golden Years. This is really just another way to say a proverb that you've heard many times in many different ways. Abe Lincoln said it as, if I had six hours to chop down a tree, I'd spend four of them sharpening the ax. And it's really just the old carpentry phrase, measure twice, cut once. So how do they plan an animation? First, they draft a script. The story is the core of a movie and nothing's gonna move forward until they've figured out the plot. It wasn't the ray tracing algorithm that made you all misty-eyed at the end of Toy Story 3. It was the characters and the situations that were developed through the story. The next thing they do in animation is conceptual design. They developed the characters, the layouts, color palettes, locations, backgrounds. They start figuring out all the objects and the methods by which these objects interact with one another. And then storyboarding. This is where most of the magic happens. These quick sketches allow for rapid ideation and budget-friendly experimentation. If something isn't working, they can change it, early, quickly, with minimal disruption to production. Once they have the storyboards, they create an animatic by dropping these boards into a timeline and setting them to an audio track. At this stage, they know how long the movie will be, what scenes work, and most critically, which ones need to be reworked. This is all before they start investing, not just in animators, but also lighting artists, texture artists, rigors, modelers, and firing up that render farm. They wanna vet the story and how it's gonna flow, not just internally, but even with test audiences. So before they even start animating, they have an extremely high level of confidence that the movie's going to be as successful. Over 100 years of grueling work has taught animators to plan in order to avoid costly failures later in production. So what are some of the things that we can do? What is the equivalent in our industry? User stories, tech specs, wireframes, flowcharts, IA, UX, prototypes, all these things you've heard before. So what is the discovery process? It's our script, it's our conceptual design. It's our storyboards, it's our animatics. It's our planning to ensure that the audience is gonna like the big project. Let's just take a couple brief, or just a brief moment to look at a couple more reasons why we do this. For me personally, most of this boils down to one major goal, narrowing the cone of uncertainty. When you walk into a project, especially with a new client, the number of unknown variables can be daunting. You need to get to a point where you and your team have a certain level of understanding of what you're about to embark on. Do you still need this if you're doing agile? It's probably still not a bad idea. In agile, we're inherently assuming that we're gonna know more as we go. At the end of the project, we'll actually be the most informed to make the big decisions. So why not give yourself at least a little head start on that knowledge? I mean, the earlier you can have more information on those big decisions, frankly, the better. Plus, agile rarely is perfect once you introduce an outside party. No matter how much your team's on board, once you bring in an enterprise, custom to all of their waterfall gant charts, all of a sudden, agile's gonna get a little bit trickier. So even in agile, it's not a bad idea to at least make sure everyone's on the same page, that there are some clear goals and requirements. And at a very zoomed out level, you have at least some idea of what success criteria is gonna be for this project. And then of course, waterfall. You wanna narrow that cone as much as you possibly can. You wanna try to make sure your team's not gonna get any surprises along the way. But realistically, where that transition between discovery and development happens will vary for both agile and waterfall and wind up somewhere in the middle. What's important is that you and the client both feel confident moving forward. You also wanna define some boundaries. Even with agile, you wanna at least be able to tackle some logistics around estimated numbers of sprints and the number of resources you're gonna dedicate to the project. If you wanna be able to do any forecasting on your pipeline, plan for future projects, you have to have some expectation of when those developers are gonna get freed up again. And of course with waterfall, you're just back to committing to and attempting to lock down the old iron triangle of scope, cost, and time. Okay, I know what some of you might be thinking. This is all fine and dandy, but we've got a company to run. You know, we gotta get paid. And this does seem like a lot of work. And it is. Or at least it can be. But always remember that the word project is in Discovery Project. And that's exactly how you should pitch it to your clients. This is absolutely billable. If they don't like the sound of Discovery Project, you know, try calling it by a name their procurement department might be a little more familiar with, consultation. When proposing Discovery, as a general rule, we try to estimate about three to 10% of what we think the big project's gonna be. That usually makes up about where we need to be. And really the variation just comes down to how much R&D we think we're gonna have to do in order to get a high level of confidence. This can be a little bit of the chicken before the egg since you know, at this point, Discovery might be one of the major goals is to define the scope and the overall size of the big project. If that's the case, just go ahead and estimate the Discovery the same way you would any other project. But in my experience, believe it or not, the Discovery process can be a relatively easy sell to large corporations. You have a few key advantages you can leverage when you're pitching these projects. They love planning and documentation. They love narrowing down those estimate ranges and they absolutely love minimizing risk. From their standpoint, the Discovery project is a relatively low risk and low cost investment. The whole point of it's just to elevate the odds of success of their big initiative. It's sort of like taking out an insurance policy on their own success. To that end, I mean, even C-sweets are people too. They're doing a job just like you and I and they also like having confidence in the decisions that they make. Another important thing to note is that this process can't scale a bit. It doesn't have to be epic in proportion. On a recent, relatively small project, we knew that a full-blown Discovery was not possible. But it was a local client. So my fellow consultant, Alex and I, we hopped in the car, we drove across the river and we hung out with their team for half a day. And we met their team, we got to see their space, we got to hang out in the little wooden cabin that their president built in the middle of their office. We even got to pet the giant taxidermy beaver that they smuggled out of White and Kennedy. And then they personally walked us through their current processes and all their software. Afterwards, they made us some phenomenal French pressed coffee and we did this all free of charge. Actually, I kind of felt like I owed them a little bit for the coffee. But why did we do this for free? Because we knew that spending that upfront time was gonna pay off in spades when we got around to coding. Plus, more importantly, we started forming some great professional relationships with some folks we'll probably be working with for years to come. All right, enough with the what and the why, let's get to the how. Before we can even write our script, we have to know what we're talking about. So step one, it's time to do a little reconnaissance. We got some interviews to do. Before we go too deep, we have to accept our own limitations. We can't let ourselves be our own boundaries to making the right digital decisions. We need to be aware of our own domain knowledge and more importantly, where it stops. We need to know when to pull in some stakeholders to interview so that we can supplement our own knowledge. Because while we may know software better than the average person on the street, they know their jobs. They know how to do their jobs and they know all the gotchas of their jobs better than we could ever hope to. If we ever wanna make something magical, you've gotta meet somewhere in the middle. Before we run out and just interview anyone that'll talk to us, let's apply a little strategy behind who we reach out to. The folks that are funding the project they're kind of a given. They're paying for it. They're gonna wanna talk to you and you're gonna wanna talk to them and make them feel comfortable. You're also gonna wanna talk to the directors and the management that are ultimately gonna inherit and be accountable for this solution that you're building. But while C-Suite's directors and management are all great, do they actually use the software? You need to talk to the people that are behind the people. You need to find the people that do the day-to-day operations today and don't expect to find them all in the first pass. As you interview people, ask yourself, does it feel like there's another person behind this person I'm talking to? It never hurts to ask. In an increasingly global world, you're lucky if your clients are even in the same time zone as you. So how do you go about conducting interviews? I'm a huge fan of body language. The number may vary but 55% of communication being through body language sounds about right to me. If you can be there in person, an added bonus of being there is it's almost guaranteed that you're gonna have non-business related conversations before and after these interviews. Even as highly introverted as I am, this is always the case. I like to think that this is analogous to college students. The ones that chose to live on campus versus the ones that live with their parents and commuted in from the suburbs. Which one of those two groups made the longest lasting most solid friendships during those years? Of course, it was the ones that weren't just there for class. So if you can't be there in person, at the very least try to do a video conference. But never ever email. Email lacks the most basic of intonation. It's cold, it's heartless. It sends a message to them that you care about their opinion the minimum amount, maybe less. Before we start firing off questions, keep in mind that you're dealing with people here. People are tribal, territorial. Sometimes they fear outsiders. Doesn't help that a lot of them have probably had tainted experiences with vendors in the past. Process automation, replacing jobs as software. That is a very tangible threat in corporate America. I've gone into a company before that had a team of eight employees where their entire job was to manually retype content from a website form into an Excel spreadsheet. Do you think they were happy to see me? Do you think they really wanted to, you know, sit there and talk to me with their kids, their mortgages, their car payments? Were they excited to hear what I was there to talk about? Of course not. And while this largely falls outside of your responsibility, you know, the best you can do is hope that their supervisors have some plan to task them with some more meaningful work afterwards. But even if they've got job security, they may feel a little bit powerless. You know, they were there doing their job, that they knew how to do with tools, they knew how to use, and all of a sudden their boss comes in, introduces someone out of nowhere who's gonna completely change how they do their day to day. Whether you want to or not, you're gonna represent that change. So what do you do? You gotta make them feel included. You have to make them feel like they're coming along on this grand journey with you, your team, their boss, and their company. You have to be humble, and you have to reinforce how much you need them. You and them, you're gonna be a team. And it's really only with their knowledge combined with your tech skills combined that together you're gonna be able to make their jobs a little bit easier and a little bit less frustrating than they are today. All right, that's interview. The most important thing we need to do is be quiet. Let them do most of the talking, especially at first. You wanna prompt and nudge the direction of the conversation, but right now it's about you absorbing knowledge from them. You wanna go into it knowing what you wanna get out of this interview, but don't lose sight of the fact that this is your opportunity to hear their half of that Venn diagram we were looking at. Take notes, better yet, record the interview and take the notes based on the recording afterwards. This is gonna allow you to maintain direct eye contact the entire time. It's also gonna let you free up a little bit to look for those nonverbal cues. Never be so excited to tell them about your grand ideas. If you're thinking about your solution, you're not listening to what they're telling you right now. Remember the keynote yesterday, being in the present. You'll be shocked how frequently your ideas are gonna shift throughout the course of your chat. So wait until you have all the facts before you voice your thoughts. But you do have to have questions and the right questions. You didn't fly all the way out there to get binary yes, no answers. You're also not a Scantron machine looking for multiple choice questions. You're Sherlock and you've got a mystery and you've got a long trail of clues you gotta follow. Ask open-ended questions where the response requires some form of explanation. When you sense that you're only hearing part of the story or you smell more information lurking behind that last sentence, ask, tell me a little bit more about that. Find out their deeper motivations. Ask questions like, what do you want at the end of all of this? Or other than money, what is this costing you? What's at risk for you if, and when possible, I like to have them lock me through their current processes. Nothing beats putting the stakeholder behind the keys of the current software. No matter what questions I had going in, this will reroute the rest of the entire conversation. Bonus, seeing what they have today gives you a target. It shows you exactly what your solution needs to be significantly better than. Have them explain to you any parts of the process that they find tedious, repetitious, or unnecessary? Likely those are gonna be great opportunities for you to pitch some automation. But also, find out what they like. Just by keeping the good and ditching the bad, you've already given your solution a significant advantage. And this is a place to ask why. It's not uncommon for large corporations that when you ask them why they do a certain process, that they don't even remember why. Who knows, maybe that requirement isn't quite as required as everybody thought it was. When you're finished with the interviews, take a step back, take it all in, try to assess which themes and stories came up repeatedly. Use this to help inform, in your perception of the client's true priorities beyond the ones that they mentioned. Make sure that the right hand actually does know what the left's been doing all these years. My fellow consultant Kevin and I, we were just on a series of interviews with a large client. We had three different groups on the phone. All three groups thought that one of the other groups were the ones that actually entered the customers into the ERP system. Still to this moment, we're still trying to get an answer as to who actually enters the data. All right, now we know the other side of the story. We've listened, we've heard them. Now it's our turn to create some artifacts that we're gonna deliver at the end of this whole process. My best advice, don't limit yourself. Maintain a robust workbench full of tools. If anyone in your company needs to paint outside the lines during the project lifestyle cycle, it's gonna be you. The big part of what you're doing is reining in this big, ominous idea. Inherently, that means that you need to be a little bit more flexible than the rest of your team. So you've gotta take whatever comes at you and funnel it down to something your team can digest. You absolutely wanna have your go-to tools and you do wanna get efficient at using them. And of course, you wanna have a few sets of standard packages that you offer, patterns and frameworks that you come back to time and time again, you'd be foolish not to. But you have to remember that every client's gonna be its own little special snowflake. They're all gonna have their own communication styles, learning styles, and even if you're providing them a solution that you've done multiple times in the past, they're probably gonna have their own little unique spin on it. So to accommodate for this, you gotta have a lot of tools that you keep handy on your workbench. It's not every day that you need that metric hex wrench, but if a European car comes by, you're gonna need it. So what does metal toad keep on its workbench? Well, before we look at individual tools, let's take a quick detour into the enterprise. When thinking about the enterprises, I really like the urban planning analogy. When you zoom out and you look at the ecosystems of an enterprise, you have all these complex systems connected by all this infrastructure and plumbing. Gosh, can't you just really tell the difference when you drive through a city that has had really good urban planning versus, and then one that hasn't? I lived here in LA for about a decade. I lost years of my life on the five. My favorite part, personally, I love where the six lanes just bottle next down to two. That's my favorite part. That's just right outside of downtown. So to address the equivalent of urban planning in the realm of software, several architectural frameworks have been developed. These are specifically created to combat issues around system complexity and poor business alignment. Now these are 100% complete answers. They all have some strengths and weaknesses, but what they do is provide an established and standardized outline to follow while plotting out your solution and how it's gonna fit within the larger ecosystem. Each of these could have their own session here today. If you're interested in using one, I do recommend following up with some online research. They pretty much all offer some form of training and certification program. We've been working with Togaf recently. One of our larger clients has been using this framework for years, and we have found that adopting it has provided a common language between us and them. While I'm a huge fan of these frameworks, they're definitely more applicable to the larger projects outside of our Discovery Projects Goldilocks zone. So for this talk, let's assume we're doing our Discovery a little bit more ad hoc. All right, so we're back in our Goldilocks zone. We have Discovery to do. Where do we start? With one of my favorite tools in my workbench, whiteboarding. It's the workhorse of all of our tools. It's the most widely used and cherished weapon in our arsenal. MetalToot has whiteboards in every single meeting room. We even have giant whiteboard walls all the way down most of the hallways. So why? Whiteboards equal rapid ideation. This is an extremely low cost of failure endeavor, paired with a remarkably high likelihood that you're gonna stumble backwards over a fantastic idea. Ideas in panning out? Erase it, start over. Can't draw? Don't care. These are doodles. You know, the outside world's never gonna see them, and this is just, it's the brainstorming process that's important. Just make sure you come into it with a lot of energy. That's what's gonna keep everybody actively engaged. Once we've done our interviews and some brainstorming sessions, we need to write our script. I know what you might be thinking, user stories, that's the product owner's job. Well, sometimes we are the product owner, or at least assisting the product owner with these stories. Not all companies have a product owner available, and if they're reaching out to a vendor, there's a decent likelihood that they don't have anyone on staff that's suitable. Or that person that they do have is already too busy, essentially. For example, I recently did a discovery for a company, and in their 30 years of being in business, they had never had to deal with e-commerce. So they brought me in as a consultant, partially because of my time that I spent in that domain. And while I was able to base about 60% of all the user stories through my interviews and through working with their product owner, they were literally paying me to provide the other 40%. So when writing your user stories, you'd be mindful of your audience. One of the most important things is knowing who you need to sign off on these stories. You want to write them for that audience. The true value is going to come from getting everyone on the same page. That's simply not going to happen if the stakeholders aren't going to read them or understand them and take the time to agree on these epics and stories. Sometimes, some things are really hard to describe with just words. Creating diagrams can help us to find the pieces of the project. It's a lot like the animation conceptual design phase. We need to figure out our characters. We got to figure out our objects and the methods by which they interact with one another. There are many different common types of diagrams and standards out there, more than we can cover in this talk. Before I go over a couple that we use commonly, there are a few general guidelines we apply. The first thing you need to do is figure out who the viewers of the diagram or various diagrams are going to be. You're going to want to tailor to that audience. Are they your developers? Are they the client's IT team? Are they stakeholders or are they executives? Let that dictate how much detail and what level of annotations that you provide. Also, a good idea is to have a nice branded stencil kit full of icons and elements that are all in the brand of your company. It can take a little bit of investment time up front to come up with this, but it's going to pay off in the long run when you and other members of your team can all crank out these high quality and consistent diagrams. First off, UML, unified modeling language. Main benefit is it's a standard. Pretty much anyone who's gone through a CS program has been exposed to this. It's great for showing the connections between objects for the development savvy. But you know what, don't be afraid to make it a little bit more visually appealing if you think that's going to help with the target audience. Process flows, these come in handy in doing anything with lots of interaction or a workflow process. Pretty much any business system portals that we do have one to several of these. These help the team gain a shared understanding of how the interactions will cross over the user role swim lanes, getting all the way down to the bottom in desired output. Some of these we also do a lot of system flows, user interface flows and decision trees. It's great to show the clients IT team how you see your system fitting in with their existing ecosystem. They should be able to see any systems that are going to interact with your new system and when necessary, add some additional information and context in the annotations. The clients IT team may also want to know exactly what the new system is going to look like, especially if they're going to have to maintain it moving forward into the future. They may be particularly interested in this if you're introducing their company to a new stack. This recently happened to us, we were working with a company that was primarily all Microsoft, all.net and as part of their initiative, they wanted to start to bring in more lampstack and that's what we did. So of course they were very interested in what that was going to look like. This also kind of helps them to evaluate do they actually have the adequate internal resources to maintain this system or is that after launch are they going to have to find someone to outsource that to? If your solution is going to utilize or push data to any of their existing systems, you should map those out through integration maps. You should address system connectivity, reports, authentication and data flow. The pull of the cloud on enterprises is very strong right now. As a result, many of their IT teams, well they're facing the threat of their sensitive business data and their systems living up in the cloud outside of their four walls for the first time. They're a little apprehensive about this. So the least we can do is outline what this is going to look like, try to ease their worries a little bit. And my favorite, Wireframes. I love these. They absolutely resemble the storyboarding process from the animators. This is our storyboarding. When we break out the Wireframes, we get the highest quality and quantity of stakeholder feedback. Why? Ever hear the pictures worth a thousand words? This requires hardly any imagination on behalf of the stakeholder. You're no longer counting on them filling in all of the gaps with their conceptions and potentially misconceptions of how software works. They can see it. They can see what they need to do with it and how they're gonna be able to do their jobs. It's all gonna just click once they can see it. Fidelity is definitely a dial you can turn depending on the budget, the timeline. High fidelity, it's awesome. It can almost act like a tech spec. But if all you have time for is low fidelity, as long as you've conveyed the idea, that's really all that matters. The very least you're providing a springboard for further conversations. If the functionality needs to be different, find out now. You're dealing with pixels, not programming. It's gonna be a lot easier to move things around. Do you need to be artistically minded in order to have a background in design in order to do these? I'm not gonna BS you, it definitely helps. But there are some tools that can help compensate if you're not. For Wireframes, I'm personally a huge fan of Omnigraphl. For me, the Stencil Library is what makes it more appealing than Adobe products. I can go in, set up my grid, turn on Snap to Grid, and just start dragging and dropping all these different Stencils all day long. I can have these high quality Wireframes and just about as fast as I can think them up. You can make your own Stencil kits, follow your company's branding guidelines, or you can download more from graphletopia.com. This is also the same tool I used for all those diagrams that we were looking at. It has some great tools for adding magnets all along the edges of the Stencil elements. You can create a lot of arrow tools for connecting them. Just like we had in all those UML and process flows. So the animators take their storyboards and they turn them into an animatic. So what can we do that's the equivalent of that? Well, we can use our tools to bring the Wireframes to life or we can whip out some quick prototypes to test out our theories. Sometimes a prototype truly does need to be a proof of concept against some real code. Can our team actually build the thing we're saying we think we can maybe build? For those, roughly 70% confidence is gonna be good enough. I mean, after all, 50% and then there's like a 50-50 shot and you're flipping a coin on whether or not your team's gonna have some long nights and weekends coming up. 100% confidence means you've already kind of built the damn thing. But somewhere in between the two is where you wanna be. About 70%. But sometimes it doesn't have to be fully functional software. Sometimes it just needs to convey the idea. It has to show the vision. It has to prove that the big project is truly worth the company investing their resources in. Food for thought, personal opinion, prototypes are temporary, so time box them. My baby brother is a civil engineer outside of Baltimore. You know, when they go to build a bridge, they make a prototype. Generally, these prototypes are about four feet wide. They never intend for a semi truck to drive down this four-foot balsa wood bridge. It's a prototype. It serves a great purpose, but that purpose is inherently fleeting. One route we take, we use wireframes to make our equivalent of an animatic. We favor the online tool Envision, Envisionapp.com. This tool allows us to upload images typically through a convenient little widget tool you can install right on your local. And then using their drop dead simple hot spotting feature here, you essentially just go in, you drag and drop, you make some little clickable and hoverable areas. You can save them to a template. And then the one feature that in my opinion gives this tool an edge over prototyping and code is the commenting. So you can share this project with the stakeholders and get their direct feedback right on top of the parts they're talking about. This leaves zero confusion around context. And you can also reply back. So you can have full conversations as you make your revisions. But sometimes you just need a little more pop. You know, maybe the funding for the big project hasn't been completely secured yet. And sometimes you just have to make that idea feel real. You know, here's a case where the discovery still needed to get the big project past a Shark Tank style panel of C-Sweets and Directors for a Fortune 500 company. This case, we wanted to make them able to feel it. And literally, I wanted them to be able to touch this idea. So we put together a little design and we set out to create a prototype that we could actually put on an iPad, something that someone could hold in their hands and touch. We did do a presentation. My colleague, Nick Proctor, I mean, he knocked the presentation out of the ballpark. You know, we provided various documents and leave behinds, including a video bumper, but nothing beats tactile. Now for a dirty little secret. This prototype was a movie prop, literally. It was the equivalent of cardboard with a good paint job. It was HTML, CSS, and just a little bit of JavaScript. This prototype and the video, these were all just made in a handful of days. If your goal was to communicate the idea, put the bulk of your energy into the idea, shift all your priorities around that. Never let the prototyping tools get in your way. I mean, they really should not be the bulk of your effort. You shouldn't be learning something new when you're prototyping, unless it's a proof of concept. So try to use things and techniques that you've already mastered. And just, you know, remember, the big project's where you're gonna build it for real. If you're just conveying an idea right now, no one's gonna care what you built the prototype in. Then there's documents. I know we already talked about the script, but this is where we talk about all the research, and we kind of pull it all together. Depending on the size and nature of your discovery, what you deliver, there may be several documents or artifacts, it's all gonna depend on the topic. The two most important though are gonna be the all-encompassing discovery document. It has kind of like your index of everything. As well as your SOW, your statement of work. The actual contract for the big project that you've been looking at. In addition to these, depending on the situation, you may provide a pitch deck, risk assessment, API contracts, comparative analysis, data migration plans, or any of the dozens of other available artifacts that come off of your workbench. Our tool of choice for these has been Google Docs. What it lacks in functionality it makes up for being up in the cloud, being some great functionality around being shareable, and having the ability to start up comment threads right around selected text. Beyond our team, we generally share our documents with our clients and give them permission to comment. We do this fairly early on. We highly value transparency throughout this entire process, and we encourage our clients to comment back and forth with us as we create the documents. The sooner we find out we're going down the wrong path, the less of our time we've wasted, the less of the client's time and budget we've wasted. Few rules of thumb for all documents that I apply. So when I was in high school, I used to run the school paper, back when they actually used to print it on that stuff made out of wood pulp. And that's where I came to cherish the old inverted pyramid. In journalism, this is the prioritization of information from the most important down to the least. It's how they structure their headlines and their articles so that if someone's just going to kind of skim over the page, they can get at least the gist of the most critical information. So how do I adapt the inverted pyramid to our documents? Well, I always start out with the most relevant, critical and high level content that you need to convey. The big messages. Then outlining any dependencies we need from them. Make that very high up in the document. Make sure they see it. Then the bulk of the implementation plan. You know, just most of the actual meat of what you're going to do. Followed up by the content that's really just for our team. If they already know about it, push it to the bottom. So the discovery document. The big gun, the whole enchilada. Even the name changes depending on who we're talking to. Discovery document, technical discovery, technology, specification, whatever. Whatever you call it. It binds all your findings together and acts as an index to all the artifacts. Keep the audience in mind when you're setting the voice and whatever you do. Don't use jargon just for the sake of using jargon. I start by doing an outline. A lot like my newspaper headlines. You know, personally I treat this document as my, well it's actually the documentation of my thought process. You know, I take my biggest questions I have about this project and those become my H1s. From there I break these down into H2s and if necessary, another layer into H3s. It's really not that much different than how a writer approaches outlining a book. So I do my first pass of this outline very early on. As I mentioned, pretty much at the very beginning of the discovery process. And then as I work, I just fill in all the blanks. Sometimes the outline is gonna get adjusted. That's fine. That just means that a little bit of insight's been gained. The tippy top of the old document should state the project goals and requirements. Keep it simple, keep it short, plain English. Everyone on the project needs to have a crystal clear understanding of the goals. These don't even have to be sentences. For example, provide an interface for editing a catalog or increase hit rate by improving search results. Then I like to link to all other major supporting documents right after the goals. Just so that everybody knows that they exist, that they're out there and it's something they should look over. Next it's great to get some very simple diagrams that illustrate the overall goals and purpose of the project. In this case showing the before and after of an automation process. Then we typically include some higher level ecosystem, architecture and process flows. And note that so far, everything I've been showing you has been fairly visual. Not a lot of text here. Without even reading, a C-suite could go in here and get the gist of the project already at this point. I've done this very intentionally. Why? Well going back to animation, one of my favorite lines from The Simpsons sums up why I'm making it easy for decision makers. I was elected to lead, not to read. And with that we can let these folks go. You know I joke here, but their time truly is valuable. They're very expensive people to have in your meeting. So that's effectively and efficiently get them that high level information as soon as we can that's make them feel comfortable. It's allow them to get back to the more important tasks they have every day. The first big block of texts we tend to include is addressing what we need from them. Most large corporations move a little bit slower than us, fast and nimble agency folk. Give them a good runway, give them a good heads up. Also I tend to include a lot of risk assessment type topics in here. You know there's elephants in the room, get a spotlight on them, that's start clearing them out as soon as we can. You know a great example of that would be if you have some serious concerns about an API that they're going to build that you're 100% dependent on, highlight it now. Also don't be afraid to recommend holding them accountable using some tools like Runscope. So there's about 30 pages of our findings. In this doc we're looking at system security, user roles, permissions, integration to their data warehouse, system and data dependencies, a B2B, poor old integration, and revisioning just to summarize a few high notes. Note that the current systems glossary is all the way at the bottom. They already know what they have, that's just for our team. But though at the very end I like to do a very clear and concise call to action with next steps. These are not even sentences. For example, review and approve SOW. Then schedule kickoff meeting. All right, statement of work. The actual contract for the project that you've been doing all this work to define. Now I can't show you this too in depth given that these are actual signed contracts, but for us these are roughly six to 10 pages. These, you know, the length can vary greatly depending on the complexity of the project. But we always make it a point to include the following. The project overview, which is kind of broken down into the purpose statement, the business objectives, the overview of the deliverables. What are we actually going to give them at the end of all this? As well as the success criteria. Then we break out the timeline and milestones. What's our phasing? What are our sprints? Then we also look at resourcing. How many developers are we going to put on this? Does it need a strategist? You know, questions like that, do we need to bring in design? And between those last two, between timeline and resources, we can kind of put together the scope and the cost. Roles and responsibilities, this can be a very important part if you have more than one party involved outside of you and the client. If you've got these other third parties, this is where you want to kind of draw a line between who's responsible for what. Don't be afraid to get detailed. Then we go over our quality assurance. We go a little bit over our maintenance support and our warranty. And then one of my favorite parts, the assumptions and exclusions. This is where you really get to just kind of take a piece of chalk and draw a little safety circle around you and your project. You know, some topics I'll bring up in here commonly include responsive, mobile, internationalization, hosting, making sure that you're gonna be able to get access to the other systems that you need. Or even just down to what version of IE you're willing to suffer. So for example, you know, if you went through this whole time and they've never brought up responsive and all the discussion's been around the desktop, you know, this is a chance to say for right now, this is really just covering the desktop view. Because the last thing you want is that the week before launch, the client's like, this looks fantastic. When are you gonna make it look good on my phone? That's not something you wanna hear a few days before launch. If you do, you better make sure you got some CYA. So then we have other key information. That's just kind of our miscellaneous area. Anything that doesn't really fall into the other sections but we wanna make sure it's on the contract. Our terms of agreement and then of course the all important signatures. Once we put this document together, we do put these SOWs through a stage gating process. We make sure that at least four strategic eyes within our company have seen, read and approved of the entire document before we send it out for signature. So now we made our deliverables, time to wrap it up and hand them over. Wait, time to show the client. Well, that doesn't sound quite right. I mean, ideally you've been sharing this all along the way. By the time you deliver the artifacts, your discovery project, it should go with virtually no ceremony whatsoever. No surprises. Your key stakeholders should have been in all along looking through the documents and commenting this entire time. The delivery really just marks the official, you know, the end of the official discovery phase. It's your chance to let that final little discovery invoice out of its cage and fly off to get into the financial department. All right, time to celebrate. The big project got approved. Now, turn around, look at your own team and now you gotta do a handoff. You can't just dump the files and walk away. The implementation team has to actually build the thing that you've been planning and they're gonna need your help and internal consultation, especially the first couple sprints. I personally recommend being an open book, share everything with your team. I literally do this with my directories and Google Drive. And during the discovery, you know, if the big project seems like it's very high likelihood of closing, you know, it's not a bad idea to, you know, bring your team in a little bit while you're executing the discovery. Try to keep them up to date on the process or the progress of the discovery as it's going on. Have them attend a meeting or two and have them help you out with the estimates. But when all is said and done, you're gonna need to go through a couple of transitions. First is the knowledge and I'm afraid to tell you that's actually the easy one. You've already boiled a lot of that down. This is something that's fairly consumable. The other thing you gotta transfer though is the ownership. And I'm not just talking about whose names assigned to the project in a spreadsheet somewhere. I'm talking about who's gonna own this project from here out. Who's gonna really make it part of what they're coming to work for? Because most importantly, you have to transition the energy. All this time throughout this process, you've been up on a stage. You've had a spotlight shining right on you. Then you try to go off stage. You try to go over across the street to the other theater, the other play. But you can't. You can't walk off stage until the next person steps up. Otherwise, the audience is gonna still be looking for you. It's critical that you identify that person and make this transition a big part of your process. Now this is difficult. Possibly the most difficult part of the process that I've found. And there's no way to sugarcoat it. Not every developer on your team is gonna be capable of handling this role. And that's fine. By definition, they don't have to be, and nor should they be. But it does put a little bit more pressure on you to choose wisely. Ideally, this person's a project lead, a team lead, a senior developer maybe, with a lot of experience working directly with clients. But make the introduction during the discovery so it's already a familiar name and a familiar face. Transition, by definition, it takes a span of time. So start the process when it feels right. The higher the likelihood of the project coming through, the earlier you start fading in this new person. And when the client comes back to you, and they will, even if you know the answer, you have to start guiding them back, shepherding them towards this other person that's now in the spotlight, just to reinforce and empower that new face. Even after your transition, you're still gonna be part of the magic. You were there from the start. You might be the only person on your team that wasn't part of the chain and the telephone game. So plan to be at major milestones of the project. Attend the sprint demos, the planning estimation meetings. Your team needs you to be their compass. You need to ensure that at each milestone, they're still heading towards the true north of the client's vision. As for client-facing, well, you've also worked really hard to forge these professional connections. So say hello from time to time. That next big project might be sooner than you think. All right, so we did a lot of work, but was it worth it? Okay, real quick, let's go back to reality. You're not gonna do all this stuff on every discovery project, not even close. You're gonna be practical about which tools and techniques you pick for each one, and you're gonna be as efficient as possible. In the end, the discovery budget's gonna be what dictates how far down the rabbit hole you go. But was it worth it? Great question. From a strictly monetary and logistics standpoint, it can be extremely difficult to quantify. Oops. What you've done is entirely preventative in nature. You will never know just how many icebergs you kept out of the ship's path. You never followed up on that bad decision. You never wasted two sprints following a dead end. But it's a good sign that you're doing something 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 like you have a rich understanding of their business goals. Your internal champion within the client's company gets a promotion. A stakeholder buys you a beer. That really means something. And you're definitely doing something right if the client becomes a partner. Thank you all exceptionally much. I appreciate you attending this session. And we got just a couple minutes left for Q&A or discussion. Who's usually the, what's the title of the person that's usually managing this process at the company? On our end or the client? On your end. Well, usually in our company, that's gonna fall to our consulting team. So either myself, a senior consultant, or one of the several other consultants that we have. It seems like your method, at least at the start, borrows a lot from Hold Splat's contextual inquiry. I'm assuming you're familiar with this so that you use it as an internal mentality for developing this process. But I'm mostly curious how you decided to pair that down because that method is very robust. How you decided to kind of cut that down to a process that works well for you at Metal Tote. I mean, partially, I mean, to be honest, a lot of it is kind of gut and just being able to evaluate what feels right or what I feel like the client needs. Because like you said, when you have these very robust frameworks or systems, you don't always need all of it. You really only can tell that the client really needs to see this piece, this piece, and this piece. And I think over time, we've just started to see trends of very common ones. Yeah, so that's really all it comes down to. Over time, multiple, many of these, we just saw consistent trends. You talked about how your discovery process is like three to 10% of total project budget, and I think you said that you do it in like 10 days? Depends. Just to address that one real quick though, when we do them in the three to 10 days, usually that's a fairly small, a slide I cut because I knew I was going to be running long on time. I addressed how sometimes if there's just like one red flag, like it's a Drupal 7 site, but they are going to do a migration from like a custom built whatever system database, sometimes we'll do like a short couple day one. And so in that three to 10%, does that include like any design work or information architecture or those other related disciplines? Typically that is going to exclude design. We don't actually do design at Metal Toad, so that's really just coming off of our line item. And so then as part of your deliverables, are you including a lot of user stories or? Yeah, it's fairly common, honestly. Like I was mentioning, it's a fairly common trend that the companies we're working with, they don't tend to have very strong agile style product owners a lot of the time. And so even if they're providing a lot of them, usually we're at least cleaning them up, organizing them and getting them ready for our team. All right, thanks. Wondering if you have any strategies or techniques for selling clients on this process when they come to you with a usually poorly written RFP where they think they have done their discovery and are then resistant to this idea that someone else needs to discover things for them. You know, that is a great question and very applicable because this happens all the time. I'm dealing with this with probably three different RFPs right now. I think the big answer is soft skills. I mean, it's getting a connection with the person, getting them to trust you a little bit, even in the RFP process, which is very difficult to do. Sometimes you kinda wanna get them talking about other things a little bit, get them, ease into it and get them, start asking them some questions. Like if you see that there's a lot of dragons hiding in this potential project, try to steer the conversation so that they start to see those as well. And it's not you telling them that there's this big ominous black box sitting here, but get them to discover the black box. And then once they start to see the holes, it's a lot easier for you to then sweep in and be like, hey, let's find them together. Let's do this little small engagement and let's define that thing that you, they just said out of their own mouth, they don't have answers for. So I guess through the discovery process, you've built really good relationship with the client and you have this deep rich understanding of their goals. You touched a little bit on kinda what that transition process is like as you're starting to kinda roll off of discovery. And I guess when we've been in similar situations, like usually the person who does the discovery is a member of the project team going forward, but it sounds like maybe that's not the case so much for you guys, but maybe you check in on milestones. I guess can you talk a little bit more about that? Like what your, maybe you personally, your ongoing communication is like with the client and whether or not you're actively involved in like the sign off on the project to say, yes, we did meet these goals. Yeah, sure. I mean, so you know, Meadowtoad, we're not that huge of a company. We're a little over 40 people. So to some degree, like myself when I'm involved in one of these processes, I'm a little bit higher level with the account level things. I'm kinda dealing more, we don't have account managers, so I kinda fill some of that void. So naturally, you know, I can't stick around with the whole project all the way from start to finish. That's very difficult because I'm dealing with these relationships across partners and other accounts, but we have started kinda growing our consulting team lately because we noticed that same gap where it's really beneficial for, you know, the people involved in the discovery to try to maintain and be there throughout the entire course. We have tried that a few times. It's working very well. Actually, Kevin here is doing that right now. Look pretty, Kevin. So I mean, that's definitely the way we're trying to head, but you know, we're not that huge of a company, so we have to make some sacrifices here and there. Thank you. Any other questions? You have two seconds. All right, I think we're all down here. Thank you.