Perception Vs Reality: How To Define Project Scope For Digital Products
UI/UX Design
User Research
Building a digital product, whether that’s a cutting-edge mobile app or a back-end software application to support your business, requires significant investment. For those who don’t do the right planning, these costs can soar to astronomical heights. But you're not that person, right? The planning stage is perhaps the most crucial part of the product journey. Those that don’t get planning right typically fall into two categories:
Businesses that obsess over/overthink the planning stage and delay progress again and again.
Businesses that leapfrog planning and either do little or no preparation, which can doom their product before they even start.
Both of these issues are down to an inability to actually conceptualise the requirements of the project. Without knowing what a product needs to be, who it’s for and how it will work, how can a business ever really understand how long it will take/how much it will cost? That’s where the scope comes in.
What is the scope of a software project?
Software scope is a written statement of the requirements of a product. Scoping is all about defining the product and project in terms of its core capabilities. There are two separate elements to this:
Product scope: what the product will be and what it won’t.
Project scope: how the product will be created - any of the non-product elements are part of the project scope.
Defining a project’s scope is essentially a case of combining your product scope with the non-product elements that it will take to build it. But with so many businesses overlooking the planning stage, lots of project scopes end up becoming a lazy list of features or ‘shiny things’ the management team likes the sound of. Additionally, project scope can be confusing as it’s also a term used in project management. In software development and design, however, project scopes ALWAYS include product-specific requirements. Where a project management scope may have a goal such as ‘Improve customer retention by 100% by 2024’, a product scope would list the specific features needed to accomplish this such as ‘Develop customer management AI chatbot’. But how can you scope a project without knowing what it needs to do? How do you define what a product will or won’t be, or even plan what sort of timeframe it will be developed? It all comes back to planning and research.
User research: How to understand the reality of a project's scope
To develop an accurate product scope, you’ll need to perform user research. The core of every great software project is based on knowing who your users are and what they need to accomplish, then developing solutions for that. Without good research to influence it, a scope is simply a vanity list based on assumptions or stakeholder pressure. At KOMODO, we take great efforts to understand the end-users of any software project we’re working on. That means not only developing detailed user personas, but also user stories and journey mapping that aims to define WHO users are, HOW they use digital tools and WHAT they need from them. We also perform user research interviews to understand the crucial (and often forgotten) WHY of their behaviour. The outputs of this level of user research tend to be clear needs and requirements. These are the core pillars of your product and will shape not only what features you build, but also when they must be built. In a typical Agile software development process, the ‘Minimum Viable Product’ is a core goal to work towards in new product development - and it’s this MVP that should contain the features most crucial to user needs.
Spell out your project's value
Once you have gathered your user requirements and have an idea of their behaviours, you can begin scoping the project. To do that, you’ll need to outline the product scope and the overall project scope. These both demand a full understanding of who your end-users are and how they’ll utilise your product. A straightforward ‘first step’ is to create value propositions for each user type. This is a single sentence statement that shows what your product is and why it matters to the user. For example, Airbnb could be distilled into “A digital platform that allows you to book short stays in people's homes anywhere in the world.” This statement can serve as the basis for your full Project Scope Statement.
How to develop a project scope statement
Developing your project scope should be based on the reality of user needs rather than the perception of stakeholders and team members. Your scope should be developed into a statement that includes the following:
Do research: Understand users and their needs
Write project scope description: Create the overview which lists the objectives of the project - what needs will be met?
Describe deliverables: Create a list of deliverables that will meet those needs - these are the features that will be core to the MVP.
Define acceptance criteria: list the critical success factors the deliverables must achieve
Identify any constraints: limitations to the project such as time or cost
Set exclusions: things not included within the scope such as additional features requested by managers etc.
Project scope example:
Scope description: developing a digital app for use on all devices that will allow those undergoing medical trials to report on their emotions and book treatment times. Deliverables:
Diary booking feature.
Satisfaction and feedback feature.
Analytics to monitor treatment progress.
Acceptance criteria:
Client sign-off after each phase.
End-user should be able to submit their feedback in one click.
The booking confirmation page must display when successful.
Constraints: the short term nature of these trials limits the development timeline. Exclusions: added data integration requested by the client.
Stick to your scope
Once you’ve defined your project scope, you have a clear roadmap to the MVP. Whether you’re working with an external team or in-house, the scope helps keep everyone on track and ensures the product does what it sets out to do. The reality is that at some point, new features or changes will crop up in the project’s lifecycle that may be out of scope. These features may be demanded by stakeholders, or outlined after a round of user testing. But, all of them add to the workload and ultimately increase costs. This is known as scope creep. It’s virtually impossible to avoid it, but you can manage it by taking the right steps. The term ‘gold plating’ refers to when a business adds new features beyond the scope to please the customer. While it may seem like a good idea if you’re trying to add value, you must remember that any changes made outside of scope will increase the burden on time and finances. Because ‘gold plating’ is done by the team working on the product, it’s usually their own profit margins or quality that they must sacrifice to include the new features. Again, this all comes back to user research. If you can take the time to understand your users and build a scope that meets their needs instead of your ideas, you’ll already be on track to a more successful product. As a digital product studio that frontloads our efforts into understanding your customers, we define our own project scopes based on genuine requirements - which means we can launch digital products that make a real difference. Get in touch now if you’d like to work together.
Sign up to our newsletter
Be the first to hear about our events, industry insights and what’s going on at Komodo. We promise we’ll respect your inbox and only send you stuff we’d actually read ourselves.
