How We Deal with Scope Shift in Digital Projects

Just recently a common question we have gotten in the past has resurfaced. 

Projects rarely go as originally planned. Please describe how you deal with possible changes in the scope or direction of the project as it progresses?

As pivots or shifts in a project occur we have a belief system around being able to communicate through the change. There are certain points of the process in which we try to concentrate potential scope changes, simply because they pose a lower risk. This requires us to first identify and set expectations with you as an organization about how we will notice this happening. Change is not always bad, but it can often be detrimental to the project at hand. If business value and / or expectations did not change but scope did, we want to understand why. We work to train through experience all of our key project members from Project Managers to Designers and Developers about how to identify and communicate these changes internally and externally. 

Scope has changed (or attempted to) in every project we have worked on. Therefore we stand by the relationship understanding of this between us and you. Then we provide the tools and structure for how and when those changes should most optimally be communicated. And finally we discuss the business, project and resource implications of such a change and if it is warranted. 

Below please find one of our conversations on scope change based on the video above:

Tony: Alright, Austeja, wanted to talk to you with a couple questions around the work style and project management for SCFTA.  One of the first questions they asked, I think we could all agree and answered to, but projects rarely go as planned. So wanting to get a little bit of insight, and so if you can describe how we deal with possible changes in the scope or direction of a project.  

Austeja: Sure, so knowing that most of the projects won’t go as planned, we make sure to be able to pivot, so that means having enough communication between ourselves and the client to be able to understand when projects are at a danger for shifting, and then when it’s happening, again, communicating through it, having the toolset to talk about the change, make sure whether it’s out of scope or in scope, and adapt with whatever that need is.  

Tony: And one of the things we were talking about the other day was you had mentioned that if a project goes exactly as it was intended, that usually means something went wildly wrong.  

Austeja: Exactly.  And the reason for that is because these projects are fluid and evergreen in nature.  So you have an intention in the beginning of what you want and the goal of having a partner that’s going to help you throughout the project is to have those good conversations throughout it, that may change your mind as to what you need, or it may more specifically describe what you need and then what you intentionally came in with might be different, having been educated about the project and what you may need throughout the process.  So for whatever reason, if you go in knowing that you’re going to have a certain product and you walk out having something totally different, that’s not a bad thing, that might be the best thing for you and your company.   

Tony: Yeah, and I know one of the things we go over a lot is just because scope changes, our goal is to see whatever we can do strategically to keep it within scope, and if it does change that doesn’t necessarily mean that if we catch early enough, if we’re communicating, that we’re redoing  or it costs more, but I know that’s one thing we always the assumption of why does it need to change? Does it? Is it just a want, a desire, a thought that popped up, or is it going to get the project to a better end result? So, I guess one of the things we’ll be sending is some examples of status reports, project plans, kind of how we do that.  So, I just wanted to give you opportunity that one of the questions they had really mentioned is providing samples of project status report that we would provide to them, is it weekly, task, hour, so just talk a little bit about what we provide and communicate with them.  

Austeja: Every client is different, which means that some are more hands off, we talk about the project in the beginning, we talk about the timeline, and then off to the races we go to fulfill whatever that is, and then include the client at particular moments where they may need more feedback or where stakeholders might have to provide some insight.  So, with those types of clients, it is very specific, touch bases within t milestones the project. For others, it’s a more weekly, or specific cadence, so maybe it’s a weekly status call that we do in addition to continuous updates from the project manager on the project status, so it can be a myriad in between, it can be the most extreme of talking to you at very specific points or maybe not at all, but either way, we adapt to you as the client.  

Tony: Definitely, I think it’s about building off of that communication.  Because we’ve had certain clients that they might say, oh yeah, just tell us when deliverables, but we might recognize and be a bit more proactive of saying, well, we need your communication, we need your buy-in, because we don’t want to get 4 weeks, 8 weeks, 12 weeks from now, and you being confused because there’s a lot of bases that you need to cover and you might not be too familiar with what we’re doing.  And that goes into then again project plan, again, utilizing Reich, depending whether we’re developing or using GitHub and stuff like that, but typically front facing to the client it will be waterfall and outlining the different things that we’re doing within Reich, sharing it with them, and providing those updates.  

Austeja: Right, so as a company we use Wrike, which is a project management tool, and that is one that we religiously go by, because it keeps us on track, and whether the client needs full visibility into that or minimal, we’re able to be flexible with that and tailor to them.