Identifying goals

Our stakeholders will have their own goals and objectives for using or sponsoring the system we are building. Understanding these goals is critical to the successful elicitation, analysis, and modeling of requirements. Stakeholder goals usually fall within two categories, depending on whether the stakeholder is a non-acting stakeholder or an actor. Actors have goals related to the domain in which they operate, for example, retail, education, and banking. Non-acting stakeholders are usually our system's business sponsors, such as directors and executives. As such, their goals are business-related; they mainly sponsor our system because they want to expand or protect their business. Let's look at domain goals first.

Domain goals

Domain goals drive our system actors to use our system in order to increase their value within their domain. For instance, if we're building a learning management system, many of its users would be aspiring to use our system to increase their knowledge or skills. If we're building a marketplace system, most of our users would want to either make money by selling items or to acquire needed items by buying them.

Here are some examples of domain goals:

• A student wants to get their coursework assessed by a teacher.
• A teacher wants to pass their knowledge on to a student.
• A teacher wants to ascertain whether the student has gained adequate knowledge.
• A seller wants to make a profit on an item they sell.
• A seller wants to get rid of an unwanted item.

As observed in these examples, an actor may have multiple domain goals. In addition, value may be added to multiple actors via the same goals. For instance, a teacher ascertaining whether the student has gained adequate knowledge benefits both the teacher and the student.

We will be exploring techniques for discovering domain goals in Chapter 5, Discovering Requirements. One thing to keep in mind, however, is that domain goals must always be aligned with business goals. We do not want to allow certain actors to achieve goals that could be detrimental to our business. With that in mind, let's take a closer look at business goals.

Business goals

These are goals that are mainly set by non-acting stakeholders, such as directors, VPs, and senior managers. These people are usually our executive sponsors, meaning that they may approve or support the allocation of resources and they may also champion the project to other members of senior management within the business. They do all that because they have specific goals that they want to accomplish through the adoption and use of our system. As system builders, analyzing these goals and their impact on our system is a crucial step towards defining their requirements.

A business goal's motivation and expected outcome should ultimately fall under one of these categories (see Further reading):

• Increasing revenue
• Reducing costs
• Protecting revenue
• Avoiding future costs

Any successful business must always be aiming towards generating enough revenue to realize its purpose. Even charities and non-profit organizations must be able to generate adequate revenue if they are to fruitfully continue their charitable or societal work.

A useful technique for determining a business goal's motivation is the five whys technique (see Further reading). If after the five questions the answer is not one of the preceding bullet points, then you should seriously question the value that a goal adds to the business. This helps to avoid and filter out vanity and pet goals, which can derail and jeopardize the project.

Consider the following business goals, where the goal's incentive can be easily discerned using the five whys:

Goal 1: We need to automate user maintenance tasks, such as password resets and account upgrades.

• Why? So that system users do not have to call the system administrator for routine maintenance.
• Why? So that administrators do not spend time resetting passwords and upgrading accounts.
• Why? So that administrators can spend more time monitoring the system and fixing bugs.
• Why? So that the system becomes more stable and performant.
• Why? So that we gain more users (increase revenue) and have fewer users leaving us (protect revenue).

Goal 2: I want to reward loyal customers.

• Why? So that returning customers can feel valued and also save some money.
• Why? So that customers keep returning more often.
• Why? So that they spend more money on our products (increase revenue).

Goal 3: We want to receive employee feedback.

• Why? So that the business can see what we do well and what we do badly.
• Why? So that the business can fix the bad things and keep doing the good ones.
• Why? So that our employees are happy working for the business.
• Why? So that our employees are productive and won't leave the company (avoid future costs).

Good business goals add value for stakeholders by specifying goals tangential or extrinsic to the system's inherent abilities and functionality. For instance, I want customers to buy books is not a valid goal for an online bookstore. For a bookstore, customers buying books is an intrinsic and implied goal. I want customers to buy more books from us than competitor X is better, though it still lacks a strategic aspect. With that in mind, let's take a look at strategic goals.

Strategic goals are the best goals

The best business goals are the ones that are not too abstract, nor too specific; the ones that outline strategy but not tactics. For instance, the goal Reward loyal customers can be framed as Increase sales by rewarding loyal customers. Increase sales is the end goal and rewarding loyal customers is the strategy. If the goal was simply Increase sales or reduce costs then it would ultimately fall to whoever happened to try and accomplish that goal, a business analyst or – shock, horror – a software developer to determine what the best strategy would be. The best people to define the strategy behind the goals are the non-acting stakeholders: the directors, business owners, and senior managers.

On the flipside, should the goal become something like Increase sales by rewarding loyal customers by giving them free gift bags if they spend over $500 in a single transaction, then we are mixing strategy with tactics. This can be a bad thing, as creating tactics requires a level of specific domain, system, and architectural knowledge that is usually lacking in non-acting stakeholders (and I'm saying this in the most respectful way). For example, the director or sales manager specifying the free gift bag ploy may not be aware of any logistics or distribution problems in delivering that many gift bags. Tactics are better developed by a more diverse stakeholder participation and should be captured separately as system capabilities. We will see exactly how to do this in Chapter 2, Impact Mapping and Behavior-Driven Development.

To put this in a military context (since it serves as a good analogy), formulating strategy is the job of the Field Marshals and Joint Chiefs of Staff. They can see the big picture and can come up with plans on how to win the war or the campaign. They create the strategy. Winning battles, on the other hand, is the job of Captains, Platoon Leaders, and other ground commanders. It is unlikely that a Field Marshal will know the specific strengths and capacity of specific platoons or have detailed knowledge of the terrain where a particular battle is to be fought, so as to create the best tactics to win the battle. These are best left to the people who have the most knowledge of such things. In a business domain, the Field Marshals are the senior business people who understand what they need to do to push the business forward. The Captains and Platoon Leaders are the project managers, architects, business analysts, and software engineers who know what to do in order to realize the Field Marshal's strategy.

Case study on lack of strategy

This business goal has a valid and obvious incentive, which is to increase revenue by increasing service contract sales.

Stated goal: We need to increase service contract sales.

So far so good. However, it doesn't outline a strategy for increasing service contract sales. A potential way of achieving that would be to offer the product at a discounted price if the customer also buys a service contract. Another way would be to offer customers a financial rebate if they don't raise any incidents by the end of the service contract. I am sure you can think of many other ways too. So, let's re-write the business goal with that in mind:

Offer financial incentives to customers buying service contracts.

That's better! We outlined the strategy (offer financial incentives) and we left it to the analysts, business managers, and engineers to come up with some tactics for our strategy, such as discounting product prices or offering money rebates. In the requirements domain models, we represent tactics as capabilities, and we will be examining these in detail in Chapter 2, Impact Mapping and Behavior-Driven Development.

Case study on specifying tactics within the goal

In this case, this business goal is about increasing revenue, which is good, but it also dictates a very specific way to achieve it.

Stated goal: Reduce product price by 20% if customer buys a service contract.

The trouble with this is that it constrains and limits our options in discovering any other ways to increase service contract sales. There could be more, and possibly better, ways of selling more service contracts (actually, I am certain there are). However, by sticking with this business goal we will never find out! So, let's re-write this business goal as follows:

Offer financial incentives to customers buying service contracts

This gives us the opportunity to investigate and discover all possible financial incentives we could offer in order to increase service contract sales.

The SMART trap

It is sometimes suggested that business goals follow the SMART criteria:

• Specific: Target a specific area for improvement.
• Measurable: Quantify or at least suggest an indicator of progress.
• Achievable: Ensure goal is attainable and within reach.
• Realistic: State what results can realistically be achieved, given available resources.
• Time-related: Specify when the results can be achieved.

I find strict adherence to all these criteria to be dangerous, as often the Measurable and Time-bound or Time-related criteria are too difficult to pin down in any meaningful way, especially at the beginning of a project. Even more importantly, the Measurable and Time-bound criteria can quickly turn into self-fulfilling prophecies, blinkering your organization and turning it into a quantity-driven, rather than quality-driven, business. Unfortunately, some people are unable to manage things they can't measure so they compensate by imposing artificial deadlines and random outputs. This is the kind of thinking that kills projects, as people focus on the numbers instead of the things that really matter, such as the product quality, the actual business strategy, and its clients' needs.

Eric Ries (refer to Further reading) calls out vanity metrics as non-actionable metrics that make some stakeholders feel good about themselves but do not offer any valuable insight or value. Imagine if one of our stakeholders wanted to increase sales by 50% in the next quarter. In this case, we go ahead and implement product features that cause sales to increase by 43%. Technically, we failed. In reality, though, we were a huge success. We added system functionality that caused many more people to buy our product. What if we did not hit the 50% target? Let's face it, the only reason that number existed is that increase sales by 50% looks much better on someone's resume than increase sales by 43%. It would have been much more effective if the goal was set along the lines of Get more people to buy our product by making it easier/faster/prettier. That would have triggered a quality-driven effort for product improvement, rather than just doing what it takes to meet an arbitrary quantity.

Case study on less time on support calls

A well-known computer manufacturer, very popular in the late 1990s, set a customer service business goal to reduce customer response time by 50%. In other words, they wanted their support staff to be able to close a call twice as quickly as before. The support staff reached this goal by speaking very quickly, and sometimes rudely, to their customers, not performing full diagnostics, and even hanging up on callers! The goal was achieved but a large number of consumers stopped buying computers from that company. By focusing on quantitative targets, the company degraded the quality of their service.

Case study on reducing cost, whatever the cost

A company I once worked for set a rather arbitrary but measurable and time-bound goal to reduce software department costs by a certain amount in the next year. When, towards the end of the year, costs had not been reduced by the desired amount, the directors decided to reach their goal by firing their most experienced and skilled engineers. When a new, big, and profitable project arrived some time later, the company didn't have the right staff to deliver the project. The cost-cutting target had been met but the company eventually went under. Being fixated on the metrics of their goal caused the company to make some bad strategic decisions.

Perhaps this was what famous engineer, statistician, professor, and management consultant W. Edwards Deming meant when he said this:

People fixated on meeting their targets will usually do so, even if it means destroying the company.

So, don't get obsessed with SMART goals. Instead, treat strategic business goals with valid motivations as good business goals.

Tip

Business goals are validated by ensuring they have the proper financial motivation and that they prescribe a strategy. Business goals that do neither should have their validity questioned.

A good way to understand the relationship between goals, requirements, and specifications is to think about undertaking a gastronomic expedition to a new city. Let's do that next.