Scope Doesn't Equal Value
Big focus on scope
A lot of focus and energy of organizations is invested in ideating, elaborating, designing and delivering significant scope of work. The demand always exceeds the existing delivery capability.
There is an important question: Is this profound focus on the scope of work, a good thing for the organization? Let’s take a deeper dive.
Think of some software system that you are using, something common, like a word processor application. How many of the hundreds of features that the application has are you actually using when editing your documents. Most likely, just a few; or may be a dozen, at best. But same applies to software that you create and there will be your users that, just like you, will take advantage of only a small fraction of the whole set of available features. But see, for the team that delivered this scope of work, it didn’t make any difference whether a feature was important or completely useless to the end consumer. Both features take time and effort, regardless. But if the useful ones constitute only a few percent of the entire scope, then why spend so much precious organizational capacity to deliver the rest?
Why scope doesn’t equal value
There is one fundamental tenet: Value doesn’t equal scope. As a matter of fact, excessive scope can produce negative value. This can happen in a number of possible ways.
I’m sure you’ve encountered systems where, as a user, you struggled to locate the capability that you needed because of gazillions of other features and, as always, a very limited ability to make them visible and accessible. But if a user can’t find what they want, they are not going to be very happy with the system they are using. And it’s quite ironic that they can’t find it because of other features that were deemed valuable and that’s why they were added in the first place.
Another way value can diminish as a result of adding more scope is because adding more functionality makes the solution bigger and harder to maintain. Simply because there’s too much code and the cognitive ability of those creating and maintaining the code has natural limitations. It becomes harder and harder to add new features. And when there is something that is really important and valuable, it will be a lot more costly to develop. Not to mention that a larger codebase is always harder to keep properly structured which makes it fragile and prone to problems and defects that are difficult to detect early in the process. Instead you usually learn about them when they start making damage.
Determining the right scope
So, how to help this?
Certainly not by ramping up your delivery capability but by streamlining your work intake process. Or let’s rephrase this: you need less scope. And the selection of what’s really important has to be done based on evidence, not speculation.
So, here’s something you can do to help determine what is the optimal amount of scope in your case: Take a brief inventory of what your teams have recently delivered, within the last couple of months. Can you rank all that delivered functionality based on its proven value? (Emphasis on “proven”). If yes, and this is no speculation, and you truly have the usage data and fair consumer feedback on the efficacy of what’s been delivered, then you hopefully know how to assess your upcoming work. Use it to create a strong focus on only what matters, what creates proven value. And if you can’t make this call, it’s okay, that only means that you have to start establishing the missing feedback mechanisms. And sometimes it takes real courage and critical thinking to admit that we don’t truly know what’s useful and what’s not, so let’s stop throwing darts in the dark and let’s shed some light on what is truly valuable to your organization. So, that’s your action item.