Scope is best defined as the most valuable product/functionality that can be delivered within the constraints of a project or a business. It is not an absolute entity like time or money. It is subject to interpretations, based on our own assumptions.
A common problem that project teams grapple with is when we interpret scope as a number. Teams always identify the set of functionality and come up with their estimates. The release plan and subsequent tracking is all done based on this number. Committing to delivering a certain ‘number’ is not likely to be useful unless all stakeholders understand what ‘value’ that number represents. These five tips will help project and customer teams arrive at a shared understanding of scope, as well as manage scope changes better.
Tip # 1 - Make it visual
A big problem in understanding scope is that while everyone (business, delivery teams) may know what is in scope, nobody really has a clear picture of what is NOT in scope. It is rarely called out. It is usually what customers don't get that makes them sit up and take notice.
The challenge is how to get someone to visualize this.
Every requirement gathering exercise results in process flows, use cases, workflow diagrams, user journeys, feature lists and a broken down list of stories or requirements. The key bit here is how these tie in with each other.
This is where visual representations really help. It takes a lot of effort to put together these visual representations, but the amount of impact they have in helping customer and delivery teams get a holistic view of what is being created, is definitely worth the effort.
Story Maps - One of the most effective ways of tracking and communicating scope changes are story maps. They give a very good visual representation of the feature workflow and corresponding stories or requirements and of the feature completion status (what’s completed, what’s in progress, what’s yet to be done and what is not planned for a given release).
Burn-up charts - Another tool that augments story maps is the burn-up chart that gives a view of the projected timeline and cost to complete the given scope.
Tip # 2 - Communicate planning methodology
This is not directly related to scope management but it is very important to communicate the methodology and assumptions on throughput/velocity that went into project planning, to the customer. Before starting development, the delivery team arrives at the effort estimates and expected throughput. When the team moves into development mode, the actual throughput over the first few weeks will validate the throughput assumptions made during planning and the plan may need to be revised based on the actuals. This is when discussions on scope, time and cost with the customer will start. Educating the customer on assumptions made during planning will make them better prepared to have more meaningful and constructive conversation when such a situation arises.
Tip # 3 - Involve end users during scope definition and development
Delivery teams typically interact with the client product owner to define the scope of a product with very little or no involvement from end users. End users get involved either during user acceptance testing phase when it’s too late or during feature showcases, if you are lucky. Surprise, surprise - quite often, delivery teams realize that end user expectations from the product are quite different from theirs and from those of the client business. This leads to a lot of frustration, last minute scrambling, shortcuts, rework and negotiations before the release, to make the product usable. It helps if the delivery teams, especially the business analysts, work towards getting end users involved as early as possible in the project lifecycle. It also helps to alleviate any threat the client may see from involving end users and reassure them of the time and cost advantages.
Tip # 4 - Put yourself in your client’s shoes
Think from the customer’s perspective while taking minor implementation and functionality decisions with the team. Try this even while suggesting options, alternatives and simpler solutions for feature implementations. This will increase customer’s confidence in your analysis skills, build trust and will have them feeling that their product is in good hands. This will also go a long way in bringing out a high quality product that satisfies both the business and end users alike, with minimum scope churn and timeline slippage. It will pave the way for meaningful and collaborative future conversations on functionality, as well as dialogue-based consultative decisions on scope. Of course, all this requires you to have had the opportunity to spend a good amount of face-time with your client to develop a good understanding of their priorities, concerns and any other aspects which may directly or indirectly impact their decisions.
Tip # 5 - And finally, keep it simple
A good quality for a business analyst to have is the ability to strike a good balance between a working product and a complex product that takes care of all edge case scenarios. In an attempt to build the “perfect” product, analysts sometimes over-engineer the product to handle all possible workflows and scenarios. We have often found it useful to consider the probability of occurrence of a scenario, the criticality of not having a certain functionality, or the impact that a functionality has for the high end user groups before deciding whether it should be handled. This will help bring out a good quality and user-friendly product by making optimum utilization of time and resources.
We hope you find this useful and that it resonates with your idea of how to ease some of the difficulties and avoid common pitfalls while managing scope. We would love to hear from you on other tools and techniques that you used on your projects that made scope management an easy, mutually benefitting and enjoyable exercise for you and for your customer.
This post was co-authored by Mangalam Nandakumar.
