Approaching a project the right way is key to minimising the risk of Digital Transformation projects going wrong. In this video, Troy and Andy talk through ways to approach large and complex projects.
Video Transcription
– Hi, I’m Troy, founder and managing director of Increaseo, and I’m here today with-
– Andy Farrell, I’m the head of digital and UX.
What can go wrong with complex digital projects?
Troy: So we wanted to have a chat today about complex projects and what could go wrong when building out digital projects.
So, what are some of the things?
Andy: I thought you said it was going to be a short show. If we talk about what goes wrong, we’ll be here for quite a while.
Look, the sad thing is a lot goes wrong, very often, and I mean that’s kind of the nature of the beast, in the IT space. But, let’s just think about some of the things that happen typically though.
1. Not getting what you expected
I suppose the biggest one is that what people think they’re getting, that’s not what they end up getting. That’s probably the number one problem, is a whole missed expectation.
2. Budget overruns blowouts
Number two would be budget overruns. People predict how long something will take and what it will cost, and it ends up taking much longer and costing much more.
3. Stakeholder disconnect
I guess one of the other things would be, where an organization effectively gets stakeholder buy-in from the entire team, and you get this kind of disconnect between what different people in the organization were hoping for and what you end up getting.
4. Customers pain points ignored
The fourth one, which is probably the biggest thing, is that the pain points and the expectations of customers are completely ignored.
And this is a huge challenge for any business, they become quite introspective, and their field of view is unfortunately very narrow. Just the fact that they’re inside the business. They don’t necessarily have a sense of what is the outside view of their products and services.
How do people wish they could engage with that particular organization?
That’s completely missed very often.
Methodologies to mitigate risks
Troy: So is there any methodologies and ways of approaching this that might help mitigate the risks?
Andy: Yeah, there are. There’s a whole lot of things. And we’ve been doing these things wherever we can. We don’t always get to. But, our ideal approach is really to break up these larger projects into smaller pieces, first of all.
Troy: To help de-risk it?
Andy: Yeah, it helps to eliminate risk. But it also helps to better undercover what the project should achieve. I suppose the first step is to step back and ask the question, “why are we doing this, and what are we actually hoping to change?” And, that means not just thinking in terms of what does the business expect to get out of this, but what’s the outside effect going to be. And to, also, get some perspective in terms of the space you’re in. So that might mean looking at:
- What are your competitors doing?
- What are some of the benchmarks for the industry?
- What do customers currently think of the experience you’re offering today?
- What’s their typical behaviour in the digital space that you already provide?
- What are they doing now?
So there’s lots and lots of questions like that.
You know, there’s usually a whole array of different processes we
can adopt, and go through that actually formulate a digital strategy.
That’s actually another big step to go through, is to essentially look
at what we can do. To help answer all those questions, and then together decide, what are we going to adopt to actually get those answers that will put some real shape behind the initiative.
Troy: Okay.
How do you meet customer expectations
Troy: So now we’ve formulated a digital strategy based on, I guess, competitor analysis and that sort of stuff. So, you talked before around, meeting customer expectations. Where does that come into the process, and what can you do about that?
Andy: The second stage is typically around the user experience. And, we want to be informed by what customers’ behaviour typically is in order to put some shape around that. And there’s quite a lot of challenges, in really getting into the minds of customers.
So one of the things we do early in that process is to go out and actually talk to customers, and interview them, and have a conversation with them. The intention is not to pitch or propose ideas, but to explore what are they doing now, what’s happening now in their world when they deal with that organization?
And so that means you need to have a conversation that draws them out and allows them to reveal those pain points, and then you can use that
dialogue as a way of starting to drill deeper into some of those problems, and figuring out where are the opportunities, to try to make that a better experience overall.
What we then do is, from that, we start to see common problems reoccurring. There would be certain themes and stuff, being repeated. You reach a stage where the next customer interview you have, you actually can almost guess the answers to your questions.
And that’s probably a good time to stop and say, well, now let’s organize the customers as we now understand them, into what we call personas. Which is basically a way of grouping customers together, based on their behaviours and expectations; demographics is a part of that, but it’s mostly about behaviours.
And we come up with a few prototypical customers whose problems we are trying to solve. And it may be there’s only a couple and sometimes there could be many more. It depends on complexity and services how many different touchpoints, in the outside world there are with your particular business.
From there we can then, start to identify, based on those conversations, some of the goals that customers have and begin to propose a solution around how we might solve that.
Wireframing
Troy: So is that when you start to dive into design? Or, are there steps before the design?
Andy: There is a design process.
But it’s tempting to start thinking in terms of visual design, as far as the aesthetic goes, but that comes later.
So at this point what we’re doing is trying to keep it abstract because what we care about first of all is the flow, and what particular features we’re going to have, and how do we represent that quickly in a way that can be changed rapidly, and yet still test it.
And so the tool that you see used quite often, and that we use a lot, is what’s called a wireframe. So it’s basically a lo-fi version of the site. It’s just black and white. Very simple aesthetic. It’s just literally lines and boxes and dots, and it’s annotated, and that way, we can essentially create a blueprint of the site, application or product. Whatever it happens to be.
And that’s great for getting everybody across what we are thinking of building.
Prototyping
But we can also take that, and it’s easy to then run some tests to validate the way we are architecting the structure of the site, the way we’ve positioned various interface elements are actually in the right place.
Troy: So you can take that back to the personas that you developed and see how they interact with it?
Andy: Yeah.
So there are tools we use to actually test real users running through that prototype.
And the way we do that is rather than prompting them, by saying, here’s how you get to X, we want to watch you do that, we stand back and just say, “Let’s imagine you want to find out about product X, here’s what we’re thinking of doing, show us how you would get there.” And then we observe what happens next.
It’s surprising how few times you need to repeat that process to uncover as much as 80% or 90% of the issues you might still have with your design.
So it’s worth doing, even on smaller projects, just to make sure you’re
not then baking into the end build something that’s horribly wrong, and is going to just make it hard for people to get the outcome they’re expecting.
Design Phase
Troy: So, we’ve got to our wireframing stage. Now, do we get to colour in the boxes?
Andy: Yep.
So that’s the next phase. It’s where we start thinking in terms of branding, and the aesthetic, and actually giving everything a great look. It’s obviously a critical part of the process as well. And that’s also where we start to think about things like content and what kind of voice we’re wanting for the site. So, we think about things like style guides, in terms of writing and also typography. And, you know, ultimately the way we’re communicating is actually a fusion of all of these things.
So it’s very, very important that the UX thinking, that we’ve uncovered earlier on, actually informs the aesthetic design, and also the content so that the whole process is actually helping to sell your product or service.
What technology stack?
Troy: Okay.
Obviously then after it’s designed, we’ve got through that process, we’re then getting into the development.
So, how do you determine what technology stack to build on? Is that informed based on the problems you’re trying to solve? Or is it pre-determined at a certain stage, because the client needs to do a certain tech?
Andy: So, that’s a good question.
I think that there are two ways of looking at that.
One is, ideally we want to be technology agnostic when we go into a problem. And as we start to understand it better, typically choices will begin to become somewhat obvious.
When we work with people who are building products, we often get asked that question, “What’s the right technology?”. The answer very frequently is simply, the best technology to choose is the one that your team is most capable of delivering. And, there are many, many different technologies out there these days. And that can be a really paralyzing process, trying to work out what’s the right one.
So we do have some preferred choices. But as much as possible we try to be agnostic and to actually weigh up the pros and cons of each, to figure out what’s the most sensible one for that particular problem.
Go live
Troy: And then, I guess then the final stage is pushing it live and to make sure you’re migrating from the existing environment to the new build while making sure the process happens seamlessly.
Andy: Yeah. Once a project moves into production, although, that kind of obviously begins with launching the site and all the operational considerations around hosting and so forth, we really see how that’s just the beginning of the next phase of the lifecycle of that particular initiative.
So, we would typically continue to analyze what the customer experience looks like, now that we’re live, and to measure, are we continuing to achieve the outcomes we expected, how are people interacting
with what’s been built? How is it performing? How is it ranking? How are people getting to it? And out of all of that investigation, which typically involves just collecting lots of data, we get to the stage where we have enough information to arrive at a new piece of analysis, and uncover new opportunities, to continue to improve, and we can start the process all over again.
Winding-up
Troy: So, how’s this approach different from a typical approach?
So I guess, it seems, it’s quite a phased approach. You’re not committing to anything in advance.
Is that fair to say?
Andy: Yeah.
So while there might be a notional sense of the overall time and cost, typically we try to move that risk, that is often undertaken as a huge guess at the front, and people start putting fixed times and costs and expectations at the very beginning, which they aren’t met. We break that into a series of steps so that the clarity improves at the end of each phase.
Until, before we get to the development stage, so after those first
three steps are complete, by that stage, then we do have a lot of clarity. So we’ve basically got a definite design, we know exactly what the structure and functionality of the site is, we know why we’ve made
all those decisions.
So it becomes quite a pragmatic set of arguments for why different choices were made. And that eliminates a lot of risks, but it also means, that by that point there is a high level of clarity, about what the requirements are.
We’re no longer in a situation which a lot of people get into, that as things are being built they’re realizing, “Ah it needs to also do this! Or that.” So that’s the ideal approach, is to have the luxury of
going through those steps. On smaller projects, we will try and compress some of those things down, but still, at least give a nod to the thinking behind that.
Troy: Yeah.
I guess with smaller projects there’s a level of knowledge that you bring to a project. And you go, “well, common sense and experience, from building stuff means we know this happens.”
So you can, a user would interact with a function or a site in a certain way. I guess, though, you’d have to be careful you don’t presume too much.
Andy: That’s true.
So if you start, as is often the case, with a really good theme and
it’s been well thought out, and you’ve got confidence that that theme has behaved well in the past and maybe you’re changing how it looks for this particular project.
Then yeah. I mean, that in itself eliminates a lot of those risks. But you’re right, the problem there is that sometimes you can reach for a theme and its actually a question as to whether or not that is actually a good performing theme, and whether you are starting with a high bar, or whether it’s actually just something somebody else has pumped out that makes a bunch of assumptions, which could be wrong.
Troy: Excellent.
Anything else you want to add?
Andy: No.
Troy: I think that’s about it.
Thank you.