 Oh, yep I got it. My name is Jordan Harrison. I am a program manager with Aquia Professional Services. What that means is I help clients build and execute really big projects in Drupal from discovery through to launch. So I'm the captain of the project ship and make sure we don't crash. We're here today to talk about selecting good fit technical solutions for the enterprise. So particularly if you've been tasked with leading or participating in a big purchase like this and you don't know where to start, this talk is for you. But I've seen this process from both sides. Prior to Aquia, I spent most of my career on internal teams as a senior technical and program lead that was mostly in higher ed. I've implemented many, many CMSs but also things like enterprise CRMs, search appliances, all kinds of cool stuff. What that means is I have made all the mistakes so you don't have to. And this is a really short presentation with a lot to cover so there won't be a formal Q&A as part of the session. But please come find me after I would love to hear your use case and answer any questions you have. You also don't need to know a lot about Star Trek to understand this presentation. But if you want to talk about how awesome Star Trek is, you can come talk to me after about that too. So diving right in, how do we select great IT solutions for the enterprise? It's going to start with requirements analysis. That's our flight plan, right? What is the problem we're trying to solve? We're going to follow that up with market research. There's a whole universe of options out there depending on what you want to buy. So how do we choose? Then we're going to talk a little bit about technical bake-offs. That's how you get your engineering deck involved. We're going to go through vendor selection and management in case you need to supplement your crew. And then we're going to talk a little bit about implementation and support planning because somebody has to build the Starship and somebody has to fly it. So including the humans in your process from the beginning is the way that you ensure success. There's a lot more to say about all these topics, but there's a very high-level overview just to get you thinking and get you started. So kicking it off with requirements analysis. What are we trying to buy here and why? I love this spot quote because insufficient facts always do invite danger and that's never more true than when you're buying giant enterprise IT solutions. Requirements analysis is going to get you the facts you need and it's going to serve as the basis for literally every other step of your project. So if you do nothing else that I talk about today, do this well. So what is requirements analysis? It's a flight plan for the entire project. Where you want to start is you want to analyze your current state. So that's how are various groups across the enterprise working today? What's our current solution? You want to look at software, but you also want to look at business processes. What does the current solution do that we want to keep? It's very likely that you have a current solution that you don't completely hate, right? What are we going to hold back and keep from that? Then you're going to want to think about the current, the best ideal future state. How do various groups across the enterprise want to be working? And what's not so great about our current solution? You want to be sure you understand your constraints? What can't we change even if we want to? This might be budget, it might be security policy, it might be platform or license, all kinds of things. But don't waste time on things that you can't change. The answers to these questions are going to define the path for your entire project. Excuse me. So since we're at a Drupal conference, we'll take a CMS replacement as an example here. Hypothetical CMS replacement. Maybe we have a current CMS and it handles images really well and it's easy for IT to maintain. And it has personalization tools that marketers like, although they want to do more. And we want to keep all that because it's a key part of how different groups are using the CMS. But maybe our current CMS admin interface isn't so good. It's low to load, support's getting a lot of calls. So we need the editing interface to be better in the new system so people can work efficiently. And then our leadership might like a certain proprietary CMS, but maybe it costs three times our budget. That's a constraint. So you have all these questions, right? Things you need to know. How are you going to know these things? If you don't know the answers, talk to somebody that does, right? Identify your different stakeholders. That might be your leadership, your IT, your business, your product or marketing folks. For purchase like a CMS, lots of people care about lots of different things, right? And they may not agree and that's okay. We're going to work on consensus next. You want to talk to them. This means a lot of meetings. It means meeting a lot of new people. You're going to learn a lot about your organization that you may not already know. Then you're going to write down what they tell you and create a list of everything everybody wants this new thing to do. You're going to constantly update this list as these conversations evolve. So how do you document what people want, right? When people want all these different things and maybe they don't agree, you start with a spreadsheet. Simple as that. You're going to list your requirements. You're going to list your stakeholders. And then you're going to have each group rank each requirement. How do you rank them? I personally like a method called Moscow. Moscow is a really quick, clear way to determine priority and help different stakeholders clarify their thinking about what is important. There's four scores here. There's your M scores, which are your must-haves. If a solution can't perform one of these, it's not to be considered as far as that stakeholder group is concerned. Then you can have your S ranks, which are your should-haves. That's ideal functionality. These are things people really, really want in terms of stakeholders, but maybe not a complete showstopper if there's other considerations. Then you can have your C rankings, which is your could-haves. That's nice to have. They're completely negotiable, right? Then there's won't-haves. And these are things not to be considered in this phase. These are good to write down because it clarifies expectations with your stakeholders. You have each group of stakeholders assign a Moscow score to each requirement from their perspective. What does that look like? Well, it can kind of look like this. I personally like to assign numeric values to each ranking because it lets you generate an average across all stakeholder groups. Say you assign your must-haves a three, your should-haves are a two, your could-haves are a one, and your won't-haves are a zero. You're going to list the rank for each stakeholder and then average them across. It's as simple as that. The average Moscow score gives a sense of the overall priorities for the entire enterprise. So that's really, really important information. So looking at this example, personalization tools are not that important to IT, but they're fairly important to product here, and they're really critical to marketing. That's a real-world example, right? By the end of this process, the overall priorities should be reviewed and signed off by all these stakeholder groups. So one thing you don't want to do is go talk to these people, generate an average, and then go buy something. You want to check what the averages are back with those stakeholder groups. So lastly, above and beyond these must-haves, you're going to need a few non-negotiables, right? So in this example, IT can't function without patch management, right? So you're going to want to make sure that IT, regardless of how the average comes out, gets patch management, right? That's just a gimme, and every group is going to have one or two of these that are non-negotiable. So now we know what our solution needs to do. How do we find a solution that fits? You can use market research and you can use gap analysis. So you can use logic to justify almost anything. That's a great quote from Captain Janeway and then Addendum by me, because market research is great. It's a hopeful tool, but it requires more than just reading a couple of reports, right? It's about becoming an educated consumer on behalf of your organization. So when you begin this kind of research in IT products, you're going to hear a lot about Gartner and Forrester. What are Gartner and Forrester? There are two major research companies which analyze all kinds of IT products, right? Everything under the sun. The reports are quite expensive. If you work for a big company, you might have a subscription already. It pays to ask. And it's a good start to see what's available, but they may not offer the complete picture. Their research is centered around the top, like, 10% or so of corporate IT departments. So if that's your organization, that's great. But if it's not your org, you probably need additional information. So do your own research, right? It's the same as buying our house. You have to ask your stakeholders for recommendations, right? They're going to have opinions. You're talking to them anyway. You want to talk to peers in your industry? You want to read blog posts and articles and analyses and become your own expert. And then if this is all overwhelming, which it might be, you can hire an expert. That's perfectly okay. So an example from a previous role I was in prior to aquia. We were doing a CMS replacement. A lot of people in the show probably worked on something like that. I didn't know the market really well at the time. So I started with the Gardner & Forrester reports to see what was out there. I did a lot of googling. Google is your friend. A lot of reading. And then I went to an IT roundtable for my industry. And the reality for my industry just wasn't reflected in the Gardner & Forrester reports because they weren't looking at the industry I was in, right? So I talked to my peers, and then I hired an outside consultant to come back with 10-ish options based on some baseline constraints. So that's stuff like hosting costs, average developer per hour costs, licensing costs, stuff like that. And as an example, one solution we looked at looked great functionally, but the license was five times our budget. So that's easy to eliminate that option out of the box, right? We also had the consultant look at key requirements. So he checked the candidates against the top 30% of our functional requirements. That's our must-have requirements. So we went easily from 10 to five options there. So now you have five options, right? So what do you do from there? Well, you can narrow this down to about two using some gap analysis. There's a lot you can read about gap analysis as a discipline, but at a very high level. You're going to take what the requirements say you need, and then you're going to look at what each potential solution does, and if there's a gap between the two, you're going to think about how you mitigate that gap. So mitigations are stuff like we need to train the team on a new technology. We need to staff up. Maybe there's systems integration with another system we need to look at, stuff like that. So what you're doing this gap analysis, you're going to consider how willing or unwilling you are to take the mitigations you need to take to close that gap. So solutions that have no gaps or solutions that have small gaps that we're really willing and able to mitigate are going to be our best solutions. So from here, you should be able to narrow it down to about two top solutions. So next up in the process, we know what we need the solution to do. We know what products might be a good fit for what we need to do. Now is the time to bring in our technical teams and confirm all of our previous assumptions, answer any remaining technical questions, and make a recommendation for the best fit solution. And one way to do that is a proof of concept exercise called a bake-off. There's lots of different versions of proof of concept with technical teams. I happen to like this one. But before we get into how to do a bake-off, I want to say don't buy IT in a vacuum. Sales engineers will come and talk to you about various products or how they implement those products, and they only show you what they want you to see because it's their job. Your own IT folks know a lot about how a potential solution needs to function in your organization. So including IT or technical teams in the vetting process helps confirm all the assumptions we've made to this point. And I don't want you to hear this as you should wait until this point to include your technical teams. You shouldn't. They should be in your stakeholder groups. They should be advising you along the way. But this is hands-on technical proof of concept work. And the findings here should be confirmatory rather than revelatory. You shouldn't expect any huge surprises at this stage, but if their surprise is lurking, you want your technical team to find them now. So how do we do this bake-off thing anyway? Structure is really important. Your technical teams are probably super busy and you can't ask them to just go try out this new thing and get back to you because it's not going to give you the information you need and it's going to stress them out, right? So you want to go into a bake-off with two options. More is really too many. You want to provide structured technical questions for the bake-off to answer. These are often going to be based on your requirements, right? Areas where you need to dig deeper. Clear time in your team schedule. You probably can't have them stop work for a sprint or two for this, but carve out, you know, hours in a day, hours in a week that they can dedicate to this work without distraction. You're going to apply some good project management principles, right? You're going to check in often. A lot of times, devs will come up with questions that you have vendors to answer. Have a PM handy that can go get those answers. Don't make the devs chase, you know, sales guys or sales engineers. You want to review and document the team's recommendation. What's their top choice and why? And then update your requirements if needed. You may find things that end up being new requirements along the way. And then one last note. Make sure your bake-off results have weight. There's really nothing worse than putting a really smart team through this process and having leadership come in later and say, oh, we're buying this other thing you never heard of, so thanks anyway. Make sure that what they come back to you with is meaningful. So hopefully you're down to one great option now. You're buying from your technical folks. But now you know you need help. And it's time to hire vendors. That's me. This is not a Star Trek quote, but it deserves a double face poem because I heard it a lot when I worked in internal teams. Don't assume vendors can work without management any more than employees can. Vendor management is a job and it takes time to do well. And vendors can be amazing, but good partnership is always needed. So first of all, you want to decide exactly what you want your vendors to be doing. Is it research? Is it implementation? Unclear goals and lack of direction cost you money. Period. You want to ask really hard questions. You want to call references. Some people don't always call the corporate references that they ask for. You want to talk to your peers. Who are they using? Who have they had great experiences with or maybe not? Good vendors should be able to stand up to screw me and bad vendors assume you won't exercise it. Go to conferences. We're a triple con, right? Who's speaking? Who do they work for? Do you like what they have to say? And good vendors often have a process or a methodology. Usually it saves us time, but you need to understand where your specific organization might need to deviate from vendors policy or process and what the implications of that might be. Maybe it's going to slow you down a little bit. Maybe that's okay, but it's good to know that up front. Now, unfortunately, the best consultants are not betazoids. Betazoids can read minds. So since I failed mind reading 101, once you've selected a partner, remember that, like I said, vendor management is a job. Expect to spend as much time managing a vendor as you would an employee. You're going to often need less effort, but you'll never need no effort. So if you aim high, you're going to have the time you need to do this properly. You're going to want to define work clearly and communicate early and often. Adhere to the process you agree upon up front, right? Know who your key decision maker is and make sure that your vendor knows that too. Don't let them chase answers, because again, that's going to cost you money. Be fair, be kind and be human. This applies in all things. And expect all of the above in return, right? So at this point, you might, if you're part of an org that does RFPs, you might be thinking to yourself, when do we RFP, right? That's request for proposals, part of the competitive bid process and a lot of organizations. We have to RFP, right? Well, maybe not. How many times have you seen a really broadly defined RFP process result in a bad fit purchase? I've seen a lot. I'd like to think I never led an effort like that. That's probably not true. So why big broad RFPs don't necessarily work is a topic for another talk, but they really do what we want them to do, which has got us the absolute best fit solution for our particular organization in use case. But many times RFPs or competitive bid processes are required. So maybe we land here, right? We rethink the RFP process as your policy allows. In the researcher bake-off phases, ask your top vendors for demos, right? Because you and your technical team are educated consumers now, and you can ask really hard questions. Be tough. Be prepared for demos. Force of sales engineers to go off book. It's going to tell you a lot about their flexibility, right? And in the vendor selection phase, solicit specific implementation proposals for your chosen solution based on what you learned so far, rather than these sort of broad open-ended solutions proposals which kind of rarely have a good result. So last, a quick note about implementation. Even if you're not leading the implementation phase or in charge of support and maintenance, you need to think of the future, right? So don't be that project manager that chose that awful thing everyone hates, right? And now, and avoid damage reports later. So we want to think in terms of implementation timelines. Are there migration concerns? Are there going to be systems integrations needed that add exponential complexity to your project? Do we have the infrastructure to even support this thing, right? For support and maintenance, how hard is it going to be for existing users to switch to the new solution? You know a lot about your current versus future state. How are your users going to bridge that gap? What will IT have to do to make sure this is supported? Are there parallel projects that block or unblock your next steps? And are there hurdles like policy or training that need to be addressed before any of this can start? And lastly, can any of this begin now and save time and remove blockers as quickly as possible? So to sum this all up, we're going to gather complete requirements, we're going to document them, we're going to prioritize them, we're going to get stakeholder consensus across the entire org. We're going to conduct market research, become that savvy consumer, and choose top candidates based on gap analysis. We're going to conduct some bake-offs to get technical vetting and buy-in from our own team. We're going to select our vendors carefully and manage them wisely and humanely. We're going to plan for implementation and support from the beginning to ensure a successful project at completion. And with that, your solutions and all your users live long and prosper. Thanks very much.