‍

If you've ever built software or digital products, you know that one of the most difficult parts is actually scoping the project. Figuring out how much time and effort will be required upfront can feel like a guessing game, especially when you're unsure of how long your process may take to code a specific feature, fix a bug that pops up during testing, or take things in a different direction if iterative testing yields unexpected results. Nevermind that new technologies and platforms to take your products across the line are always emerging, so what worked six or twelve months ago might not work anymore today. 

If you've been frustrated or confused trying to know the unknowable, don't worry, you're not alone. Ask any software engineer, and they'll tell you that scoping is one of the trickiest things to get right.

At POWER SHIFTER, we have endless software and digital product projects under our belt. Along the way we've developed some tips and tricks to nail the scoping phase. 

Don't go chasing waterfalls 

In a traditional 'waterfall' model — where software is built sequentially, each step following the previous one — scoping a digital product project requires gathering detailed requirements from customers and stakeholders upfront. This phase is, inevitably, time consuming: it can take months (or even years) to have the requirements in place. The worst part is that the effort required in no way guarantees the quality of the output. The results are often buggy or inflexible. 

Even after a large requirements gathering phase is conducted, costly delays can send a project over budget. Often, this is because requirements change during development, affecting the timeline. 

At POWER SHIFTER, we take issue with this model, namely because it doesn't allow for the feedback and iteration that produces high-quality products. 

(Following the wisdom of Martin Fowler, who was "suspicious of using metaphors from other professions to reason about software development", we believe it's dangerous to try to anticipate how a product build will go in advance. Software development is too abstract. As Martin Fowler explains, if it has to be compared to anything, a puzzle is more apt, since programmers spend ample time writing unique code to stitch together different solutions into a functional whole). 

Beware of creep(s) 

The main culprit when it comes to accurate scoping projects is scope creep. Any good project manager knows that a clear and concise project scope is essential to both the client and agency teams. But with changing requirements, and new information is uncovered, a software development project can completely shift course. 

Let's say, for example, that a software / digital product development team identifies that their application needs additional features to meet distinct user needs uncovered in user testing. If there's no buffer in the original scope and timeline, chances are this will throw off the scope, leading to increased costs and schedule delays. Without proper planning or clear objectives, likely changes and additions can be detrimental to the wellbeing and timeline of the project. 

How to improve at scoping software and digital product projects 

Know who and what you're dealing with 

The main factors that affect software development effort/pricing are: the type of project, the size of the project, and the size of the development team.

1. Type of Software Project - From a high level, typical software development engagements tend to break down into the following types:

• New Software Development – New software involving custom development.
• Software Modification – Enhancement of existing software.
• Software Integration – Integrating software packages such as Salesforce or SAP and other third party integration that extend the functionality of the software that the service is being integrated to.
• Web Development – Custom web-based software development.

2. Size of Software Project: 

• Small –  Minor adjustments like interface tweaks or bug fixes, requiring limited client interaction. They're typically quick to complete. Client interaction is usually minimal since the modifications are clear-cut and often driven by technical needs.
• Medium – More complex than small projects, these involve creating standalone solutions or integrations, often with a single data source. Examples include simpler mobile apps or web interfaces. These projects will likely involve regular client interaction for meetings, design reviews, and sprint planning, leading to a longer completion time than small projects.
• Large – These are large-scale projects requiring multiple system integrations and security features. They consider future growth and maintenance, needing consistent client interactions like extended design sessions and regular milestone meetings.
• Enterprise –Enterprise projects are typically mission-critical systems built on a comprehensive framework with strict security, logging, and error handling measures. These demand thorough integration of IT and client teams and may involve cross-functional collaboration with various stakeholders. Time demands may include lengthy design sessions, reaching consensus on milestones with various teams, and regular check-ins. In addition, there's the need for standing meetings with key stakeholders.
  
  

3. Development Team Size:

The resources and roles allocated to a project may determine how fast you're able to bring the project to fruition. Depending on the team members and the hours they can allocate to the build, the project team may be able to work more efficiently. Being clear upfront on the resources and the hours they will dedicate to the project will allow you to more accurately forecast the timing needed to bring the project to completion. 

Once you're clear on these factors, you should be able to more accurately scope the project.

When developing software, embrace an Agile methodology 

You've probably heard the word "agile" thrown around. In software, an agile methodology approach involves rapidly prototyping and testing features in shorter, iterative phases to ensure a feature works. If the feature doesn't work, this allows the team to fix it, pivot, and find a new approach.

This process creates a constant feedback loop from users and to make changes that iteratively improve their service or product. With an agile approach, software development has room for experimentation — and bugs or issues are found immediately, rather than at a distant launch date.

An agile scope management plan should still document the anticipated scope, but in smaller stages called releases. These releases are split into smaller time-boxes, known as iterations, or sprints. To ensure that the backlog remains relevant and prioritized, a practice known as backlog grooming (or backlog refinement) is used. This is a regular session where the product owner and development team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery. In other words, it's a necessary measure to keep everything on track. This will allow you to plan for the features and tests the team anticipates running, while leaving a buffer for potential redirections.

Software projects can feel impossible to scope — but with an agile methodology, you'll be able to account for shifts from the get-go, setting your teams up for success.

The way we create software has modernized — the way we scope projects needs to be, too. If you have questions on how to start following an agile methodology for your software projects, get in touch.