Use Project Scope Statements To Save Your Bacon (with Robyn Birkedal)

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: You’re nervous holding the phone in a cold sweat. The client is mad. They’re on the phone threatening to ax the project and not pay for the work. And so far, everything has been going so well. They were totally chilled out and so were you. They wanted their site redesigned. Sounded simple. And you didn’t really bother with writing anything down because. Well, it just felt like everyone got it. Everyone was chill and now they’re not. What they actually thought they were getting was a rebrand on top of that redesigned website, now your stomach is in knots because, you know, you screwed this up. Nothing was written down. And it’s their word against yours. Now, I’m just stressed outPsaying this. So if you want a whole bunch less stress. Keep listening to this podcast to discover why Scope statements are so important. How to write them and use them for your project.

Thanks for tuning in. I’m Ben Aston, founder of the Digital Project Manager. Welcome to the DPM Podcast. We are on a mission to help project managers succeed, to help people who manage projects delivered better. We’re here to help you take your project game to the next level. Check out thedigitalprojectmanager.com to learn about the training and resources we offer through membership. This podcast is brought to you by Clarizen, the Leader in Enterprise Project and Portfolio Management Software. Visit Clarizen.com to learn more.

So today I’m joined by Robyn. And Robyn is one of our resident DPM experts. And conveniently, she lives just down the road from my importance where I read recently. She likes emojis, list-making, and puppies. So she’s a chef turned project manager with more than 10 years of project management experience in agencies and startups. And she’s also actually about to become more available to take on contracting work. So if you’re looking for a contract PM, track it down on LinkedIn. But hey, Robyn, thanks so much for joining us today.

Robyn Birkedal: Hi, Ben. Always good to be with you.

Ben Aston: Now, I want to start actually with going back to that list-making and puppies. Have you made the list today?

Robyn Birkedal: I have. I actually this is I’m such a dork. I have one list for today’s top goals. I have one list in my planner. And then I also have my Google Calendar. So apparently I need three different lists at any one time. And what you can’t see behind me is my crime wall of post-it notes.

Ben Aston: And that’s like the back catalog of lists.

Robyn Birkedal: Things in different categories that I am trying to achieve personally and professionally or even, you know, just different content, ideas for you.

Ben Aston: So do you have a puppy with you as well?

Robyn Birkedal: I do have my eight-year-old puppy, but obviously, I love dogs way more than cats and everybody can hit on before that. Emojis feel less enthusiastic about lately. But I think that was the face.

Ben Aston: I was so, last year.

Robyn Birkedal: I don’t know

Ben Aston: So obviously posts lists are a big deal for you. Some you find them inspiring. But I’m curious as to where you get inspired. What’s what are you reading? What are you consuming right now to just get inspired and stand by it?

Robyn Birkedal: Oh, this is a great question. And I feel like I could talk for like 30 minutes about this one right now. Obviously, the digital project manager is a constant source of inspiration. I took a short pause from being as heavily involved in that Slack community. And now that I’m back, I kind of missed a lot of my friends there. And that’s been a complete joy, but also locally for my friends and my community. But I do want to do a shout out to one, have a really great Portland Community Groups that I’ve been involved with through the years are called PDXWIT, which is Portland Women in Technology. And I just really appreciate that community that’s been organizing really well put together, skill-building events, mentorship, and access to jobs in communities. And they’ve really taught me a lot about diversity and inclusion. And so I highly encourage all of you to kind of create something similar to that or check them out at pdxwit.org.

Ben Aston: That’s cool. And what are you trying to get better at? We’ve all got a bit more time on our hands of the moment. And I feel like I’m being inundated with masterclass and fitness and all kinds of things. But as you’re thinking about, you know. Well, what’s inspiring you? What are you be inspired to do? Are you. Is there anything that you are particularly working on a new hobby? You’re taking up a new coding language or diving into it. What do you what are you doing?

Robyn Birkedal: Well, recently, I haven’t worked in Drupal for like those seven years. So kind of catching up where that is at. But outside of that, I think this. And Ben, you’ve known me for years. This feels almost like a real, true secret to share out loud with you. Is that I’m thinking about actually getting different certifications. So, like, actually getting my PMP or actually taking I think it’s like, you know, safe. I don’t even have to figure out what it is but like kind of exploring if that is something I want to do. Moving forward, just kind of being more exposed to those methodologies versus kind of remaining fine with worry about.

Ben Aston: That’s cool. Well, good luck with that one. And anything else that you’ve discovered recently that is making your life more awesome is the little things right now. One is making was to bring a smile to your face was bringing you a moment of joy.

Robyn Birkedal: This is also embarrassing. I feel like I don’t know why I’m so nervous today, but I have really been enjoying working from home and in the background. I put on this one station on YouTube TV, which I have a subscription to, and it’s like one hundred percent serve to channel and living in Portland, like, you know, it takes me an hour and a half to get to the beach. I’m not a surfer. I don’t know anything about surfing, but I’ve really enjoyed watching apparently. Ambient Surf TV championship’s in the background and now I’m obsessed with so many different people, like Andy Irons and the Kelly Slater debacle and it’s just I’ve learned a lot from it, which is the weirdest latest thing, making my life awesome.

Ben Aston: Who is your favorite surfer?

Robyn Birkedal: Definitely Kelly Slater.

Ben Aston: You know, they were here. That was a good start as a save option. When I was, um, I may claim to fame was I went surfing with Kelly Slater in Hawaii.

Robyn Birkedal: What you can’t just say kind of doesn’t work.

Ben Aston: Well. We were coming out of the water and he was going in the water with his girlfriend, and we crossed and said, hi, Kelly. So we went surfing with him. Right.

Robyn Birkedal: Yes. You’re in the water at the same time.

Ben Aston: Yeah, I mean, that’s.

Robyn Birkedal: It sounds like you’re under the big waves, though, if you’re, like, out there, Kelly. So.

Ben Aston: Yeah. Yeah, it’s why. So my claim to fame. So, I mean, let’s get back to this serious topic, moving away from the beach, back to Scope statements. And let’s start with why. I mean, I tried to set the scene at the beginning with why we should care about Scope statements. Projects go wrong. There are misunderstandings that happen and Scope statements can save our bacon. But, I mean, let’s start with your why have you got any horror stories of not having Scope statements? I talked about it in the intro. Why does Scope statements get you excited?

Robyn Birkedal: Oh, absolutely. And I think just even hearing your intro moments ago, I was really thinking about how that trauma came back to me and how it will always come back. So Scope statements are super important because it’s where you ensure your team and your client has a clear understanding of what the overarching requirements are. And ultimately, it’s going to define how you’re going to fail and how that would work. The thing we’re trying to protect here is opening yourself up for conflict with the client, with your internal team, and then also just trying to align everybody and, you know, avoid litigation there.

Ben Aston: So we are trying as much as possible to clarify and unify understanding, and I think what Scope’s statements are great for is codifying that understanding. And I think sometimes we can think, hey, we’re all on the same page. We’re all friends here. It’s often worse, actually, when you are friends because everyone can just assume that everyone else is understanding one another. And then their sneaky words like, you know, update or refresh that is really ambiguous on what the Scope statements do is reduce that ambiguity in the gray areas and make things a lot more black and white.

Robyn Birkedal: Absolutely. And I think, you know, even in the 10 years I’ve been working in this space, those terminologies change even on a quarterly basis, right. And I think before we really talk about like what they are and how they are, I just kind of want to share that, you know, writing a scope statement is really underappreciated in this role. It’s the driest thing about the gig. And typically, this is the hardest part to kick off your project. Like nobody wants to have ownership about it. It’s your thing to do. But I just want to state that personally, I love it because. Well, I mean, I’m pretty nerdy, but putting in this time at the beginning of the project ensures a really efficient future on set for that project.

Ben Aston: Definitely. So, I mean, let’s talk about it at its most basic. For people who hold on a second, what is the scope statement? How would you describe a Scope statement?

Robyn Birkedal: Yeah. So I think there’s this wide swath of different terminologies that we can use, just as you were mentioning, Ben, about, you know, refresh versus redesign. Right. And how are they different from the SOW? So, Ben, I think we can go back and forth about this. But now I understand a scope statement is simply a way to describe the work you’re agreeing to deliver. And it describes, you know, at the most fundamental elements the constraints or limitations of the project. Right. So we’re going to talk about what’s being delivered, what’s not being delivered. Assumptions about what you’re going to deliver. And then any additional clarifications.

Ben Aston: So the scope statement, yes, and the Scope statements we use to describe the work there, we’re defining the scope and we’re codifying the scope. We’re saying, hey, this is what we’re doing. This is what we’re not doing. And sometimes if we can’t define what we’re doing or not doing, we at least describing the process and what that process can be like. And people sometimes ask, hey, well, do I need. Do I need a statement of work or what does an agile statement of work look like? And I think this is a big challenge. Right. We still need to define what we’re doing and what we’re not doing. But instead of defining the deliverables, what we can do is target that outcome. We’re trying to get to and that process that we’re going to follow to get we’ll try to get to the outcome.

Robyn Birkedal: Absolutely. And I think, you know, piggybacking on that. There are some basics you should follow. Right. And we’ll talk about some tips for that. But there is not just one template that every digital project manager is following. There’s a following. There’s not just one thing that everybody’s doing and you can’t just copy and paste it. So every business is different. Every project or program is different. And what we’re seeking here is just consistency to cover your back. Right. Or as I put it in that article, your bacon. Right. Because you need to protect your team. You need to protect that business initiative.

Ben Aston: Yeah. I want to I want to. Have you got any stories of how you didn’t define this code statements as fully as you need to or should have and what happened?

Robyn Birkedal: Well, I think this is a slippery slope because I have in previous roles been advised not to put a lot of detail in because that could potentially open you up for legal litigation. Right. If you put in too much. Right. So we can kind of fight back and forth a little bit more if it’s more a gray area. But where I found my most success is putting in as much detail as you possibly can. So whether that be a waterfall, whether that be agile, like define everything, you know, within that statement and then cross-check that with the client so we can get into more horror stories later. But I think over the years of experience, like, you’re not going to do it perfect sometimes and you’re going to have a client that figure something out different. It’s just about navigating that landscape and putting in that time upfront as best you can. But, yeah, we’ve all got worse stories.

Ben Aston: Yeah. So my horror story is when I think I’ve said this before, but we were working with a large consumer electronics client and creating some custom animations for them, and the client wanted to make sure that we’d bought the rights to the animation. So we did. I think we bought like a five-year-old media buyout so we could use it. The animations in whatever way we wanted for five years, which was, you know, this was just we were just creating this animation for a single campaign. And so, you know, we only needed it for a year max. So we thought, oh, we’ll just buy four, five just because just in case we wanted to reuse it next year. And later, down the line, the client. Comes back to us and says, hold on. Like I asked you to buy the rights for this.

I mean, yeah, we did. I mean, you know, but we need them, right, in perpetuity. Like, we want to be able to use them forever in any media, in any format. And we’d only bought it for five years, which became a huge sticking point because the animation studio who produced this for us. Well, I knew that they had us. They could charge us anything. So so they tried to. And in the end, this whole actual client relationship became completely undone off the back of this one scope statement, which wasn’t fully defined. And that was just around how long the buyout would be for the animations from the third party. And. And did the whole client relationship just from one scope statement. So it can be these things can have massive, massive consequences when there’s this small and this misunderstanding that can really rattle people sometimes. And sometimes people just pick fights because they can, which was the case with this. They didn’t really need it, you know, in perpetuity, but that’s what they wanted. So they threw their toys out the pram.

So these are things to take really seriously, because not only can they sink the project, they can sink the whole client relationship. But let’s talk about actually writing these Scope statements and the process that you go through. How do you ask actually make them up? How do you decide how to write that scope’s that you talk about, you know, not making it too specific and that the advantage of that is it leaves a bit open to interpretation, which can be good, or you can be really detailed and try and cover every possible scenario. So how do you go about writing the script statements?

Robyn Birkedal: Well, three things before we even talk about that. One, I am not a lawyer. I do not provide formal legal advice. So I’m just talking about my experiences mainly from my career in advertising. Secondly, yet? I am not a lawyer. Number two, I would just want to send you some love about that bed because, like, ouch. Yep. I totally know those perpetuity terms. And I think, you know, that contrast between one year and five years in perpetuity is really dramatically different. And I think, you know, there was a healthy lesson in that. What I want to go back to, though, is kind of, you know, within our environments that we work in Scope statements are a lot of different things.

Right. So we can call them estimates. We can call them the holdout scope of work. We can call them a contract. We can call them a proposal. Like it’s essentially like a nest of things that go within several different formats. So some of the names I’ve used before is a statement of work contracts, proposals couple of works with, like we talked about, but they are not an NDA and MSA and ICA or an SLA and you can hear more about that in my article and what those definitions are. So basically, just trying to point out that this isn’t the only thing you need to be providing with your client. It’s just a component of that.

Ben Aston: Definitely.

Robyn Birkedal: Okay, so back to your original question. I think you were just asking, how do I make them write them? What’s my process?

Ben Aston: Yeah.

Robyn Birkedal: Well, no, I mean, there are a few different approaches. I typically have used templates that are already provided by my in-house team. Luckily, I’ve been provided a lot of really great workplaces that already have a template on hand. I also do keep versions of the previous SOW in a personal folder so I can pull back and see, you know, how did I craft, you know, a scope or a statement that referenced a branding project vs. a digital project versus a refresh or a redesign. But obviously, I think the digital project manager is a great resource for that. And then I know that you wrote an awesome article about writing a statement of work that does include a template. So you can kind of source a lot of details there, too.

Ben Aston: Definitely. Cool. So I think this idea of having to develop your own bank of Scope statements that you can, you know, reduce, reuse, recycle is super important because the way that we talk about delivering work is actually, you know, normally the parameters that we’re having to describe if we’re doing a rebrand project are going to be the same project. The projects we’re gonna be talking about, how many concepts we’re developing, how many rounds of revision we’ll be doing, what the client interaction and feedback loop might look like, what the final deliverables might be. Actually, the kind of if we’re producing the same kind of deliverables time and time again and going through the same process, then the Scope statements that we’re writing can actually be recycled quite easily.

So actually, in the Post, if you’ve not checked it out yet, go to thedigitalprojectmanager.com/project-scope-statement and you’ll see a whole bunch of Scope statements that we have. Some of them are generic. So some of them you can actually reuse and recycle for your own projects and just change, change the names out. And then some of them are more specific. So the most for the more specific ones, we have to have this understanding of what the project is. But some of them like Scope statements that we can recycle, a project to project Scope statements like defining who’s going to pay for or who’s going to be responsible for licensing imagery or videos or who’s going to be or what the turnaround time might be for a client to approve a piece of work or review and provide consolidated feedback or how many rounds of approvals there might be.

So some of these Scope statements, you can just create a bank of them. We’ve got a whole bunch on the score that you can just recycle some of them we’re going to have to be more specific about. But let’s talk about good and bad Scope statements we talked about. There are two ways, I guess, of doing this. You can go well, it maybe it’s a continuum of a loose scope statement versus a very specific scope statement. Now, it’s not necessarily good and bad. Either one either ends of that continuum. But what do you think makes a good or bad scope statement?

Robyn Birkedal: That’s a big question. But I don’t know. We could spend hours talking about that, right. I think what I do really appreciate what you were saying earlier, though, is like to lean on that bank of your different Scope statements in the past and also lean upon others in your current workplace or reach out to different friends and ask if they have something similar that was super effective so that you’re not always starting from scratch. Right. Like, lean on this DPM community, lean on people so you don’t have to start all over. But I can tell you some five things you can do to cover your bacon. Do you want to hear that Ben?

Ben Aston: Yeah. Go for it.

Robyn Birkedal: And this is just coming from my personal experience. But what I find really successful is to number one, define why I typically like to call this part the overview. It just feels a little bit more formal. But this is essentially the first section where you’re defining the work and defines why this project exists or program why it’s happening and what it will achieve. Right. So we’ve all had overviews in our essays growing up. We’re using that here and present-day as adults. I typically like to delegate this out to an account manager. You have that so they can go run that back to the client and get those KPI’s is that we can talk about. This is not where we need to narrate everything. I keep it short and concise, but we just need a frame-up essentially that value statement that will outline the rest of why we’re doing this work and why it’s important that we can level backup to this. Why?

Ben Aston: Yeah, and I think this started with the why is super important just because if all else fails, this is kind of our backstop. If we can demonstrate that actually what we delivered on the original intent of an ad, it delivers on that. Why? So if it’s about fundamentally the what we’re trying to do is build something that increases the number of subscribers. Well, the client might not like the way that we executed it, but if ultimately we can prove and show that, yes, it does exactly that, that we are building the subscribers and that works. If we can align the most basic level of achieving that, why I’m reaching that outcome, then it provides us with some common ground to work from.

Robyn Birkedal: Absolutely. And I think that can be worked in all project methodologies, right. Of how we’re tackling this. Right. You need to always know why we’re proceeding forward. And I found it’s really helpful to kind of put at the top of the Slack channel or in different team documentation as well. And so kind of craft that on that and then share it with everybody to align the teams. The second tip I have for you, though, is to outline the approval process. And this may seem really basic, but I feel like this is always where in the past things have gotten a little spicy.

So I’m highly encouraging you to at least craft basic language that details out the approval process for deliverables. So, for example, when should the client give us feedback? Who is providing that feedback and how should it be delivered? Obviously, you can start basic within the statement for now, but no, that should be expanded upon before everything’s moving in motion. I think Ben and I, both have had a few headaches here and obtaining feedback and how and we can also talk about how we took this under dependencies and assumptions in the future. But it’s best I found to always talk about feedback and that approval process with the client verbally and then have written format for that within that statement.

Ben Aston: Definitely. Yeah, that’s some of the advice.

Robyn Birkedal: Okay. Moving on to the third tip is I would highly suggest: Champion, that you identify what you’re actually going to be delivering. And typically this will be the biggest part of your scope statement. And this is a Wild West, right? It could be super detailed and expansive if you’re doing more waterfall. It could be more process-focused if it’s more of an agile approach. But what it’s going to do is it’s going to list exactly what people are getting when they’re getting it and how they’re getting it. I come from the standpoint of trying to be detailed. But as I know, everybody doesn’t agree with that. But I am super passionate about rounds of review, contract entry, migration, hosting a configuration formal QA also been speaking to like image rights and then ultimately deployment.

Ben Aston: Yeah, and I know I’m also a firm believer in, hey, if we can define this, let’s define it, let’s try and block in the canvas. And this is where I think if you don’t know exactly what you are going to deliver. I would adopt the sandbag approach, which is, hey, we know at the very least we’re going to deliver this and then we can at least level set on that understanding that at the very least, we’ll deliver two concepts. If you think you can develop for, say, you’ll develop two and commit to doing two because it might turn out that for whatever reason you do any delivered to. If you think, hey, you can build, you know, up to five components within the page. Well, let’s define five, and let’s agree to five, even if you think it might be actually six or seven.

So sandbagging can be a good way to find some common ground. That’s the most likely kind of aligned to that most likely outcome. And that means that you don’t need to say, hey, or we’re going to deliver seven modules. But you say, hey, we deliver five. And then you can surprise and delight and make sure that you’re not overcommitting yourself. And I think that’s the key part of writing this scope statement when we’re defining the deliverables. We just don’t want to overcommit ourselves because the danger is if we say seven. And it turns out we only needed five. Then the client might turn around and say, well, can I get a refund, please? Because you actually ended up doing five.

Robyn Birkedal: And that’s absolutely happened to me. I think it also can really help control what’s happening internally with your team. So you may have some, you know, design development or two. You know, really, I love that intersection of creative development. But sometimes they disagree with that workload. So your designer might go crazy or you, sir, might figure out your strategist might say, Okay, we need 20 templates right and so by kind of having these upfront discovery conversations week. We can try to mitigate that internal churn as well, not just on the client. And so, Ben, you were talking, alluding to the fourth tip that I have, which is to define what is included and what’s not included. And typically, I put this in a different section outside of what those deliverables are. So after I’ve identified like, yes, you will get.

Three modules, for example. This is definitely where I have an exhaustive list. Just to try to protect what I know and what I don’t know. I call it boundaries. If we think about it in personal terms. But this is where I’m covering my bacon. So first up, I like to have dependencies and assumptions is technically what I like to call it within these statements. But here’s what you spell out where nobody is going to get away with. So this extra may repeat back on a few things above in your statement, such as written feedback, and it should come from in that relationship. But in addition, it could be like, for example, if there are multiple deployments if they decide they don’t want to move forward with the deployment.

This is where you outline like if there is a second if you push out the deployment date, there will be a change order issued because that’s going to take additional time for the team and reshuffling your resources or people to get there. Which is important. And in my article, I list out some exhaustive examples for you. And then secondly, I love the section called Exclusion Statements, or as I call it, out of scope. And this is everything that you think that they might ask for and you want to make clear that you’re not providing. So, Ben, going back to that image fee in perpetuity. This is talking about FEMA’s training documentation, hosting, or font fees, these digital style guides. It can go on forever, but you’re just trying to protect yourself that you’re not on the hook for providing that because you didn’t talk about it.

Ben Aston: Yet, or maybe you did talk about it. And that’s where these misunderstandings can occur. These have also called negative Scope statements. So it just listing all the things that we’re definitely not doing. And I think what can sometimes happen in that process of defining the project brief and defining the projects, it might be that the client comes in and says, hey, well, we want this we want to revamp our website. And they just they talk about re rebranding as well. But it turns out that actually in the statement of what way? You know, out, they don’t have the budget for a complete rebrand. So you need to include a scope statement or negative scope scale statement that says we will not be doing any rebranding.

And that will then you can refer back to it and say, “Hey, client, I know you know, you seem to think that we were going to do a rebound, but we did write it down here in the scope as a scope statement to say we will not be doing any rebound work on this project.” So it’s worth thinking about as we’re trying to rewrite these negative Scope statements, as we’re trying to anticipate what are all the things that the client could think they might be getting, but they’re not getting. Refer back to all those conversations you’ve had and think, well, what were some of the things that some of the crazy ideas are that they threw out there and make sure that you include them in your list of things that, you know to do.

Robyn Birkedal: I love that. Yeah. And I don’t think there’s any right way to do this. It’s just more kind of like trusting your inner gut and listing out what are all the ways that this could go poorly. And I’ve had managers in the past that are like, Robyn, you’ve written down like you, catastrophizing essentially way too much. And so I think for me, like kind of mapping out what could go wrong and then summarizing that a little bit more concisely is also helpful, because that’s me, you know, being in my craft, thinking ahead, trying to mitigate that risk at the very beginning stage of the project. I think we’re ready to move on to the fifth and final tip, which is a little controversial potentially. But I like to make a scope statement matrix and. So I came up with this a few years ago, and I think it was passed over to me from somebody else, too.

But what I realized is that I have spent hours in the past in an active project just going through version histories of documents or files or Slack or email or sketch files or, God forbid, code, just to figure out exactly what we said. What that format was. And it’s not clear like I’ve wasted a lot of project hours doing that. And so I’ve learned that at the onset of delivering that scope statement, I can do the work upfront and just keep track of deliverables. Just so that we have a clear understanding of how we’re executing against that statement.

Ben Aston: Yeah, so the idea of this is that as we because sometimes these deliverables that we’re producing, that statement of work, we wanted to become a document that’s not just a one-time thing, but one way. This is one way that we can actually make the statement of work relevant throughout the project. So by putting those deliverables into a matrix, kind of tracking with them, reminding the client or the stakeholders that, hey, this is a document we’re taking seriously, this is a document we’re using, that can be a great way to track things as we go and to keep the document and the conversation about life.

Robyn Birkedal: Correct. And Ben, I would even go so much to say is I have not always shared these matters with Matrixes with the client directly. Sometimes I just keep them within the project file structure. Right. Internally. But I kind of like bring it out when that contention potentially comes up so that I have all the resources needed to mitigate that issue immediately. Instead of spending the hours in the past.

Ben Aston: Yeah. So, I mean, this all sounds like plain sailing, right? If you follow these tips and just you just gave statements, all will go wonderfully well, right or wrong. So tell us what some of the biggest challenges you’ve had or where the Scope statements go wrong.

Robyn Birkedal: I think where things haven’t worked is essentially it’s not about always following, quote, quote, the rules, but you need to be flexible about approaching every project individually. Right. I think what’s hasn’t worked for me is I’ve tried like, you know, I think back to years ago and I’m like, Okay, well, this is the template. I always follow the template. And I think we just need to be more. Flexible about how we approach every project and understanding that clients are on different levels of how they want to approach things. And that’s usually where it’s been a problem. Just my own learnings. And so I think over the past years, I’ve been more flexible about it, but also more rigid in terms of what we actually are signing up to do.

Ben Aston: Yeah, I think one of the biggest challenges is in yet, really, I think in just defining how definitive you’re gonna be, how well, when you start the project, when you’re trying to write a scope statement and you’re not entirely sure what you’re delivering, it can be tricky because you can be tempted to where you can overreach and you can say, hey, yeah, right at the beginning, the project, well, we think we’re gonna deliver X, Y, and Z. And then it turns out after the discovery phase or off the design phase that the Z part of the project is kind of redundant, is not needed or not necessary or you can’t afford it.

So I think it’s always worth thinking about your planning horizon. And it’s good to write Scope statements, but not to overreach and maybe split your Scope statements up into realistic chunks that are within your planning horizon. So if you’re going into the discovery phase, just try and get away with writing the Scope statements for the discovery phase and then say, hey, as part of this phase of the project where they’re going to develop the next part of the project, the scope and the Scope statements for the craft phase or the design phase of the project. So I think overreaching, I think, is potentially the biggest challenge that I see when we’re developing these, because we think we know stuff. We think we can anticipate what’s gonna happen, but so often we can’t.

Robyn Birkedal: Absolutely. I think another challenge, just kind of like came to me right now is when you get a sign off on that scope statement from the client, but they have it involved all of their stakeholders on that. And that can really detriment your project. And so just having that verbal walkthrough and kind of alignment session where you talk about that, I think it’s super helpful.

Ben Aston: Definitely. And I think I mean, I think what’s important there is the verbal walkthrough, because I think what we don’t want clients to do as well is to sign it often, to have not have read it themselves and not to have understood it. We want them to understand what they’ve committed to because what we don’t want is this. We don’t want this to be a legal document. We don’t want this to be. We want this just to be to facilitate getting a conversation to level set on expectations. So we don’t ever want it to come to. Well. Let’s go to court and discuss what this statement of work actually really means and have a judge or attorney interpret whether or not it was delivered. That’s not the point of this. The point of this is all about alignment to get on the same page.

So that is a conversation tool so that when we talk to the client when we talk them through the Scope statements, we’re not trying to trick them. We’re not trying to kind of cheat them out the word. But we’re just trying to level set. We’re trying to get on the same page so that when we do the work when we deliver those outputs, they’re going to be happy with the outcome of the project. And the things that we’re producing. So try not to think of this as a legal document, because if it goes that far, then you failed and probably you’ve everybody’s going to lose money. You’re probably gonna lose the client. We don’t want to get to that point. What we want to do is a level set on expectations so that everybody is happy with the way the work is done and the way the work is being produced. So that’s my big takeaway, I think, from our conversation today.

Robyn Birkedal: Yeah, and Ben, I think there’s nothing more amazing than that feeling where you can actually copy-paste that scope statement into a legally binding document. And just making sure that, yes, that word is my favorite one aligned between the client and internal parties.

Ben Aston: Definitely. Let’s get some alignment. So, Robyn, thank you so much for joining us today. It’s been great having you with us.

Robyn Birkedal: Thank you for having me.

Ben Aston: And I’d love to know for you who are listening, what are your tips and tricks for Scope statements, your statements of work? Where do you put your statements? How do you produce them? What works? What doesn’t? That’s known in the comments. Let us know your fail stories and winds. And if you want to learn more and get ahead in your work, come and join our tribe with DPM Membership head to thedigitaprojectmanager.com/membership to get access to our Slack team, Mastermind’s mentorship, templates, workshops, office hours, AMA Sessions, E-books and more. And if you like what you heard today, please subscribe and stay in touch on thedigitalprojectmanager.com. But until next time. Thanks so much for listening.