 Well, hello World Camp Europe 2016, thanks for the intro, Frankie. I am indeed David Lockie, director at Pragmatic, we are indeed a specialist wordpress agency based in the UK, formerly a proud part of Europe. Today I want to talk to you about discovery and definition. Our mission at Pragmatic is to create success with WordPress and a prerequisite for creating success is to remove pain from a project process. And we've all been there, anyone that's been involved with the digital project or WordPress project has had that moment, that kind of sinking feeling in the pit of your stomach, where you realise that you've missed a requirement or you've made an assumption and you're going to have to work all night, probably not make any money, anger your client, maybe even all three, which is obviously a painful process all round. So we found that this discovery and definition technique has been invaluable in helping us to avoid that pain. And I want to run to it with you today. So a project often starts like this, a simple inquiry, can you build a website? And as an agency we'll rapidly try to qualify that lead out. The two most important questions being how much money have you got and when do you want it done by? And if we're lucky the client will have an answer and be forthcoming about it. And in this case it's a decent budget, everyone needs a website next week or next month or maybe even tomorrow. And they've got some thoughts about what they want so they're going to send the brief over. So there's a fit top line, we're looking through the brief and we think okay so they want like a WooCommerce shop and they want it to do this and that and the other. And we're going to start overlaying our approach, our expertise, our understanding on top of the client brief to come up with our own vision of what this project's all about and what's going to make it a success. The client however probably has their own ideas. So they're going to be taking inspiration from their experience with websites that they use every day. They may well not be technically savvy so they might not know that that just doesn't make any logical sense. You can't just make this thing do that without years of underlying data. And their expectations of what's in a project are going to be limited to, generally they're going to be limited to what is the end result. So it's a website that looks great and does all these things. As an agency we're looking at that project budget and we're going okay so this is planning, this is creative, this is production, this is testing handover, QA, pre-go live checks, go live, all that kind of stuff. So we've got to spread that money a lot more thinly than a client might realise. And so often we end up here. Anyone that runs an agency, this has to be one of their favourite internet memes of all time. And so this is the riskiest part of this whole enterprise. Do we say no because we don't really understand enough. It feels like it could be pretty risky, high expectations, quick turnaround time. And therefore miss out on like a great client relationship. Do we force the client to go to a lesser WordPress agency and get the work done? Or do we go, yeah, let's do this, let's make it work. We're pretty sure that we can merge these two things into something that's going to be good at the end. But we've all seen what happens when projects do go ahead at this stage, right? You end up with a site that looks great but just doesn't work or the other way around. It's really functional but it looks like a dog's dinner or our personal favourite. We've had this website built by another agency and it's nearly finished. Can you just do these last few things? And that's the result of a poor planning process, right? Is you kind of hit these things and maybe the agency bows out and they think, you know what, that is 10 grand small work. I've got five grand of budget of invoice that I'm not going to get out but I'm okay with that. I'd rather just not get paid and walk away. And so how do we solve for this problem? It's not, as you might think, a job of making that budget realise that brief. Neither is it a question of squashing the client's dreams and making their brief fit into the budget that they have. Actually, it's a more interesting process than that. It's understanding why they've written that brief and why they've chosen that budget and what they actually want to achieve. And there's no way that you can do, like, progress against this problem without understanding that from a kind of fundamental level. So most often in this case, we'll start with, like, the first part of the project and it's not going to be like, okay, it's the cat and the child. It's going to be, you know, something that's slightly different. So maybe the cat and the tiger. But then the client's ultimate vision of this, like, kid with a tiger on a boat in the ocean, actually it's going to evolve because they're going to end up with a lion and a girl in the jungle on a rock and the lion's eating like a gazelle or something because a digital project is as much about organisational change and learning as it is about just whacking a bunch of code together. And so whatever a client thinks that they want digitally in two years' time is probably wrong, you know, well-intentioned, well-meaning, but wrong if they're going to learn what the website is teaching them. So they're kind of false goals, both of them. And so here we are in this weirdish world space between sales and production. How do we take this lead and turn it into a great project that's got every chance of a successful outcome? And that's what this talk is about, discovering definition. And that's the process by which we align vision, requirements, expectations between the client and the agency so that we all understand what the project is, what the process is, what the outcomes are. And that we've factored the success in from the beginning. This is what it looks like. It's pretty straightforward. Discovery, that's stuff that we do together. Definition tends to be a phase of work that we do separately and playback is where we come back together after definitions complete. And what I'm going to do is dive into each of these sections, into each of the activities and try and break down what they mean because otherwise it's a bunch of words. So discovery starts with pre-discovery. We move on to typically a workshop setting where we're going to meet stakeholders, we're going to run through a whole bunch of Q&A and we're going to use that opportunity to challenge some of the answers that give us and share some of the expertise that we have from building hundreds of projects. So pre-discovery is set up all of your internal processes, work out which team or which developer, which project manager is going to be the best fit for delivering it, who's got capacity. Make sure that you've planned all these bits of work in so that once you kick off the process then you can finish it quite quickly as well. You need to have a look at the brief that you've been sent over or the brief that you've written down from your initial calls with the client and then take all those answers and put them into your own project plan, your own project documentation so that when you're working on, your team is working on lots of projects, they always find the same answers to the same questions in the same place in the different project plans. So then we can go into a workshop, like a discovery kick-off meeting is usually what we call it. Looking like we've done our homework rather than turning up with the same blank template that we always use. So we use like a Google Doc, it's just a sheet and it's a really quick and easy way of everyone to collaborate, chuck a whole bunch of answers in a structured way. It's essential that we have everyone, that's a key stakeholder in the room, so that's project manager, team leader, lead developer from your side and it's the decision maker, the budget holder, the business owner, whoever is going to have ultimate say over the project from the client side, otherwise you're going to risk having to redo this or they're going to come in later in the process and take away an assumption on the everything breaks. It's really important to understand that people communicate in different ways, so like me, I'm a talker, as you can probably tell. It's amazing how many people don't actually understand what you're saying, they're just not unagree, so use different techniques, draw wireframes up on a big piece of paper. It's amazing how far apart your assumption of where the client is with you on that journey can be. Another really good exercise is like a retrospective, so I don't know if you've ever come across this, it's like an agile technique, so particularly where there's an existing site or you're doing a rebuild or an extension piece on there, it's really worth taking time to find out what people got glad, sad and mad about their existing site because those are all the learnings that help shed light on why you're doing this project and it's really important to capture that and go forward so that you can tell them at the other end of the project. Now you've got an effective content management system and the site loads in less than 30 seconds. So during this interview, we're going to be looking to answer a whole bunch of questions and answers everything from like, what do you want your business to be like in five years or who are your target customers right down to where's your domain name registered, do you need an SSL certificate? Really very wide scope, I mean I think we have like 150 questions that we run through so it is a lot and it needs like a process to run through and do that. The next bit about challenging assumptions is I'd say it's more of an art than a science because you don't necessarily know which answers you're going to get that make you think do you really need multilingual or are you just saying that because you think your competitors are doing you think it's important that the experience will do that just like listen to all your clients saying and stack it up against what they say that they want this project to do. So once we've done all that we've essentially drained all of the clients ideas and visions and expectations out of the project then it's time to move on to definitions so typically both parties will have a bunch of actions out of the end of discovery say like find out who's got the Google analytics logins or we need to go away and do a bunch of stuff before we can complete this process and definition really looks like that finishing that process and then recompiling all those answers into something that is a brief. So research is understanding what the heck you're doing and don't vouch for the fact that your client has done this understand who their clients are who their competitors are. If you're really going to create success then you need to understand the competitive landscape that the website is entering what's a business purpose and there's a bunch of techniques that you can do there I won't drop down too much into then you need to de-risk what's left so once you've gone away and you've put a WordPress site together with a default theme and a bunch of plugins and tested whether this all hangs together can you complete all these things you need to work out what's not being done where does the technical risk remain in the project so it could be an integration or a component or an interface that doesn't exist or the one on codecanyon looks like ropeier than usual what are you probably going to have to build out a custom and what's involved with that make sure you really zoom in and understand that piece of work because that's probably the bit that's going to come back and bite you At a top level of trying to help a customer understand what their website is going to look like a site map is pretty fundamental a user journey and mapping and wireframes both complement that so if you've got a site map like why do those pages live there because this user journey says that they need to check out the season seats or you need a confirmation page because that's where people get after they've made a payment so cross-checking all these different things like if a user needs to go from a home page to a news page to a news that sign up confirmation page do those pages exist in the wireframe and do the things that you're asking people to do exist on those pages it's a lot to hold in your head basically and then that's a lot to communicate at so write it down also make sure that you finish your text back so answer any lines that remain TBC or I don't know or I'll get back to you on that and just make sure that it's as complete as you can possibly make it because this is your this is really your risk mitigation as the person that's got to build this if you don't capture the fact that this is only going to be browser compatible, cross browser compatible for browser that's two years old or newer if you don't have that in there then somebody's bound to come along and make you make it i.e. seven compatible or something like that so just think of all the things that clients could ask you that would change the project make sure you've got a backstop answer for it and once you've done all that then you can get back in the room with the client and discuss what this project actually is so you can do these things we can have a look at the wireframes sorry sure slides will be available online later as well so here we've taken wireframes and we've assembled them into like a UX specification so it's not just his wireframe this is the wireframe for the homepage on this device and these are the key messages and these are the things that we're asking people to do and those are annotated because if you give somebody a wireframe they'll still see two different things one person will think well that's at the top that must be the most important the other person will think that's got the button that must be the most important so document this stuff out and it will actually help form a basis for a kind of continuous improvement later on so it's a way of documenting all of the knowledge you have about the site even before you start building it you can also assemble all your wireframes into like either just like printed this then this then this kind of user journeys or even better you can upload your wireframes into a tool like Envision make them clickable and that kind of natural way of navigating what do people see when they land on this page on a mobile device what happens when they click this thing there that usually like it's worthwhile it's a bit of a process but it throws up some interesting stuff that you don't want to get to by the time you're presenting your actual built website it's pretty likely that the nice green project plan that I showed earlier on is going to have some lines which remain TBC the answers that we can't get out of the client in time or like we just both jointly don't know until we get a little bit further down the line we've done some of this custom development and it's really important to talk about that so here we're like to every single project ever risks the client's going to miss their deadlines what does that mean? and it's not the case that if they miss their deadline by two minutes two days then you'll push the project back by two days because that's not the way that we work right we have capacity and it's resource for different projects at different times so it could be like actually it's two weeks so you need to talk about what that impact is because the client will have their own imagination about it similarly, what happens if they ask for something that's out of scope how do you handle that? do you just say no? do you do a change order? do you whack it into the next sprint? how's that way of working actually play out? and finally and probably most importantly for you as an agency or as a freelancer is a brief and a proposal that actually makes sense they are de-risked we've got a you expect we've got a tech expect we've got a risk register we've got a cost we've got a plan of when all this is going to be done and when the feedback rounds are due and what happens if they miss those and that's your main commercial document for the rest of the project all the creative all the production all the testing all the handover all the go live all the subsequent services now you've got a chance to understand what they are that's the magic so if I was in the audience three years ago I'd have been thinking there was no way in hell I am doing all this work for free before I even start getting paid for a project and that's true there are really hard deliverables out of a discovery and definition process and you should be charging for this time a money so the client is getting a you expect and a tech expect and a project plan and a proper brief these are all valuable commercial things they might not have thought about them before they started a website project it doesn't change the fact that they need them and that they should pay for them and there are other benefits as well so this is perhaps one of the most important things you can do with a client it's to understand their business what's driving them what they hope to achieve why is this their family income is it like a side project all that stuff it matters and so having that understanding having that trust and developing those ways of working does this client never answer an email are they better on the phone do they change their mind should you have a slack channel to pack up all the other things do they just want everything with a ticket number and an email sent back to them everyone's different and until you have been working with a client for a while you don't realise what those subsidies are and actually in the thick of a project where you're all committed to this thing that's the wrong time to work out how best to work together and so after all this we're asking people to sign off on some money to do a project and does discovering definition guarantee they're going to sign it no actually quite a good outcome of discovering definition is sometimes the client going you know what maybe I should get this creative brand book done before I start the website or maybe we should do this technical integration piece or we should get this person in like we should get a project manager or I had a digital because this is like this is an important piece of work so that's fine actually like not embarking on a project that's doomed to fail is a pretty good outcome what I will say is if they do sign on the dotted line and you do get a chance to run on the project the chances of successful profitable outcomes are much much higher like we've had so few projects fail once we've been through a rigorous D&D process like all these questions all those 150 questions either you ask them at the start and you get a paid for it or you ask the client ask you them at the end and you have to right roll over and do them you know it's very difficult to bypass all of that understanding and knowledge but the pain is at the end if you haven't asked them so I know I don't have long left but charge for this it's not a freebie it's some of the most valuable work you can do as a professional bring cake, keep people's blood sugar up this is you know the big meetings some of them will be like existing