You’ve set an estimate and the features within the scope are clear. Ideally, you have the groundwork you need to build the best product possible. All that remains is to decide how to manage that scope throughout the complex development process. Even when we consider  heavily algorithmic features, the initial specifications of most products won’t be perfect. There are too many variables to predict – engineers and clients might discover new challenges, features might not be interpreted the same way by everyone involved, regulations are complex – namely, in industries like fintech. As a result, scopes are rarely immutable and the consequences of a rigid agreement to color within the lines can start to add up. 

A flexible scope can offer benefits and ways around some of the most common misalignments and stalls in software development.

Before you commit to a flexible scope (and an open-ended future)

It’s important to consider how to make this kind of mode functional. Here’s an important mental checklist to cover:

1. Be explicit about the budget and deadline. Some things must be certain when you’re telling a client the features might change. 

2. Have checkpoints and major project landmarks. You and the client need to see the project evolving in real time and this becomes especially important with a flexible scope. 

3. Revise when surprises arise. Don’t wait too long to revisit the plan when something does come up during your checkpoint. 

4. Support clients by being transparent about the reasoning and importance of deadlines. Not only will this help you understand their feature needs (and their priority), it will help them understand how you work.

5. Ensure both technical and business departments are conscious of the opportunities in a project. They should be aware of what is possible in a product and you’ll have a backlog from which you can select additional features.

Now that you’re all set with the mechanics, let’s explore the equally important why of it. Why would you choose this mode for your development team? 

Avoid stalls caused by contract renegotiations

Clients might produce an initial great idea, but that ideation stage itself doesn’t necessarily stop once development begins. New ideas can come about from a variety of not always predictable sources. Customer testing can reveal new in-demand features or find gaps that need to be addressed. Legal requirements of regulations can put planned features into question. 

If you’ve agreed on a fixed scope model, that means facing two equally unideal choices: restart negotiations – or, continue working on a product knowing about these inherent flaws. 

Even with the best relationships with clients, multiple renegotiations can erode patience and trust on both sides. More importantly, it only delays the more enjoyable aspects of development – figuring out how to implement the new feature or finding a creative solution to new challenges. And then imagine this may happen multiple times – the stress and time lost adds up exponentially and very soon you can end up with a project no one will look back on fondly.

If you agree on a flexible scope to begin with, there is no need to delay. If nothing does change (your first feature scope was perfection)you’ve still lost nothing by leaving the agreement malleable. 

Don’t let the asymmetry of features derail expectations

It can be easy to take common tools for granted when you’ve worked with them for a while. So it’s easy to overlook a simple fact: the work required for features can be very misleading to non-engineers. Powerful, flashy features appear very difficult to implement even if they are quite straightforward. On the other hand, minor, boring features are always assumed to be simple. Features perceived as minor can even end up omitted from the most detailed scopes. 

These asymmetries pop up in fairly common features – partner integration being a major one. 

The typical expectation: a partner API can be slapped onto a product, much like a sticker. The reality: integrating a partner API takes about as much time as if the third-party elements were coded from scratch. To properly integrate an API, you need to become an expert on their platform and business model. And then there is still the work of actually correctly integrating it – if it’s used the wrong way, it will create more problems. In the end, you may as well have built your own platform to integrate. And this problem is compounded if you’re suddenly trying to integrate multiple partners who each have a different approach.

So why implement these kinds of misunderstood features at all? In this case, the benefit of integrating a third party API over building from scratch is the regulatory and compliance work that you can spare the team. With that in mind, there’s clear business value in dealing with partner integration and it’s reasonable to leave a comfortable margin offered by a flexible scope – for any and all third party integrations a client might end up needing.

Mitigate the stress factor

A flexible scope won’t completely eliminate the stress of working on projects that still need to get to market in time to be relevant. Deadlines are even a helpful boundary on run-away imaginations and overengineering. What a flexible scope can achieve is build cooperation based on open communication rather than rigid demands. This will enable both developers and the client to prioritize and pick features – and to communicate problems before they spin out of control. People are much more inclined to share concerns when they know they’re working within a mesh rather than a solid box.  Rather than punishing people for missing a deadline, you reward them for speaking up about issues and coming up with new ideas. Over-promising becomes a lot less necessary, quality is maintained, and the integrity of your team isn’t compromised.

And when delays are discussed immediately, the whole team and the client can react to those challenges much faster. There is more room for decision making and more options remain open to you. It’s a lot easier to build a stable product over time, than to scramble to fix a broken one that should have been done last week.

This alleviates the temptation of making promises that you realistically won’t be able to keep – at least without sacrificing some measure of sanity or quality. Sometimes, even with the best of intentions, we even break promises to ourselves – you can tell yourself something will be done in two weeks and fully believe that. In reality, the feature will end up taking two more weeks, then suddenly it will take a month, and end up completed in three. This puts undue stress on the team and the client, when it all could have been avoided by working within a scope plan that allows for open communication and adaptability.

Build an environment for self-realization

What is the final result of all this? By letting the feature scope expand and contract for inconvenient new realities, you can empower people to be radically honest and make decisions. Over time you can build an environment of self-actualization through this foundation of trust and increase ownership of the product . And feeling trusted is an integral part of feeling empowered.

The decision to go with flexible or a fixed scope comes down to the company culture you want to cultivate. There’s nothing inherently wrong with a fixed scope and there will always be developers that lean towards having those boundaries in place. But in some cases, you may simply find it aligns with your values, agile methodology, and that effort to build team power.

When you go by the checklist we covered in the beginning, it’s a self-proving and self-enforcing system. The benefit of that is you’ll be able to track the efficacy of this model for your team week by week – rather than dealing with major surprises in the last 10% of a project.