Achieve Real Benefits without Scope Creep
Scope creep. It’s a phrase with mostly negative associations for me, and I don’t think I’m alone in this.
Perhaps it’s that I grew up (professionally) with more waterfall projects than agile efforts. Perhaps it’s that I’ve pushed back on adding scope more than a few times, in an effort to deliver what was promised, when it was promised.
Scope creep doesn’t have to be all bad. It may mean that someone saw value in what’s being delivered and asked for more of it. Or it could be an indication that productive discussions were had between siloed groups, increasing understanding along the way. But the fact that we’re calling it scope creep means that expectations are shifting, which can be disruptive to progress overall.
The fact of the matter is that delivery of something valuable will likely include multiple milestones, no matter the delivery methodology in play. That’s why we’ve compiled four ways to achieve real benefits without scope creep. You’ll see in these a preference for agile mindsets and methods, but they’re applicable to waterfall and iterative delivery, too.
How to achieve real benefits without scope creep:
Specify a clear and compelling why: be clear about the benefits we’re aiming to achieve, and share the why widely.
Create an intuitive and accessible backlog: have a transparent backlog – and intuitive ways to add to it – of the cool things we can do after achieving the milestone we’re focusing on now.
Build in scalability: collect enough information about business and technology priorities, constraints, and practices across the organization to choose solutions and processes that will scale, without having to finalize the entire business and technology architecture at the outset.
Embrace structured continuous improvement: utilize agile frameworks and methods like program increments and retrospectives to give clear goals for a period of time, get smarter together, and then keep moving forward.
I’ll use a digital modernization project as the main illustration in this blog, to add practical examples of these techniques.
Specify a Clear and Compelling Why
The purpose and potential benefits of a project or program can seem so obvious to its leaders that they neglect to say them out loud. Or perhaps they simply share the rationale from the project request documentation, which can be short on details and context.
A bit of time and effort to share a clear and compelling why will pay off, I promise. It will give something to rally around, and the process of defining the why is often illuminating in itself.
Defining the Why
Laying out a clear why can be easier said than done. People leading the effort may be too close to the action to see other perspectives clearly. This is when we recommend bringing in additional stakeholders – a different delivery leader or, even better, a leader from a different area of the organization entirely – to workshop the project why together.
Key to this step is including potential benefits as other stakeholders see them. You’ll hear organizational change management experts talk about one or two WIIFM’s (pronounced WHIFF-ems), or key questions to answer on behalf of those who will be impacted by the change.
The most common is: What’s In It For Me? What benefit can I expect to experience based on this project? What value gained or challenge avoided can I expect in my everyday experiences? WIIFM #1 gets at the reasons for this change, the why.
A second WIIFM is What Is It To Me? This variant helps us break down the components of the effort into easily understandable concepts and components, rather than a string of jargon. WIIFM #2 keeps us honest in describing the what of the change.
Sharing the Why
Once you have incorporated other perspectives into a compelling set of benefits we’re aiming to achieve together, it’s time to share the message widely. This is a great time to engage your key change management stakeholders (identified by Prosci, leading change management researchers and trainers).
First up is the sponsor, who authorizes the change. The sponsor should communicate directly with employees about why we’re pursuing the effort, at various times, in various ways, and making sure to address various perspectives.
Next up are the people managers, who support their direct reports through their change journeys. People managers should be equipped with the compelling why, WIIFM #1 and #2 (with the invitation to tailor both to their team), and details about the project.
If you haven’t already, engage your change practitioner and the delivery manager (project manager, scrum master, release train engineer, etc.) who will be enabling the effort, and work with them to create a change strategy and change plan that dovetail into the delivery plan.
Expect to repeat the clear and compelling why many times over the course of the effort, since the message will get crowded out by other priorities over time.
And, as we’ll see in the next section, this why may be focused on the first set of benefits we’re delivering. Call it phase 1 or the initial product or the foundation (I’m not a fan of the minimum viable product language; I prefer minimum lovable product or minimum scalable product, but that’s another blog post). Just make it obvious that we’re after a larger set of benefits, and we expect to realize this specific set of benefits on our way to the whole.
Project Example of Why
Let’s illustrate this with a digital modernization example. Say we’re embarking on an effort to move from a mainframe technology platform to a software-as-a-service (SaaS) technology platform. We maintain our own application today, and the data is stored on servers in our headquarters’ basement. The SaaS solution we’re moving to is accessible through a web browser, maintained by the vendor, and our data will be stored on servers hosted by one of the major cloud providers. We will need to develop applications and integrations around the main SaaS solution, to make it work well within our suite of capabilities.
Depending on which team initiated this effort, our project could have been pitched with one (or likely multiple) of these reasons:
It’s becoming increasingly difficult to find team members to support the mainframe program.
We’re thinking about moving offices, and the idea of moving all the servers from the basement somewhere else isn’t pleasant to consider, both from a business continuity perspective and from a logistical perspective.
Our customers keep asking for access to more information from us, and we’ve been growing our customer success team to keep up with the requests.
The list likely goes on…
All of those are defensible reasons for an effort like this, but each is addressing a limited stakeholder group. If I’m not responsible for moving servers to the new location, I’m not particularly motivated by that reason – particularly not if I have a lot of work to do in adopting the new system! If I’m insulated from the technical support team, I might have no idea how much effort goes into maintaining a system like this. We need a bigger why to point to.
A clear and compelling why likely connects to company-wide goals like serving customers well, expanding market share, or increasing profitability. In this case, we may define a compelling why as: To delight our customers with the information and insights they’re seeking, we need a stronger, more flexible technology foundation. Adopting this SaaS technology platform will position us to protect our existing market share and pursue adjacent offerings.
I’m sure we could make that better with a cross-functional workshop, but you get the point. We need a company-wide why that we all can point to. And then we can layer on more specific why’s to make it tangible for each team (feel free to reuse our initial reasons at that point!).
If we’re going live with the three core modules of the new platform with a certain team, then adding on more functionality or more team members, we’ll need to be clear about what portion of this value we’re delivering out of the gate. That brings us to our backlog…
Create a Clear and Accessible Backlog
One of the things that can decrease enthusiasm for a major initiative is hearing, “that’s in phase 3” or “we’ll get to that… eventually.” Typically, this is in a discovery, requirements-gathering, testing, or training session – that is, when the delivery team is interacting with end users of the solution – and the conversation uncovers an ask that either is in a set of features and functionality to be delivered in a future phase, or isn’t represented on the roadmap at all. This can be a tense moment, with the temptation for end users to say, “well if it doesn’t have that, I don’t see any value here.”
In fairness to the delivery team, we can’t deliver everything that’s of value to everyone in one phase or program increment. (This is what has snowballed many a waterfall project in the past!) And in fairness to the end users, it can be difficult to describe what you want until you see a prototype, thus the potential for changing requirements or requests as features and functionality are delivered.
That’s why we recommend having a transparent backlog, the list of all the features and functionality we hope to deliver, and making it accessible for people throughout the organization to see and to add to. With an intuitive backlog, we can have a candid conversation about what value we expect to deliver when – and we can talk about tradeoffs and the potential for shifting the delivery plan.
It can be scary at first to be so transparent – “what if end users see that we don’t have a clear plan?” or “I didn’t write this user story with perfect grammar!” – but we find that good faith collaboration is usually worth the risk. This probably means putting the backlog in a widely accessible tool (with role-based access and permissions), and helping stakeholders get familiar with how to navigate it. It probably also means some awkward conversations around what is and isn’t in the backlog.
Each of these discussions are opportunities to build buy-in and trust, if the folks participating in the activities will stay curious, seek to understand, and come back to the compelling why.
Drawing a Line in the Sand
But if the backlog is accessible, and we’re talking about changing priorities, how do we get anything done? It’s a valid pushback, and this is where the Scaled Agile Framework (SAFe) concept of program increments, combined with robust interactions with end users around priorities, is really powerful.
Using stakeholder input – throughout the team and all the way to end users – we agree on priorities for the next increment (say ten weeks). Great, the delivery team has their marching orders and can move forward with clarity and confidence. And the priorities and potential value to be delivered after that ten-week increment aren’t yet set in stone, so we can talk about what features and functionality will be most helpful, and to whom, around the rest of the backlog.
This makes conversations around shifting priorities – outside of the program increment, mind you – less tense. They’re an opportunity to learn how better we can delight customers and enable real value.
Project Example of an Accessible Backlog
Again, using our digital modernization example, we can imagine a list of “things we want and need the new system to do.” This likely starts out with overlapping categories, various levels of granularity (that is, big-picture goals and zoomed-in system needs), and some meaningful holes. Don’t worry too much about the initial quality: we’ll get better together. Focus on getting as much information – on paper, in a spreadsheet, in a backlog tool – as possible. This information can be gathered through discovery sessions, requirements workshops, and reviewing the current solution’s feature set. Just be careful not to say that we need to make the new solution exactly the same as the old one. There’s a reason we’re making a change, remember?
After you have a decent initial list, spend some time to make it make more sense. This likely includes adding categories, jotting clarifying questions in existing requirements, and stubbing in placeholder use cases (to discuss with stakeholders) where you see logical holes in the list.
And then share the backlog!
Resist the desire to make it perfect before making it accessible. You will find things that are wrong, that are unclear, that are missing. That’s part of the process. Go through the backlog with the people who participated in discovery sessions and requirements workshops, asking questions and showing how their input was translated into the backlog. If you’re using sizing and/or prioritization methods, go through the backlog at a high level with the relevant teams and ask for feedback on the information being provided. (This isn’t asking for everything to be sized; it’s getting feedback on the framework and overall process.) The backlog will be an important tool for success, so make sure the way you’re maintaining it serves you well.
Depending on your organization, you may give end users access directly to the backlog, or you may have them work with business analysts, customer success team members, or other liaisons to get their feedback incorporated. However it works the best with your culture and processes, make sure stakeholders know how to view and contribute to the backlog.
Along the way, point back at features and functionality delivered based on their requests and celebrate your combined success! The solution will be more valuable based on end user input, and we hope that end users see real value in what’s being delivered. It’s a win win.
Build in Scalability
Alright, we’ve got a compelling why and an accessible backlog. Nice! One of the potential stumbling blocks at this point is feeling like we need to map out the entire business and technology architecture before we get started. If these are new terms, both point to creating visuals that show how the various pieces of the business and technology fit together. They’re often highly simplified to start, with more details layered on, say, of how systems connect to each other.
I love seeing the big picture, and I’m a big fan of both business and technology architecture. But requiring that we finish mapping them out before we begin an effort can be too rigid. We recommend collecting enough information about business and technology priorities, constraints, and practices across the organization to choose solutions and processes that we’re quite confident will scale, but not insisting that we finalize the business and technology architecture at the outset.
Essentially, we’re seeking to create a good enough design that we avoid a lot of rework due to changing guidance along the way.
This has risk built in: we’re definitely going to learn throughout the process of discovery, backlog refinement, development, testing, and more. So we will likely have some surprises and decisions to make around how process, structures, and systems work together as we proceed with the effort. But, working with cross-functional input, a greater desire to learn than to be right, and with our compelling why out front, we can sketch out business and technology designs and guardrails well enough to enable the effort to succeed.
Project Example of Building in Scalability
On the business side of our digital modernization example, this could look like:
Listing out mission-critical end-to-end processes and their major handoffs
Mapping out key stakeholder groups and their top goals
Whiteboarding the quintessential customer journey we’re looking to enable
Summarizing regulatory requirements and how they constrain our options
These will help us point the functional ship generally in the right direction, rather than lurching between priorities as we go.
On the technology side, this could look like:
Listing platforms, protocols, and languages to use, and the process for evaluating other options
Sharing guiding principles, patterns, or templates for the major solution areas
Iteratively publishing enterprise architecture diagrams, as information becomes available
Specifying review and feedback processes
With this, we’re aiming to put down the technical edge puzzle pieces and give enough guidance on how to go about filling in the rest of the puzzle that each individual and team can make sustained progress.
Embrace Structured Continuous Improvement
The final recommendation can probably apply to lots of areas, in business and in life; clearly set up time to do the work, evaluate the work and output, incorporate lessons learned, and then repeat! By getting crisp on which of these times we’re in, we can prevent a lot of churn and angst, while making sure that we get smarter together as we proceed.
At FlexPoint, we’re fans of agile frameworks and methods like program increments and retrospectives. As mentioned above, a program increment gives us a specified period to achieve specified goals. Adding on retrospectives (we may have one or multiple within the delivery team, and it’s great to have one with end users, too) gives us time and space to look back on what we’ve done together; have a candid discussion of what went well, what didn’t, and what we want to experiment with going forward; and incorporate lessons learned into our goals and practices before setting out on the next increment.
Project Example of Embracing Structured Improvement
Turning to our digital modernization example one last time, say we structured a program increment around building out core functionality and related applications in three modules of the solution. As the timeframe comes to a close, the delivery manager facilitates a retrospective among the delivery team.
During the “what went well” portion of the retrospective, a business analyst noted that the cross-functional workshop to define what client statements will look like was particularly successful. The group discusses the key elements of the workshop that went well – say, setting and enforcing ground rules for participation – and prioritizing ground rules becomes part of the team’s workshop template.
During the “what didn’t go well” section of the retrospective, a developer brought up that a certain kind of bug was found multiple times in user testing. Through a candid discussion across development teams, it comes out that this edge case isn’t included in our development pattern or review processes. The enterprise architect takes an action item to update relevant patterns, and a technical lead takes an action item to add to the review checklist.
In both cases, the team’s practices going forward are stronger because of the retrospective, likely resulting in better outcomes and time being better spent in the next program increment.
Achieve Real Benefits without Scope Creep
We hope these recommendations will indeed help you achieve real benefits without scope creep.
With a clear and compelling why, teams have a sense for why we’re investing in the effort and what we’re expecting to get out of it, both in the near future and the longer term. With an intuitive and accessible backlog, all stakeholders are empowered to understand what’s being delivered and to advocate for the features and functionality they find most valuable. By building in scalability, teams can make real progress quickly and prevent costly rework. And by embracing structured continuous improvement, everyone can focus on getting work done, learn from the experience together, and incorporate lessons learned into future plans.
Seeing real progress in the areas that people agree are valuable can be really satisfying, too, and provide the motivation to keep up the great work together.
If you’d like to talk through how these recommendations can look in your team or organization, please set up 30 minutes with me. I’d love to discuss.
