How To Scope Software Projects

This post originally appeared on the blog at neo.com.

Scoping software projects is always tricky. It’s relatively easy to put together a comprehensive feature list, but it’s maddeningly difficult to know in advance how much time and effort it will take to design and build a system that includes every feature in that list. People frequently ask us about this, so I thought I’d take a few minutes to share our approach.

One reason that software estimation is so difficult is that a simple line-item in a list of features can mean many things to different readers. As a result of this, once design and development begin, stakeholders are often surprised to see these differences in expectations revealed and frequently request changes and revisions. This adds unexpected time and effort to the project—time and effort not accounted for in the original estimate.

Another more significant reason that scope is so difficult to manage is this: at the end of the day, we don’t want our systems to deliver a list of features—we want them to create successful outcomes for our users, our customers, and our organizations. It is often the case that as we begin designing and building features, we discover that the features we had planned do not create the outcomes we seek. In this situation, project teams are faced with a difficult choice: do we keep working on a pre-negotiated feature list, or do we change our plans in response to what we’re learning?

Neo (and many other consulting firms that use Agile Project Methodologies) handles this by avoiding fixed-scope projects. Instead, we construct our projects to deliver outcomes, not features. We do this by maximizing our ability to learn as we go, and to respond and change based on what we’re learning. Our focus on learning-as-we-go means that we build primary research with customers (sometimes called “customer development”) into each phase of work.

Here is how we prefer to handle scope definition and management:

  • We like to start engagements with a validation phase in which we explore a few different high-level directions to achieve our desired outcomes. This phase is intensely learning-focused. What is the business problem? What is the customer problem? Is there really value in solving it? What is the right solution to that problem? Depending on what we discover, we’ll pick a direction, and this will have huge influence on the final feature set.
  • Once the direction is set, we’ll start the development process with a multi-day workshop that we call an “inception.” This is when we work together to define the feature set we want in the product.
  • Once that feature set is declared, we have what we call a “backlog”–simply put, it’s a list of features we think that we’ll need. We prioritize and estimate items in the backlog to get an initial sense of how much work we’re facing.
  • Only then do we begin making software, and over the first few weeks, we begin to get a sense of our rate of progress. It’s at this point that we really start to understand how much work we’ll be able to get done.
  • As soon as we’re able (while we’re building, usually within a few weeks) we are pushing our features live (to preview/test users, or real users) to see if the features are effective—do they achieve the outcomes we seek? Based on what we learn, we adjust our backlog—revising features, adding them, removing them, changing their priority, improving what we’ve already released.
  • This feedback process is critical! Because we get immediate feedback on whether or not the work we’re doing is valuable, we can manage the project in a way that focuses on delivering value, not just a feature list. But this feedback and adjustment process makes fixed-scope contracts difficult–because we can’t really know at the start of the project exactly where we will end up. And admittedly, this is a risk that many organizations find uncomfortable.
  • We help organizations manage this by giving our clients full control of project priorities on an ongoing basis. (If you’re an in-house team, think product-owner and stakeholders here.) We start each day with a collaborative priority review, and each week hold a collaborative review of progress, feedback, and prioritization. Stakeholders move from managing scope to managing priorities, always with an eye on the key question: is the product that we’re creating delivering the value we expect?
  • Finally, we don’t tie payment to scope. Instead, we structure all of our agreements on a time-and-material basis. In other words, we quote a weekly rate, we don’t exceed that rate, and then we work at that rate for as long as necessary. And while we plan our engagements to last a specific amount of time, our clients can elect to stop at any time they like. So, in addition to having full visibility into the value being created, they maintain a hand on the budget lever the entire time.

We’ve found that this process works well for us–as long as we’re keeping the project honest by building real market feedback into the work at every stage. What have you found that works for you? Let us know on twitter @neoinnovate.

Leave a Reply

Required fields are marked *.