Monday, 17 October 2016 16:05

Just Because You Can Satisfy a Need, Doesn’t Mean You Should

Written by

I described how to discuss the problem statement to reach a shared understanding about the need you are trying to satisfy with a project.

The natural follow on to that discussion is to ask the hard question – “Is it worth it?” In other words, is that need worth satisfying at all, or is there a solution that will allow us to satisfy the need effectively.

While that seems like an easy question, it’s one that doesn’t get asked as often as it should and when it does it isn’t always answered honestly. I’ve found a couple of approaches to ask and answer that question in an effective manner.

Use Strategy as a Filter, Not a Bucket

Todd Little poses the question "is your strategy a bucket or a filter"? Let’s dive into that a little more to understand what he means.

Let’s take a financial services organization that publishes their six "priorities" on their website:

  • Putting customers first
  • Growing revenue
  • Managing expenses
  • Living our vision and values
  • Connecting with communities and stakeholders
  • Managing risk

If this organization treats their strategy as a bucket, their portfolio management approach asks someone championing a new project (i.e., the sponsor) to describe how that project supports one or more of those priorities in order to be considered “strategic” and improve the chances of it being approved. The priorities may even be listed on the project initiation document template, encouraging sponsors to craft a story to force fit the project under one or more priorities. At this point strategy does not aid in decision making because depending on how good sponsors are at crafting stories, all projects could be positioned as strategic and the people responsible for making decisions about a project are left with no discerning information.

If, however, the organization used strategy as a filter, the questions asked about a project’s relation to the priorities are different. Instead of asking “does project A fit into the strategy (fit the priorities), the organization asks whether project A fits the priorities better than project B or other options. The strategy is used as a way of determining which projects are a better fit and should move forward. The other projects aren’t necessarily bad ideas, they just aren’t as strategic and therefore should not be done now in preference to others.

I like to take things even further to use strategy as an explicit filter. In this example, the organization would reduce the number of priorities, down to only 1 - 3. Then these “priorities” could be turned into decision filters expressed in the form of a question: “will this help us do X?” Each project would then be assessed by those decision filters. Projects where the sponsor can answer “yes” to that question would continue. Projects where the sponsor can’t answer yes to all the decision filters are stopped or are changed in a way that they can pass through the filter.

Using strategy as a filter aids in decision-making and provides coherent focus, which is what strategy is intended for. You can use it to clearly state what you will not do, which Michael Porter called the essence of strategy.

Define Success In a Measurable Fashion

The second way to effectively discuss whether something "is worth it" is to understand what you mean when you ask that question. That means establishing clear objectives that you can use to measure success. You want to measure success in terms of the need satisfied (i.e. the outcome) instead of based on a specific solution (the output). This allows your organization first to determine if the need is worth satisfying at all, and if necessary, assess different solutions to determine which one is the most effective in satisfying the need. You may even find that even though the need is worth satisfying, the cost of delivering any of the solutions outweigh the benefit gained from satisfying the need.

To help reinforce the characteristics of good objectives, Tom Gilb in Competitive Engineering suggests a set of attributes which you can identify for each objective. Below are those attributes with an example from a website looking to increase the number of subscribers to its newsletter.

Attribute Description Example
Name Unique name for the objective Increase the number of subscribers per month within 6 months.

What to measure
(Gilb refers to this as scale)

The change in subscribers to the newsletter in a calendar month average
Method How to measure
(Gilb refers to this as meter)
Subtract the number of subscribers at the end of the previous month from the number of subscribers at the end of the current month. Average those changes over the months being measured.
Target Success level you’re aiming to achieve Average increase of 25 subscribers/month
Constraint Failure level you’re aiming to avoid Average increase of 10 subscribers/month
Baseline Current performance level Average increase of 10 subscribers/month

A benefit that comes out of setting these attributes is the discussion that occurs in order to decide what the target and constraint should be, as it allows the team to get a clearer understanding of what success looks like.

Understanding the need first and being able to describe it via objectives gives you the opportunity to ask the question “Is this need worth satisfying?” So in the example above, the team can ask:

  • Is it worth it to increase the number of subscribers we add per month?
  • Do we need to do things to just increase the number of new subscribers, or do we also need to worry about retention of existing subscribers?
  • What is too much to spend trying to accomplish this?
  • What are we forgoing by increasing the number of subscribers?

When setting objectives, be very careful about unintended consequences. The discussion above focuses on using objectives for the purpose of making decisions about projects and/or products and can drive behaviors in the teams working on those projects. This is especially the case if those objectives are also used for the purposes of performance reviews. The financial services company referenced above faces a significant scandal dealing with employees creating fake accounts in order to meet the sales objectives they were measured by. This is a dysfunctional use of objectives if there ever was one and something you need to watch out for.

So How do you go about doing this?

In the article that started this series, I acknowledged that the lack of clear decisions about what not to do reaches up to decision makers in the organization. I also suggested that business analysts can play a critical part in getting those decisions to happen. The practices I suggested above are great ways to get the conversation started about whether a project is worth it, both when it is starting and after it is already underway. It’s important to ask probing questions, and you want to make sure that you are probing in the right places, and in the right manner.

I have found it helpful to have conversations with the broader team to understand what decision filters the team should be using and what objectives you should use to measure success. Then, if you realize that the project you are considering does not seem to pass those filters, or to meet those objectives, have private conversations with the project sponsor about your concerns. It’s generally not a good idea to call them out in front of the whole team, especially if you want to maintain an ongoing working relationship with that sponsor. You may find you may need some help with someone that has a good relationship with the sponsor either by coaching you through the discussion ahead of time or joining you in the conversation. You need to ask those questions; just consider how you go about asking them.

Have you had the opportunity to question whether a need was worth satisfying? I’d love to hear about your experience in the comments.

Kent McDonald

Kent J. McDonald helps teams discover the right thing to deliver. His more than 20 years of experience include work in business analysis, strategic planning, project management, and product development in a variety of industries including financial services, health insurance, nonprofit, and automotive. He shares resources for effective business analysis and product ownership in IT at and practices those ideas as Product Owner for the Agile Alliance.

Kent is author of Beyond Requirements: Analysis with an Agile Mindset and co-author of Stand Back and Deliver: Accelerating Business Agility.

© BA 2020

macgregor logo white web