Controlling (Scope) Creeps (with Suze Haworth)

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Ben Aston: Welcome to the DPM podcast where we go beyond theory to give expert advice for leading better digital projects. Thanks for tuning in. I’m Ben Aston, founder of the Digital Project Manager. Now, if there’s one thing that derails almost every project, it’s scope creep. We all know it’s bad. We all know we want to avoid it. But how do you know it in all its various guises? What causes it? Whose fault it is? And most importantly, how do you actually deal with it? All will be revealed in today’s podcast, where we’re talking about controlling creeps of the project scope variety.

This podcast is brought to you by Clarizen, the leader in enterprise projects and project management software.

Learn more at clarizen.com

I’m with Suze Hayworth today. Suze is one of our resident DPM experts at the Digital Project Manager, and she works as a freelance Senior Digital Project Manager in London in the UK. She’s got more than 10 years experience working in agencies, and she’s experienced a lot of scope creep, so she’s a great person to be talking with us today. Suze, welcome.

Suze Hayworth: Hi, Ben.

Ben Aston: So Suze, we were just chatting before we started recording. Can you tell us a bit about the kind of projects you’re working on at the moment, and you know, some of the challenges that you’re facing?

Suze Hayworth: Yes, so I’m currently working at an agency in London freelancing, so I’m sort of split between a senior project manager and project director role across two accounts. So, one of them I’m working for IKEA, so sort of large retail, eCommerce company. And we’re doing a design system for them, sort of prototype design system. And then I’m working on also …, another eCommerce retailer in the UK. So, a lot of retail projects at the moment. Yeah and challenges, I guess, it’s always hard to talk about the challenges … especially when they’re alive. Yeah, I think-

Ben Aston: Is it that pesky client?

Suze Hayworth: Yeah. No, actually. They’re really, I have to say this anyway.

Ben Aston: You do.

Suze Hayworth: That’s true. It’s true. They’re very good clients I’m working with at the moment. I think it’s, I mean this is the sort of good and bad thing about projects, and being a project manager in general, is just working with people. So it’s great. I love working with people, different characters, and quirks, and that. But also, you do sometimes get to a point where you get a bit frustrated with struggling to try and get stuff out of people who don’t want to do stuff and things like that. So yeah, I’ve had a bit of that recently, I think.

Ben Aston: Fun and games. So well, tell us about the project to build a design system because I think that’s an interesting project, and actually, it’s the kind of project that we’re seeing more of. Whereas previously perhaps, everyone liked to treat every kind of project as a special snowflake, and you know, the creatives wants to be creative. So talk us through, what is a design system? And how do you … Like what is the project that you’re actually working on? And how is it … How are you kind of rolling that out?

Suze Hayworth: Yeah, so it’s a really exciting one actually because like you said, design systems are coming sort of more and more into play in the digital world. And so they basically are like a bit of a style library I guess for the design digital design for companies and brands. So what they do is set a baseline of designed components, modules, templates that any designer or developer that sort of work with their brand can take and use to develop their own designs and code from that. So it’s kind of a baseline, so setting, and the baseline design, and that sort of promotes efficiency. So you know, reusable code and designs, and also just efficiency and consistency within the company.

So, where somebody like IKEA … is a huge, huge brand and has many sort of different agencies, people, organizations working for them, that sort of design system can set a standard that designers and developers can work with. Say that, you know, the button on a page, a call to action, can be consistent across multiple platforms, devices, et Cetera, and apps. You know, whatever sort of properties they are using.

Ben Aston: So, talk me through the kind of, the process of the I guess managing the projects because it’s a … It could kind of be like how long is a piece of string kind of project? How do you … Is it something where you’re just … What did you start with? And kind of what are you iterating on? Where does the product end?

Suze Hayworth: Yeah, so for IKEA, I mean a lot of brands don’t actually … They do this as an internal project. So, IKEA kind of looked outside externally for support and help on this, and for us to be involved in the design. I think that’s really smart move because we can kind of come in as the outsiders and review things with a bit more of a not sort of ingrained in the company approach. We started out looking sort of conceptually at assessing the principles, the core digital principals, the kind of concept behind our design, IKEA’s sort of brand, design principles. So that was the kind of setup. So it was a more strategic kind of look at the whole kind of experience and design principles behind it. And then, we started to get more grounded into designs, to setting a baseline design based on existing foundational elements, we call them. So things like color, typography, grids, and then kind of develop that further.

We then did some user testing with that design against a few sort of platforms that we picked from IKEA’s range of properties, and then we’ve got on from there into designing and building specific components, and then hosting them on a design system sites, which is just kind of internal at the moment. Because what we’re looking at is more a versatile prototype to initially kind of get this up and running, and then it will be developed into a full solution sort of once we get the end of this stage.

Ben Aston: Cool. What does that full solution … Is it a kind of living, breathing style guide with snippets that people can just grab? Or kind of templates that they can grab? Is that kind of where it’s headed?

Suze Hayworth: Yeah, I think any design system project needs to be an ongoing, living thing. So it’s not got a finite end. It’s not kind of a product that you just stop with, and then that’s it. So, it does need to be developed with … I mean we’ve just started and sort of scratched the surface in terms of the initial principles, foundations, and components. But from there it’s sort of grouping those components, developing modules, then sort templates as well. And then looking at sort of how you get people using this, I guess, and sort of circulating it, getting people onboarded with it. So this is huge, huge project, and especially with the sort of amount of different parties involved in the company. So yeah, so we just sort of almost just kicked off even though it’s been almost a year so far.

Ben Aston: Cool. Sounds like a fun one. So I’m always curious to ask people whether or not they found any tools recently, or you know, what’s making your life awesome at the moment? Is there anything that you’ve found? Anything that you’ve read? What have you discovered recently that other people should know about?

Suze Hayworth: Not so much been using different tools recently, to be honest. Sticking with what I know. But this is properly ironic considering I’m on a podcast, but I’ve been listening to more podcasts recently. Yeah, so usually I listen to music on the way into work, an hour on the commute, but recently I’ve actually been … It’s sad, so I’m using it a little bit more usefully, but I’m listening to a range of podcasts. It’s been really good because it’s another sort of way to learn and obviously use the time when I’m standing on the … . I was going to say sitting, but I never get a seat. Standing on the cheap to work. Yeah, so using that quite usefully.

Ben Aston: What … Are there any podcasts that you found really helpful or interesting?

Suze Hayworth: I have to say the Digital Project Manager podcast, definitely. That was a given. And then, … I actually did a podcast recently for, was it the Drunken …. So after my DPM Summit session I did recently, I spoke to him about what my session was about. And then The Bureau of Digitalists over in the DPM summit. They do some good ones, and Brett who runs the summit, Brett … has recently put out one called Sprints and Milestones, which is based on his book around Digital Project Management sourcing, quite a useful resource.

Ben Aston: Good stuff. So get listening to your podcasts. One thing that I’ve found really interesting, I don’t know if you’ve heard of it, it’s called Blinkist. And it’s … Do you know what? I have to be honest. I don’t listen to a lot, if any, podcasts other than my own where I talk. But one of the things that I always find is that I always think, oh, I should really read that book, and then I either buy the book, and then never get round to reading it, or just never got round to it. But yeah, Blinkist has this thing, it’s where basically they’re very condensed summaries of books. So it’s kind of like a-

Suze Hayworth: I think I have heard of it actually, yeah.

Ben Aston: Yeah, so it’s … It basically takes, I think it takes about 15 minutes to read, or you can hear it readout. Someone’s kind of reading the summary of the book, the main points. So it’s kind of like a podcast, and the great thing about it is that you can speed it up as well. So not only can you play it at normal speed, but you can play it in double speed too. Then and it takes seven and a half minutes to read a book or listen to a book.

Suze Hayworth: That’s amazing. I need to try that because I’ve also been trying to read a bit more recently. Trying to fit in more books would be good.

Ben Aston: Yeah. That’s my kind of book hack for you all, Blinkist. Cool. Anyway, we’re supposed to be talking today about scope creep. So let’s talk about scope creep. And for the uninitiated, for those who haven’t heard about scope creep, what is it? And why should we care about it?

Suze Hayworth: Yeah. So it’s basically when your scope, obviously, so your deliverables, anything you’ve agreed to, features on a project, they basically expand or grow from what you originally agreed to. And that’s without accounting for them in terms of extra time … Project can be affected by this because it could come in in a variety of formats, but just where things start to slip in or creep in, and where they sort of come in and extend time and make things slip within your project.

Ben Aston: Cool. So it’s, yeah, it’s additional work that we hadn’t accounted for, and then that is going to have an impact on our budget, on our timeline, and obviously the scope, the amount of work we’re doing. So there’s lots of reasons why this happens, right? There’s lots of reasons why the work that we thought we were going to do, or planned to do, suddenly becomes, there’s more of it. We’re very good at creating work for ourselves, so I mean in the article that you’ve written, we’re not gonna talk through all the reasons of what causes it because there’s a whole host of reasons.

Suze Hayworth: There are a lot, yes.

Ben Aston: But what would you say, for you, what are the most typical or the most … Yeah, let’s talk about the most typical, and then let’s talk about the kind of most sneaky.

Suze Hayworth: Yeah, so I guess the most common ones I’ve seen, firstly, not sort of being clear about the scope in the first place. So when you’re setting out deliverables, writing a statement of work at the beginning of a project, if you’re sort of too vague or loose with how you describe things, you know or how you haven’t got quite a tight definition around what you are actually delivering, that can obviously come back later and anyone like the client or even internally, people could actually take that and take it, and it means very different things. So then it starts to escape. The project starts to grow based on sort of quite a vague kind of setting of the deliverables upfront.

So I think that’s the first one is being clear about scope upfront, and also just making sure that whoever is signing off this scope is very clear on what they’re getting. So, statement of work. Great, obviously, in terms of laying out all the deliverables, and what you’re doing with the project, but obviously they’re quite a long document. You’re sort of giving them to a client and expecting them to read, and digest, and understand everything within that. So it’s really important to make sure that the core points, and the core things that they’re getting within the project, and timings, and budget are really pulled out and explained to them explicitly. And if you think they have read it, they do go very grounded in their feedback, you know, it’s really important I think when you are delivering an initial kind of scope for a project is to work that through with them in a meeting. Just make sure they do understand what they’re getting.

So that’s where I’ve seen a lot of problems in the past as well, where a statement of work is agreed to, and then people down the line and just like, oh, but I thought I was getting that, even though it might sort of be more explicit through.

Ben Aston: Yeah. So yeah. So there’s us not being clear at the beginning. We might say something like, hey yes, client we’re going to create for you a page template, but we don’t define fully, okay what actually goes in the template? Or often, I think that one of the challenges is, and this is kind of what you talked about with the second thing, so we’re not clear, or it’s just that we haven’t … It’s a communication thing, right? We haven’t made it clear to the client what we mean by a template.

Suze Hayworth: Yeah. So, exactly. It’s the two things there, which is setting and understanding the deliverables clearly upfront but then making sure that whoever is signing off the scope really understands what you’ve said as well. So that’s the kind of second layer to it because even if you are quite explicit, it might be that they still got an idea of something else that they are getting, which you haven’t actually even written in the scope.

Ben Aston: Yeah. So those are, I think what you’ve covered of, not being clear. The client not understanding. I think they’re probably the most two most kind of typical kind of instances of how scope creep comes about.

But what do you … I mean, let’s talk about the more sneaky side of it. Like how … What have you found the most kind of unusual, or you know, the kind of scope creep that happens without you realizing? How … Kind of tell us about how that comes about in your experience on the projects you’ve worked on?

Suze Hayworth: Yeah so, I think the typical way to see scope creep with PMs is that, is the client. You know, the client’s going to ask for something else, or extend things, or want something more all the time. But actually, I’ve seen it that it can come from internal teams and internal stakeholders as well. So your internal team members, if they don’t have a clear understanding of what they’re doing, they kind of go off in different directions and just without realizing, extend the timings of what they’re doing, extend functionality. So a designer could just design something that actually hasn’t been thought through in terms of how that’s going to affect the development scope if you sort of set that upfront. So, they could just be doing that quite unintentionally. Or they could have a different agenda almost so that they want to build something. I’ve seen this before as well, where they actually want to … you on something they want to design or build into that.

So, it’s probably a bit more surprising when it comes from internally because you kind of want everyone on the same page, but it can happen. And then also sort of other internal stakeholders that can be kind of business needs kind of worked into that. So, it might be that internal stakeholders want you to deliver more from a client relationship point of view, or they might agree to stuff that you weren’t aware of. That’s also another classic. So yeah, I think that’s where the kind of slightly sneakier ones I guess come in.

Ben Aston: Yeah, no, I think I totally agree with that in terms of the … Yeah, one of the most causes of kind of sneaky scope creep is yeah, it’s when it’s internal. When it’s gold plating. When it’s our own internal teams trying to put this gold plating on what they’re doing so, and often happens with strategy, and UX, and design. But it can happen in development as well. When someone wants to do a really awesome job, or someone’s thinking, hey, I think we can make this into … This is going to be a showpiece. This is going to be something that we can submit to awards, so let’s put it in the extra effort, but then no one’s ever really had that conversation. Okay, well who’s paying for this additional work?

Suze Hayworth: Exactly.

Ben Aston: Or where … Who’s taking responsibility for this? So going rogue is definitely … Yeah, definitely-

Suze Hayworth: Good way to put it.

Ben Aston: Yeah, where you have independent thinkers coming up with their own interpretation of what you’re asking them to do, and I think another one that I want to talk about, which you mentioned in your article, is QA as well. When we’re in that quality assurance phase, but perhaps we haven’t defined when we were writing the user story at the beginning, we haven’t fully defined the acceptance criteria. Or you know, we haven’t defined with QA, hey guys, don’t worry about testing on IU9. We don’t care for IU9 anymore, and you know, the QA team are like, yeah, but there’s always bugs with IU9, so we should do it. Or you find out they’re, you know, testing on blackberry or something random like that, and all of a sudden not only are they spending loads of time testing stuff that we don’t care about, but we forgot to tell them. But then also you have the developers trying to fix things that don’t actually need fixing. I don’t know if you’ve found that too.

Suze Hayworth: Oh completely. So QA is one of the, I think, the big areas of project, especially more sort of more … in your projects, where you kind of can estimate at the beginning roughly based on what you know about the development period of time. But it’s really hard, obviously, to estimate for how much QA there is in terms of how many amends there are to re-QA and to retest. So, that can just kind of enlarge and enlarge and enlarge, especially if you don’t set those parameters upfront. So like you said, sort of setting the acceptance criteria, assessing your browser and device matrix, assessing your priority on your bugs and your issues that come up. So what are the ones you have to fix to be able to release? What are the ones that are priority, sort of lower priority? So two, three, four that you could actually release without addressing? So maybe sort of more design or surface amends.

So it’s kind of, again, it’s about sort of defining that core scope for things as much as you can. So taking away that uncertainty upfront. But again, I think with this, and it is all about throughout sort of any sort of project, it’s really about sort of core communication and keeping the communication open. So, with the client, if you are sort of going to QA, and you’re finding that there’s more time being spent one device, which is a nightmare, one browser, like IE, that could be a nightmare. It’s about sort of being upfront and sort of exposing that sort of very quickly to the client or stakeholder.

So, telling them that, IE, for example, is causing a lot more time for the QA. We can, you know … And then sort of suggest some alternatives to that. So, we can … We’ve got these browsing devices to cover. We can prioritize IE because it’s really important, and we know that the user base is huge for you, for IE. So prioritize that and continue with that, and then we’ll treat the other browsers their priority. So it’s kind of about looking at exposing any sort of issues where you see the scope creeping as quickly as you can, but also providing alternative solutions when you do expose the kind of scope creep.

Ben Aston: Yeah, I like that … I think that’s really helpful. So we’ve talked about a couple of things that cause scope creep, the unclear scope, going rogue, QA. And let’s talk about whose fault is it because in order to deal with it, I think it often helps if we kind of identify who’s at fault here, not so that we can point fingers, but more that we can work out how we deal with it. So, and the two that we’ve talked about is the client. The client’s asking for more stuff. Maybe they’re asking for more stuff because they weren’t clear about it, about what we were delivering. We’ve talked about our internal stakeholders, and our team gold plating stuff, and creating more work for ourselves.

But you mentioned some other kind of parties in your article as well. Third parties, users, and us as project managers. So what do you … I mean I’m keen to talk about us as project managers. That’s most of who we have listening is project managers. So to what extent is this our problem and our fault? Is it our problem, or is it everyone else’s problem?

Suze Hayworth: So yeah, I guess when you’re looking at … It’s not blaming sort of whoever for the scope creep, it’s really sort of trying to ascertain the risks. So say if you’re looking at who the people are within your project who could cause the scope creep instead of what they can do, and it’s really a good way of looking at the risks upfront. So what people could do down the line.

And when it comes to you, I think obviously, we tend to look outwards in terms of what could the team do? How could they increase things? Look at the client as an obvious one, et cetera. But I think with you personally, it’s about sort of not flagging or highlighting when things do happen. So there can be a tendency, and I hold my hands up. I’ve done it in the past where if there’s an issue on a project, you kind of want to try and solve it, but kind of bury it, and not just constantly, especially there’s a lot of issues in a project, constantly be flagging them to the client or exposing yourself to that sort of negative slant on what’s happening.

So you kind of almost want to do your best to keep the project going, and battling against the timings, and you want to get things out, so you kind of saying, okay, we can count for that here. Or we can count for that here, but you’re not exposing that to the client at that point because you want to try and solve it. And I think that’s a really big area where we can actually do better, I think. I have thought this in the past for myself.

So that’s, it’s a much easier conversation to have with somebody if you’re, I think, honest and open about it, and you’ve raised the issue if it is an issue quickly. And you can talk through it, and I think that it’s really important, like I said previously, to be able to present solutions. So not just raising, oh we’ve got a problem, and then just kind of flounder a bit as you try and work out what to do about it with the client. It’s kind of recognizing first we’ve got a problem, what is the problem if it is based on a problem. And then going to the client with a few alternative solutions about it.

So if the creep has come from an internal basis, you can work through and sort of see what you can do to pull it back, but reflect the client still that it’s happened. If a client is asking for something which is over and above what you’ve agreed, you know, don’t just try and swallow it and account for it. Just as a please, you know, like have a look at the impact it will have, and then make sure you’ve got kind of a few different options worked out. And then you can go back to the client and discuss that impact, and what they might want to deprioritize, for example.

Ben Aston: Yeah, we’ve kind of jumped to talking about how we deal with it.

Suze Hayworth: Sorry.

Ben Aston: That’s totally fine because I think, you know, as we think about what causes it, this is what we’re talking about here is once we’ve actually ascertained that there is some scope creep happening, what do we deal with it. But I also think as PMs, kind of going back to the causes of the issue, as PMs, we can try to be clearer with our scope. And I think it’s always like asking one of your PM buddies to have a look. Often asking QA. QA are great at kind of finding holes in what you’ve written, and like, yeah, but have you thought about this? Or one of the business analysts. They’re great at kind of picking holes in scope and saying, Hey, have you thought about this? Or why haven’t you kind of defined this?

So yeah, being clear with the scope, and then that communication aspect as well that we talked about earlier. Being better at not just throwing a statement of work over the wall and kind of hoping for the best, hoping that the client signs it, and then it comes back and we’re like, yay, we can get started on the project. But actually talking it through with them I think is really useful in stopping it from happening in the first place.

But I like what you’re talking about in terms of how we deal with it. You’re talking about, hey, don’t just kind of sweep it under the carpet. And I think as PMs, we can often think, hey, especially if we’re kind of client-facing too, there’s this temptation to not address and not be proactive about it because hey, it might be all right. We want to retain the relationship with the client. That’s really important. So we kind of, we’re not transparent about it to start with, and then it becomes too much of an issue. And what you talk about in the post, you know, being proactive, being transparent about it, prioritizing, analyzing the impacts, I think is all really helpful stuff.

But one thing I want to talk about, which you kind of touched on in your article, is what we’ve been talking about here in terms of scope creep is kind of often a challenge that people associate with waterfall projects, where you do lots of planning upfront and then you kind of execute phase by phase. But is this a problem too for agile projects? And you know, what does that look like with an agile project? What does … What scope creep … What should people be looking out for on an agile project that’s kind of more iterative and that’s seemingly more flexible?

Suze Hayworth: Yeah so, that’s what I really did want to get across in my article was that the thing is we see scope creep as quite a negative because we’re trying to sort of keep things to a fixed scope that we’ve agreed, and we’re trying to battle against kind of anything changing that. And what’s great about agile and using agile methodologies is that, it’s really about embracing change. It’s one of the core principles of agile, and it’s about change actually creates, and embracing change creates a better product or service in the end. So actually you’re doing something quite good by allowing change into your project.

So, yes. And my point sort of around that is about change and not being seen as the enemy. It’s actually quite a good thing when you look at it. It’s just how you handle that that you need to be worried about, I guess.

But in terms of how it can actually come in in agile projects, when you used to look at maybe a scrum based project, as an example. So you will still … You know, it’s an agile project, but you still agree what you’re doing for your time box period, your sprint in this example. So you will set that, set what goes in your backlog. So it might be that your product owner or client you’re working with on this could come in … So, during a sprint, add something in or try and add something into the backlog when you’ve already kind of planned it out, already agreed to what’s going in it. And that can affect what you’re going to deliver. It effects the release.

So it’s just being careful about sort of what they introduce in isn’t just coming in in addition to everything else. It’s almost you need to look and reprioritize based on that and make sure the amount of effort for the stories or epics you’re bringing in can actually be balanced out by deprioritizing something else. So it does still happen. But I think the great thing about agiles, obviously, with the smaller time box periods, when you’re releasing something, you can probably deal with the introduction of changes a little bit better.

Ben Aston: Yeah, no, I really like that. Changing the conversation. And you kind of talked about this, you know, embracing change. And I think often when we talk about scope creep, it can often have … Be a very negative conversation, and it’s a negative conversation because it means, scope creep typically means, more costs. It means we’re going to turn around to the client and say, hey, you’re asking us for this thing, this additional thing. This was not originally planned for, and so it’s going to take additional time. It’s going to take additional budget.

But I think having a more transparent and kind of ongoing dialogue with the clients around the reality and the constraints of their budget mean that we can only do so much, and being able to prioritize with them, and have that kind of prioritization as an ongoing discussion so that they don’t need to worry about the fact that hey, they might not get this piece of functionality that they thought. They kind of wanted at the start. But within the process of the project, we’ve kind of actually identified something that was more important. That change is good change to have, and I think you can have that as a conversation throughout the project, and not just springing it on the clients at the 11th hour. Oh, sorry. Yeah, you either need to pay us more money, or you can’t have that thing. And we’ll do this, do x instead of y. That’s when it becomes very negative, but it’s … I like what you’re talking about in terms of an ongoing dialogue that really helps smooth out that conversation.

Suze Hayworth: Yeah, completely. I think it’s really important to have these conversations around what you are delivering, like you say, on an ongoing basis because what it should relate back to really is what is going to be most beneficial for the users who are using your product or service in the end. And to have these conversations, instead of saying if the client or whoever’s coming in and say, well, we actually want this. Don’t just think, Oh God, no. We’ve already planned this, but you know, that’s it. We just say, no. We can’t do that unless you pay us more money, and it’ll extend your timings. Maybe have a think about it and just start framing it and shaping it in the way. Okay, so what you want, what is the benefit to the users? Why is this coming in as a requirement now? Are we addressing a new need? What are the reasons behind it? And then, if it is sort of valid and is actually going to be something that proves a lot more useful to the users, and sort of start to bounce that against other deliverables, and sort of say, okay, well this feature that we want to introduce is actually going to be much more useful than this other one. Let’s deprioritize that instead.

So, it’s about having those ongoing conversations, keeping the client really involved in what you’re doing, and if there are sort of new requests, just analyzing them and working out why they’re being requested. And what is the actual end benefit of them?

Ben Aston: Yeah. No, that’s … I think that’s really sound advice. Make it a conversation. And think about the user, I think is really solid advice. And yeah, I think what we’ve been discussing has been great, and I think what’s really resonated with me is that changing this conversation from a negative one to one that’s an ongoing dialogue. Like scope creep doesn’t have to be a negative thing. It can be good. It can be good for the users. It can be good for the client, for the project, and our teams too. So it isn’t something that we should necessarily run a million miles away from and be scared of, but embracing it I think is really solid advice.

But in terms of thinking about people who are like, hey, you know, … this. My big problem is for all my projects, they always end up over budget. They’re always late, and we just have these massive scope creep problems. I think this will probably be most PMs, particularly when they’re beginning of managing projects. This is what they’ll be faced with. It’s, hey, the project’s just going over. Everything’s taking longer. We’re gold plating everything. The client’s asking for more stuff. What’s the kind of one tip that you would give someone who seemingly, their project’s kind of run away with them? What’s your kind of first tip for reining that back in?

Suze Hayworth: I think, if you’re asked to come into a project new, so it is like a project which is just kicking off, the best thing to try and work on is the actual estimation, and sort of how you ask, scoping for that project. So making sure that you’re not just working the silo. You’re estimating with the team. You’re making sure your estimates are as good as they possibly can be, bearing in mind that they are estimates. Say that when it comes to actually delivering what your, you scoped for, you know, you’re not suddenly finding your timings and budget running away from you.

In terms of if you’re coming into a project new, and it’s an ongoing project, I think just taking stock of where you’re at, seeing sort of how far your over, and making sure you’ve got an accurate picture of what’s left to do, and then having that conversation with the client so you’re making sure that you’re talking to the client around the issues with it, where it is sort of over, and then just flagging that so that you are having those open conversations.

Ben Aston: Cool. Well Suze, thanks so much for joining us. It’s been great having you with us, and as one of our DPM experts, Suze is also going to be making an appearance in our upcoming course starting in February. It’s called mastering digital project management, and if you’re not sure what I’m talking about, but you know you need some PM training, check it out. It’s a seven-week crash course that includes interactive video lessons, assignments, webinars, group discussions, and the option of coaching sessions too. Head to DPMschool.com and get yourself signed up before the course fills up. And if you’d like to contribute to this conversation about scope creep, comment on the post and head to the resources section of TheDigitalProjectManager.com to join our Slack team where you’ll find all kinds of interesting conversations going on. But until next time, thanks for listening.