¶ Intro / Opening
Welcome to the CMO Series Dish to Masterclass.
¶ Introduction to RFP Mastery
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 Novosel, and Chris Etherton, Head of Digital at Alex Partners, 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 for the clear understanding of both the functional and non-functional requirements. So welcome Anders and Chris. Hi Charlie, thanks for having us. Thank you both for joining us today. It'll be great I guess to jump straight in Chris and to set the scene for those who don't know you.
Briefly kind of talk us through your website project at Alex Partners and where it's at now.
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 which certainly helps and i think we probably realized the vision that we set out right at the very sort of start of the project which was to develop a business tool rather than just an online brochure so so we're kind of seeing that already you know without without changing any behaviors or processes elsewhere in the business we're seeing you know an average of sort
of two mqls a week for business opportunities purely via the website via some of the new forms and things that we build into that and ctas and you know that's in addition to the you know.
¶ The Importance of Clear Requirements
Conversations and conversions that come through the website you know such as clients reaching out to consultants directly through their bios and that kind of things so i think that's a i mean it's a great signal already that it's working or starting to do the things we wanted it to do and it's just incredibly flexible optimized for seo our pages index incredibly well, carbon score on the website is fantastically low very soon all of these things were kind of you know in our in our heads when we
started started out and you know that things like a low carbon footprint contributes to you know performance a blisteringly fast performance on our site on any device anywhere in the world so so yeah so we're very happy and then that's just the start really you know we've got a fantastic foundation to build on you know in the in the years ahead yeah that sounds amazing and great to hear that you've already got those kind of leads coming through
off the back of the new website so yeah brilliant thank you for kind of giving us an update on that and I guess kind of you mentioned setting out those kind of requirements from the start it'd be great to hear from you both on this one. Why are RFPs kind of important in this process of building a website? And what are the big things that firms often get wrong?
And Anders, should we start with you on this one? Sure. Well, you mentioned yourself that the requirements, it's essential to know your requirements. But often we see that the requirements that you have gathered on beforehand, they are not sufficient. So it's good to have a thorough internally do your due diligence, go through everything, speak to the relevant stakeholders and then create your own requirements.
But then start speaking to agencies at that point, I would say, already to be challenged a little bit. Hopefully it will mean that you end up with a more thorough description of what you need. Yeah, great. And I guess, Chris, from the client kind of perspective, and obviously you have a very technical background as well.
What's your kind of stance on that with you know where do you see firms often going wrong with the rfp for me my feeling is at that very first point right where you're where you're you're you're out in the market and you are looking for a you know a suitable partner somebody you're going to be spending quite a long time with you know i think for me you always need to be looking a little bit looking at things a little bit differently than perhaps you would do from a traditional rfp process.
And what I mean by that is that kind of procurement type, IT-led type approach.
¶ Crafting a Discussion Document
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 the 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 you know in some of your thinking and and bring expertise to the table and. Won't just deliver you know kind of.
What you've written down on your rfp and also that you just that they're you know you know you can work with them right you're kind of testing you're trying to develop a relationship and understand you know understand what these these people are like and whether you're going to be able to work with them for this for the next whatever 12 18 months maybe more depends 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 I think you're trying to get a sense of you know who these people are that you're going to work with and you know explain your problem and get them to come to the table with maybe new ways of thinking to you know kind of help help you get a feel for what that relationship is
going to be like 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 the bigger picture in that vision and and kind of seeing if you're the the partner's on board with that i guess and and also getting their view on on how to approach it i think it's a good place to start you're going to go down the road of you know that you will go through a full onboarding and process and that
and a large part of that will be detail requirements gathering you know your discovery phase etc so you know you're going to cover all those bases it's not like you're being you know you know you're not just kind of writing something on the back of a fag packet but you know that i think that if you're thinking about just going out into the market and and looking at who your you know potential partners will be that's a good way to start i i wholeheartedly agree.
¶ Building Trust with Agencies
I think often we see that companies come to us and then they have noted down their requirements and then they think that it's the holy grail and they know everything. They actually also know what they need so that 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 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 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 I think a really good point it's about at that point I guess building that trust building those relationships and and kind of working with someone you you kind of have that shared vision with so I think that's 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 alex partners 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 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.
¶ The Role of Data in Projects
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 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 and
you know functionality that's a great way of doing that 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? 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 challenge challenges to to be given from from our side so we we like challenging if we if we disagree with something we're seeing or we we're 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 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.
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.
¶ Relationship Building in Projects
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 yeah it is 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 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 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 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 well knowing that will never happen so that's what we see a lot of where 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 are you know you're 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 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. And I think it's worth, I think probably helpful for anyone listening to kind of talk about how we did that bit of it.
And 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 Novosel previously and I didn't want to...
Influence anyone's decision in any way shape or form so what we did was that we created a you know a scoring sheet with a various various kind of things that we were looking for in a in a in a supplier in a partner and then everybody that sat in on those kind of initial pitch meetings were scoring all of our all of the agencies all of our all the potential partners based on those same criteria so you know we got to that that point that kind of you know the
decision to work with novicell in a in a very open and fair and balanced way in in my opinion so then then we move into that next piece and this is the piece that that andis is talking about kind of like okay so how do you understand what the real shape of your project is and we so we our initial the initial thing that we signed up to if you like was that we would just complete that discovery phase so and then we'd get to the end of the discovery phase which we would pay for up front
and then And at that point, there would be an output and the output would tell us all of the things that we'd agreed to, all of the things that all of the functionality and all of, you know, basically what was going to be delivered, you know, 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, you know, because you know, the website and all of the development work and, you know, the year long project is going to be, it's going to be expensive, right? It's going to be expensive.
Sensible to do that piece right up front to work to make sure that you know what your what you've what you think your budget is is accurate based on what you want and then and then you can have those conversations with your with your partner around okay so what is a priority what isn't what's a what's a what's what's critical what's a nice to have you know what could we map perhaps put off into phase two or are there different ways of
doing the thing that we thought about so that we can manage cost effectively so and 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 you know everybody knows what the end result is going to be 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 then you have to make some tough choices and then select or deselect functionality or whatever 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 and ask for more yeah i think that's really insightful i think that that whole thing around kind of scoping those requirements early and making sure you know there's a level playing field for that for all of the agencies that you've got pitching then obviously aligning your budget and kind of expectations with that and
I guess just kind of delving a bit more Chris into when you work with Anderson and the team at Novosel did you have kind of clear ideas of the specific requirements that were integral to the web builds or were there any kind of frameworks that you were keen to follow based on your own knowledge and experience?
¶ Understanding Technical Requirements
Yeah I think I mean yeah there were I mean we we had a host of non-functional requirements which, sounds very technical and boring but yeah 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 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 but environmental impacts standards compliance that kind of thing and i guess for me for most of those requirements they kind of suggested or lent lent towards directed me towards a composable approach. And I was obviously familiar with the attention that Mac Architecture was getting, but also open to alternatives, as we said. It's good to have that vision and those ideas, but I think it's fair to say
that 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, probably one of the biggest parts of our requirements. Yeah. Because it had so many knock-on effects or so many contributing effects to the end result. Yeah, 100%. And I know, I mean, we've had Mikhail on from Novosel before talking
about composable architecture and that kind of framework. But I guess, Anders, maybe do you want to just quickly give the listeners an overview of what the MAC framework is? Oh, you're putting me on the spot here. So, well, there's two different things. So MAC is more like it's basically an acronym for an association, I would call it. So some principles. But we like to talk about it in the composable way.
So it's more like composing a platform. So rather than having the monolithic platform where you, 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. It's a monolithic platform that promises to give you everything. And then the way we like to do it is that we like to let you compose best of brief or best of need systems for what's best for you.
Meaning that right now, you might have a marketing automation tool that is 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. It could be whatever system you have. but all of these systems are connected together with APIs and there's no system that owns them all.
¶ Composable Architecture Explained
So in the traditional way, the CMS, content management system, would be the system that owns everything and 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 i agree i think i you know the you know and for anyone listening out there thinking that oh what what if we or if we can't customize it that's that's no good to us because we have a this particular way of doing things or it's not that you can't customize at all it's just that you're not having to overly customize your you know your back end in your in your content management system for example because that system you know you can you can work
within the existing framework of that particular platform but then you have in you know because you're effectively working headlessly you have like a composition layer that sits in between you know what what your clients see as a website and what you're working on in the back end in that composition layer that can work you know like that's where the customization to some extent happens you know it can take that data and it can transform it in any way you want and present
it in any way you want and so that's where the that's where that the sort of the the exciting you know kind of composition happens and then what happens to and this point you know if i need to replace that cms then i bring in a new one and all i do is just connect the various data points to the same end points in that composition layer so you know my yeah my bio is coming in a certain way with certain types of information i just make sure they're
mapped to you know what the composition i 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, Mac 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...
¶ Non-Functional vs Functional Requirements
You know the equally dynamic needs of your business which are also changing so you so you know and the acronym microservices they're just individual distinct single applications that deliver a functionality or a process the a is api first products with fully opening fully functioning apis that just makes integration easier and more flexible cloud is the c cloud native and you know all the benefits of cloud computing you know scalability resiliency etc and then
the h is headless you know that's really just the back end where you store and manage your data and you know as anders was saying completely separate from the front end user interface and apis deliver your content your services your data just from multiple systems so it's secure by design as well meaning they cannot be hacked brilliant thank you both i think that's a great explanation and we'll also pop the link in in this podcast description to michael's recording on composable
as well if anyone wants to hear more about that just kind of going back to those the the technical kind of requirements chris in your project you mentioned some of the non-functional aspects like performance accessibility were there any kind of functional line items that were included in the rfp sort from the start that were central to the the successive of the website guild.
Yeah definitely and probably too many to list here if i'm honest but i think yeah you 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 details 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 to me, we should make that very clear.
But you should also be clear about the big picture decisions that you have made or the big picture decisions or desires that you have. We had some kind of guiding principles that we used 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 sort of other needless kind of interactivity. We wanted a powerful search solution. And I think Anders has sort of touched on it just now.
When you buy a monolith solution, you're often hamstrung by their product suite and their offering. So you're tied to maybe their search engine that they know and use well and it's just part of their product. Whereas with that 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.
And we kind of had that as a vision initially that you know a really really powerful search solution was was critical for us yeah we had things like language support obviously you know we you know we launched with four languages but we are you know developing them all the time we're just about to launch a spanish language site so you know so we kind of you know we knew there are certain things that from a functional perspective
you had to have then there's also stuff that's a little bit experiential and so maybe would fall into the non-functional requirements but actually some of them i mean i like to talk about them sometimes because they feel like they're they're they're going to influence your you know the the user experience and the functionality so you know things like bios like for us our people are incredibly important they are kind of really our our people are our product right
because you know we we have our consultants that go out into the market and they and they solve people's problems or they help them realize the the opportunities so you know explaining how the how bios on the role bios play in the user experience and the way the site works was incredibly important for us you know so how those bios are connected and integrated into all of our content and how our people are then integrated into all of our content you know from insights to service or industry
pages case studies news press releases other other people's bios you know careers pages job adverts you know it's when you when you're in a. You know when you're in professional services particularly your your people are your greatest asset so making sure that you're you're demonstrating that and showing them off right the way through your entire site was really important to us and again it helps just helps you get that message
across to your to your partner so that when they eventually do the then come in and do some of that more structured pitching you know they they get it right they understand exactly what matters to you, what is most important to you and your business. 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?
¶ The Role of Content in Success
Yeah of course i mean so yeah okay so what i suppose what i'm talking about with bios right is is that the huge focus for us is personal brand and market presence for our consultants so the best way to do that to develop you know your personal brand and build a market presence is to have an opinion and to demonstrate your expertise and your experience and insights or thought leadership is a powerful way to achieve that you know content syndication and activation you know it's probably the most
critical piece right because you just just if just because you build it you know if you build it they will come and it's not it's not true right yeah just because you've written this piece you know you you know 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 link back to and your and your website is that right so yes absolutely it should be it should
be part of your rfp yeah brilliant and i think you know that that activation piece like as you mentioned as well is is is really important well you've both shared some some fascinating insights today so thank you both I guess just lastly before we we leave you for the day is 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 besides everything
that was just discussed I would say remember that content is king. So it's all about content still. So we're talking about a lot of technical stuff here. But the key thing here 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. So the technical stuff is just an enabler to reach the end goal. 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 but, you know, that that would be my first recommendation. I genuinely I 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 you know from their career yeah 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 there'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'm a i'm a i genuinely think that you know you're you're you're kind of starting out the right way if you 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 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 it's unfair it's asking for trouble and if you're you know when you're talking about budgets and things like that just make sure you're baking in you know you know budget to help you know we did things like we brought on a actually somebody
we worked with a firm for a long time but we brought that person in to manage the whole content work stream which you.
Know you know to add as and as 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 and you've got all of the you know people suddenly realizing oh wow i've got to rewrite you know 15 different pages on in you know 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, you know, managing that content work stream is tricky. So bringing in industrial resources to do that was sensible to us. And I think it's probably sensible for anyone embarking on a project like this.
Yeah, I think that's a great point. And I think around kind of 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.
¶ Final Advice for CMOs
So, yeah, great points from you both. thank you well that that's all we've got time for today so thank you both um 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 to 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 puzzle.net forward slash digital masterclass so thank you all and we'll see you next time.
