How to Define The Success of Your Digital Project – Membership Marketing 101

Hi everyone and welcome to The GRM Membership Marketing series! 

Curious to see what three different departments have to say about how you can define your digital project success? Watch our video!

SHOW NOTES & RECOMMENDATIONS

Membership Marketing 101 Episodes

VIDEO TRANSCRIPTION

H: Hi, guys. It's Harry from GRM Digital.

I hope you're all well. I'm the business development manager here, and I've been invited to take part in 1 of our podcasts. Today's podcast is a really interesting subject, so it's off the back of a tender that we were involved in.

And one of the key questions that came up within this tender is: how do you define the success of your project?

So, me and the team, felt that it'd be a really interesting subject to do a podcast about. So, I really hope you enjoyed today's content.

With that, I'd like to pass it over to Nej and Rob to introduce the subject in a little bit more detail. 

N: Thank you, Harry. Yes. Very, interesting question. And I think it's a question that applies in many contexts.

It's a very loaded question as well. How do you define a successful project? And I think that a successful project looks different from the various perspectives of the different stakeholders that the project impacts.

I think broadly, there's the way in which I would address that is I would say that there are two different things to look at.

One is the actual deliverable of the success of the deliverable. Does that deliverable achieve the objective that was set out at the outset?

And the other one is the actual project's life cycle itself. Has that been successful and what defines whether that's been successful or not? Would you agree with that, Rob?

R: Makes sense. You answered the last question on the recent tender. 

N: We do tenders, all the time when we get asked a lot of repetitive monotonous questions.

But this time, this question really stood out because it made us think about how we define successful projects and actually put this down on paper.

How do you differentiate between what's a successful project and what's not a successful project?

R: Well, I would say it was actually good for that question to be put towards one's rather than someone coming towards with a brief saying this is what will define a successful project, which, in many ways, comes across, as we've had it before, we're defining a successful project might be just being on a budget.

When in reality, we know that it's much harder than that, isn't it? Especially when you think deeper into the target audience who might be using a website. 

N: So, and I think you touched on one area there, but going back to the other area, I think it's very much in line with the conversations that we sometimes force at the outset of engagements and projects that we do with our clients and one of the key questions that we always ask is how are we going to measure the success of this website or application or portal depending on what kind of engagement it is.

And we have an entire workshop that talks about that because it's a very thought-provoking, discussion, that actually forces us to say, right, that that let's define some metrics that are going to be clearly represented if those metrics are moving in the right direction, they're going to clearly represent that what we built here has been successful.

It's a way in which we as an agency also guarantee our success to some extent because if we agree on clear metrics and we know exactly what those metrics are and what our focus is going to be and by what measurement the success of our implementation is going to be measured and we can, with a level of confidence, an influence that clearly demonstrates an improvement in those objectives.

That's why it's really important to select measurable KPIs that derive from high-level business objectives, that we can then clearly demonstrate through a user journey and focus analytics around that.

R: I would say, obviously, the key point for me, you've just mentioned there are the high-level business objectives because obviously in large organizations, this might be a project that's run by just one small segment of that.

What they're trying to achieve with that project has got to be it's got to be part of an overall bigger picture as well.

So, that's why in the workshops, we always try to get people from these organizations involved so that they can have an important into what sort of metrics and KPIs they think we should be.

H: So, taken from what you've said, the message that I'm getting is to take an analytical approach to measure those metrics.

Now in your experience, we specialized within the membership and an NFP space.

In your experience, Rob, are there any key performance indicators or any commonalities within the key performance indicators that you could group together that somebody who is trying to define the success of a project could consider?

R: Yes. That could be I'll give you an example. I mean, you touched on the membership sector. For them, that could be improving the value that their website brings to their members.

In which case, that would just be having them on the website for a longer period of time. So, time on the page and how often they're engaged in a certain piece of content. How many pages they're viewing before they leave the website? How many login sessions they're getting on a log in area that they might have? Training courses are attended online.

All these sorts of things are amazing metrics, which sort of do all come together to add to that overall goal of, let's just say, the higher-level business objective is to increase value for members.

So, you can see how that sort of like transpires down in stem smaller metrics. Which we the most important thing we can easily track online. 

N: So, another simpler example, let's say, is an example that might apply to an e-commerce organization.

The business owners of senior management are going to come to a meeting with those whom we're not selling enough online. We need to make more money.

Our website is not generating enough revenue. That will then translate down to, okay, we need to get more transactions. We need to get more completed searches. We need to drive more relevant traffic to the site.

We need to, I don't know, get more catalogue downloads or whatever. But the high-level objective is always just very unspecific about it. It's specific about what the business needs.

But it's not related to how the business is going to achieve that. If we go and implement a solution that they clearly demonstrate, right, the level of traffic you've gone up until now has been here.

That becomes a KPI. We continuously want to do various activities that are going to increase that level of traffic. At the same time, we'll look at the number of transactions.

We'll look at increasing the number of completed transactions. We look at things like average basket value and we look at increasing that and what those things define for us are key functionalities and areas of focus.

So, for example, for increasing the basket size, well, it's all about the categorization of products and recommending the right products to the right users through that journey so that you'll encourage them to buy more.

And then once the project has gone live, that's the time when we can actually continually look at those KPIs and do continuous improvements and what we would expect to see in any of these scenarios, as long as those numbers are clear, is a consistent improvement on all of those KPIs that we keep influencing and driving forward.

H: It's really interesting.

A question that came to mind, as I was listening to you, both, there was especially for our viewers and our listeners within the membership and particularly those who may be looking at a project at the moment and its success of it.

Are there any key challenges or common challenges that occur within the membership in our experience that we could share with our viewers today that might help them when planning a project in the success of that project?

N: Well, so before answering that question, what I think would be useful is we've talked about defining the success of what we're implementing.

Right? So how is the solution going to be either successful or not successful? I think it'd be useful just to reiterate the other aspect of success, which is the project life cycle.

So, I think it's important to recognize one factor that applies to every project in any industry. So, every project has three key constraints.

Right? You have your need for what you're actually building. You have a budget and you have a time frame. Now what we always say to our clients is look, on any project, we can guarantee two of those three constraints.

We can guarantee to me and fulfil two of those three constraints, but there always has to be some flexibility on one of those constraints.

So, for example, if an organization has a fixed budget and they need to be live because of a key event within their industry by a certain date then there has to be some flexibility in the actual deliverables.

So, in a case like that, we might do what we call a Moscow matrix where we developed fundamental functionality that's critical and the rest of the functionality becomes the best endeavour as long as it doesn't impact the budget or the time frame of that delivery.

So, a lot of times, you know, we get inexperienced teams coming to us and saying, yeah, it's going to be on a budget, on time, and in scope.

But to actually expect all 3 of those things on a project. And that's the only way that you're going to determine that a successful project is to set yourself up for an unsuccessful project.

So, I think it's also important to look at how are we going to look at that implementation life cycle to define that element of success.

R: I think, as you say there, it's interesting that know, the number of briefs that we come across that have that as the definition of success, like the time frame and the budget when you can almost see that they're not thought on a deeper level in terms of what this project, let's just say, it's a website might mean for their members, you know.

So, I think, we do get some strange looks when the first initial question we come up with is how do you define success the success of the website, for example.

And it's almost like they haven't planned for that question, isn't it? This is funny when you look at the scope of these briefs as well. 

H: So, why do you think that is within the membership space? Is there a particular reason or a set of reasons that have contributed towards that being the case?

Or is the industry slightly behind the early adopters? 

N: So, I wouldn't say it's a membership-specific problem. I'd say it's a general marketing and digital marketing problem.

Like, that that's a historical problem. Right? And 1 of the things that for me is about hate is opinions. Right? Opinions are something that everybody's got.

And a lot of the time organizations will get a group of people around the table that could be a talented and experienced group of people that will make a decision about, oh, I like that or I think that would work or that would be good, whatever.

The fact of the matter is that you know if you're defining success based on the opinions of a group of individuals, but you're not defining metrics, on how you're going to measure that on how you're going to measure that success, then you're going to appear successful in the eyes of some appear unsuccessful in the eyes of others.

It's so why this question is really important and thought-provoking is what we try to get away from an opinion. Right? We might have built an awesome solution that's actually exceeding the expectations in terms of deliverables for all the stakeholders.

But then you might get some team member or manager that comes along and make comments on “I don't like the look of that”, Right? By then bringing them back to, okay, what's the purpose of that? Well, look. That purpose has been fulfilled and it exceeded.

It’s kind of, in a very polite way, negates their opinion in that.

R:  I'd also say as well not going to, by sort of, when they come at you with a proposal, it's defining the success based on the free fundamentals.

And as you mentioned, I think a lot of it's down to down to maintaining or trying to maintain a bit of control, because in a way they are engaging with a third party to come in and help them with this project.

So yes. And I think in many ways, it's they've got that opinion in the house of what they think the website should be.

So, they'll come in with a list of very specific requirements and sort of maintain control by saying this is what we want.

The success needs to be it needs to be on a budget, on time, and within scope when in reality, they're not really thinking of the bigger picture and using external assistance.

N: A statement we categorically make that goes all hand in hand with that question and that would be my advice to anybody out there undergoing any sort of a digital project.

If you can't measure it, don't bother doing it. Okay. 

R: So, defining success than in your experience, and as you might obviously work on projects a lot longer than most do have, what tips would you give then? So, it's not to be too specific with your answers when it comes to success. Or how would you define success?

So, I think that the example that we gave was a great question to put across in a tender. Right? What we don't like to see is tend is too restrictive, that is too focused on defining the success metrics for the agency and hand in hand disabling the agency from truly adding the value that they are there to add.

So, I think that you know, what's important is to communicate the high-level business objectives. To explain the reasoning and the drivers behind that project and to leave it to the agency, to actually advise on how best to demonstrate the success of that project. As far as the constraints are concerned in terms of project delivery, that's common for everybody.

You've got a time frame. You've got a need. You've got a budget. Any organization, any agency that comes to you and says they can guarantee all three, they're full of crap. Right? Because there's no way that anybody can guarantee that because, for example, mid-project, there might be a new browser version released that requires extra time.

There might be a new device created by Apple with the screen size that's previously been on support and now we need to cater for it. So, there are a lot of unforeseeable within our industry.

That's why choose what to constrain to be critical to you. Aim to get those two constraints locked in and clarify to the agencies. So that when the agency plans the project implementation they plan it in a way where they are focused on fixed deliverables of two constraints, but have some flexibility in that third constraint. Does that answer your question?

H: I think it's really useful for me personally speaking. But also, many of the listeners as well to listen to you and your experience within the industry.

I do have a question. Now I'm not entirely sure it's specific to our subject, but I will ask it because it's come up in a lot of conversations I've had with prospects.

Now when trying to define the success of a project, in many cases, it is a web transformation project that a lot of these organizations are doing.

Now in many cases, a lot of organizations a stumbling block for them is selecting the right technology.

So, making sure that the CMS that they've selected is correct. And a common theme that we found is that many agencies have a technology preference in mind.

That they tend to push forward to their prospects. I understand that we take a completely different approach as a technology-agnostic organization.

But what important significance does just selecting the right CMS to play in defining the success of a project? 

N: It's a little bit of an in a lot of people's minds, it's a little bit of a chicken-and-egg situation.

Right? Do you select an agency and allow them to select your product once they define your requirements? Or do you select the technology and then find an agency that's comfortable delivering that technology?

In our experience, we believe that technology should not drive deliverables or the specification of those deliverables, we believe that we should always lead by defining the ideal solution from a user journey perspective, and that's not just an external user journey, it's internal users. So, the people that are actually responsible for managing that website.

That's what we've always leaned towards. But it you know, in some organizations, in some scenarios where, you know, you've got a very, for example, in large corporates that own multiple brands and in multiple countries and they've got a centralized IT team and a centralized development team where they're restricted to certain technologies and so on.

It may be viable go and select a technology that's going to be suitable to support the organization as a whole because of the unique scenario that the centralized team is looking to fulfil or the unique skill sets that they have.

Both approaches can be valid. In terms of agencies having a preference, well, that's not a preference towards this suitable product for you Mister Client, this is a product that we've got skills, and it's easy for us to develop, and we've got a partnership, and we got a kickback from reselling the software and we get partner status, etcetera.

So, I think a lot of the time, you know, it's important to recognize the drivers behind an agency's recommendation. With that, there is one caveat that I'd like to put out there - a jack of all trades and master of none.

So even though our approach and objective are to be technological as we will never enter a situation with already having a preferred choice of what technology we want to sell. We also can't be experts or leverage technology out there.

So the way in which we've dealt with that approach is we continually look at what the tech key technologies are and try to cherry-pick a couple of leading headless options, a couple of leading enterprise traditional CMS options, a couple of very flexible mid-tier options, and then maybe 1 or 2 open source options, and then make sure we've got team members and teams that are skilled up within those technologies so we can still deliver quality whilst not being married to a solution from the outset. 

H: That's really interesting. That really does answer the question.

Rob, what's your perspective on this? 

R: Mine is, for me, I guess, just worth saying it's refreshing when an organization comes towards and isn't married to technology, but is open to actually understanding what else is out there.

You know, there is always the option that an organization could use two agencies, use one for the consultancy, and then find someone else to deliver the rest, which is an approach, which we know has worked well in the past. So, I guess, yeah, you don't want the technology to be determined and the success of the project in any way.

That's got to be like deeper business objectives to do that and that should be in detail based on a consultative conversation with experts in the CMS industry, what technology options you should then consider?

N: I think it's also important to say a couple of cliches, but 1 size does not fit all which is an argument as to why you can't go into a conversation about web projects with a solution already in mind.

However, it is also software. So, there are multiple solutions to any particular challenge Right? Because it's software, we can get it to do anything, including make you toast in the morning.

Right? The question is, how complex or how costly it will be to get that particular software to do what you needed to do? So, there are multiple solutions to any challenge. So, if there are criteria like we prefer a dot net technology because we've got a development team that's able to support that, we prefer working in a cloud infrastructure because we don't have any service and everything else hosting cloud and things like that.

Those can be criteria that are specified at the outset of a project because that does not mean that we're restricted as to the recommendations.

It just means that we're one step further in narrowing down the suitable options for that particular organization because we want to fulfil all of their needs.

Right, their operational needs, as well as their users' needs, as well as their overall business needs from whatever solution is that we're building.

But I think it's I think this has been an interesting topic to discuss. I think it's It it's a great question that really stood out on a particular tender.

And I hope that this discussion is going to trigger some more interesting questions from our audience that we can possibly dissect in our future discussions.

H: Yes. Absolutely. I mean, before we close off, Robert. Have you got any additional comments to add to that Nej just said? 

R: So, I guess I, just be glad to summarize.

Wouldn't it be the key points very quickly? How do you go about measuring success? For me, like, things I would look to do would be to include people at all levels of the organization in asking that question.

Be open to receiving outside consultancy from an agency that's probably been there, done it, and worked with organizations similar to yours. And I think that's probably it from you, Nej? Any quick ones?

N: For me, I think it's important again to differentiate the success of project delivery and the success of the solution that's being delivered. I think that question needs to be taken into those two separate dialogues.

And in reality, once you've defined those criteria in both of those remits, then success on the delivery and the success of the solution is what ultimately defines the success of the project. 

H: Absolutely. Well, thank you, both gentlemen. Really appreciate that very, very much. And thank you for watching today's podcast as well.