Charlie: Welcome to the CMO Series Digital Masterclass. Today, we're delving into the complexities of professional services website projects and the nuances of crafting a winning RFP. I'm Charlie Knight, and I'm very lucky to be joined by Anders Holt, CEO of Novicell, and Chris Eatherton, Head of Digital at AlixPartners, to share their expertise from both the agency and client perspectives. In this episode, we'll discuss the biggest challenges firms face when drafting an RFP, the importance of involving technical experts early on, and how to approach a project with a clear understanding of both the functional and non-functional requirements. So welcome, Anders and Chris.

Chris: Hi Charlie, thanks for having us. 

Charlie: Thank you both for joining us today. It'll be great, I guess, to jump straight in, Chris, and set the scene for those who don't know you. Briefly talk us through your website project at AlixPartners and where it's at now.

Chris: Yeah sure, so we launched our new site in April this year. We're incredibly pleased with it. It's been very well received, which certainly helps. I think we probably realized the vision that we set out right at the very start of the project, which was to develop a business tool rather than just an online brochure. We're kind of seeing that already. Without changing any behaviors or processes elsewhere in the business, we're seeing an average of two MQLs a week for business opportunities purely via the website, through some of the new forms and CTAs we've built into it. That's in addition to the conversations and conversions that come through the website, such as clients reaching out to consultants directly through their bios. It's a great signal that it's starting to do what we wanted it to do. It's incredibly flexible, optimized for SEO, our pages index incredibly well, and the carbon score on the website is fantastically low. All of these things were in our minds when we started, and factors like a low carbon footprint contribute to blisteringly fast performance on our site, on any device, anywhere in the world. So we're very happy, and that’s just the start. We've got a fantastic foundation to build on in the years ahead.

Charlie: Yeah, that sounds amazing, and it's great to hear that you've already got those kinds of leads coming through off the back of the new website. Brilliant, thanks for the update. I guess you mentioned setting out those requirements from the start. It'd be great to hear from you both on this one. Why are RFPs important in this process of building a website? And what are the big things that firms often get wrong? Anders, should we start with you on this one? 

Anders: Sure. You mentioned the importance of knowing your requirements. But often, the requirements gathered beforehand aren't sufficient. It's good to thoroughly do your due diligence, speak to relevant stakeholders, and create your own requirements. Then, start speaking to agencies to be challenged a bit. That will hopefully lead to a more thorough description of what you need.

Charlie: Great, and I guess Chris, from the client perspective, and with your technical background, what’s your stance on this? Where do you see firms going wrong with the RFP?

Chris: For me, I think that you should articulate your vision for the website. We had an RFP, but really we called it more of a discussion document. And the idea for that is that you articulate that vision for your website, tell a story of where you've been, who you are, what problems you want the website to solve, what your vision for the future is. And I think so many people get caught in that, you know, that kind of really formal RFP, you know, box ticking kind of process. You know, I think you start to lose some of what's really important. You know, you're going to be spending a lot of time and money with the partner that you eventually settle on. So you want to make sure that they really get what you're trying to do. You know, are as passionate about it as you are. Will challenge you in some of your thinking and bring expertise to the table. Won't just deliver what you've written down on your RFP and also that you just know you can work with them, right? You're kind of testing, you're trying to develop a relationship and understand what these people are like and whether you're going to be able to work with them for the next whatever 12, 18 months, maybe more, depending on how well the project goes. And don't get me wrong, we have a fantastic procurement team, and so when it comes to negotiating terms and conditions and commercials and whatever else, there's nobody better, right? But that's when you need their expertise. Right up front you're trying to get a sense of who these people are that you're going to work with and explain your problem, and get them to come to the table with maybe new ways of thinking to help you get a feel for what that relationship is going to be like.

Charlie: Yeah, I think that's a really nice way to approach it. I really like the idea of that discussion document and kind of setting out the bigger picture in that vision and seeing if the partner's on board with that, I guess, and also getting their view on how to approach it. I think it's a good place to start. 

Chris: You're going to go down the road of full onboarding and a large part of that will be detail requirements gathering, your discovery phase, etc. So you're going to cover all those bases. It's not like you're writing something on the back of a fag packet. But I think that if you're thinking about just going out into the market and looking at who your potential partners will be, that's a good way to start. 

Anders: I wholeheartedly agree.I think often we see that companies come to us and then they have noted down their requirements and think that it's the holy grail and they know everything. They actually also know what they need, so they have noted down what's wrong and they've also noted down the solution to it. And I think that is what Chris refers to as the old traditional procurement process. We see it a lot and we always try to go in and challenge and if there's no room for that then we would rather walk away than we would try to entertain something we don't believe in, meaning that we are to, for example, send pricing over for a solution or propose a solution that we know that is wrong. That's simply not how we do it. So I would say Chris is absolutely right. The most important thing in the beginning is to figure out, find the right partner that you have trust in. If you have technical experts in-house, you're able to evaluate if the partner is good enough technical but most customers don't have that means that you rely on trust in people and of course you can speak to references which.Is always a good idea and look at what the partner has done previously. 

Charlie: I think a really good point it's about at that point I guess building that trust building those relationships and kind of working with someone you kind of have that shared vision with so I think that's a really, really important point. I guess Chris from your perspective kind of managing a project like this what should firms be doing I guess before that RFP process begins can you kind of walk us through your approach at AlixPartners? 

Chris: Yeah so I don't know I think I guess the first thing is it's probably data right I mean everybody's plugged into google analytics if if you're not you've got a bigger problem than just rebuilding your website I'd suggest but you know that's going to tell you how your clients are using your website what they're looking for and why and if you're not building your website to address those needs your client's needs then you're already failing so you know data plays a huge part in that I can't tell you how often these projects become kind of navel-gazing exercises so you know a good example for professional services where the way you list your practice and industries you know are you using language that the client would use or are you kind of inflicting your internal labeling or your internal structure on your your site visitors so I guess that's another thing is you just really think about you know if you're if you're you know how your clients are using your site what they expect to see and what would make sense to them. And then I think I would probably then look at my website and replicate those journeys, the ones that the data tells us the clients are undertaking, but also maybe the journeys that you want them to undertake. And then as you're doing that, you can see what works, what doesn't, what's experience like. I mean, you should already know your site better than anyone else, your existing site, and have a long list of things you want to fix. But you should also know kind of you know how you go to market better than anyone else and how the website can support that better and what is going to transform that and so you're you know I think you're living the experience of your users is a is a is a great place to start on that because that's going to really going to kind of determine you know what your business goals are you know what you're trying to achieve in that sense but if you're thinking about user experience and you know functionality that's a great way of doing that.

Charlie: The idea around kind of the language and who you're catering for and your clients and prospects what you know what they expect to see is is a great point and and then of course all the other kind of functionality that that follows and as from your perspective how important is it or I guess what stage in this process would you advise firms to get that kind of technical expertise on board with you know what at what point is it best for you to come into a project?

Anders: Well, as early as possible, of course, because regardless of any client that has done some requirement gathering, we still do our, what we call the scoping phase or requirement gathering. And spec out the whole project once we get onboarded. So for us, it's the sooner the better. But as Chris mentioned, if you could do the chemistry meetings and you can have those kind of meetings first to start having something discussion brief, in this case, is better than having a set RFP because then you are forced to respond to that RFP if you do the formal process. So it it it allows for more questioning and more challenges to to be given from, from our side so we like challenging if we if we disagree with something we're seeing or we were wondering why then it's good to be able to answer ask those questions and get the answers and that's what we often see in the formal traditional way of tendering is that it's just a document and you have to get back with the answers before this time and you have five sentences so there's no room for this so the sooner the better for initial chemistry and then I would always recommend that you do proper requirements via a third party so or so you do or you go sorry you go externally to do the requirement gathering so you don't only rely on your internal notes because there might be something that comes up in conversations that would not come up when you sit internally and discuss it. Also, there will be questions asked by the agency that you cannot come up with yourself.

Chris: Yeah, definitely. I think that's really, I mean, I'd agree with that because, you know, you're bringing in a technical partner who you would hope, right, has an awful lot of experience, both with perhaps your CMS of choice or your architecture of choice. And while I like to think that I've got a reasonable amount of experience and I'm reasonably technical, it's always good to have that external perspective, but also bring some experience and ask some of those tricky questions is really valuable.

Charlie: Fantastic, yeah, so again, it's kind of back to that relationship building isn't it as well and kind of scoping each other out I know Anders when we spoke before, you use quite a nice analogy around dating and you know in those early stages when you're getting to know a client and vice versa so it's about learning whether you know you're going to get on and you're going to work together I think that's a nice way of putting it. 

Anders: Yeah it is a long it is website project it's not for two months it's for many months potentially more than a year so it's very important that you are working with people that you get along with very well. 

Chris: And I guess people might think yeah but you're an agency right you're just pleased to be signing the paper but but you know i know you know anyone will know that's worked through these projects is the last thing you need is to find yourself in a situation where you just can't work with these people or the you know the the you know the and the relationship sours so and that's a natural it's a genuine fear right if you haven't done that work up front I think there is a danger that like you say you just sign the paper let's get let's get going let's get building this thing yeah 

Anders: Yeah and then remember that if you go by the traditional tender then someone sends a document says can you do this and you can say yeah sure we can do that we didn't discuss how we should do it. So now I can assume as an agency, I can do it for the lowest cost possible. So I can just reply and send the cheapest offer I can ever think of. Well, knowing that will never happen. So that's what we see a lot of. We're up against, we get told, "Oh, these guys said they could do it for this price," but based on what? So if we haven't done the thorough requirement gathering, then you're... It's like going to someone saying, "I need a new car," and I need to give you a price. I don't know if it's a Ferrari or Fiat, but I can, as an agency, conclude it's a Fiat because it's cheaper. But you think it's a Ferrari, then we have a problem once we start working together. That's why that requirement gathering in the beginning and aligning expectations is super important.

Chris: And I think it's worth... I think it's probably helpful for anyone listening to talk about how we did that bit of it. It's because I think that once we'd worked out that you guys had the experience and the expertise that we needed, and we were happy to work with you. And again, a little bit of how we did that was that, you know, I'd worked with Novicell previously, and I didn't want to influence anyone's decision in any way, shape, or form. So what we did was we created a scoring sheet with various things we were looking for in a supplier, in a partner. And then everybody that sat in on those initial pitch meetings was scoring all of the agencies, all of the potential partners, based on those same criteria. So we got to that point, that decision to work with Novicell, in a very open, fair, and balanced way, in my opinion. So then we moved into that next piece, and this is the piece that Anders is talking about, like, "Okay, how do you understand what the real shape of your project is?" So our initial thing that we signed up to was that we would just complete that discovery phase. And then we'd get to the end of the discovery phase, which we would pay for upfront, and at that point, there would be an output. The output would tell us all of the things that we'd agreed to, all of the functionality, and basically what was going to be delivered, like almost like a statement of work. And then really, what the real cost for that would be. And for me, that's really important in separating out those two processes because the website and all of the development work, you know, the year-long project is going to be expensive. It's going to be expensive. So it's sensible to do that piece right upfront, to work to make sure that what you think your budget is accurate based on what you want. And then you can have those conversations with your partner around, "Okay, so what is a priority? What isn't? What's critical? What's nice to have? What could we put off into phase two? Or are there different ways of doing the thing we thought about so that we can manage cost effectively?" So I think that's a really smart way of doing it because at least you know what the shape of the project is, and you're not going in under any misconceptions. So everybody knows what the end result is going to be.

Anders: Exactly. And that's how it should be. Sometimes we are locked with a budget where you only have X amount to spend. And then, of course, based on everything that was found out during the scoping process, you have to make some tough choices and then select or deselect functionality to make the budget meet. But at least then you would have a roadmap for afterwards. Yeah. And again, if everything is tied to business goals, then it should be here where you actually have ammunition to go to whoever holds the budget and ask for more.

Charlie: Yeah, I think that's really insightful. I think that whole thing around scoping those requirements early and making sure there's a level playing field for all of the agencies that you've got pitching, then obviously aligning your budget and expectations with that. And I guess just kind of delving a bit more, Chris, into when you worked with Anderson and the team at Novicell, did you have clear ideas of the specific requirements that were integral to the web build, or were there any frameworks that you were keen to follow based on your own knowledge and experience?

Chris: Yeah, I mean, we had a host of non-functional requirements, which sounds very technical and boring, but for me, they're some of the most critical decisions you will make. One of the first places we start on any website project is "Don't Make Me Think." It's a usability principle we like to follow. It's also the title of a great book by Steve Krug, over 20 years old, and it's still just as relevant today. We talked about performance, extensibility, environmental impacts, standards, compliance, that kind of thing. For me, most of those requirements kind of suggested or directed me towards a composable approach. I was familiar with the attention that MACH Architecture was getting but also open to alternatives. It's good to have that vision and those ideas, but we asked every agency, "Validate our thinking. Do you think this is a good fit for us? Feel free to pitch other approaches if they thought it would better suit our needs." So, yes, it was absolutely part of our requirements because it had so many knock-on effects or contributing effects to the end result.

Charlie: Yeah, 100%. We've had Mikkel on from Novicell before, talking about composable architecture and that framework. But Anders, maybe do you want to just quickly give the listeners an overview of what the MACH framework is?

Anders: Oh, you're putting me on the spot here. Well, MACH is basically an acronym for an association, I would call it, some principles. But we like to talk about it in the composable way. It's more like composing a platform. So rather than having a monolithic platform, the suites, where you buy everything in, there's a couple of them that are very well known in the professional services industry. For example, Sitecore is a monolithic platform that promises to give you everything. The way we like to do it is to let you compose best-of-breed or best-of-need systems for what's best for you. Meaning that right now, you might have a marketing automation tool that's the right fit for you, but that might change later on. So that gives you the ability to change that. It could be the recruitment platform or whatever system you have, but all of these systems are connected together with APIs, and no system owns them all. In the traditional way, the CMS (Content Management System) would be the system that owns everything, including the data. And that is very dangerous because every time we have to update that, that comes with a lot of complications because during the time you've had it, you probably customize something. And the more you customize, the more tricky it gets to update. I'm sure a lot of listeners have been through this a few times, but it costs a lot of money as well. So by not customizing that and not letting it have full responsibility of everything, you make it much, much easier to change your mind and change systems during the course of your journey. Platform. 

Chris: I agree. And for anyone listening out there thinking, "Oh, what if we can't customize it? That's no good to us because we have a particular way of doing things." It's not that you can't customize at all. It's just that you're not having to overly customize your back end in your content management system, for example, because that system—you can work within the existing framework of that particular platform. But then, because you're effectively working headlessly, you have a composition layer that sits in between what your clients see as a website and what you're working on in the back end. In that composition layer, that's where the customization to some extent happens. It can take that data and transform it in any way you want and present it in any way you want. So that's where the exciting kind of composition happens. At Ander’s point, if I need to replace that CMS, I bring in a new one, and all I do is just connect the various data points to the same endpoints in that composition layer. So, my bio is coming in a certain way with certain types of information. I just make sure they're mapped to what the composition layer was expecting and what it was getting from the previous system. So it's much easier to do that matching and switching from core source systems than it would be if you had a traditional CMS. In the simplest terms, MACH architecture is about embracing a modular, flexible design philosophy that is tailored to the ever-changing tech landscape that you might use as an organization, but also the equally dynamic needs of your business, which are also changing. And the acronym, microservices—they're just individual, distinct, single applications that deliver functionality or a process. The "A" is API-first products with fully functioning APIs that just make integration easier and more flexible. Cloud is the "C"—cloud-native, with all the benefits of cloud computing: scalability, resiliency, etc. And then the "H" is headless—that's really just the back end where you store and manage your data. As Anders was saying, it's completely separate from the front-end user interface, and APIs deliver your content, your services, your data from multiple systems. 

Anders: It's secure by design as well, meaning it cannot be hacked. 

Charlie: Thank you both. I think that's a great explanation, and we'll also pop the link in this podcast description to Mikkel's recording on composable as well if anyone wants to hear more about that. Just going back to the technical requirements, Chris, in your project, you mentioned some of the non-functional aspects like performance and accessibility. Were there any functional line items included in the RFP from the start that were central to the success of the website build?

Chris: Yeah, definitely, and probably too many to list here, if I'm honest. But I think you need to be clear about what the site should do, and like I said before, don't forget you're going to have those discovery workshops where the real detail is captured and turned into requirements that you then sign off on, obviously. So the RFP isn't an exhaustive functional requirements document, and I think it's very clear we should make that distinction. But you should also be clear about the big-picture decisions that you have made or the big-picture desires that you have. We had some guiding principles throughout the project, one of which was best practice over best in show. An example of that is that we got rid of mega menus, accordions, and other needless interactivity. We wanted a powerful search solution. And I think Anders touched on this. When you buy a monolith solution, you're often hamstrung by their product suite and their offering. You're tied to maybe their search engine, which they know and use well, and it's just part of their product. Whereas with the composable approach, we're able to look at the market and choose the best fit for us. So much of the site is driven through our tagging architecture and served up via search. We had that as a vision initially—a really powerful search solution was critical for us. We had things like language support. We launched with four languages, but we're developing more all the time, and we're just about to launch a Spanish-language site. So we knew there were certain things from a functional perspective that we had to have. Then there's also stuff that's a little bit experiential and might fall into non-functional requirements, but some of them influence the user experience and functionality. Things like bios—for us, our people are incredibly important. Our people are our product, right? We have our consultants who go out into the market, solve problems, or help clients realize opportunities. So explaining how bios play a role in the user experience and the way the site works was incredibly important for us. How those bios are connected and integrated into all of our content and how our people are integrated into insights, service pages, industry pages, case studies, news, press releases, careers pages, job adverts—that was really important to us. When you're in professional services, particularly, your people are your greatest asset, so making sure you're demonstrating that and showing them off throughout your site was critical. Again, it helps you get that message across to your partner so that when they come in and do the more structured pitching, they get it. They understand what matters most to you and your business.

Charlie: Yeah, I think that's really insightful. Thanks, Chris, for that. And I guess, you know, to your point around your people being your greatest asset, you know, does thought leadership come into that? You talked about the bios and kind of showing off, you know, their expertise. Was thought leadership a consideration kind of during that process as well?

Chris: Yeah, of course. I mean, so yeah, okay. So what I suppose what I'm talking about with bios, right, is that the huge focus for us is personal brand and market presence for our consultants. The best way to do that to develop your personal brand and build a market presence is to have an opinion and to demonstrate your expertise and your experience and insights. Thought leadership is a powerful way to achieve that. You know, content syndication and activation is probably the most critical piece, right, because just because you build it, you know, "if you build it, they will come" is not true, right? Just because you've written this piece, you've got to activate it, you've got to get it out into the market, you've got to make sure people are seeing it, but then you need somewhere, I think, a central hub for all that activity to link back to, and your website is that, right? So yes, absolutely, it should be part of your RFP.

Charlie: Brilliant. And I think, you know, that activation piece, like as you mentioned as well, is really important. Well, you've both shared some fascinating insights today, so thank you both. I guess just lastly before we leave you for the day, if you could just give one kind of essential piece of advice for a CMO embarking on a website project or about to write their RFP now, what would that be? And Anders, if we could start with you.

Anders: Besides everything that was just discussed, I would say remember that content is king. So it's all about content still. We're talking about a lot of technical stuff here, but the key thing is to have interesting content and have a great user experience to drive engagement and conversions. That is why you embark on a website project. The technical stuff is just an enabler to reach the end goal.

Chris: I'll assume for all the right reasons that that CMO has an experienced head of digital who's writing the RFP. You know, maybe I would say that, right? But, you know, that would be my first recommendation. I genuinely can't tell you how many senior marketers I have spoken to since we launched the website who don't have an in-house subject matter expert. Aside from writing the RFP, you know, that individual is likely to be connected to a network of digital peers who can recommend partners, agencies they've worked with, or who will have their own list of trusted collaborators from their career. It probably isn't going to be their first rodeo, so they can advise on best practice, they'll understand technology transformation, how to run a project, you know, and they'll be the key relationship with whichever partner you choose to work with. So, you know, I think that, you know, it sounds like I'm playing my own trumpet a little bit, I've just realized, but I genuinely think that you're kind of starting out the right way if you make sure you've got in-house skills to help you navigate what is going to be a very complex and challenging project. And maybe my last little bit would be I'd wrap into that, you know, talking about making sure you've got a subject matter expert in-house, but don't treat this as a BAU project. And what I mean by that is don't expect your probably already very busy team to then manage a complex technology project while doing their day job. I think it's unfair, it's asking for trouble. And when you're talking about budgets and things like that, just make sure you're baking in budget to help. We did things like we brought on a firm we had worked with for a long time, but we brought that person in to manage the whole content work stream. To add to Anders' observation, yeah, content absolutely is king, and anybody who has ever run one of these projects will know just how challenging it can be when you start to get the broader business involved. You've got people suddenly realizing, "Oh, wow, I've got to rewrite 15 different pages about my practice area," or "I've got to come up with 17 case studies," or whatever, you know. I'm probably exaggerating slightly, but that's where the complication comes, because for those people, this isn't their job. This isn't necessarily their priority. And so, managing that content work stream is tricky. Bringing in external resources to do that was sensible for us, and I think it's probably sensible for anyone embarking on a project like this.

Charlie: Yeah, I think that's a great point. And I think around the in-house expertise, you know, there will be firms that don't have that kind of technical expertise in-house. So, I guess it's about, like you mentioned, building the right networks, partnering with the right people, and kind of building that team early on, whether it's internal or external, just to make sure that you've got the right people on board for the project. So, yeah, great points from you both. Thank you. Well, that's all we've got time for today, so thank you both, Anders and Chris, for joining CMO Series Digital Masterclass. I'm sure any of our listeners wanting to learn more from you both can reach out on LinkedIn. For anyone listening, you can subscribe to the CMO Series podcast on your favorite podcast platform and find all of the episodes of Digital Masterclass at passle.net/digitalmasterclass. So, thank you all, and we'll see you next time.