 Awesome, well, thank you everybody for coming this morning. We're really excited to be here and thanks for taking your time to listen to our session. So we're going to be talking today a little bit about finding the right Drupal partner through your RFP process. And just to introduce ourselves, my name is John Stewart. I head up ZenSource, our product development, business development, and really working with our agent scene development partners to develop web apps. I'm joined by Jake Bell, who's our chief architect, who's going to talk a little bit more about some of the technical details about what goes into things. But Jake leads up our cloud architecture and oversees the engineering for our experience platforms and code base. So a little bit about us. We are an open source platform combining Drupal hosting, Drupal support, and an experience design system. And really what we are geared to do is partner with our agencies and help clients provide a foundation, Drupal foundation infrastructure, and accelerate their web development. We're based on the East Coast, three offices up and down the East Coast of the U.S. and to work across a lot of different verticals, healthcare, education, financial manufacturing, so those are our big ones. So what we're going to talk about today is really a few different things. So this is really geared toward both the client side as well as the partner platform side. So from the client side kind of understanding if you're developing an RFP for a new Drupal partner, whether it be development, whether it be a Drupal platform, hosting support, et cetera, or if you're the site builder and fielding those RFP responses, what are the types of things you want to look out for, what are the types of things we're seeing and seeing success with when going through that pitch process and getting selected to work with a different client partner. So just kind of starting with the summary of truths about Drupal and what are the clients asking us? What are they asking us to solve? Why are they coming to Drupal? So starting with community or culture and industry, why do we love Drupal? It's flexible, it's grown to an enterprise level in terms of its security, we're able to get the market faster and we're minimizing financial risk with the tools that are available in terms of our time, in terms of our budget, in terms of the things the community provides. From a community perspective, leveraging the community to develop features, but also having it be easier to upgrade and support and cost, seamless third party integrations, making sure it's future proof. From an experience perspective, having the admin experience be marketing and content author persona first, sourcing what we can from the community, things like layout builder, various authoring tools, but also building our own features to streamline things for our client authors. And Drupal's constantly evolving from a marketing perspective, the API capabilities, cross channel marketing and being able to push content out. These are the things that our clients are asking for, whether they're already on Drupal or they're already committed to Drupal, or if they're considering it, this is what we're really hearing, what we're seeing going to the RFPs. And just kind of looking at who our personas are, who our clients are, what are we hearing, what are they telling us? They're saying that their current CMS is limiting, it's not flexible, it's more expensive to make updates, there's too much code that goes into making updates. The CMO side is probably saying, I'm looking at not just a website, not just a web app, but an experience platform, how are we driving conversions, how are we in the education space getting more admission fulfillment forms in the healthcare space, how are we getting more requests and appointments, things like that. And from our CTO side, we're hearing the needs of their current CMS is probably end of life. We're hearing more and more that why are we going to Drupal because it can live anywhere. We can develop it anywhere, we can support it anywhere, we can host it anywhere. And we're hearing from our IT partners that they like that freedom and flexibility to not be tied to one vendor, but in many cases have a smaller team and want to know that you've got a partner that can support it. One thing that's really interesting that we're seeing more and more, over the past couple of years in particular, I feel like every single client comes to us, every single prospect comes to us and says, I don't want to re-platform ever again. I don't want to redesign ever again. I want to do this one time and I want to continuously evolve. I want to continue to build on top of our tech strategy, build on top of the foundation. I don't want to come back in five or seven years and have to re-platform again or do a really costly upgrade. Going from seven to nine or seven to eight or nine is a pretty big leap and beyond that. I want to know that those upgrades are going to be pretty painless. You know, at Zen Source, one of our big features is that we maintain all of our clients for their security updates, but also we do all of their upgrades, incremental and the major releases so that they're always on the latest version. But that's, you know, I think in terms of the RFP process and understanding how you can deliver a web app and experience platform for your clients where they don't have to worry about a re-platform or a major expensive upgrade in the near term and can really focus on growing their tech roadmap, doing the things beyond phase one to really evolve that ecosystem. That's what really after and that's what we're hearing the most from our clients. And, you know, from the authoring perspective, often we're hearing that that old system is just not flexible. It takes too long to do things. Our brand's getting lost because maybe we have too much flexibility. So in terms of when we get these RFPs and we get these proposals to go and pitch our clients whether you're coming from a development shop or a platform for hosting and support and more like ourselves, what is success going to look like? You know, from the client perspective, we want to make sure that we're delivering on time and on budget but avoiding those hidden platform costs and those ongoing development costs being able to maintain that. You know, delivering a platform that is true to that strategy. One thing we often talk about is that Drupal should be a platform that really enables your digital strategy. It shouldn't be limiting that digital strategy. It should be helping guide and enable. So creating a platform that allows them to stay true to that strategy but also really evolve it over time. That's what success will look like. And all while making sure that that code base is flexible, the authoring experience is low code. It's easier to maintain with less developer support. And that ease of authoring, making sure that the onboarding and the retention with the internal audiences, that's probably paramount to anything, making sure that the authors can maintain this thing and retain the knowledge within the tools that we build. And we're going to talk a little bit more about this in a moment, but making sure that that content migration is smooth in the ease of that scale for additional content. The content migration part of the process is always the most time consuming. It's always the most expensive and it's always the most stressful because there's just so much that goes into it. And really factoring in the time, the budget, and making sure the partner has a really good idea of how to migrate that content and migrate it effectively is going to pay for itself tenfold down the road. So where do we start? Finding the right platform and partner that shares revision of that brand enablement and that strategy. So through that RFP process, finding the right development partner, but also finding the right platform for hosting, for support, for additional features, design system, whatever it might be, that's what we want to figure out in the RFP process is to guide and vet those different vendors to make sure you're finding the right partner that's going to meet all of your needs. So different things, different approaches to look out for, things that we're always working with our clients as we develop RFPs to make sure we're vetting but also things that, you know, from the platform side, we really want to make sure that we convey and build trust in our clients and in our prospects is around how we approach the admin experience. So, you know, in that process really inquiring into the vendor's process for developing the admin requirements but also deep diving into that admin design process. So we all know we're all here because we love Drupal, it's highly customizable, there's a ton available in the community, but it's also something that we can really partner with our clients, our authors, our Drupal development partners and really be collaborative in terms of the workflow and the different authoring tools that we build. So one thing we always encourage our clients to do and from our side always offer to our clients to show our demos of our work. So, you know, we've, whether we're building a site from scratch or we're taking over a site or maintaining it, not all Drupal sites, Drupal 8, Drupal 9 sites are created equal even though they're using a lot of the same modules, maybe the same distribution, whatever it might be, the results can be very, very different in terms of the implementation, in terms of the approach. So I think it's really important to work with any potential partners to figure out, you know, how do they approach the admin experience design and what does it look like and is it going to work for us? Because, again, what we've seen is some are incredibly easy and intuitive and, you know, all the fields are in the right place and labeled great and in, you know, really great use of Layout Manager and a variety of other tools to help remove friction from the admin, but other sites on the exact same platform, exact same set of modules, we've seen just things that are completely different than that. So it's really important to really pressure test that. And, you know, one way we've been successful doing that, we call it a product playbook, maybe you call it requirements, we also call it a build a reference guide from time to time, but really defining the business and function requirements but also putting a lot of time into the platform and custom experience needs. This is a process that we always encourage our clients to do and we account for quite a bit of scope up front in the discovery phase to make sure that we're doing this together. So what does that mean exactly? We do stakeholder interviews at the outset of a project. So, you know, from the Zen source side we'll partner with our agency on the development side and figure out with our clients, you know, what are the needs of the business. We're going to create prioritized business requirements and function requirements. We're going to do a tech roadmap of what it looks like now versus three or five years down the road. We're going to collaborate with marketing and IT, identify all the integrations, make sure we're thinking about what we're going to do now, how it needs to scale in the future, but I think even more importantly, what we really want to do are identify opportunities. How do we uncover pain points, you know, features that are error prone, things in the current system, whether it's an older iteration in Drupal or another platform, what's not flexible, what's not working, and we want to identify the quick wins but also the longer term enhancements that are going to save us time and make the author experience that much better. And then what we really do is we understand the needs of the authors. So diving into their workflows, I don't just mean Drupal permission in a workflow and roles and things like that, but I mean like their day-to-day workflow. You know, what else do they have on their plate? What does their day look like? How much time do they spend in the CMS? Are they a small centralized team that develops all their content? Are they a bigger decentralized team that has more authors in there doing just very specific things, whether it's just updating like news or events or something like that, or really trying to figure out what their different touch points are? How many cycles or reviews do they have? Who needs to approve certain things? Working with an education client right now where they have a core team that does the content writing, but then they have five or six different layers of review and approval before it gets published out. So identifying what that end-to-end journey looks like and building the tools that are going to streamline that, make it easy, incredibly important. And then looking at those friction points and figuring out how we can remove them as we do a new implementation. So how we tend to approach that and how we encourage our clients to collaborate with us and with our agency partners is to onboard and bring authors up to speed early. So we encourage one-on-one training at the latest Drupal admin in the code base that's going to be used. So something we'll often do with clients too and maybe we are a year away from a site redesign but there's an opportunity to get some new marketing landing pages and market now. Try some new creative, getting used to the Drupal 9 interface, getting used to our code base. It gives us a lot of opportunity early on to figure out what works, what doesn't work, what can we optimize for the bigger redesign. And it gets authors familiar with the tools before we get into our detailed training. And then we build up these requirements together. So it's the functional requirements but those CMS experience requirements, we sit down with our clients and we go through layout by layout, module by module, how is this going to work? What's there by default? What are the field labels? What's on the page when we create a new one? How easily can we clone things? All those different types of pieces and then diving into their permissions model. How are they going to maintain site governance? All those things we do with our clients. So kind of getting back to how that ties back in terms of the proposal piece. I think making sure that as the partner where guiding our clients and recommending this approach to really make them feel comfortable with the tools we're building. But then from the client side, making sure that we're asking our potential partners about this and we're factoring the time and the budget and the resources to really deep dive into this throughout that design process is really key. Content migration process. So as I mentioned a few moments ago, and I'm sure a lot of us have been through this more than a few times, but the content migration process is super time intensive and super resource intensive. But when done right, it's the difference between launching on time and on budget and not. We believe that it should be a mix of automated effort and manual effort. So I think if a vendor says, we can do 100% manual migration, they're probably not investing the time in the tools for things like using the Drupal Migrate API. There are plenty of things that we should be able to script and migrate over and not rely on authors to do. But at the same time, any vendor that says it's got to be 100% automated, probably will have reasons down the road why it can't or why there's issues. So from our perspective, finding the right mix of what needs to be manually migrated and what we can automate to have the integrity of that content be the best that it can be is the right way to go. That's usually what we recommend to clients in the RFP process when we talk through that in the pitches. But we also, coming from the client side, really recommend that. Really pressure testing that with your potential partner and really deep diving into how they're going to handle migration is probably one of the most important things for success. So how do we do that? I think ensuring that your development partner is thinking about efficiency of automation but being realistic about the road ahead. We really encourage clients to dig into the approach of content strategy. How do they go about it? Analyze how they execute the automated migration but also their process to clean it up. Training and implementation is huge. We have, whether it be a web app, an enterprise level, health system, whatever it is if you were to ask us for what does a training program look like give us the hour by hour over a week or two week training, how do you approach it? That should be something that the vendor can provide and walk through pretty easily. That should all be really canned and really determined up front. But how we approach it is we do a mix of working with our agencies on the content strategy side as well as the trainer side. So this picture here on the right is actually a picture of one of our clients, Cornell University College of Agriculture and Life Science a few years back we did a redesign for them and with our agency partner, Primacy and this process you're seeing on the screen is before we even got to training it was printing out these huge comps and cutting out modules and the Primacy content strategy team went through and worked with them to figure out how to develop content how to map content, how to put together the modules before we even got into training. And then once we got into training the ZenSource team came in and we helped them go through the curriculum but using that real content not just standing in front of a room of people going through a deck of how to edit in Drupal but really rolling up our sleeves working sessions side by side building out real pages together we find that that is the recipe for success and ensuring that that's part of the process that's part of the flow of the time and the people to do that is really going to help so you know kind of in short whether the vendor has a dedicated team helping you populate all your pages or strategists they're going to help organize or both having some level of that in there is just going to make that migration go that much smoother and just the integrity of the build. Jake I will hand it over to you to talk a little bit about the next piece so these next sections are covering just some of the issues we run into with the large sites or basically non-standard sites where there's a lot more going into them than just the average sites so a lot of times yeah you run into this with you know hospitals continuing care education, social where they've got a lot of either data coming in from multiple different systems they have multiple departments that might want their own permissions their own ecosystem within the content management system or just even like multi-lingual things where the normal approaches don't always translate very well so there's definitely I mean again a lot of modules out there but it's a good to know whether the vendors already vetted these are going to work with that particular approach also in the case where say custom development is needed if they're familiar enough with whatever the API available for the set of modules they're using to actually you know bring that to fruition so yeah as it says here you want to make sure that the whatever solution they're offering is tested to scale up to the enterprise level but also without necessarily locking you into any proprietary functionality so down here we can discuss some of the things that we just run into John touched on some of these briefly but just making sure that they are up on their compliance especially if any there's going to be any personal information or PII stored on the website you want to make sure that they're developing these solutions to scale and what that I mean there is both in the form of upgrade paths but also making sure that the solutions that are working for once you've populated 10 pages are also working if you're publishing say 500 pages you want to make sure that whatever solution they're doing is flexible enough and that it's designed to integrate well with a lot of the other community modules available sometimes we run into where a solution might work fine in certain cases but then when you start adding workflow or visions on top of it things start to get a little tricky and then what we'll touch on more in a second is importing and managing any say external data and that kind of goes back to content migration piece with the external data so while the content migration of the actual site content the page content is so time intensive and consuming also really vetting that where the client's data is coming from is it coming from proprietary database are there things that we're designing that don't live in that data and needs to be co-mingled in Drupal how do we marry that data together and have it all display and work perfectly on the site both the third party and the Drupal specific we just had a case with the client where they have data coming from a third party feed but also want to be able to create the exact same looking content in Drupal but it's just more you know more personalized kind of more on the flow of their tone and voice but being able to really vetting a vendor to make sure that they have the approaches to bring in data and display it and have it work from a lot of different places we find next to the overall content migration is probably one of the more time consuming parts and one of the gotchas you really want to make sure your chosen partner really has a really good way to vet that and execute. And just to get into some specific questions that we like to ask or that we see asked common again in the process of data are they familiar with things like Migrate API or feeds this goes beyond even just migrating data from the existing website but most large sites that we work with such as health care providers they'll have say like provider data coming in from their credentialing system and need to run on a schedule and that needs to continue well past the initial site development usually daily the other big one as far as scalability is what sort of caching system that they've worked with if they've used their solutions tend to offer memcache redis obviously if you're going with like one of the the more like well-known hosting providers like an aqua or pantheon those tend to be documented well but if you're going with you know more of a custom provider just make sure that they've worked these into their solutions and specifically when we're talking about things like varnish if they don't go with varnish or one of the other like well-known ones make sure that their caching solution is supporting what's called tag-based expiration and what that means is a lot of solutions will when a content author is updating a page it'll be smart enough to expire that one URL but without the cach sorry without the tag-based caching they don't have the ability to expire anywhere where that page is used so you start running into issues where if your site is embedding articles used on other parts of the site into it those will be out of date from the main article and that's what tag-based caching gets you around and then another big one with larger sites are just any SEL implications so you know I'm sure everyone's throwing the metatag module on as just a default but there's also a big push to start getting data schema or JSON-LD functionality added on top of that it's great if whatever vendor you're going with has already come up with a lot of default values so that the content author doesn't necessarily have to fill out specific fields but it can say you know populate based on summary of the body text or title or maybe like a hero image depending on if you're using like say twitter tags and then another big one is when it comes to redirects do they have they implemented a large scale way to say import those redirects and then also handle them in a performant manner which usually we try to move it as far up the stack as possible the redirect module is very good for doing like vanity URLs or small amounts of redirects but doing it directly in PHP is going to be more performant than that and then doing it in Apache is more performant still because the redirects are happening now before they even reach your Drupal site and so the other big piece is specifically with the hosting aspects of it so one thing is to find out what they're actually offering as far as going with to white label so a lot of places use AWS these days or Azure preferably they'd be on some sort of cloud based solution but even if they're not just make sure that they have the staff on site and what their turnaround times are for troubleshooting issues same thing with their model security do they have any guaranteed uptime response times do they have their own automated monitoring tools at hand to show site uptime and in some cases can they make these available to you and it explore the other piece too would be more on the security aspect is how are they keeping the data safe do they have encryption at rest encryption in transit do they have good auditing as far as who has access to your data certainly for the ones that are white labeling say AWS AWS has certain guarantees up to a point but it still is onto the vendors implementing these to have their own layers of security on top of that and then as I mentioned above see what kind of encryption they have available if it's just at rest or if it's in transit as well or maybe something on top of that say with web form encryptions so the other big piece is the support aspect of it so the site can be perfectly up to date when it launches but then you know quickly you know within a week or two we'll start falling out of compliance depending on if their security updates available so see if your vendor offers like some sort of support package to keep everything up to date and if they do offer that package you what how far do they go in covering that and so if the do they run updates and then if there's issues that's then put on your team to solve or are they actively monitoring a lot of the core modules that they're using in their sites to see like you know when new updates are coming out or any known issues it really like find out if they're capable of diving into like solve problems or if that's just not necessarily covered and also if upgrades are offered how far those go if they're just minor versions say like nine three to nine four or will they actually cover larger version updates as well you know I don't think you'll find anyone that covers say seven to eight but for sites that are already built on eight the upgrade process tend to be smoother and so that's not as unrealistic so they yes that here because it is so critical make sure to factor that into whatever budget that you have for the project we'll talk more about this in a second but as far as one click updates they're very good for what they are but don't necessarily assume that every aspect of the site is going to be covered by it and if they're they do have a lot of automated testing what's their process for actually releasing these updates is there like human element to reviewing these updates to make sure that the site isn't in an error state after they've done applying them or you know is that on your team to basically review the updates before they're pushed out so some specific questions you can ask as far as hosting if they're not using one of the mainstream environments they should be able to provide audits like SOC2 and get you any sort of information on an architecture diagram to see where the firewalls are in place how access is obtained how you're expected to get say SSH access or FTP access to work at the file system and if they do offer firewall what types of things are they checking for does that cover DDoS protection things of that nature so in the case of like support packages the one click updates again they work very well for small websites but when you start getting to larger scale websites what we tend to find is that a lot of them don't necessarily support Composer very well or if they do cover updates they only cover core and only then if there's no patches being used on the website so just get into the specifics of what is and what isn't covered just so you're not surprised post launch and then if the vendor is offering any sort of proprietary based tools that sit on top of Drupal just find out exactly what Bryce was mentioning in his keynote earlier is who owns the data at that point some of those tools are very smooth for the editing experience but then if you stop paying for your subscription you're essentially locked out of updating the site after that and so it really needs to be like a pro con analysis of whether they're smooth enough to justify potentially losing some level of ownership to the data and take this last part just to close before we take any questions you might have from the client perspective really understanding your partner from the development side from platform, Drupal platform side what's the special sauce they bring to the table and for those of us on the site builder and platform side what is it that we offer what can we bring, what sets us apart in the pitch process, in that whole RFP process and when we're competing against other agencies and platforms and what makes you truly special if you're a development partner on the Drupal side, Drupal platform you're going to take advantage of the community for the client's benefit but devote resources to making that unique experience if you're considering Drupal or have already committed to it it's likely because you expect certain things to come standard but are also excited about the flexibility that we have that we don't always get with Enterprise and make sure your partner is prepared to not only leverage Drupal to accelerate the build but also bring tools and strategies to really build out that technical roadmap for us at ZenSource we saw years ago that more and more clients are moving to Drupal every day again, Dreyas spoke about this at length this morning but across healthcare, across education across these more enterprise huge ecosystems more and more clients we're seeing are asking for it every single day and ZenSource decided at one point let's look at building a front end and back end experience design system something that we can install and it has all the foundational UI modules and page layouts and forms and site search and whether it's a really small build or a really large build using the client's budget and their time and their resources to do what's really custom unique to their brand is what it's about and that for us is kind of having those foundational UX accelerators is what we think we tell our clients as well and for those of you looking for different vendors on the client side are also those of you who are site builders and work for particular platform or software company trying to really unearth the value prop and what's unique to your brand and what's going to set you apart from other potential competitors that's what we really want to convey and try to find harmony with our clients so you can visit us at ZenSource.cloud for more information or to learn more about our products or hosting our core support our experience platforms and you can reach out to Jake and I anytime we love the chat we love to meet talk about your business talk about what challenges you have or what solutions you offer we love to partner, we love to collaborate so please feel free to contact us anytime any questions we can answer anything sure hello I need a mic I'm Laurent from Total Energies so as clients I have an itchy question for you is sometimes we're in a situation where our vendor deliver and we realize the penalties we will not solve the issue and I would like to have your feedback from your perspective did you meet unfair penalties during a project or do you have some suggestions how to for us to write better penalties that is win-win so there's a question more around in the case the site was built implemented by internal IT in maintaining the site or is it more the requirements it's like the way the contract is written and so basically in case of usually the penalties are delays the delivery is late because it's too too many critical bugs so in these cases the next bill will be lowered by this percentage so but when we write an RFP this is the point where we can fix that or improve this part so it's we don't meet this great question a couple different ways we've looked at it what we often encourage clients to do with the RFP process is to write in a warranty period really having a certain set amount of time developer hours a certain criteria whether it's 36 days after go live where they have to fix anything that's deemed critical writing in assumptions like anything that's deemed critical priority one functional display and then also what we often do is work to build an assumptions that you know in order to meet scope all the requirements in the business requirements the bill reference guide whatever you call it the product playbook have to be met so before we can consider it a true handoff having the assumptions in place in the RFP process of final sign off on requirements and the work is not done until these requirements are done tickets, issues, bugs, etc you know must be complete and then from that perspective writing in that warranty period of how long they have to fix those bugs and what success looks like we find that's the best way to do it because if we don't get to the bottom of those assumptions when the site goes live what does success look like like to your point maybe there's you know things that you think are critical that the partner doesn't think are critical or vice versa so making sure that there's ample time beyond go live and a certain expectation of delivery and time of delivery the more assumptions up front the better the more clear we are with the scope and what's in and what's out and not leaving it to be you know vague in terms of what those requirements are that's always what seems to work best for us and it's best for our client and it's best for the vendor to be really clear and transparent that's where we've been I would say too it's good to work in assumptions on adding in like various review checkpoints during the project so versus say having like the finalized solution delivered all at once you're preferably like the vendor can start getting you into the system maybe necessarily before the entire sites finish but just early enough that you can still see the content structure and maybe some key elements of it to catch these sort of issues early in the build process which makes a lot cheaper to you know pivot at that point if there's just more of a not so much that they're not me the requirements but maybe there's just a misunderstanding of exactly you know what the requirement was you can catch that kind of stuff you know much earlier in the process yeah that's that's actually really important one we often will work to put in certain you know deliverable milestones in the RFP and that's a great one like what we like to do is release you know a homepage three layouts and ten modules first and if that's good we move on if it's not what's the feedback then in the next release okay we make those improvements make those revisions release the next batch the product's better it's more tailor requirements and you're not getting this huge delivery that you're stuck with at the end that's too late to fix or out of time to out of money so those iterative releases to you know to staging before we go live we find the clients are always a lot happier with the product when we do it that way we're a little bit more iterative and transparent hmm I see and maybe I have an advice for the for the audience is like it's always easier to make a contract with the when it's fixed price better determine the means like with allocated means rather than always focus on the results like because the result is always as you said assumptions by for what the size of the team the experts at that at that time and that can create a lot of issues after if you say I'm not happy with the results but it was based on assumptions from the from the quotes and if it's fixed bid and there's an assumption that those things need to be met within that fixed bid scope versus it took us a lot longer than we thought and you know it's really another $50,000 change order for this feature because we underestimated it another thing we do that really helps is try to do statements of work for discovery through user experience and then estimate the build after the more opportunity you have to go through that strategy go through the requirements go through user experience concepts and then have a range for the build and have those really focus requirements and wireframes to develop the build budget that always ends up being a lot easier as well because it's so much more accurate at that point versus trying to make assumptions up front that you might not know thank you if we were in the ideal world which documentation would you expect from the customer site to start a website or how customer can better prepare to that process number one will always be thorough documented third party integration documentation apis proprietary databases that data whenever we have more documentation around any data or homegrown proprietary apis you might have that's always going to be the best because when we get into doing an integration and we know there's some database over here and there's some random X and L feed and we'll create a job and import it when it's more ambiguous that's where we budget the fastest and the more documentation and production ready you know apis we have up front is definitely going to be the best way to do it. Yeah I'd say like the second probably after that when the second most important is this will probably be shortly after the RFP process but if it's possible to give your vendor access to say like maybe a staging environment that you have so they can actually log into the system to see how the data is structured see what modules are being used things that you might not necessarily think of in a vacuum but they'll be looking for based on the type of project that they're doing. Hi I've come across this issue a couple of times recently and so a client approaches us and says well they'd like to have a project done, relaunch or whatever and one of my first questions is well can you also send me some of your internal documentation of your workflows how do you author content how do you do things they don't have it how do you deal with this type of situation where there's very little documentation that the client could provide to you so you understand the workflows. Yeah that goes back to what we call the product playbook whereas part of our discovery the stakeholder interviews we meet with the authors because that's one piece that more times than not is not documented there's not time there's not resources to do that but what we do is we'll sit down with the authoring team usually it's the core marketing team and as we develop the functional requirements the CMS experience requirements we'll work through the current workflow what are the authors doing the review the review process how are they publishing all the different pieces so that's where we'll factor in time and budget up front to understand and document what the current process is because you're right it more times than not is not there but we need to understand that so we have a couple more questions what tools to use by agency for workshops and scoping the project with the customer what are the most expected formats of artifacts for selection process as the answer to the RFP can you say the first part of it again what tools to use by agency for workshops and scoping the project with the customer maybe they're thinking more like some of the UX tools like freehand yeah so one of the projects things we use a lot are things like like Miro we'll often do workshops with our clients up front using something like Miro or something like a freehand where we'll do interactive workshops together to sketch out what's in their ecosystem start doing some low fidelity wire framing that kind of a thing that's what we find especially with all of us being remote these days more of like that interactive whiteboard Miro is a product we have a lot of success with and we use that quite often to help scope and kind of help understand requirements before we get into the build that in my opinion is probably the best one the other one is what to look for in vendor or RFP when our policy requires that site to be hosted internally yeah that's a really great question we run inside all the time I think that goes back to and Jake I'll differ you on this one a little bit but I think that's where it's really important for your development partner to have expertise in their own security teams they have their own information security officer that's going to help work with your IT team to make sure things are within compliance that we're doing best practice for data encryption and how we store past data I think having even if you're not hosting, if your development partner isn't hosting but having hosting capabilities and understanding the configuration how to troubleshoot different server configurations that's really important because when it comes to systems if IT's supporting I think the more that we can do to help support them Jake probably having a shared repo that we all have access to that kind of a thing I don't know if you have any other thoughts on that shared repo is definitely a big one a lot of issues we have we've run into in the past is where vendor has their copy of the source code the client might have theirs and the processes may be able to sync those up centralized one if you can but also as far as hosting internally goes too, I'd want to spell out where where the vendors support ends and yours begins so does the vendor just troubleshoot site code, will they troubleshoot actual environmental issues that might come up on your server will you be maintaining the server updates, security updates or will the vendor and frankly are you able to give the level of access if you do want them to support it to have access to those servers to do it themselves or is it assumed that you have staff on hand that can handle deployments and the update process and work with the vendor to get those updates out there I think we have one more question so it's for gen source is it possible to migrate from gen source to own hosting at some point and use it without the subscription yeah 100% that's actually you know that's our business model by design so gen source we have our own distribution design system but it's all entirely built on Drupal built on open source we have subscriptions for hosting and for our support and our upgrades we do have certain standalone host experience things for things like landing pages a lot of our clients host externally in support externally whether it be on prem, aquia, pantheon whatever it is at our core it's a code base the whole idea is that we don't have anything that you can't walk away from but there are certain things that are value add like the support and like the hosting that's more subscription based but everything is you know totally you own it and can move with it so what we do with a lot of our agency partners is they you know download our design system in our code base we have full control to go and use that to build any implementation they want for any client and host it anywhere so that's really where we are at our core but happy to give anybody a demo or talk through it more next week or whatever and we're in the process of getting the distribution actually posted to Drupal.org just haven't gotten there yet but hopefully by the end of the year we plan on getting everything cleaned up enough to get posted to the community see you in time but thank you everybody thank you guys