Handling Scope Creep

[00:00:00]
>> So I've kind of touched on this a lot of times. And a lot of the things that we have already done and already talked about in terms of our process, a way of managing projects, will help with scope creep. But I didn't wanna pull it out particularly at this point, because this is often where scope creep really kinda kicks off from a design perspective, if you've shown the design, and then the goalposts begin to move, right?

[00:00:27]
But I think it's important to say that scope creep isn't inherently bad, that digital does allow us to adapt to projects as we go. And especially if we break it into those stages that I talked about, right? So the discovery, the prototype, the build, the live between each of those phases is an opportunity to take stock and to pivot your direction.

[00:00:55]
So if you get to the end of the discovery phase and you learn about some constraints on the project, that may mean you have to change the scope. Or you might learn something about your user group, which means that you wanna introduce some functionality you hadn't previously considered.

[00:01:11]
Or it may be that after the prototype stage, you didn't test very well and so you need to add a different feature that you'd missed out. That's fine, those are opportunities baked into the process to do that kind of thing. But that's not to say that we don't need a strategy for dealing with maybe the less useful scope creep that comes in at random intervals.

[00:01:35]
And the technique that I use is really, really simple that I create a backlog of post launch work packages and test scenarios. So, and again I do this in notion because I seem to be obsessed with that app at the moment. And effectively what I'm doing is every time somebody comes up with an idea, I say, great let's move that into my backlog for we'll assess it once we've got the main bulk of work done.

[00:02:06]
And it can be involved in our post-launch iteration phase. And then there'll be other occasions where people will say, I'm not sure this works or that doesn't, and our responses were let's test that, all right? And I use that a minute ago deny as an excuse for us for it not to happen.

[00:02:25]
But actually, you should actually write down, okay, there's a test scenario that we need to run at a later date in order to confirm this particular thing. So now, of course, getting a client to accept that, it's difficult if you suddenly drop it on them, right? But if you build it into the process from the very beginning, you've set people's expectations.

[00:02:53]
So if right at the beginning when you discuss, look, these are the stages we're gonna go through. If you discuss live, if you say that once we go live with this website, that's not the end of the project, that's not the end of the engagement, there is opportunity to evolve and improve the project at that stage.

[00:03:09]
Then, absolutely, is gonna be a lot easier when you start talking about adding things that phase. The other thing is I'm always the one to first come up with an idea of our scope, right? So which sounds weird, but it actually works really well. Because if you're the first person to come up with an idea of scope and your response to your own idea is, we shouldn't do that now but we'll put it in that backlog for post launch.

[00:03:35]
Then you're kind of applying the rule to yourself and not just to other people. And this list is brilliant. This is gold dust, because this is your opportunity to actually evolve and improve the website after it goes live. And if you happen to work for an external agency, this is a roadmap for ongoing work.

[00:03:57]
And if you work in-houses, it's justification for ongoing investment in this particular product rather than getting abandoned and allowing it to decay over time. So really, having that kinda backlog is really useful tool. Another little bit of advice I wanna give, and again this is gonna sound awful when I say it.

[00:04:16]
A little bit of advise I wanna give in terms of how to deal with comments that you get back and scope creep in particular is, never say no to scope creep. [LAUGH] That sounds awful. Because you're thinking, no, I need to say no, we can't do that, we don't have the budget, we don't have time.

[00:04:35]
It's just the word, no. And it's how we go about dealing with it. The trouble is that scope creep, sorry, the word no has immediately confrontational, right? And probably untrue in a lot of situations. I get this, I'm on the other side of it with developers often, right?

[00:04:58]
I love you developers, but there are just some times when it gets tricky. So I'll come up with some design and the developer turns around and says, no, we can't do that. And I know they're blatantly lying, because you can do anything if you've got endless time and money, right?

[00:05:15]
So, actually no is not correct, right? Instead, it's a matter of unpacking that and saying why, braising those questions around that subject, right? Let me give some examples and it'd be a lot clearer. We could do that but it would add an extra two months to the timeline, is that feasible?

[00:05:43]
See how much better that is right? Or well, I estimate that cost about an extra two grand, do you have the budget for that? Or okay, that's great, we can definitely do that, what feature are we gonna drop to make that happen? Or would you prefer to deal with this post-launch or do we wanna push back the launch date?

[00:06:08]
It's another really good one. I think I'll probably need to see the business case to justify that, is that something you mind putting that together so I can have a look? Makes such a difference how you word it, and you word it as a question. The one I particularly like out of that is, would you prefer to deal with this post-launch or push back the launch date?

[00:06:33]
This is actually a parenting technique that I learned [LAUGH], right? If you want your child to eat vegetables, right, if you say to them, you have to eat your carrots, they will say no, right? But if you say would you like carrots or broccoli, right? They'll pick one out of those two choices, okay?

[00:06:59]
And that's exactly what I've done with that question, would you prefer to deal with it post-launch or now, right? So think about how you're handling those conversations and interactions. And think about the words you use, because they make an enormous difference to whether or not you're gonna be able to deal with your scope creep, whether you're gonna be able to do your feedback, etc.