Defining Scope

Knowing the scope of the product or project you want to execute is one of the challenging things most managers face right up front even before any work actually begins. Take this case for example:

1. I want an application that improves my output by 50% that in turn saves $100k.
2. I want an application that integrates seamlessly with all the other tools I use daily.
3. I want an application that moves data among all the applications that I use daily.
4. I want an application that helps me solve world hunger!

If the above needs sound familiar to you, then even before you begin, you are staring at a problem where what really needs to be solved is shadowed by how much is expected to be solved. Do you want to save $100K or do you want to improve efficiency by 50%? Do you really want such superb integration or is it just a “nice to have”? How do you handle data changes if your data moves across so many applications seamlessly? Some questions which take a lot of analysis to answer than to request them upfront.

Defining the scope of a Product/Project is generally overlooked with the good intention of delivering for a client or looking smart by solving a problem. As always, most of the end users are good at pointing to “something” and saying I want “that” in red/blue etc., as opposed to defining what they exactly what. It’s up to the product/delivery manager to identify what is truly needed.

Some of the fundamental questions you can begin asking when facing a problem are:

1. How many of your wants are must have’s vs. could have’s / nice-to have’s. If you cannot populate a matrix equally with these three column’s, then you are overloading your product. There are exceptions to rule’s but generally, this is true.

2. How can you break down your product into phases/releases (at least 2-3) without spending more than 6-8 months on phase 1? The thinking behind this is to allow for resources to leave the team, take a break and also add new talent without breaking the rhythm of the teams.

3. Can you define the scope of your phases/releases and deliver a functional product and not exceed the above set time-frame. [Think Apple iPhone 1 and their ear-phone jack! You really cannot & should not solve all the problems in the first release!]

The challenge in defining scope stems from the facts like:

1. The client wants it all.
2. You cannot visualize an incomplete product.
3. You don’t believe an incomplete product will have adoption.

The first 2 points above can be overcome by good management. The last one takes courage and guts to believe that a good product that solves the basic problem at hand, in the long run, will add value as opposed to an inferior product that solves the problem in its entirety.

Feedback @ravi_kalaga

Similar Posts: