Determining a project's scope can be a challenging task. There are often many business needs, sometimes conflicting, that pull a project in different directions. Occasionally there may be different groups within an organization that all need different goals achieved. And typically, you're expected to achieve them all on a single fixed budget.
Issues like these can present us with some interesting challenges. Occasionally I'm asked how we manage to identify and resolve these multiple, often conflicting requests. The following is a short summary of key points I like to keep in mind when attempting to answer these questions.
Explore scope definitions as thoroughly as possible.
Project descriptions are initially pretty simple. It's common to see a request that sounds simple at face value, however, once we start investigating the requests in detail, we usually stumble upon some level of complication or unknowns.
As a hypothetical example, suppose a online retailer wants to take invoice data from their front-end website and push it into their accounting software. On the surface, this sounds like a simple request. 'Take this invoice from our website, put it into our bookkeeping program.'
However, even a cursory exploration will expose some major needs that might presently be unnoticed.
For instance, how are invoices handled? Are they all treated similarly, or are there unique circumstances for different types of invoices? How many different workflows are needed for these unique types and what are the differing steps between each? Do these paths cover all edge cases?
Challenge and expand any assumptions, especially hidden ones.
Additionally, descriptions like these often include assumptions that may not necessarily hold true for the lifetime of the project. Assumptions, particularly implicit assumptions, should be identified and scrutinized. There's nothing inherently wrong with them directly -- but ensuring they are shared and communicated among the team helps reduce risk and promote accuracy in estimating.
In our example, there is an implicit assumption about the difficulty of working with the storefront and the accounting packages. Is there an easily-used quickly-learned, open developer-friendly API for access? Are their restrictions around the API access? (In our hypothetical example, the accounting software allows write-only access, which means we can't make modifications to data we've previously moved).
Even the challenges and assumptions exposed through this investigation can lead to further challenges. For instance, knowing the API only allows write-only access will likely reshape the design of the application and it's process. It means there needs to be extra thought and concern placed around handling invoices. When are these invoices closed? What if an invoice payment fails? What if payment is remitted later on? What if a payment succeeds on an invoice, but the product is later returned or the charge needs to be refunded?
Investigating these needs offers an easy method by which we can communicate with stakeholders the scope of a project or the complexity it involves. The communication that occurs around these needs often builds trust and respect between involved parties.
Ruthlessly cut as much as possible to still solve the problem.
After following this line of thinking, the project likely feels exceptionally larger than before, often anywhere from two to twenty times larger. That's usually a good sign for project planning, it often means you've thought through a lot of the potential areas where complication can occur.
But it's typically terrible for your budget. Someone is likely getting very nervous about the extra cost and scope. Now is a great time to cut down scope, and there are a number of ways to do this. Going back to our hypothetical online retailer, let's look for some potential avenues to reduce cost and time without compromising the stability, reliability, or quality of the project.
In our earlier discussion, we learned that there was a tricky API for the accounting package. Perhaps we can avoid a lot of this complexity by integrating with a different accounting platform.
Additionally, we identified that there were many different workflows a single invoice might move through, depending on its content. We could measure the rates of these invoices. Perhaps we cover just one or two of the most common paths, and leave the rest to be manually invoiced as before. We've eliminated 90% of the manual work, while keeping the project costs as low as possible, promoting the best results for the least investment.
Sometimes we'll get lucky, and lower scope can happen with little to no drawbacks. But most of these cuts will involve some sort of cost vs benefit tradeoff. Getting stakeholders involved along in the project can help sort through these decisions.
Involve the best data available, and interpret it carefully.
But getting folks involved isn't enough. We talked about assumptions and implicit assumptions previously on the scope side. But that also comes into play in these decisions. Often, assumptions will be introduced on the tradeoff or result discussions around a project too.
You may hear statements like, "if we make [tradeoff X] we'll get [result Y]". These should be identified right away as assumptions, and validated.
Note that assumptions aren't inherently wrong. In fact, they could be entirely accurate. But don't let that prevent you from validating them anyway. If they aren't, a false sense of accuracy could be introduced in discussions that causes problems later on. Just because some assumptions are accurate, doesn't mean they all will be, and only by being vigilant on validating all of them, can you prevent those from sneaking in.
There's a number of ways to go about validating assumptions -- to many to list here. But one of the many approaches I'm fond of is developing prototypes or "minimum viable products". This is similar to the strategy that Eric Ries writes about in his book The Lean Startup. While intended for businesses running products, a similar experimental and user-focused methodology can be applied to projects with similar beneficial results.
Incorporating scope investigation into agile workflows
Reading this might sound a lot like a step backwards. Individuals with a waterfall background might read this and interpret this as a regression in workflow. "Isn't this basically 'big design up front' in a project roadmap form?" And it's true, this could be applied in that manner.
But it doesn't need to be. Everything in this line of thinking can be successfully applied in an agile workflow. In fact, this approach often encourages agile thinking more than might otherwise occur naturally within the team.
Identifying assumptions and challenging scope forces the project and the team involved to collaborate with the customer, and be adapt at responding to changes. It also requires interactions between individuals (as there's no other way these changes can occur). It also helps ensure that a project don't simply create working software, but the right software, and the right amount of software.
This is a method I often follow for working with clients who are starting out on a project. But it's just one of many ways to successfully identify needs and promote good results. While the methods may vary, the time and energy spent in solving these problems can reduce stress and pays off well in over the lifetime of the project.