8 DECOMPOSING GOALS

This chapter covers the following topics:

the relevance of goal-based analysis;

goal and functional decomposition;

understanding goal levels;

using goals to achieve business agility;

using goals to define iterations and releases.

INTRODUCTION

Agile business analysts need to apply goal decomposition to ensure that the focus of an agile change project is on the delivery of business goals. The ability to understand business goals and then separate them into things that can be logically achieved by the business is necessary for any business to thrive. Achieving this, however, can be problematic as large goals often get divided into functional areas of the business and the original goal can become confused or lost. In this chapter, we discuss how to break down goals so that smaller goals can be achieved earlier, without losing sight of the bigger goal. Decomposing goals in this way is critical to the success of agile change projects because the success of change can only be determined by the value received by the customer. The only way of achieving earlier success is therefore by understanding and delivering smaller goals.

THE RELEVANCE OF GOAL-BASED ANALYSIS

Goal-based analysis is a logical mechanism for breaking down and orgnising business goals. All organisations have goals but we tend to call them business objectives or strategic outcomes. In simple terms, a goal is something that the organisation or business wants to achieve, such as ‘increase sales by 5 per cent within the next 12 months’. We analyse goals because it helps us to keep the focus on what the business is trying to achieve strategically. Goal-based analysis has been discussed in the context of requirements for some time. The easiest way to understand a goal-based structure is to look at a high-level business process for an organisation.

 

Figure 8.1 Organisational chart showing a high-level business process

images

It is clear to see that the organisation is split into functional areas represented by the vertical boxes shown in Figure 8.1. While all of the functional areas are valuable, they need to operate and work together to achieve any outcomes for the business. If each functional area were given the individual goal to ‘increase the size of their function by 5 per cent within the next 12 months’, this may not result in the organisation achieving the overall goal of ‘increasing sales by 5 per cent within the next 12 months’. Each function cannot deliver an overall business outcome on its own.

The business process, which runs horizontally, shows how an end-to-end business process utilises all of the functional areas of the business required to deliver a defined outcome. So, if the goal of this business is to increase sales by 5 per cent, it is the functional areas conducting their parts of the business process that will achieve this goal. In this example, the business process represents the work to achieve this high-level goal. At an enterprise level, these processes are often called value streams and represent the value that the business offers through delivering its products or services. This is discussed in more detail in Chapter 6.

Decomposition is the process of breaking down complex entities into smaller parts. Breaking things down in this way helps us to analyse the individual components, as they become easier to understand. Business analysts are well versed in decomposition and things that are commonly decomposed include:

requirements: overview to detailed requirements;

processes: organisation to business process to task and to step level;

work breakdown structures: elicit, analyse, document, validate requirements;

goals: strategic goals, business goals, project goals.

It is important to maintain a view of the higher-level goal when we are decomposing this into lower levels. This helps to ensure that we have actually achieved the overall goal.

GOAL AND FUNCTIONAL DECOMPOSITION

It is human nature to want to break a problem down into its constituent areas, such as process steps or functionality, to make it easier to conceive and understand. Each process step or functional area is only an element of a decomposed goal and the goal cannot be achieved until all steps or functionality have been delivered. This makes it harder to deliver value earlier, as the smaller goals are divided amongst the process steps or functional areas of a business. When decomposing goals we need to maintain the focus on the following:

breaking down the goal into smaller goals;

keeping sight of the value expectation of the customer;

ensuring that a process is not decomposed.

When we decompose a process or function it is called functional decomposition. Functional decomposition is useful if you want to understand how to do something and it assumes that ‘what is being done’ and ‘why it is done’ are understood. Given this, it is also assumed that there is a high-level context that is unlikely to change. Each decomposed element of a function will be performed according to defined steps and business rules, which functional decomposition allows us to focus on investigating and understanding. When a function is decomposed, the sub-function does not focus on the achievement of a business goal but on completing a piece of work that contributes to the overall work of the function.

Goal decomposition

Let’s consider an example scenario.

Ben and Jasmine have aspirations to run their own profitable business. The business they have chosen is a café. Opening and running a profitable café is their ultimate goal.

If we assume that the ultimate goal is correct, and won’t change, and that opening a café is the only goal they are focusing on, we could decompose the goal into the functions shown in Figure 8.2.

 

Figure 8.2 Functional decomposition of the goal, ‘Open a café’

images

Figure 8.2 shows the results of functional decomposition. While this is not an exhaustive list of functions it provides some key functions that Ben and Jasmine will need to carry out.

Although Ben and Jasmine have aspirations to open and run a profitable café, they have neither run their own business before nor worked in a café. Therefore, there are things they need to learn. They are concerned about the location of the café and are not sure it has enough passing trade. Also, they know what drinks and food they like to eat in a café, and how much they are willing to pay, but they are not sure who their customers will be and whether their customers will want to eat and drink the same things that they do. As a result, they are unsure whether their ultimate goal is achievable. To address this issue, they have decided to try out some ideas before committing too much money, time and resources to a business that might not be successful.

The functions identified in Figure 8.2 are focused on achieving the original goal, which would require them to give up their day jobs and invest all their time and money into setting up a café that may never be profitable.

This seems too risky to Ben and Jasmine, so they have sought advice. They have been advised to start smaller, to test the market and to incrementally grow their business. This way, if it doesn’t work they haven’t invested all their time and money and, if things don’t work out first time, they can learn lessons from the experience and adapt their approach. To do this they have decided to identify smaller goals that can help to lead them to their ultimate goal.

Their goal of ‘Opening a profitable café’ has been decomposed into smaller goals as shown in Figure 8.3.

 

Figure 8.3 Goal decomposition of the goal, ‘Open a café’

images

Now they can focus on achieving just one goal, such as ‘serve hot drinks’. This can be further decomposed as shown in Figure 8.4.

 

Figure 8.4 Decomposed goals for the ‘Serve hot drinks’ goal

images

Decomposing goals in this way allows choices to be made about which goal, or goals, to do first. Each goal contributes to achieving the higher-level goal. For example, ‘serve tea with a tea bag’ or ‘serve filter coffee’ are both ways of serving hot drinks. This demonstrates how a high-level goal can be decomposed into smaller or mini goals, each of which will offer potential value to the customer. In each of these cases, customers will be served a hot drink.

Using a goal decomposition approach, it is straightforward to prioritise the decomposed goals and provide a means of delivering the product in one initial increment and subsequent increments. In this scenario, we may want to serve three types of hot drink from the outset or alternatively we may want to focus solely on serving good quality coffee, leaving the other options to be added later. The initial investment and effort to be made is dependent on the goal(s) agreed and how well they are achieved initially. It could be that a stand serving tea with tea bags and instant coffee, using hot water from flasks, is all that is required in the first increment. This will provide essential management information such as whether there will be enough passing trade, if customers are requesting ‘good’ coffee, the variety of drinks customers request and whether it is worth investing further in the business. Prioritising the decomposed goals is an effective means of setting up an enterprise that is adaptable to customer needs and can develop as the business grows. Techniques to prioritise goals are described in Chapter 9.

When decomposing goals, the following considerations should be borne in mind:

What value will the actor, or customer, get from this goal?

Is this goal delivering a partial service or product to the customer?

Why do we, or the customer, want to achieve the goal? For what purpose?

Each goal must offer value in its own right.

Functional decomposition

Functional decomposition is a way of breaking down the function or process into small pieces, or chunks, to make it easier to conceive. However, the whole process can only work if all the steps or parts are completed. This means that each task or step does not achieve any goals, and this is only done by combining the functions across the entire process. For example, in Figure 8.2, ‘obtain equipment to make drinks’ is an essential part of making a hot drink, but on its own does not offer any value to the end customer. Only when it is combined with the other functions/tasks will the value of serving a hot drink, such as serving instant coffee, emerge. Also, once there is a clear decomposed goal, the entire sub-function may not be necessary; in this example, a goal of serving tea and instant coffee would require far less equipment than providing a range of specialist filter coffees. Applying a functional decomposition approach can result in increments being developed that do not offer the possibility of deployment, as they do not achieve anything tangible for customers. Therefore, it can preclude agile teams from working effectively, as there is limited focus on achieving relevant goals.

Within organisations there are always limitations on the funds and time available. This inevitably results in there being more work to be done than is possible within these limitations. This is why projects and businesses need to focus on delivering the highest priority aspects first. It may turn out that once we have achieved the initial goals, priorities change and we decide to not try to achieve any more. Alternatively, it could be that achieving the initial goals has been so successful that additional funding is made available for further work. If we had decomposed the ultimate goal of opening and running a profitable café on a functional basis at the outset, we may have a lot of equipment but still be trying to set up and open a café. Decomposing goals provides a route to begin work and to move forward and therefore helps in the achievement of both the ultimate and intermediate goals.

UNDERSTANDING GOAL LEVELS

Understanding the range of goal levels is important. In his book, Writing effective use cases, Alistair Cockburn (2001) introduced ‘goal levels’ as a way of reflecting the different levels at which functional requirements may be expressed. These elements were discussed in Chapter 6. Figure 8.5 describes Cockburn’s levels within the context of understanding goal levels. For simplification, the clam level has been omitted.

When decomposing goals, ensure that the goals stay above the surface and remain visible (i.e. sea level or above). Fish-level goals add no value to the customer. They are essentially sub-tasks that need to be done in order to achieve the goal. Figure 8.6 shows how the, ‘Open a café’ scenario can be broken down through the different Cockburn goal levels.

 

Figure 8.5 Cockburn’s levels of goals

images

 

Figure 8.6 Examples of different goal levels

images

USING GOALS TO ACHIEVE BUSINESS AGILITY

Goal decomposition is extremely helpful when an enterprise is deciding what to do in order to offer value to customers. As discussed earlier, it helps to identify where an organisation should focus its efforts and at what point. However, it is also important to ensure that the decomposed goals are achieved in a way that aligns with the business architecture for the organisation. The business architecture provides a blueprint which defines aspects such as the value streams and capabilities of the organisation, and how these capabilities may be achieved. The POPIT™ model is a useful way of viewing the elements required to build the capabilities within the business architecture.

One approach that may be applied is called ‘modular business architecture’, whereby the business goals are realised through individual ‘components’ or ‘modules’. These components should be self-standing so that they are tightly cohesive (the component has all the functionality to provide the service) and loosely coupled (the component interacts with other self-standing components in order to form desired configurations). These may be software components that communicate via standard interfaces that send and receive messages and data. Alternatively, they may be business components that interact with the rest of the business through interfaces. A typical example of a modular component used by many businesses is the payment management capability offered by organisations such as Worldpay and PayPal. These components offer the delivery of a business goal – enabling customers to make payments securely – and are self-standing. They may also be used as part of several value streams within an organisation, providing a basis for standardisation and reuse.

Organisations can outsource the achievement of goals – such as customer payment – or can build internal business modules that deliver specific goals. These modules can be deployed where necessary across the entire organisation. This is particularly useful when embarking upon business change or business improvement projects. Goal decomposition enables organisations to consider which capabilities are needed to achieve a sub-goal and identify where a modular business architecture can provide a basis for organisational agility.

USING GOALS TO DEFINE ITERATIONS AND RELEASES

Goals are not only useful to break down strategic business objectives or build a modular business architecture, they also help to define the iterations and releases for business change projects. If we understand the goals and sub-goals, we can prioritise them such that the goals to be achieved first are developed and released at an early stage. This may involve working on a particular business use case or epic as described in Chapter 6; these may require the decomposition of business goals (possibly at cloud or kite level), each of which may be delivered by various combinations of the POPIT™ elements. Within software development projects, ‘user stories’ (Chapter 12) define the goals to be achieved and form the basis for deciding the content of an iteration or release. For most software development projects, the sea-level goal is the goal that is agreed at the start of iteration. Each user story defines a goal that should deliver an outcome for the customer or business and should be small enough that it can be completed within an iteration. Iterations are discussed in more detail in Chapter 15.

CONCLUSION

Goal decomposition is a valuable technique that aids the adoption of agile and offers business agility to organisations. It helps projects to deliver working solutions in increments and offer beneficial business outcomes at an early stage. The goal decomposition approach is highly relevant to business analysts, as it ensures a focus on business outcomes. The contrast with functional decomposition highlights how completing a functional task, such as providing part of an IT system, does not necessarily contribute to the achievement of business goals. When decomposing goals, it is important to remember two things:

1. Decompose the goal itself, not the steps needed to achieve the goal

2. Stay at goal level, above the sea where it is visible and not at a sub-goal level.

Agile business analysts need to apply goal decomposition to ensure that the focus of an agile change project is on the delivery of business goals. They should also support the customers in identifying the required business outcomes and the decomposed goals that will contribute to their achievement. Ultimately, business analysts should be concerned that the changes made improve the working lives of their customers and the work conducted within each iteration. The changes deployed in each release and the overall results from the change project should be focused on achieving this.

Goal decomposition is important to the success of delivering small incremental business outcomes that enable business agility. If we fail to decompose the business goals we may run the risk of trying to deliver something too big, or too risky, which can consume more time and money than we have. Breaking down goals and only achieving small goals allows learning to take place and provides time to adapt on the basis of this learning.

It is important that agile business analysts focus on delivering outcomes that are of value to the business. After all, if the goal is to drink a cup of tea and all we have is a cup and a tea bag with no milk or hot water, it would be impossible to claim that the goal has been achieved and something valuable has been accomplished.

REFERENCE

Cockburn, A. (2001) Writing effective use cases. Boston, MA: Addison Wesley.

FURTHER READING

Paul, D., Cadle, J. and Yeates, D. (2014) Business analysis: 3rd edition. Swindon: BCS.

Cadle, J. (ed.) (2014) Developing information systems. Swindon: BCS

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset