Ask a Business Analyst what comes before defining project scope, and they’ll hopefully say understanding the product roadmap.

THE need TO UNDERSTAND THE PRODUCT ROADMAP

Every project (or greenfield product development) begins with what has to be developed. While this would seem as a great starting point, it always helps to take a step back, and ask these questions:

  • What is the long term vision of this product?
  • What is the product roadmap?
  • How will it be monetized?
  • What are the pain areas you are addressing with this software?

(Source: Goal.com – Is that in or out)

These questions are but a starting point. It helps business analysts, project leads, among others better understand the intentions behind developing the project. Such questions also help teams evaluate other perspectives and options – ultimately leading to options that might make for better alternatives in the future. More importantly, it helps make it easier to define the project scope.

WHY IT HELPS WHEN DEFINING PROJECT SCOPE

When I was working as a Business Analyst, I would always have a detailed conversation with our clients about the business context of their product. It helped drive conversations, while increasing our understanding about:

  • the extent of the project or product to be developed
  • what parts of the project to chalk out as deliverables

With this understanding, we would be able to prepare better requirements, milestones/products, functional architectures and ultimately in defining project scope.

AN EXAMPLE OF DEFINING PROJECT SCOPE

When working with a client on their ad server, we came to an inflection point. As a greenfield project, it became very important for us to define what each milestone was – each milestone was linked to a tangible revenue opportunity. With pressures on time and making the duration between milestones smaller, we worked on a reduced scoping that allowed faster turnaround on development, but didn’t compromise on the functionality provided. Sure, some amount of manual intervention was required, but that didn’t stop the client from running campaigns or generating revenue.


The defining of scopes, however, is not limited only to the project. It is also very much required in the product context. But, more on project scope vs product scope in the next post.