 Good afternoon. My name is Nicole Land. I am a central health agency which is located in the U.S. Our primary location is in New York. We are a virtual company. And my session today is I am leaving New and it's basically the risk of dumping in your old format for Drupal. And that oftentimes I see a lot of sessions that talk about moving to Drupal and why we should move to Drupal. And I had kind of the idea that I should prevent the sessions because once you've made that decision and you're in, then what happens? So, there's no further ado. Let me get started. Five assessments. Of course, one of the things I'm going to talk about is, of course, the hidden reasons of moving. And then, yes, people with bad news, CMS is going to move to, but there are in fact risks. There are often unrealistic expectations, hidden costs, change management issues, and, of course, unrecognized risks, which is primarily a lot of what I'm going to be talking about for most of this presentation. And it was funny that I had actually suggested several sessions, and this is not the one that I thought was going to pick up, but it's somewhat concluded that this one did because it almost wrote itself to be just a very large implementation with the U.S. Department of Energy, the Group of Seven, and pretty much this staff in dedicated to that project, which I will get into more. So, what I will do, of course, is share my professional experience. And my professional experience, as I said, has just come off of a very large implementation with the U.S. Department of Energy, which is my most recent site. I was the lead manager, the project manager. I don't like to often call myself that. Prior to that, I was also the lead project person for Lifetime Employment Movement people about almost five years ago. It was one of the largest people institutions at that time, with like 30 million units a month, so it was pretty large. I've also since then did that company, moving on to a site called the Post Game, which is a Yahoo! Sports site. And before that, or right after that, this is street.com. So, I was pretty very fast and pretty small and fairly large. So, you know, I feel like I do have the experience to kind of share with you at this point, a lot of moving to Drupal for my old CMO. And who would I be not setting goals as a project manager for my sessions? I always like to do either pretty self-explanatory, set the expectations, talk about the management issues we've dealt with before, provide a list assessment framework, then am I surprised at it? And of course, any of you that haven't been involved in the management assessment, there are some time-sanity issues involved in a large number of things, and I would talk about that as well. So, one of the first things I like to do with approaching a project like this, and again, smaller large, and they often involve speaking some understandings. And before I even get into the details of the project, I'd like to get my head straight because I call it and formulate some of the key issues that I will encounter as I approach this project. And first, there's some things, and again, I'm going to have to read some of the white part. It's important what I call Drupal Double Speak. And essentially, Drupal Double Speak, and I'm going to have to get low on my screen because I can't read it all clear, and essentially, it's kind of a euphemism. So, someone said downsizing versus layoff. Downsizing sounds a little softer and gentler than layoff. So, there's a lot of Drupal Speak that goes into Drupal Migration Project that you should get familiar with. There are bugs there. And of course, being the first, which is I could move on, there's a module for that. The application usually looks being stated to you as you start to engage in a project like this. But to go, the final goal is already built. I think we've heard that quite a bit. The truth is, is that there's generally a lot of customization, a development work, but going from sitting the designs and functionality that a client or the organization is in fact looking for. That's the first Drupal Speak. Final designs. I love this one. It's one of my favorites. Of course, the designs are almost done. And just a few more quick, essentially, you know, you'll have what you need, but it shouldn't change functionality. Once again, the way of this is often just even some of the smallest things that you design can change some significant functionality in the site that you're planning to build. So, be mindful of that. Flexibility. I hear this one a lot. This one came up a lot in the U.S. Department of Energy. If there was a constant statement after they had kind of pulled the idea of going to Drupal, is that we want a more flexible content management system. What does that really mean? And what we came to find out is that they wanted a CMS that essentially actually would be seen like an out-of-the-box pre-prop software with no bugs. The truth is, is that in that case, we were building completely custom implementations. You know, most people take time to roll out. And often, there are bugs longer during the deployment. So, be mindful of that one. Hockey rates. Often, I hear this. Is that a 4-star property statement? Is Drupal a spring? But in the Drupal double-stream, be mindful that every Drupal project is unique. And sometimes, there are hidden costs. We haven't got that. Like hosting or support. Those are hidden costs. And sometimes, you know, on a given project, it has to look even more expensive. And another good one is there's towers all over the world. The clients have often said that, you know, they probably could just go out and get anybody, you know, anywhere. And the fact that I spent some time at the hotel and I met a gentleman who was here previously trying to recruit. And it's, you know, even in Europe, from what I understand, it's even difficult. I know the market in the U.S. is terribly hard to get Drupal development out. So, no, it is not as easy. And be mindful, again, that not only are you confronting finding talent, you're confronting different management styles, considering some given implementation. And finally, this one came up a lot again in my last project, and it's critical launch issues. Something came up. Critical launch issues are a large implementation. Often times are what I call, I would say this bizarre, unknown use cases, that oftentimes don't have a, you know, a large impact on a final product, but it often deals with maybe a stakeholder who yells aloud, and this may be a balance, but essentially it could be a very small thing. So, again, the double C. And one of the things about engaging in your migration project is getting to know your language. Secondly, the things I like to wrap my brain around are the people that you work with on a project. I'm currently calling them tribe members. It is a community once you start to put together a implementation project or a migration project for people. And that some of these are finished off as finitary and others out of just some detail. And that often when people are selected to see a matter, not everybody is talking about it. Just know. And it's important that if you're going to be successful in this engagement to recognize, again, the people who you are working with and the different types of roles that people take on, and even after a formal role, like a chief implementation officer, the behavioral roles that often happen in the project. So the evangelist is typically the person who, you know, spots the people. They're that person or person who said, okay, this is a good idea. Let's bring it to our organization, something that we should do. And usually no problem with this person and that the only thing I often encounter with the evangelist member is how well they've sold people. It depends on what they told the client or the organization about what people in fact can deliver. So going back to some of that Drupal double state today, well, you're going to get this ultimately flexible CMS system. Oh, it's going to save you, you know, millions of dollars. So your evangelist is trying to keep your ear out for how they've cut out from school people to the organization. The second message is in the cost of aggressive members, and oftentimes this member needs to recognize his or her new field. And I think that you can't quite figure out how it got there because they're not usually a very vocal member of the team, but they're typical styles, something that is subversive, you know. And that if you're versed with anyone like that, they're pretty easy to recognize and be mindful, and they do need to be mentioned and confronted when they become difficult. The third member is the open hostile member of the team, and they pretty much speak for itself. They're going to do any type of project that some folks who would just word it out. Fourth is the know-it-all. And I probably shouldn't say this, but the know-it-alls are often legacy developers in the organization and they're often not as proliferous, but because they're somewhat stressed about the introduction of people and having to learn a new platform, a new development platform, and so they wouldn't have conflict with the Google developers if, in fact, you know, there was a different team of folks and, you know, just supporting them and things like that. So they're a little bit of an organ, but they're only a little bit of all. The athletic member, of course, speaks for itself because he's the person who took care of that. And he doesn't give you much time on your project other than if you have a dependency on them in order to do, say, content entry and they're not there, but interestingly, they're the ones that find that in the schedule that you have set up, it can affect them. The field member, a very, very important member on this role could potentially be playing either a CTO, a CTO, a director. I've even seen this role taken on by, you know, a lonely production manager. Like, this is the person who used to be others I've made just now, but they are then all defending to the death. They will defend the developers. They will defend projects. They will find resources to make this thing happen. And it's a role that emerges often in projects and it's not someone who you kind of know from the beginning. And it's not necessarily an ambulance. So look for that field. And there, you know, it could be you. It could be the project manager, but the field is an important role in a migration project. And last but not least is the chief, which is fairly self-explanatory, but it's actually the person who keeps control over all these people and keeps things moving and, you know, keeps the warfare and the struggle and the back and forth down to a minimum and continues to talk away at the budget and keeps the teachers that's rolling out all the while while managing all the bubble speech and private members. So that's the chief. And that's been one of them as well. And finally, kind of the last area to get your head wrapped around on a migration project is moving to Drupal is a big change for a lot of people. And I think, you know, there are a lot of, you can go to some questions here that talk about the technology and there are a couple. And that's all true and we can all kind of adapt to, you know, hosting the best way of the technical work, all of that. But oftentimes what makes a successful migration are the people involved in it. And if there is a lot of change that's being introduced in the project, particularly in their workflows and their style of work, people get scared. And that I know on my last project, some of the work actually resulted potentially in sound sightings. People losing their jobs. When you're selling a project that says saving money, sometimes saving money means personnel. If people get scared, don't be mindful of that. And depending on the type of change and how it impacts these individuals, oftentimes the passive aggressive and open possible, I'm usually just folks who are dealing with a lot of change. So again, people are scared. The speed of change is important. Unfortunately, a lot of web projects have time to market these and don't have the opportunity to introduce the change, you know, to change slowly into the organization and get all of the necessary buy-in. So again, more conflict and more risk. People react differently. Once again, I talk about the various roles. Some people deal well with things and run with them. Others are scared to death and will, you know, dig their feet around and will just essentially stop moving. And last but not least, and most importantly, is that change is a risk and that that's pretty much the foundation of this presentation. Moving forward are managing and dealing with the risk of moving to people. Once again, migrating is a terrible risky and what to do. An illegal thing I would say about this before moving into it. One of the things that I think has made me especially successful on a lot of people's migration projects is the fact that I managed to do it. The course of project management often is about managing the cost to schedule the quality of the product, which are all important, but I just kind of put risk above that and that schedule, quality, and budget, there are a lot of known things. And if they're already known, there's not a lot to manage, which they're managing over risk that come out of this thing. So that is a fact. So identifying the most common risk in a migration project. One of the biggest is no typical experience. It's great when I encounter an organization of the people who they haven't reached one person who has used the Drupal CMF makes the project so much smoother. It's almost a nightmare when no one has used it, has ever seen it, and they are thoroughly entrenched in their legacy of CMF. That is a very, very difficult project and there are a lot of important risks that come up. Of course, unknown dependency, scheduling issues, typical, double data entries, how we can say a note about often, when you're migrating, you have the old site and then you have the new site and that there are a lot of skeptical things that you can do on the screen, but that's not what I'm talking about with presentation, it's all the land printing and it's essentially getting your contributors and other cordials back to buy into the idea that they're going home and that they're going to have to pay for the information. Not only do they open to them for a while, but the new ones as well. They don't like that. Of course, you are packing a breath of an open household and you just double data entries, time period, as an opportunity to add that. Second, let's put the end of it. Unidentified block behavior. I mentioned this one, because this happens a lot when I'm seeing lines in my offerings. The block, often don't have a descriptive information. If it's identically generated, it is funny. It doesn't need overrides. Get it clear if you can from the very beginning. If you don't, you'll build the block, you'll build maybe six of them, and find out they're not exactly what your clients or your users expected of the behavior of that specific block. And then, of course, in the legacy system does not have a clear integration path. There are, I saw even assessment talks about this. There are plenty of technical solutions, but, again, once again, it is a risk if there is no clear path. And, finally, lack of clear content mapping, which is related to the above, is that as you're creating a migration plan and looking at no content, of course, the content producers haven't quite thought about how their old content is going to, in fact, map to the templates, to the layout. So, again, something we can expect. I just know users and stakeholders in the organization, of course, do not forget their technical skills because they're technical. In fact, they know the most about people. It doesn't mean that they cannot expose a lot of risks in a migration plan. And, in fact, hopefully, it is a group of people who, typically, don't observe it. So, make sure that you're talking to your hosting folks who are liberalized and they'll realize they can identify in a project. And spend time with the editorial content contributors because they have expectations about how they're going to conquer the system and what that administrative interface looks like. Again, often overlooked in a migration plan. Setting up a trap, I think this is not practically highly scientific, but it's seeking down to some degree. And managing risks is very important in a migration plan project that's admitted and currently listed. And that many format farms are available on the Web. You can just basically do a Google search for risk analysis. There are hundreds out there. Plenty of formats. I'm thinking a couple of different formats and I'll walk you through a few of them. And it's, but a foundation part of it is the likelihood of the risk occurring and the impact of the economy project, which is what it is. It's a format that I often use but sometimes I keep. And, you know, this was a little bit more detailed than that it being almost certain to happen, 95% of the time, likely to happen, 55% to 95%, possible impact. 65% unlikely, 35% or rare, less than 5%. If you really don't have a lot of time, I mean, well, that works too. And hopefully you can see some of this, but I'll walk you through it. Once again, these are impact definitions. The impact definitions, you could get a little bit more positive things creating depending on the specifics of the project. And you do what you want to talk about impact in terms of cost, federal and impact on the project. So this is one that I'm using my last project and that we talked about very serious impact to the project which is essentially meant that we were not going to be able to launch or it was going to produce a 10% jump in the budget so it would be a fixed rate project. So a 10% jump in the budget was going to mean it was probably serious is you could probably live without it but should be mitigated and that it would probably mean some changes in functionality but so business companies are going to be pretty pissed off about it. So moderate is often something that you can live with but again it does involve constraints and it can be lower and lower whereas the last in minor and again depending if you're working on a financial site even minor risks you might want to mitigate that but that's really your call. So this is a sample assessment I pulled out four of them just to give you an example and so one being and that's the very top dollar this is raised to me because it's a lot of money and it's a lot of money and it's a lot of money and it's a lot of money and it's a lot of money and it's a lot of money and it's a lot of money and it's a lot of money and it's a lot of money and it's a lot of money and that's where it's raised to me to make decisions, and they were burning for a fifth rate budget. That's a risk. Impact on the project was pretty minor. So we, I'll talk about what we decided to do about that later, we had emergency requirements after the discovery phase was completed, this is standard, all the time. And if you've even done an extensive discovery, I guess your requirements is really a fair act in effect. This is very likely to occur, but we saw it as a moderate risk. Thirdly, they had to make a decision on this whole thing. This was very serious because we was fascinated to get our development environment set up, maybe get our staging environment set up, and then ultimately this would impact, you know, the development timeline of the development of all types of work. So hopefully we were very serious and very likely to occur, and I'll ask you to put an end to this. And last but not least, there was no clear migration factors. We spoke about this before, we were migrating from a CMS system called Red Dot, and Red Dot does not have a clear migration factor useful, and so we just needed to note that, and it just kind of sat on the table for a while. So finally, I'll talk about what the mitigation plan is later, but it was almost certain to happen, and we established that many people in the study couldn't find a path to actually get the content out of Red Dot successfully and to do so. So creating a written mitigation plan is a useful migration factor, and that there are kind of three foundational things that we're going to do. So one, here are some common goals, like before you come up with your own creative one, you need to address 80% of your problems, which they probably will break, and set clear and measurable goals. Clear and measurable goals are really important, I'll talk about that in a minute. Conduct the project discovery, provide as much training, adapt to the policy budget, and schedule the lab. Those three things will get you out of a lot of risks. So setting clear and measurable goals. When I put a couple up here, again, these are all real, you've heard them, first thing, we are moving to groups because we want our school labs to be more flexible. What is really more flexible than we need in this? What does that look like? How does it, another, we expect to save a lot of money when we do this. So we're looking at that for a really good time. Very important to collect that detail, because if you see, in a statement of work, for instance, it says, you know, spend a lot of money, if you want to get to the detail, so that you can actually work through this thing. And then I had another project, where they said they wanted to bubble their topic a month after they launched. My personal interest to do, that easily takes about six months, I'll tell you some people want to take a profit, stabilize and increase. But that's not really what it's often times just a gift. So we felt that was an unrealistic statement, and we asked that. It was very, very important. And all I will say to this is that I know a lot of projects when you engage in them, do not actually have the budget for contacting them. They help everyone involved to understand what is going to happen as much as possible in this context. And it's the key to minimizing risk in a collaboration project. That is helping the culture, the political beliefs that are going to be put in place, the document and the requirements. It also is ideal for, I think we put this in the project discovery documentation, a project overview. I mean, there's, even if it's not going to be a long extended one, do a split one. Even if it's for one day, you can put a list of questions together that you can swap out into teams or with your clients. Things that you just really need to know before you start to engage in it. The more you know that ahead of time, it's the left and right mistakes and mistakes that you're going to tell at the actual good point there. Training and documentation. Again, I think that's what's dedicated to this. Just a slide to indicate that very, very important and as a risk-making plan, there are often some things that you can do with budget development. Often what I would do is create an inline documentation as much as possible in the group of SNMR versus creating a group. Only because over time, it's extraordinarily difficult to maintain budget in both places. So, you know, you want to be kind of tight on your penny, try to do inline as much as possible. Another technique that I use is I do a lot of demos for our stakeholders to often include functionalities that we're building. Often times, those are recorded and we post them and then make sure that we're using them for other engines. So, it's a great way of, you know, saving training time. And last but not least, is maintaining some sort of project training. I can't undertake this enough. When people are running around looking for stuff, it's just a complete waste of time. So, at the very beginning of the project, that's essentially what you're putting. And so, putting everything together, we're going to talk about the risk assessment. So, what I did is I went ahead and indicated whether we were going to mitigate these risks and what the actual plan was. And so, in the case of the first one, that worked wisely to occur in my nerve, we decided not to mitigate it and just said we left it blank. And second one, in terms of experiencing requirements or actually emerging requirements after the discovery thing, we decided to mitigate that one. And what I thought when we moved to the ticketing system where we put the entire feature set and broke it out into the ticketing system and that we tracked changes against that feature set. So, of course, it logs into specific features, but as well as improvement requests. And it makes that very, very clear and we continue to put back on the stakeholders to make them understand what you're asking for. This is what you described in the feature set and just continues if you want to look to it. And when you're talking about a very, very large migration project, it's just really hard to keep track of on a ticketing process. So, you know, just the system that we often use in Europe, but anything, a bill of whatever it is, a lot of them will give you the ability to do that. The other one is that the motion solution was not in place by the date that we needed it by. In this case, we had to push the law state. We were communicating it out on tickovers. Sometimes, you just got to do it. There's an incident that comes up in a project that you must mitigate, but often it means going back for more money, putting a date, or changing approach. And that, back to me, is no clear migration path. This one, getting back to that one, how this one ended up being mitigated is that the client decided to do manual data entry. They didn't pass the timeline, they decided to do it, but they didn't want to spend the money to hire outside vendor consultants to actually do the migration for them, which is their choice. They were willing to deal with, you know, the craziness that ensues around the money. Really, I had to do this. Distributing and publishing risk and measures in the program. The initial risk perception I usually take in the project discovery documents. And at that point, I've also been uploaded to the Federal Repository. I send it out on e-mail. I'll run away at meeting. I'll talk to the stakeholders. Make your risk known. If you are managing a project, a migration project, you don't want to be the person who gets in with, you know, the red cloud saying that there's an issue. But oftentimes, people are not going to be angry, I mean, to you, but they would rather know a predatory way to expose those risks and escalate them and verbalize them instead of kind of grumbling to yourself, or, you know, this is going to be, you know, horrible, and just, you know, talking to the other project members, escalate those risks to all the appropriate stakeholders and documents. I cannot underestimate that. It's the importance of that in the project, like this. In terms of final thoughts, what I would say from my experience, again, getting into mindset is be very, very decent. These are difficult, complicated migrations. And the people, and the dynamic, wonderful system, I absolutely love it, but not everyone grasps it, they don't go, they're not. It's not as easy for some people to actually understand it. In fact, I had a client recently, and they actually had been doing Google Fix for a while and were showing if there's the amount that they had built and, you know, they were talking about how they wish that they had a way to search the project. And they were like, well, where are you on the front edit tab and you can just click through and you're doing that kind of thing, which is just poor Google. They somehow, some developer a while back figured out how to strip it of all of its native Google personality and that they had no idea. And so you have to be patient. It's just sort of things like that. Not everybody is moving at the same place you are. Again, understand your situation. I talked about the people and the double-take. I would say your biggest risk comes from the people in the project. The technology oftentimes is too easy. It's the personality that you're having to manage. So to learn those personalities, learn those roles, there are probably a lot of things that you've identified. Learn to deal with them. Particularly if you're dealing with someone opening a house close to the property, they're not going to catch you off guard if you know who they are. This is kind of the standard way that they're going to be paid and you know who they are. You could basically deal with it without being angry and upset because they've caught you off guard. So know who your people are and manage them. So be incentive to how others deal with things. Remember, people are open to something. It's free. And because people are moving it to a massive rate system for money, saving money means people's jobs change. People lose their jobs. Organizations, you know, reoccupies and structure themselves. And that is pretty scary for a lot of people. Identify your risk of went through and trying to do that. It's very basic. There are certainly advanced ways of doing it. They've got formula and can do risk formula. But again, if you've got projects and you often don't have time, they're quick and dirty. High, medium, low or percentages will work just fine. But as long as you're writing them down and identifying them to your stakeholders, that's what's important. And then last and not least, if you put together the things that are unknown in a project or those risks, the more successful your projects will be. All, as I said, all digital migration projects are weekly. Very good question. I'm going to repeat that. Audience members said that the personalities are very interesting and that at what point do you decide to walk away from a client? Correctly say that. Okay. Well, not me, but my company is in that situation now. And for us, often walking away from the client has to be with my guests to be honest. And we often look at our hourly rate, and if you're telling us a high hourly rate, if you don't tell people to deal with them, if they're difficult, they'll deal with them. If they're not paying us a high rate, this is very simple. So that's one way of dealing with it. Sometimes it's not just about the personalities, that if you have really good names, then again, if you have those past aggressives and an opening house file, they're not actually that difficult to manage. You just have to figure out how to get around them and how much power do they have. I mean, also in the opening house or past aggressives, it's not the advantage, it's not the person who brought people to the organization, it's not the reason they're here. Past aggressives in the opening house both are usually developers or content editors. They make the project difficult, because they can't necessarily ruin it if you let them. So, any other questions? Gentlemen here. Another personality question is gentlemen in the audience said that her first couple projects were destroyed by a massive aggressive type and didn't see it coming. What are some techniques to deal with them? The way that I deal with them first is to recognize them, because if you don't see them, yeah, they're going to run on over you and they're going to send those perversive emails, they're going to, you have a situation where you have to go to the same place and they're so great. They have an internal development team and they go back to their internal development team and they basically railroad with, you know, crazy questions. But that's not all. So, first is recognizing them. If they keep at all, they can bump them. And that I, in fact, in this most recent project, I went to the evangelists and the stakeholders and said if this person persists to behave in this manner, I gave a list of behaviors and your decision to deal with them or not. The passive addresses need to be converted. It cannot be ignored. They are subversive and they undermine your project and can help them. It's a difficult personality type to deal with in a project. Again, we have a lot of clients who give you a lot of examples. One in particular right now who has some experience with stick and because we just did Department of Energy with seven, we feel like, we pretty much have our trust in seven now and we're trying to move them to seven. We're getting a lot of clients from the development, their internal development team wanting to do things in the sixth way and that because they don't really know some of the changes that have happened with seven, we decided to, you know, take a turn up a different architecture approach and what's important there is explaining and giving detail as to why. And that, um, so one scenario is if they have an internal development team, they're working on six, and it's not six, it could be in five to six, it could be, you know, whatever the jump is. But it's also explaining what the benefits are and don't assume that they know what they are and move them from one direction to the next. And I find that that's generally very helpful is to explain the differences in what they're going to get out of it and why this is better. But doing things the old way is not necessarily going to help them. So that would be one of the scenarios. But yeah, I've been confronted with that situation and because I'm not the the company, I'll usually leave that so you might not leave that to explain how to flush out those constraints. Any other questions? Hmm. It's funny. I've done very small implementations and I've done really big ways. Um, I don't think that there's any optimal number. I think the better question actually we've stated the question. That's what I was supposed to do. The question from the audience member was what's the optimal number optimal number of team members correct? I was going to say for me it's not so much the number it's when you introduce them. So if you want to have 15 members on your team try to have all those 15 members at the very beginning. Don't try to interview 35 of them six weeks before launch. It's just really hard to get people up to speed. So if you do an adequate product discovery with all of your different people there's two people at the very beginning of the project but it's not the five it's usually when you're introducing two members for me. That's the question. Let me rephrase that because I'm not quite sure of the question but essentially it's that yes, the premise of this presentation is that there's decision to make your group lives on and they're made. And now you're asking where after that decision is made that just varies to me on top of it. Our last project and I've worked at every scenario last project the client actually did it. I created Jira account for a number of their editorial and production staff and they banged away at the site as they were entering the conference and which essentially started doing the ultimate UAT in the client handbook. We were happy with that. There were some shortcomings in that because they were not in fact professional testers and there were a lot of things that they missed. So, of course, Monday or the day after a lot of stuff for things that they didn't test often being results. For some reason or another that often gets missed but I think UAT people missed that as well. I've worked on other projects where they went out for QA team to India and it worked out really well. We've worked where they went in for QA team. One of my team members from three houses sitting in the way back home through the marrow and he was on a project the GATT and he had a wonderful internal QA team. They had even real quick, I think they were these test riders. We've had every area and I think I wasn't working on the GATT project but based on what I've heard that was actually just pure pleasure but that one worked out where they had an internal team who was familiar with the project and they were actually professional testers. So, I would say that's the idea too but it could be any scenario but I would say if you are a vendor do it in the contract because often people say that you're supposed to do it and you may not have budgeted for it and it's not ideal that if you're building that you're actually testing it as well. Kind of risky. What's your current theme? Okay, it's a question. The question is they're currently making decisions you've already made the decision to go to Drupal and they're just trying to decide whether to outsource the actual work. Okay, good question. I actually spent the evening discussing this topic and once again I've had a recent project in my class like this. One of the things I would say that our company offers and not everybody does is that we have a lot of senior lead done and what we will do is go into an organization and say okay, we're going to help you build the capacity of your organization we're not here to stay forever if you have any right now you have no way to in-house in-house talent and I'm going to suspect you're trying to hire in-house talent. Okay, so that's the program that they try to get some of that in-house talent that you're starting to commit before you actually start because if you start getting engagement say with an outside firm to get you up and running and none of that in-house talent is there they're not there to learn or garnish the institutional knowledge of the build and anything else so I would say get your in-house staff first and then hire a company. The other approach is if you can't hire any Drupal development talent which is very possible and you may want to look at a firm where you can have a long-term relationship with so those are the two approaches and I think they pretty much guide what the budget is doing at this point. If your schedule permits keep looking if it doesn't engage a firm and maybe someone not as expensive and over it will give you a discount based on the long-term relationship. Yeah. Yeah. The question is that the presentation is focused on getting a good clear start. Yeah. That's ideal but where else in the project what are the stages the requirement occur? Every state to the audience. Every single state and when I mention the ticketing system usually as I said what I like to do is get the entire feature set broken down into the ticketing system for which the developers work again so we don't have components it could be calendaring specific blocks it could be just a number of things and that because requirements keep happening throughout the stage of the project it's very important to have that original requirement that binds what that original requirement is and then a tracking mechanism to see where the dialogue is going. Do you hear the conversation of new things or it shouldn't be taken this way? If you're one of the builders make sure your entire team is aware of that. I am the school where I tell all my developers absolutely if you hear anything that is suggestive of a new feature or a change in scope that's when it's in it. You don't have to confront the person to do it. It's very, very important if you're in strong management to have that dialogue and that there is a tracking mechanism that they can reference. So open communication with your team is critical in making sure that they understand the difference. Once again, the last part of their work on it the client really didn't understand the difference between a bug and a feature improvement. They had no idea. It's a little bit of an education to teach people the difference between a bug and a feature improvement and don't assume that I get a workshop for them. I basically sat down and did an entire workshop with our client explaining the difference between a bug and a feature improvement. When I said you don't know it now that it's going to get really important as we move down the park and if we're finding out that we've lost they're flooding us with requests but they're not. This is a change in scope and I need to understand the difference as well. I might be getting ready I'm actually avoiding but the question is have I ever worked in a steering committee for a project? Let me say I'm getting ready to and that in fact the client as an officer in London will be visiting him on Friday and let me say I asked for the list of everybody on the committee the decision makers and sent me a list of 22 people. Thank you, but thank you already. So I have not personally worked in one I usually push back and enforce on the organization of the project. Give me a single point of context. That's why I'm they're not going to give me one. I'm going to have to work with these people but I'm going to cite it. I'm going to keep kind of rungle and see who the dominant personality is on the team and who carries the most complex and then try to kind of leverage the decision making into a couple of people's hands. I don't know if I'll be successful. Never worked on one but I'm going to. Any other questions? Very difficult and I agree with that. The point and somewhat of a question I talked about selling groups that can exist in teams and sometimes it's just the sell job was not explained well and they were not trained and oftentimes they'll come around. I do agree with that. We worked on a project. I worked on a couple of projects. One where the company, organization made no effort whatsoever to invest in their existing development staff provided no training brought us in as a simple development partner. We started developing their internal developers and they had no idea what we were doing and did not understand and essentially by the end of the project they don't fit. They had nobody to fund this project. They were out of budget. It was the call of the project. They were warned but decided not to be trained. Whereas another organization and it's expensive, hired long time staff, they have lost no one. But there is a few. There are a couple of developers that I have seen who no matter what you tell them, they are every fiber in their body is telling them that this is just wrong because who is wrong and it's just not the right way to do things. Yes. And I'm connected. So yeah. So I would say that's very true. The training your existing team is very, very important to the success of your project and that goes back to the gentleman's question over here as to get your staff on board before you bring any people support out in so that they can benefit from the work that they're doing with the people asking. And then the other additional question. Great. Great questions and I'm here for the time because I'm glad I actually ended early because it gave us plenty of time to get all the questions answered. Again, I thank you and I appreciate your attendance. Great questions. Thank you.