 Okay, folks, we're gonna start right on time today. So we're getting into the day on a very scheduled note and everything. So as people come in, I would like to welcome you to the next session in the business and strategy track for DrupalCon. The, just a couple of housekeeping things, the slides for the sessions. Look, I'm not sure exactly when they're going to appear. We'll be released for all sessions at the same time. So check the session page. You'll be able to download those. Also, there'll be the audio for the session with live slides in a YouTube video available for download from the site as well. I'd also ask you to please fill in your session evaluation. You go to the schedule page on the website and you'll be able to evaluate the sessions that you go to. And that goes into feedback back to the presenters and back to the DA. So I would really appreciate a short amount of time to do that. You can also post comments on the session pages. I am going to pre-exuse myself because I gotta go check out of my room in a minute, but I'll be back. But in the meantime, before I do, I'd like to introduce you to Pam. Pamela Barone is going to be taking this session. She is a web project manager at Previousnext here in Sydney. She manages large-scale web development projects on the Drupal platform, of course. So she has absolutely the right prerequisites to be talking about requirements for your Drupal projects. She currently specializes in delivering Drupal to government, higher education, and media organizations, which I think are Previousnext's key verticals, using agile methodology. Her session is entitled, Rethink Your Requirements. Please welcome Pamela Barone. Can everybody hear me? So as Mark said, I'm here to talk about Drupal requirements. I'm going to talk a little bit about why I think it's important to use Drupal to refine your requirements and then just give you a couple of ways that I've learned how to do that. I just really believe that framing requirements in Drupal terms is the best way to get a good outcome on both sides of things. It's the best way to leverage what Drupal does well to avoid misunderstandings down the road. Just a little bit about me, Mark introduced me already, but I'm a project manager for Previousnext in Sydney, and I do mostly work on government media and higher education. This is just some of our recent work. And before I started working in Drupal, I was a content editor at a large media company in the US, so my formative years were on the other side, at the client side of things, and now I'm on the dark side, the vendor side. Just first a disclaimer, there's no magic formula for how to do it in Drupal. It's not a translation, it's not a, you know, this is the way you write them in Drupal. It's really just about getting started in the right direction, using Drupal terms, using Drupal methodology. Like, Drupal is already your framework, so it just makes sense to use what Drupal does when you're writing your requirements. Kind of some background on how this came about. This is what kept happening. The client would give us requirements, they would say what they wanted. We would deliver what we thought they wanted, and then they'd say, no, that's not what I wanted. This happens all the time, and it's not unique to Drupal, but I think the great thing about Drupal is that there are a lot of ways you can use it to avoid this. And the kind of classic example that we see is, this is just a quick example, but the client says we need to integrate video with BrightCode, that's our video provider, so we just need to get BrightCode video on our Drupal site. We say no problem, there's a module for that. This will be an hour, easy, great. Then you deliver, and they say, right, this is fine, but we need to put our player IDs in to target our pre-roll ads. And you say, ah, okay, well the module doesn't actually do that. We can do it, but it's actually gonna take 10 hours instead of one hour. So 10 times as long as we said, and there was no module. Like I said, incidentally there is now a module for that that we built because of this specific use case, but it just seems to happen over and over. And I realized that we must be doing something wrong. The client told us what they thought we needed to know. They're not purposely holding back details because they're trying to mess this up. At least I don't think so anyway. They assumed that when they said we need BrightCode, that it would include all of the stuff that they have in BrightCode, whereas that's not really how it works. But they told us what they thought we needed to know, and we thought they told us everything, but they didn't. So I just started thinking, I mean, why does this keep happening and what are some ways that we can really avoid this in the future? And the real problem is that it's really hard to build a website from a stack of paper or just a collection of documentation because there are so many nuances and there are so many subtleties and there are so many different ways to do things that it's just really hard to say, here's what I want and then here's that exactly as you envisioned it. So starting from the beginning, I just started to think about what are we really trying to accomplish with requirements? And I think it's really whatever you need to understand what the client expects from the outcome. And successful delivery really depends on understanding exactly what they expect and why it's valuable to them. So I'm not really concerned about format that you use for requirements. Is it user stories? Is it a 200 page technical spec? Is it personas? It doesn't really matter and I don't really think the methodology that you use matters either. We happen to use Agile, but I don't think that's too important to the underlying concept of just a mutual understanding of what they want and how you're going to deliver it. So where does Drupal come into this whole picture? I think it should come in as soon as possible because you've already chosen Drupal as your framework. So why sort of pretend that that's not going to be what you're using. Discussing requirements in Drupal terms just reduces the potential for confusion and misunderstanding. And it eliminates some technical fitfalls that you can run into down the road if you implement something in a way that you thought made sense, but the client said no, that's actually absolutely not going to work. And I think there's a little bit of hesitation among Drupal people to say, well, Drupal's so flexible. So I don't really think that we need to have Drupal requirements because we don't want to make it seem like Drupal only does things a certain way. But if you're going to use Drupal, there's just no reason to kind of hesitate or try to avoid this because there are two parts to it. Drupal is so flexible and that's part of the problem. You can do anything, but should you? It's really the question. And the other thing is Drupal provides a lot of things out of the box and does things really well, but also does things in a really specific way. So if you tell the client, yep, just tell me whatever you want in your words and I'll build it. You probably can, but you might end up undermining a lot of what you get with Drupal when it's delivered. So it's really not about saying, no, no, no, we can't do that in Drupal, that's just not how it works. It's more about just being clear and being realistic about what you're going to give them. So this is a really standard requirement that we get on almost every project that we do now. Publishers must be able to quickly and easily revert changes to all pages. It's pretty standard, but at the same time, this is not something that Drupal really does. To be completely honest, Drupal is not a page-centric model. That's not a weakness, it's just the way things work. It's very dynamic in nature, so that kind of snapshot of a whole page is just not something that really happens in Drupal. There are initiatives in progress now with content staging to enable this, but it doesn't exist at the moment. And you can come really close, but it's not very easy. So when we see this, we say, yeah, we can do that, but if you meant publishers must be able to quickly and easily revert changes to all content, that's really how it works in Drupal. And it can seem like a small difference to Drupal people, because we're just so used to that being the way it works and it works really well, but to content people, it's a major thing, because if they come from a page-centric CMS, this might be a little bit scary to them. They say, well, what do you mean I can't have a snapshot of a whole page? I don't understand. It seems like a weakness in the system, but it's really not, and in most cases, the content will suffice, like, versioning the content is fine, it's plenty. It'll satisfy people, but you just have to be clear. So this is the idea, basically, is that both of you are thinking about it in the same term. We come to it with so much Drupal experience that it can seem, like I said, it can seem really unimportant that it versions content, versioning pages, because we're so used to it and we have a really clear picture of how it works, but in most cases, the client has never seen Drupal before, they don't understand how it works, they're coming from a CMS that might be really outdated and just does things in a completely different way. So they have just a different idea of how it works. So what you really need to do is specify how you're going to satisfy the requirement. Not just say, yep, we can do that, tell them how. And then like I said before, Drupal is really flexible, but at some point it can become a liability because, like I said, you can end up undermining the things that Drupal does really well. So trying to cobble together page versioning, just because that's what the RFP said is a perfect example of jumping through hoops and going in circles to make something happen that you really just don't need to do. So just be honest at the start. Revisioning content is really easy, Drupal does it, Drupal Core does this. Revisioning pages is not easy, it's really hard. And best case scenario, the client says, oh yeah, that's fine, it doesn't really matter to me, that'll do. And if they say no, say why, what's your use case? Is it because you're afraid people are going to publish things that they shouldn't have and you want to be able to undo it? Well, let's try a workflow system, a really strict workflow system. Is it because you want to keep an archive of what your site looks like on a given day? Well, we've actually built an HTML crawler for that. It's a lot more lightweight and it's stored on a separate server so you can click through and see what the entire site looks like at any given time. And that's completely outside of Drupal and in some cases that will meet the needs. And then it could just be, well no, our editors have to switch between versions of pages a lot. And that's why we want it. You could say well, versioning the content will probably be enough because the dynamic list is probably completely independent of that. So building page revisions is a really major commitment and it requires a lot of planning and it affects a lot of the rest of your site architecture. So it's like I said, it's really important to be clear about do they really need that and if so why and can you find a better alternative? So the first thing I think that's really important in terms of actually how to make this happen is get your clients to learn Drupal as soon as possible. This is actually a picture of Drew's bookshelf so it's a bit of an extreme example but there's so much material out there that clients can use to educate themselves. There are formal training opportunities all over the world. There are even free training days you can recommend. You can hold a workshop with the whole team and just show them kind of the basics, the most important things and just give them an idea of the way Drupal works. We recommend that all of our clients take the Drupal in a day aquia course and by the end of the day they'll have built a Drupal site using views, contextual filters. They learn a lot of things that they definitely won't be using on a site that we build but it's a really great way of getting them to understand how things work and then they can be better at communicating how they envision that it will work. Suggest books to read, give them node one tutorials, just really make it clear that you expect some engagement from them on this level. Get them involved in technical conversation. Don't just say, yeah, tell us what you want. Don't worry about the technical side of it, that's our job. Force them to get involved in these decisions. And then when you're doing a project plan and when you're laying out your project, budget for it because you're gonna need this time to talk things over and to really iron out the specifics. So no matter how prepared the client is, they might come in and say, no, I've got a 200 page RFP. I don't need any requirements gathering. This is all you need. Just explain that, yeah, the RFP is great as kind of a, I don't know, blueprint is the wrong word but it's great to give us an idea of what you're expecting but it's definitely not enough to communicate the final outcome. You'll never get what you need from a document that's been provided by the client. So just include this in the budget. Just say this is part of what we do. You know, it's not just padding your estimates. It's not just a contingency. It's something that you need. So just tell them we start with pretty much, I mean, this isn't specific to every project but say 20% of the project budget is gonna be spent on starting things off, getting things, getting a project vision established and really working together with them to do that. So your inception phase can include any number of things but it should start with a kickoff meeting where you get together with them. You discuss roles and responsibilities. You know, you kind of iron out the details of how you're gonna work together but you also establish a project vision which is just a really quick statement outlining the purposes and the goals and what the client hopes to achieve from this project and it's really important that you actually kind of keep referring back to that and remember that that's what you're doing and don't get lost in kind of a sea of feature requests and scope creep because at the end of the day you need to just achieve that vision. It's not about kind of change requests and all that sort of stuff and why doesn't it do this? Just keep referring back to the vision and say well, yeah we can do that but do you really need us to do that because that's not really what the project was initially supposed to be. The other things are just workshops if they don't want to get you in a room with our staff, send out a feedback form and get just kind of some highlights about what they're expecting, consultations. So use that vision that you've established to kind of get an idea of how the work is gonna be shaped so if it's a project that's really strictly about the front end they don't like the way the site looks, they want to improve the kind of end user functionality, that's fine but if you find out through your consultations that actually what CMS editors hate the current CMS then that's gonna really have to shape the rest of the project and they might not have mentioned that actually. So through your inception phase you should like I said establish the roles and responsibilities and the most important person on a project is the product owner. That's what we call the client lead in Agile but it doesn't really matter who you call it whether it's the client project manager or the client lead, whoever it is. This is basically your ideal product owner. He or she is smiling and just reveling in all their responsibilities and ownership. Yeah that's great and yeah we're gonna collaborate. This is great. Ideally it should be somebody who uses the CMS on a regular basis and not just somebody that the client assigned to it because they want to make sure it doesn't go over budget. It should really be somebody that can get engaged throughout the build and make decisions and give you useful feedback. And you really should expect a certain level of engagement because like I said, this is absolutely the most important person on the project. It can make it or break it and I've seen this happen a project that sort of was really vague in the beginning but ended up going really really well because the client was really engaged and really involved. At the same time a project that seemed like it planned out to the detail and then the product owner just really didn't care and in the end the client didn't get what they wanted. So we do daily scrums. We send out weekly reports. We have approval deadlines. We have expected response time all up front but the reality of it is a lot of times your product owner can end up looking like this. I mean in some cases it's just not a job they wanted. They didn't want to get involved in the project. They didn't want to hassle. They're managing internal expectations. They've got committees. They've probably also got 10 other jobs and meanwhile they're just stressing out about the budget and constant surprises and just being bombarded with requests from you. If it's too much to handle you've really got to take that into consideration and figure out how you can reduce what you're expecting of them. So just say, hey what can we do to make this work? Is a once a day email too much? Is a once a week email too much? How can you kind of hand over part of your load to us? So you give us a really big kind of overview of what you all accept. We'll try to take on that role of product owner. So in Scrum that's sort of how it works. The Scrum Master can take on the responsibility of product owner if the product owner is not available. And this works out really well because like I said oftentimes the product owner is not thrilled with this job and in that case you really have to help. And if you do have a good product owner you can take advantage of one of the things that I think Drupal is best for which is prototyping and doing iterations and doing demos. So everybody knows this already in this room. You can really quickly add new features. And so in cases where the client isn't sure you can say, well let's try this control module. Does it need most of your needs? No, not really. Okay, well let's try another one. I mean that can take just a few hours to get to the right decision. So instead of spending say a week or even a day or whatever it is, trying to think of every possible eventuality and writing it down and saying if this then this and then we need this and then we need this, just say let's try something. Let's try something and see how it actually works and then we can probably answer a lot of these questions without getting too far into it. And the other thing is it saves unnecessary dev time so if the client says I need these 10 things you go off and do those 10 things well sometimes they would have been happy with two of the 10, but you really, you can't know that because you didn't tell them. This is a very in-depth requirement for managing links that came straight from an RFP. And at this point in the project we were up to our eyeballs and scope creep and we looked at a list like this and we said some of these make a lot of sense. Some of them are redundant. Some of them I don't even think are clear. So something like it should not be possible to have broken links within the site managed by the CMS. I mean content editors will find a way. No matter what you do, they'll find a way to have broken links. This is just not very realistic. So like I said, at this point there was a lot of scope creep happening. The budget was a concern so what we said was let's focus on that top line which is the overall goal of ensuring that there will be no broken links on the site. So this is really all they wanted. They wanted to be able to manage links so that they didn't have a bunch of 404 pages. We gave them a very pretty 404 page just in case but you really have to focus on the core intent of the requirement so that was the goal. We don't wanna have a lot of broken links. Clearly they came from a system where they had a lot of broken links so this was a major problem and I think as a result they kind of overreacted and got a little too specific. So what we said was let's start simple. We'll set up a link content type for managing external links. So there was a node ID for every external link on the site every time they linked off the site they were linking to a node ID and that way if they need to change it or if it got broken they only need to change it in one place they didn't even have to go around finding everywhere that it was linked to. The next thing is the link checker module which actually satisfies two or three of those requirements just out of the box. It runs periodic reports or it runs manually. Every time Cron runs it does a sweep of every single link on the site and checks for broken links. You can use that to generate reports. You can use it to generate notifications but it's a really great tool. And the other module we suggested was link it which is a way of linking within your Drupal site through the WYSIWYG without manually typing in without using that link icon. So you're linking directly to a node ID you're not linking to an alias which can be really confusing for editors to say well I don't understand why there's a number here why can't I just link to the alias and the reason of course is that the alias might change but the node ID will always be the same. So we implemented this, it ticked most of the boxes and it was pretty simple. It really didn't take a lot of time and we said look we'll do this for you, you test it out, let us know if you need more and we can add more to it. But in the end they were really happy with it. It totally met the goal without too much complexity because I think you also have to be careful when you're trying to tack on layer on layer on layer protection it can become a burden for the editors because if there are too many places they have to go to check things they're just not gonna do it. So like I said this was really simple you have the link checker report and that's pretty much all you need to manage those broken links. And the next thing that I think is really important is it goes without saying that you guys all have expert Drupal teams I don't need to tell you guys that it's really important to use developers who know how to use Drupal very well. But your whole team should really have a good understanding of the way things work and even your sales team should know a little bit about it so that they're not going off making promises that either you can't keep or that are just too expensive to keep. So beyond that though I really think it's important to get the developers involved in the process as soon as possible. Show them wire frames, show them requirements bring them to client meetings get them talking to the client and I think it really gets them involved in the whole project vision and then I think as a result they take more ownership of it. So they don't just see it as here's this list of tasks just complete it and then tell me when you're done and I'll worry about it from there. Then they can kind of get involved and give you ideas and say oh you know what? You said you would do it this way but I think actually a better way and a faster way or an easier way might be to do it this way. And then the other thing is that you can actually vet their approach you can say no don't tell me you can do it I know you can do it but how are you gonna do it? Because a lot of time developers minds work in a little bit of a different way they're not thinking about the content management side of things they're thinking about what's the quickest what's the easiest what's the technically best way of doing this where a lot of times if you actually ask them their thought process you can say yeah that's actually a great idea that's really clever but I don't think it's gonna work and this I think could be a whole talk on its own but you can't ignore the content editors. Their input and feedback is just so critical and if you don't have them on your side you're in big trouble. And I think what we found a lot of times is that the client kind of resists this concept of we should consider what the content editors want they say no there's too many too much of a hassle we don't want to hear from them and if you find that that's the case with the client then you need to be the advocate the content editors need an advocate and if they don't have one in their organization then you have to be that person because even if the client that we don't want to hear from them they're gonna hear from them at some point and if you wait too long then it's too late and it's gonna be really expensive to fix and I did some custom training recently for a very large web team at the end of a very complex build and there were a few bugs still but I was really excited and got there and I was all bright eyed and ready to show them how things worked and I mean just about every 15 minutes they would say why does this work like this and we'd say well that's what they told us to do and they say but that really doesn't work for me and you know oh okay and you can hear that a few times before you kind of think well I can't just keep blaming it on the product owner I can't just keep blaming it on the web team because at some point it just gets to be ridiculous like why were we making these decisions and why was the client just completely ignoring what the content editor wanted and half the time they specced these really complicated features as a way of making things easier for the content editors and in the end they hated it it was so automated they had very little freedom and I think the client thought that they could kind of reign in bad behavior by having a lot of limitations in the CMS and it really didn't work so what came out of that training and I did about five of them so by the end I just said like I know, I know you hate it but just I'm just gonna show you how it works if you have feedback on why you think it should work differently please follow that up through the appropriate channels but I can't help you so find out about how their current CMS works talk to them, do they hate it? probably why do they hate it what do they hate most about it what are the top 10 things they hate what are the top 10 things they do every day that they wish could be made simpler on the off chance that they love their CMS find out why they love their CMS are they gonna hate you for screwing it up it's probably not even that complicated like content editors they have a very difficult job and I did this job for four years so I know how it is and there's just nothing more exasperating than being shown a brand new CMS that you had absolutely no input on and just sort of scratching your head and thinking why did they do that that way that just doesn't make any sense so you just need to insist on it just say it's built into your process if the client says no we don't want you talking to the content editors just say you know what I know it's probably really politically delicate and sensitive and you don't want to open a can of worms but this is what we do so we're gonna come in we're gonna have this workshop you can be the bad guy you can settle disputes but it's just really important to get that feedback as soon as possible because like I said if you wait until the end of the project and you show them what it's like and then they get their feedback then you have a hundred angry people criticizing every little thing and even if you hear from them at the beginning it's a nice way of kind of explaining if you prioritize the things that you want us to do most we'll probably get to those we're not gonna be able to do everything you want we're not gonna make you a perfect system but just giving them that tiny little voice and making them feel like they've been heard can go a really long way so this is kind of along the same lines but you're building a content management system you're not just building a website so matching the design is just not gonna cut it because a lot of times the design doesn't specify how the backend's gonna work and that's a really critical thing so there are always a lot of different ways to do it in Drupal and you need to pick the one that works best for them and the only way to do that is to talk to them so find out who's gonna be performing this task how often are they gonna be doing it you know you say well there's a really simple way we can do this but it might take them a little longer to do it in the CMS so is it worth spending a couple more hours of development to make this a simpler task and this is a wireframe we got from a client it seems very straightforward a bunch of blocks with some dynamic lists and it was a layout that only appeared once on the site so this was not a repeated layout it was just a once off page and it seemed really obvious to us once off layout there actually isn't any original content on this page at all it's all references to other content so we said panels, beams, blocks and views no problem we're using that elsewhere it's very simple and it's very efficient the problem was when we delivered this to the client they said yeah it looks right on the front but why isn't it a node everything else is a node where's the node edit page I'm so confused how do we manage it I don't understand why there are all these little tiny different things that I have to edit it's not just all on one page how can we fit into the content hierarchy they were using a really complex hierarchical structure and we used the node hierarchy module well we didn't know that this page was in the hierarchy we didn't actually have a place there but they intended to use it that way and of course since it's not a node you can't put it in the node hierarchy so that was a major problem and the other problem was that they wanted to be able to track revisions and beams at this point are not revisionable so that was just another kind of tick yep okay we did it wrong probably and it just didn't make any sense to them and the thing is it's not as if we didn't ask the right question we didn't even ask them any questions because the idea that this should be anything but panels, beams, blocks and views was like just never even under our heads but in the end we rebuilt it as a node and I actually don't think we set up a content type just specifically for that one I think we did it like a display mode situation so it wasn't a total disaster but I mean from a technical perspective our implementation made perfect sense we could defend it from a technical perspective easy but it just didn't meet their needs so it really didn't matter that it made technical sense it was kind of a minor thing it only affected one page and we fixed it but this wasn't the first time we had a misunderstanding and it definitely wasn't the last either and I think it really led to a dynamic where it just got contentious because we would make a decision, implement it they would tell us they didn't like it and then we got really defensive we did this right because these five reasons and we shouldn't be defending that after we've done it we should be presenting them our plan and then defending it before we build it so that it can be a lot easier to change things and change our minds so like I said it was a small misunderstanding and in the end we fixed it but these kinds of things really build up and just can make the client just sort of feel like you don't get it and the other point is that like I said this only affected one page sometimes when you make a decision like this it can affect the entire site architecture so it can't really be fixed without a major cost so it's just another example of how we were just thinking different things we were thinking how to build it they were thinking well what's the best way to manage it so we just didn't consider how our approach was going to affect them so the next time we came to do something like this I started thinking about how we can find out what we need to know so this was another build we did it wasn't a complicated build it's a simple enough design but for a content editor a page like this raises a lot of questions the developer would say yeah this is no problem I can do this in a second but that's not really the point the point is how are you going to do it and the client wanted the ability to customize that sidebar content but the client will say yeah I want to customize sidebar content okay well do you want to do it per page do you want to do it per section do you want it to be a URL based sidebar content do you want it to be taxonomy based do you want it to be based on the menu there are so many different ways you can do it so these are just a few of the many many ways that you can do this a field on each node that's a lot of work right they can target each page but it's a lot of work and you're going to get a lot of duplication one page per section it's a little bit more complicated to build but it's a lot less content to manage and also a little bit less flexibility because every page in that section is going to have the same content a field on each node but it inherits if it's empty that's even more complicated to build but a lot of flexibility again you can apply it to a lot of content or override it if you need to and then the final way we thought of is block visibility settings which is really simple to implement and it gives you a lot of flexibility but it can be a little bit scary that manage block page there's a lot of potential to break things on that page so you really have to kind of trust that people are going to know what they're doing there and I mean this is four of probably 25 different ways you can do this and each one offers a different balance of ease of management ease of development and just complexity in general so you have to think about which one's going to work best I mean you're not going to go to the client with 17 different ways of doing it and say hey which one would you prefer think about it from their perspective how many people are on their team how many people are going to have to do this have they used the CMS before do they have any technical ability or are they you know that kind of Microsoft word mindset have they ever seen Drupal before do they understand how it works do they currently do this task in their CMS and how do they do it there that's a really important one that I think people forget about there's nothing worse to me than when the client says but in my old CMS I could do this and you want to say yeah but in your old CMS it took 24 hours to publish anything but you can't really go there so you just you have to kind of get to that before so ask them so when they say something like I want to be able to customize it you have to understand that there are so many different subtleties and nuances to the different approaches that you can take to this do they need to version it like I said before we implemented beans which work really great but you can't revision beans so that's a really major one and then again are there ongoing maintenance implications so say you set it up using context well we save context and code so if they want to change it down the road are they going to need us to update a code setting and in the end we thought it over and then we went back to the product owner and we said what do you think about block visibility settings she was really familiar with Drupal by that point and she felt really comfortable using block she said yeah that sounds good like I said it is a little scary to manage block's page so what we did was we locked down the permission and said only admin users can update the setting which in a way limits the flexibility a bit because you only have one or two people that can do it but it was super cheap it was super easy and it's really flexible so now she can target one page every page anything in between using any different number of criteria this is a quote from a client at the end of an inception phase at this point we had more documentation than we knew what to do with they said we thought of everything there's no way anything will change and of course everything changed everything that could change did change there were committees that changed their minds they saw the implementation like we did exactly what they asked and then they saw it and they said oh you know I think we actually don't want it that way we want to change that and sometimes we said we're going to build it using these two contributed modules well it turns out actually those two modules don't work well together at all so we're going to have to either do this customer find a different way of doing it but the point is that it's not that that guy didn't have a clue he really thought well we've sorted out everything and there's no way anything's going to change so that's really the at the moment I at the time he said it I thought oh gosh he really doesn't know but that's not the point the point is that he's never done this before so we've done it before a lot and we're supposed to be the experts so it's really our job to let them know that the end of the inception phase is not going to be the final word there are going to be a lot of things to do after that a lot of changes you're still going to need a lot of input from them and so when the client says something like this it's really important not to just laugh it off and say he's in for a treat you really have to kind of educate them and slowly but surely they'll catch on and they'll understand what they need to do like it'll get easier basically it gets better as they say so that product owner who might start off with a frown finds that as you keep asking him questions and as you keep peppering him with feedback he'll get better at giving you what you want on the first go so he'll say I know how I want this done and I know what to tell them so that they don't have to bother me again which is good so it really is our job as the Drupal expert to get from them what you need from them so like I said things change clients change their minds developers change their minds stuff sometimes just doesn't work so the really important thing is like I said not to shy away from this and not to say sorry you told us this this is how it's going to go it's really fine to go through these kinds of back and forth feedback loops we don't actually call them change requests like I said we do add up but the idea is still that it's an ongoing process so you're gonna hit road bumps and you're gonna you're gonna have problems but it's just about honest communication and like I said before at the toward the middle and at the end of the project is when you really need to start thinking back to that project vision so as you come down the line and you keep getting these the features to start piling up and they keep making things more and more complicated it's your job to stop and say hey we can do this we can do anything you want but do you really need it does this align with the project vision can we even do it right in Drupal you know does the client keep adding on feature and feature and feature and they're having you rebuild Mailchimp in Drupal say no we're not gonna do that there's a Mailchimp module sign up for a Mailchimp account it's gonna cost you a lot less money trust me so just think about is this really adding value they're paying for it but are they gonna get anything back for it and then where you need to redefine them change the requirements simplify their requirements deprioritize things and just plain eliminate things but at the end of the day it's all about being clear and telling them in Drupal how you're gonna do it so make sure they understand what they're going to get rather than sort of the surprise here's your UI hope you like it it's really just about open communication and speaking in Drupal terms and demanding that back from them make sure they're engaged it's a system that you're building for them so this concept that they don't need to know the Drupal side of it they're gonna need to know at some point when you deliver it there they're gonna have to learn it they may as well learn it at the beginning it's gonna make everybody's life a lot easier and like I said we do agile but I don't think it really matters what methodology you choose I think this is still really important any questions? sweet oh sure how we manage budget well it depends on the client to be honest some clients don't like the burn down aspect but I think it's all about like if they've agreed to it then they understand that they're burning down against the budget and it gives them the flexibility of not worrying about scope creep and not forcing them to fill in change requests so some of them are really nervous at first and they say yeah I know it's agile but are we gonna get what we are we gonna get what we wanted and you can say yeah yeah like you can tell them all you want you can reassure them all you want but it really takes just the first few weeks I think of building in Drupal and showing them after a week they have a functioning CMS really about building up that trust and like I said we send out weekly reports so every week we send a list of what we've done how much it costs how much is left et cetera but it really is just depending on the client it's whatever makes them most comfortable but really once once you have the budget like I said it's 20% that pie chart was 20% inception 10% delivery and 70% construction but if you found that the inception phase only took 15% of the budget that's 5% more you can use for construction and they really like to hear that they like to hear oh cool more money that's a good question I'll have to go back I'm not actually sure let's see the question was how did we resolve the requirement about linking to a node and being able to see the link that's on the target and those G's maybe we didn't like I said we're happy with a simple version of it let's see which one is it oh it must be possible to create income within pages if the anchor is clearly marked for authors I would say I don't think we did because if you really look at that closely I don't know what it means like authors must then be provided with a simple mechanism to browse a list of relevant anchors when creating links to pages so when you search for a node to link to you get presented with a list of the anchor on that node page yeah I have no idea how you do yeah the question was do we use red mine and how do we find it I love red mine I've used it before but it's really simple it's really kind of just the basics it's just what you need and I think it gives you a lot of flexibility and a lot of visibility and I think that's one that goes back to the agile budget thing when the client can see exactly what you're doing I think they feel a lot better about you working away all week kind of in a bubble they can see what you've done and they can see how much time we've logged on it and we do have clients that say that seems to take a lot longer than I thought what's the story with that and there are forums and there are back logs and there are a lot of plugins for red mines that you can do to enhance it and extend it I would say dated is I think is the wrong word I think it's just really minimal so base camp is really pretty and it looks really nice but I think it's also kind of overkill and it has a lot of flowery features that can get in the way whereas red mine is basically an HTML page with links on it so I mean you can embed images and you can embed media and you can upload documents but it's very I would say it's very utilitarian but in a good way yeah and like I said there are plugins and extensions you can you can theme it I'm sure you can make it look prettier but seems like I don't know this is my business director so yeah but it's never a surprise so yeah you're never going to get to the last week and you go oh my gosh we're not going to finish it's so it's so clear and everything is estimated and so it's much more you're much more ahead of it than that so halfway through you can get a really good idea of are we going to be able to finish everything that's in there if we're not there's ten things in here we think we can do six if we simplify those six we can do eight if we simplify them even more we can do all ten there are a lot of options and I think a lot of clients that might have been afraid of agile at first find that really comforting and actually really cool they don't have to fill out a change request every time they want something and you're not constantly fighting them and saying actually that wasn't in the RFP so we're not going to do that unless you pay us more and you don't have the ability to do workshops and you do have kind of limited access to requirements I think obviously like I said budget for it and explain that it's required and really try to educate them about the fact that if they do tell you what they want they'll actually get what they want and the way you can do that is like say if you have a client that says I don't care about Drupal and I don't want to talk to you go to them and use that as evidence so if that's the case if they won't tell you much and they won't give you much access the first few times they get contentious and the first few times that you find they're not getting what they want take that as an opportunity to start a conversation about you know if you did learn a little bit about Drupal and if you did give us a little bit more feedback you'd be a lot happier with the result but I mean of course some clients won't hear it so they'll hear the word of the requirement it's an unfortunate situation I mean I know that it does happen but there's not much you can do other than stick to the letter of the contract should be okay yes that's right fantastic Pam look could you please show your appreciation for Pam Barone and it looks like we're going to get an early minute and during this early minute you could perhaps fill in your feedback in the evaluation forms on your program schedule page you can do it for this session and also the other sessions that you've been to that would be great